For a project, I need to continuously polling (every 1 second) your Iotawatt asking for power consumption, however I’m not sure which is the correct way to do it. I’ve already looked at the forum/documentation and source code with little result.
but I get an empty array. The minimum window for obtaining a meaningful result is 5 second.
I tried also with the undocumented status endpoint:
http://10.0.7.0/status?outputs
Although I get some response, from what I’ve seen from the source code, it’s simply the last value in the bucket. Given that I’m asking the value every 1 second, I need an average of the measurements from the last 1 second.
So, what is the best way to obtain this information? Alternatively, It would be fine also to receive all the measurements of the last 1 second, I can do the average on my code.
There is no correct way. As you discovered, the query API will deliver 5 second resolution metrics.
The status display does have a one second refresh rate under most circumstances, but the data produced is not a strict representation of the previous second. There is a Service called statService that maintains a current value at one second intervals. The value is damped by adding the new value * 25% to the previous value * 75%. This is to make the reported number more stable, however whenever the new value varies from the previous by more than 2%, the new value is used without damping. This allows for quick observation when loads come on or off.
Does your reporting have to be instantaneous? If not, then pushing the iotawatt data into influx and working from there might be a better solution than increasing the workload of the iotawatt unit itself.
This has the advantage of data being backfilled of Wi-Fi has a glitch as the iotawatt would publish skipped data when connectivity is restored.
Thank you for your answers. I definitely need more real-scenario testing. In the end it might be sufficient to have the value from the statService.
@overeasy To be sure that I’ve correctly understood the code and your answer, let me elaborate a bit:
a Iotawatt unit take ~30 samples every second. The statService computes on these samples the average over 1 second intervals, let’s call it A. Then the status query returns the last value (i.e. A(second T) if it varies more than 2% else it returns a damped value (i.e. A(T-1) *0.75+ A(T) * 0.75. Is it correct?
A bit of “practical” context:
To answer @philrob , yes, I need a (soft)-realtime reporting.
What I’m trying to do is to build a power manager that keep the mean power usage under a certain threshold. I’ve installed a Iotawatt unit in an hotel and they have recently installed a set of very power-hungry appliances (nominal power consumption when everything is switch on ~ 100kW)
Unfortunately, the electricity provider will gives us not more than 50 kW for the time being, so my idea is to have a set of relays controlled by a script that can deactivate and schedule the loads in order to keep the power usage under that threshold. Loads can be detached for some seconds with no issues, they have heating elements that have a lot of thermal inertia, so no one will notice it.
Maybe the Iotawatt is not the best way to obtain power-usage statistics in real time (there are power monitors with RS-485 ports that are already used in commercially available products) but for sure it is the simplest way (just an HTTP request!). So I want to give it a try and see if it works.
The good news is that I have to maintain the 15 minutes average consumption under a certain threshold thus, even if I get 5 seconds averaged consumption I have plenty of time to deactivate some loads and decrease the 15-minute average.
Tomorrow I will test a first version of the script that uses the 5-seconds average from query API, if you’re interested I’ll keep you updated on the results!
It’s more complicated than that. Without trying to explain everything, when the unit reports 30 samples/second, that is the total nomber of channels sampled in a second. If you have a fully loaded unit with 15 channels, each individual channel will be sampled about twice per second. On the other hand if you only are sampling one main and the VT, each channel will be sampled 15 times per second.
For each channel, after sampling, the previous sample value is multiplied by the time since the last sample for that channel, and the resulting Watt-milliseconds is added to a running total.
When the datalog or statService want to know the average value, they divide the increase in Watt-milliseconds by the elapsed time (in milliseconds) since their last computation. To do this both the dataloger and the statservice must keep track of the last Watt-milliseconds that they observed and the time of that observation. Also, VA milliseconds are accumulated the same way as are Volt milliseconds and Hz milliseconds for voltage type channels.
Not going to go deeper into it. For more details see the code.
Now that you have better defined your problem, I don’t see why you want one second data. You need to maintain a 15 minute average. That should be easy to do using the query API. There are 180 5 second intervals in 15 minutes. During each interval you can query the running average to see if more drastic action is needed. Switching large loads off and on in response to one second data doesn’t sound like a good strategy from the perspective of equipment wear and tear as well as voltage consistency. It might be better to do things more gradually using an algorithm with histeresis.
Thank you Overeasy for the answer, everything is quite clear now.
I’ve tested a basic scheduler that detach loads based on 5 seconds average and it seems to work surprisingly well.
Indeed, as you said, taking decision on 5 seconds average is sufficient, maybe a longer window can be used too.
I’ll have to tweak a bit and improve the scheduler (adding histeresys as you said, put some guards that guarantees that a load cannot be detached forever) but the general idea works and I’m quite confident on the final result.
If you don’t mind, I’ll post the link of the github project (when it will be ready), in case someone interested will land on this thread.
Thanks a lot for your answers and for developing such a wonderful product. With a Iotawatt unit and a couple of days of coding I’ll manage to obtain the same functionality of products sold for 10k$
Just as an addendum to this - i use an iotawatt for managing my battery systems at home over 3 phases.
Based on 5 second query intervals and without trying to be to ridiculous with my coding (Node Red) i managed to use a rolling 5 sec average from iotwatt to net out my feeding/drawing from the grid.
Over the course of 24 hours we have less that 1.5% error (i.e. grid draw/feed) and when analyzed on an hour by hour basis many of them are far lower than that
A quick update on the solution, in case someone is interested…
After 10+ days of working in a “production” environment, everything seems to work really well. The script is able to maintain the load under a configurable threshold. Moreover, I started to increase the various intervals in order to avoid switching loads too frequently, currently I’m considering a rolling mean of 20 seconds and I’m switching on and off every 15 seconds. I’ll try to increase again the intervals just to see what happens but I think the current configuration is a good compromise.
It was really interesting to understand that the maximum power peak (which here in Italy is billed ~ 4 Euro for each kilowatt every month) can be kept under control especially if you have a lot of resistive loads. For example, we used to have peaks around 32kw (so ~128 euro every month).
After looking at the Iotawatt statistics, it turned out that the maximum peak happen only once or twice a month (i.e. bad luck):
[Grafana](https://peak frequency)
After adding resistive appliances for additional ~90kw I’m having no problem in maintaining the peak under 24kw and no appliance user has noticed anything, saving ~ 32 euro every month.
Alex
P.s.
For the really interested ones, a pair of graphs that shows the energy consumption and the software switching on and off loads (the graphs refer to the same period): Load Load averages
