If you are doing energy metering then I recommend recording the kWh rather than kW and doing it on a periodic schedule to a dedicated database. It makes energy calculations over any time period very easy. Historian is not good for this sort of job.
No, never reset. Use it like your utility company does and just record the kWh reading and t_stamp. Then you can calculate the energy used in any time period by subtracting the first reading from the last.
To generate data for a chart you would need the difference between successive kWh readings.
One other big benefit of this method is that, should the logging fail for a period of time, you can still calculate the average energy use through the data gap. With kW logging you can't.
Because you can never lose any information. With any reset operation, there is always a tiny interval where an increment can be lost.
Also, you don't have to record just at midnight. You can record on the hour, every hour. Or every minute on the minute. Or every five minutes. Whatever granularity you choose, and never losing any information. For any longer period, the energy is simply the first recorded value after the period minus the first recorded value of the period. Trivial in any database.
When recording more often, you minimize the disruption of downtime, as the energy is simply accounted to the next recording, not lost.
For multiple meters I'd recommend a table structure like this:
t_stamp
meterId
kwh_reading
kvar_reading
Everything else can be calculated by SQL or script.
@pturmel, I'm interested in what you'd recommend for t_stamp values. Would you round down to the nearest second or minute to make the queries easier to catch the boundary records?
Shouldn't be necessary when using properly rounded-down timestamp parameters in the WHERE clause.
It is important that the actual recording be fresh data from the source OPC item, not from a subscribed tag. That is, transaction groups should be configured to OPC Read mode, and scripted inserts should use system.opc.readValues().
But this is what historian does, isn't it?
Then we only need to enable historian for this tag.
(not to stir, but looking for best implementation)
And do query history on this tag on using single time instance.
"What is the Energy yesterday Midnight"
"What is the Energy Today Midnight"
Subtract them.
Main goal really,
I wanted to save in database, discretely because I wanted to show on bar graph Energy Usage Per Day.
I am happy with the below now:
I will historized Energy Tag. Make two queries on it and store the difference in database for reporting.
Its not perfect but should solve most of the problem (missing data, miss "writing to database" code)
This will return 1 value (Maximum within 60sec).