MQTT Messages for "gauge"

I am using Flukso in connection with FHEM (Home Automation). FHEM is subscribed to the MQTT-Queque of my local MQTT-Broker and is running fine (I am using most the counter-Data). Now i like to use the "gauge"-Data for a special analysis ("When does the heater uses gas and when not"). As soon the heater uses gas i get a new MQTT-Message. But when the heater is finished using gas, i did not get an "0" MQTT-Message. Instead there are no further messages until the heater uses gas again. Is it somehow possible getting this information? In the Panel-Module from Markus Gebhardt is a "workaround": When there is no new message within 60 Sec. then the panel shows 0. Also when i use the http-API, it returns a "nan"-Value.

Any help is appreciated.

Regards

Andreas

gebhardm's picture

The FLM intended gas, water, and electricity impulse meters "tell" the FLM that an event "I have detected the use of another liter or watthour" occured; this event just tells to increase a counter of actual usage - in liters respective watthours.
Additionally, the FLM is able to enhance this event notification by a timestamp to provide the data necessary to calculate how long it took between the occurred event and its predecessor.
With the difference "t = current count event timestamp - last count event timestamp" and with the counter constant value x (from the configuration) the quotient "counter constant value x / time since last event t" can be calculated; this quotient then is equal to the "average number of liters respective watthours used in the time interval t" - unit is liters per timeunit respective watt (since timeunit per timeunit cancel themselves - with the appropriate factor 1 hour = 60 min = 3.600 sec = 3.600.000 millisec - everything is detected in milliseconds) - this average then is transmitted as "gauge"...
Thus can be understood that for sending "gauge" information, on impulse inputs an impulse, thus a count is necessary - otherwise the calculation just waits for the next count event to occur.
Having understood this, it is "obvious" that the line

  1.  if (now / 1e3 - value[0] > 60) value[1] = 0; // difference between current time and last received event timestamp

is no "workaround", but an actual approximation of such quotient calculation for the last event transmitted (which might have been sent many seconds later than the event occured - see MQTT quality of service set to transmit "at least once" - which means, the last message is always in the MQTT queue) - if the last event occured too long in the past, then the quotient is near zero anyway, so, assume zero...
Time to refresh some school knowledge on derivatives and the notion of dx/dt ;-)

andbez's picture

Markus,

i did not mean any harm to your knowledge. Your knowledge of Flukso (and Mathematics so far) is far behind my one. I just realized, that the http-Interface sends a "nan" after a while. I made a short analysis for another Flukso- and FHEM-User
(http://forum.fhem.de/index.php/topic,29387.msg353399.html#msg353399) :

realtime([[1446407838,924],[1446407839,924],[1446407840,924],[1446407841,924],[1446407842,924],[1446407843,924],[1446407844,924],[1446407845,924],[1446407846,924],[1446407847,924]
,[1446407848,924],[1446407849,924],[1446407850,924],[1446407851,924],[1446407852,924],[1446407853,924],[1446407854,924],[1446407855,924],[1446407856,924],[1446407857,924]
,[1446407858,924],[1446407859,924],[1446407860,924],[1446407861,924],[1446407862,924],[1446407863,924],[1446407864,924],[1446407865,924],[1446407866,"nan"],[1446407867,"nan"]
,[1446407868,"nan"],[1446407869,"nan"],[1446407870,"nan"]....

This shows me, that Flukso itself "says", that there is no more usage of "gas" anymore. And that is the question, if i can see this "nan" as MQTT-Message. And with your explanation i do not expect this anymore.

gebhardm's picture

Exactly, there is no MQTT message if no pulse is transmitted (I wanted to explain the condition, therefore the lengthy discussion, no offense taken ;-))
The REST-API "seems" to just fill a minute to not have to provide arrays of different length (OR, there is an array of defined length, but not enough values to fill); so the NaN is just an indication that there is no reading...