Question-and-Answer Resource for the Building Energy Modeling Community
Get started with the Help page
Ask Your Question

Meter's in EMS sampling as Output Variables, no accumulation within reporting frequency

asked 2022-01-09 21:49:22 -0600

mechyai's avatar

updated 2022-03-15 08:56:43 -0600


I am using EnergyPlus 9.5 as a library with Python EMS 0.2.

I am having a problem where if I have a meter set at a reporting frequency beyond my simulation timestep, say hourly or daily etc., whenever I read the meter during runtime with EMS I am only getting the current timestep's sum for that meter, not the reporting period accumulation.

This was discovered because I have a solar energy generation output variable and hourly meter at 10 min timesteps, and they both return the same timestep data during runtime. Even though, the meter data still outputs hourly cumulative results as expected once the simulation is complete.

Any help with this would be appreciated, thanks!

edit retag flag offensive close merge delete


@mechyai can you include a table or plot of the results to help explain the issue? Also, if the EMS sensor is only getting current timestep data, then you should likely use EMS Trend Variables to sum sensor data over multiple timesteps. You set the number of timesteps to store instead of all timesteps like the Output:Meter:Cumulative object.

Aaron Boranian's avatar Aaron Boranian  ( 2022-01-10 10:33:05 -0600 )edit

I think this is expected behavior. I am pretty sure the cumulative reporting happens only when the simulation completes. As Aaron said, you can store the accumulation with trend variables, or inside your Python code.

bonnema's avatar bonnema  ( 2022-01-16 15:12:44 -0600 )edit

Aaron, the pic is posted below. I don't think I can use trend variables as I am using E+ as a library, but I can just as easily do this with Python as @bonnema suggests.

@bonnema interesting I didn't know that, thank you! That may be worthwhile adding to the Python EMS documentation for meters, I spent a good while trying to figure out what was going wrong, but nothing was it was just working as expected.

mechyai's avatar mechyai  ( 2022-01-16 19:05:07 -0600 )edit

In regards to the doc suggestion; first, I see what you're saying, but in traditional EMS you do not use output variables (or meters) but rather EMS:Sensor objects. In the python plugin implementation in-IDF sensor objects are not required, but the user does have to include the appropriate Output:Variable (or meter) to read data. The data will be at the fidelity of the calling point (e.g. on_begin_timestep_before_predictor(), not what the user chose as the reporting frequency.

bonnema's avatar bonnema  ( 2022-01-17 12:43:00 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2022-01-16 19:06:29 -0600

mechyai's avatar

updated 2022-01-16 19:08:11 -0600

PV Meter vs. PV Variable - sampling the same values each timestep. Meter does not accumulate within its hour sampling period. The answer is that the accumulation of meters (with sampling periods greater than the timestep) happen at the end as a postprocessing step and can not be measured during runtime. Some additional Python code or trend variables can fix this.

Thanks @Aaron Boranian and @bonnema

image description

edit flag offensive delete link more


I would suggest using Output:Variables whenever possible. Output:Meters can give inconsistent results depending on the meter and how data is summed inside E+.

bonnema's avatar bonnema  ( 2022-01-17 12:38:49 -0600 )edit

Could you please briefly introduce how we can accumulate it via Python code?

S.Wang's avatar S.Wang  ( 2022-01-28 10:38:45 -0600 )edit

See example files here. This sums the outdoor dry-bulb temperature for every timestep.

bonnema's avatar bonnema  ( 2022-01-28 11:29:50 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer


Question Tools

1 follower


Asked: 2022-01-09 21:49:22 -0600

Seen: 154 times

Last updated: Jan 16 '22