Meter's in EMS sampling as Output Variables, no accumulation within reporting frequency
Hello,
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!
@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:Cumulativeobject.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.
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.
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.