I'm using the JSON interface to read real-time values from the FLM for a pulsed watthour meter.
The meter generates 1600 pulses per kWh -- 1.6 pulses per Wh -- 0.625 Wh per pulse.
It's pulsing now at a rate of about once every three seconds. That's about 0.21 Wh per second, or 750 Wh per hour, or 750 W. The load is relatively constant. Not exactly, but no large variations. I am independently measuring the load with another meter that's reporting 705W -- fairly close.
The JSON API is returning 584 W for 13 seconds, then 1172 W for 3 seconds, then repeats. The last 2 to 5 fields in the returned JSON array are "nan". The nan timeslots appear to be regularly updated within a few seconds, all with the same value.
I can deal with the nan's. The bigger problem is the 2:1 variations in reported power.
Any idea why this is happening? How and when are those numbers calculated? I could understand if they were only updated when a new pulse arrives, but that should be once every three seconds, not 3 then 13. What's worse is that neither reported value is correct.
If I average the values over the 3+13 second range (694 W), that looks about right. I guess averaging is a workaround for now, but it also means the data won't be as "real-time" as I'd like it to be.
As this pops up once in a while - see https://www.flukso.net/content/r232-release-notes
Known issues:
Real-time readings are not correct for pulse inputs with meter constants that are is not an integer fraction, see this forum post. So constants like 0.5, 0.25, 0.2, 0.1 will work correctly with the real-time interface, while 0.625 and 0.4 will cause bogus values. This bug does not impact the readings on api.fukso.net.
Glad to hear it's a known bug -- although the description of the cause doesn't exactly fit what I'm seeing.
Is it possible to change the meter constant using the wireless interface? Or do I need to move it back to a wired interface first?
Is it possible to read raw pulse counts from the realtime interface, instead of watts?
Sorry, being also just a user, I can hardly resist to answer...
With respect to the addressed behaviour being a bug or a feature: It's hard to cope with "inadequacies" of different number systems, especially between the Galois Field (2) (the binary one) and the Real numbers when using arithmetics (it's computer science thus neither a natural nor an engineering science ;-)); the source code is open, so feel free to adapt and provide a proposal to alter the behaviour...
With respect to "better" alternatives, again a quote from https://www.flukso.net/blog
A Mosquitto MQTT broker on each FLM. Sensor readings are injected into the broker and can be read out by any MQTT client. Point the client to the FLM's IP address and select port 1883. Gauge (Watt) and counter (Wh) readings are published on /sensor/xyz/gauge and /sensor/xyz/counter topics respectively.
Thus, there is a direct trigger for count events as provided by the pulse ports; and a MQTT client should be avaiable for nearly every programming environment.
See https://www.flukso.net/content/mqtt-mq-telemetry-transport and try www.giyf.com with "site:flukso.net searchterm"
Still, it would really nice to fix this problem in a firmware update. When my air conditioner is running, it draws a constant 5 kW. Yet, the minute tab readings I get fluctuate between 4 kW and 6kW every few seconds because of this beat effect.
A secondary effect that consumption readings on PVOutput.org look like they were drawn by a drunken snail, especially at low power levels. When I see my fridge turning on an off over night, with everything else in the house steady, I get a vague wavy line instead of a nice square wave.
It can't be that hard to fix the code to produce more accurate readings?
Cheers,
Michi.
I hope no one is suggesting that this behavior is actually a feature. The reported number of watts aren't just a little off -- they're completely wrong. That's clearly a bug.
I've come up with a workaround: multiply the counter coefficients by 1000. So 0.625 becomes 625. As long as the FLM receives at least one count per minute, the fluctuations go away.
Although this fixes the readings on software I wrote that runs locally, it breaks the flukso.net graphs and makes pvoutput much less useful (I can set a rule there that multiplies reported power by 0.001, but that only works when the number isn't summed with a reading from a clamp).
bart, any news on when/if this will be fixed please?