Time since last MQTT update

[GlennK]

I have several ESP8266 nodes uploading various readings to Node-Red via MQTT every 10 minutes and then the ESP goes into a deep sleep since it is running on batteries.  The readings are used to populate a Node-Red-Dashboard UI and then various readings are shipped off to InfluxDB for historizing and longer term analysis on a Grafana dashboard.  I'm looking for the best way to measure "time since last update" for specific MQTT input nodes.  One reason would be to show on the dashboard how long it is before the next update will occur.  The other is to know that the data update is overdue and therefore the data is probably stale... and by how much.  I have not yet located a node (or someones posted flow) which does this.  Any ideas before I dive off into a function node to craft a solution?

[Zenofmud]

When NR receives the MQTT message, why not stick the current time into a global (one for each ESP8266) and you can have some other flow triggered each minute (or what ever time you want) checking the current time to the global time for each one.

On Mar 16, 2017, at 1:37 PM, GlennK <glenn.k...@gmail.com> wrote:

I have several ESP8266 nodes uploading various readings to Node-Red via MQTT every 10 minutes and then the ESP goes into a deep sleep since it is running on batteries.  The readings are used to populate a Node-Red-Dashboard UI and then various readings are shipped off to InfluxDB for historizing and longer term analysis on a Grafana dashboard.  I'm looking for the best way to measure "time since last update" for specific MQTT input nodes.  One reason would be to show on the dashboard how long it is before the next update will occur.  The other is to know that the data update is overdue and therefore the data is probably stale... and by how much.  I have not yet located a node (or someones posted flow) which does this.  Any ideas before I dive off into a function node to craft a solution?

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.
To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/636a12e6-9938-4836-a244-1809928e53a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dave C-J]

And the last will and testament feature of MQTT can be used to flag a broken connection, if the device stops sending

[GlennK]

After noodling around for a while, this is exactly what I came up with as a best short term solution.  I tied a function node to the output of an MQTT node from each ESP and wrote the current time into a global.  Then the output goes to another function which again grabs the current time and subtracts the previously stored global time.  Then the output is formatted for a dashboard text box.  The second function also has a trigger node input running every 10 seconds which updates the calculated elapsed time and therefore the dashboard.  Thanks!

[GlennK]

Thanks for the suggestion.  I have several Arduino's which are continuously powered so I want to know when they have lost connection.  But, I have several ESP8266's which drop the connection when they go into a deep sleep mode and they just re-establish it again when they power back up and transmit (~900msec).  I will have to investigate and see how the LW&T feature might work in this scenario.

[hello world]

Greetings,

I posted a flow that is similar to your concept here.  Polling lastUpdate is certainly not the best option if it's an mqtt device; you can avoid it with lwt with retain.  At wake, publish the message "online" to the same topic the lwt is set for "offline".

I have 10 "dumb" rf sensors that push serial csv to node-red, so polling the lastUpdate is my only option in that case.

I have since updated all my devices to use lwt when mqtt is in play.  If you are expecting the device to pub about ever sec then lwt is the way to go.  The default timeout for receiving the lwt "offline" is 15 secs.   #define MQTT_KEEPALIVE 15

Hope that helps.