I have a set of LoRa sensors connected to my home IoT server. They measure temperature and humidity and report the readings from time to time, depending on how much the values change between two consecutive measurements. One of the sensors is located in the garage, which is beneath my apartment and separated by a thick layer of reinforced concrete. No Wi-Fi signal can penetrate it – but LoRa works without any issues. Some of the sensors are configured to report at least once every hour, regardless of whether the values change. This helps me ensure that the sensors are “alive”: as long as a measurement comes in at least once per hour, everything is working properly. All measurements are stored in a time-series database.
This is not a polled type of communication – the sensors are not actively asked to send their data. Instead, they decide on their own when to report to the server. The problem with this communication pattern is that if a sensor stops working, it simply stops sending messages – no data is stored in the database. I needed a way to detect such events, and decided to try Node-RED for this purpose.
The Solution
I came up with the following solution: Each time a measurement is received from the sensor, it resets a timeout mechanism, which in turn prevents an email notification from being sent. If the measurements stop coming, the timeout eventually triggers the preparation of an email subject and payload, which are then passed to a flow responsible for sending the email to my mailbox.
The key element in this setup is the Trigger node, which waits for a configured period before passing along a message it receives. However, the exact behavior of the node isn’t the most important detail here. What matters is that the timer inside the node resets every time it receives a new message (i.e., a measurement). So, as long as messages are coming in regularly—reported by the MQTT broker—the node should never trigger the downstream blocks responsible for preparing the email:
The dark purple node named “lora/node11/temperature” is an MQTT input node that reads measurements sent by the LoRa Node 11 sensor on my MQTT broker. This is how I collect and distribute the measurements throughout my system. The “Initial trigger1” node is necessary to trigger the “Timeout 70mins” node immediately after Node-RED starts or after a flow re-deployment (to get it running). Without it, and in the case of a malfunctioning sensor, it could happen that an email is never sent.
This is how the Timeout (Trigger node) is configured:
To prepare the email Subject and Payload, I used a standard Change node:
The small gray node behind the Change node is a Link to another flow responsible for dispatching email notifications to my inbox:
The green node on the right is an Email node from the installed node-red-node-email add-on:
A brief explanation is also needed for the link indicated by the dashed line in my flow. It consists of connected Link Out and Link In nodes. This link is added for two reasons: first, to make the flow look clearer, and second, to allow the timeout to restart immediately after triggering an email notification.
And voilà!
The only potential issue with the flow above is that, if the sensor fails completely, you’ll continue receiving email notifications until the sensor is fixed. Perhaps my missing measurements detection method could be smarter—maybe it should try to send up to X notifications before going silent, or perhaps it should increase the interval between notifications. Maybe that’s a topic for another time.