Is the heartbeat message the only way to detect Node Red restart events without creating sandbox violations when running on Venus?
Thanks
running on Venus
What is Venus?
You are probably going to need to include a lot more context here
I would hazard a guess at Venus OS from Victron to run on Cerbo or RPi devices. Node-RED can be run as an APP under VenusOS. I run NR on it's own server and use MQTT for communication.
As to the Heartbeat message, can @logic28 give a few more details that we might understand what and where these messages come from. If they are from VenusOS, might I suggest he try the Victron Community where there are many people more familiar with this use of VenusOS and NR. Although, I must admit, I am intrigued by the question!
If the sandbox permits MQTT connection to an external broker service, the LWT ("last will and testament") messages can be used to identify restarts, subject to a small delay
VenusOS has it's own MQTT server. I have yet to find out how to connect to an external one. I could then use Mosquitto on the NR Server (same IP, but under my control for security!).
That would allow you to get a message when Node-red starts up.
An external broker would also allow notifications if the NR device goes down, eg a power cut.
If you can configure things, you can always bridge the two brokers directly so that they exchange messages. That way, you only need the brokers and you can let node-red on each side just talk to their local brokers.
I do use the Venus MQTT broker for many purposes with no problems.
I want the essential Node-Red flows within Cerbo GX in order to avoid externally dependent potential errors or interruptions. I will move some less critical ones to an external MacBook Pro eventually. I am having some minor issues since the introduction of Starlink Internet which is why I need to detect if and the exact time of any Node-red restart do me a coincide we're doing drop out. One of these important elements is the system restarts, which is why I need to monitor it and log it as I do for many more parameters.
I specifically designed my system to run on board, I do not trust any external device particularly I do not want any cloud-based support. However, I will move some less critical ones to an external MacBook Pro eventually, which will be running inside the off-grid control room (cabin) 24/7. I am having some minor issues since the introduction of Starlink Internet which is why I need to detect if and the exact time of any Node-red restart do me a coincide we're doing drop out. One of these important elements is the system restart, which is why I need to monitor it and log it as I do for many more parameters.
Use an Inject node set to fire on startup, that will fire each time node-red restarts.
and I use Telegraf with a test for various services as well as IP endpoints, data is auto-sent both to InfluxDB for historical records/dashboards and to MQTT for more immediate reporting.
My setup is:
Teltonika RUTX50 to connect to Mobile Network
Wyse 3040 Thin Client running Diet Pi with Grafana, and InfluxDB installed.
RPi Zero 2 W running VenusOS with MQTT running
and a SONOFF Zigbee 3.0 USB Dongle E for my Zigbee devices.
Personally, I run NR on the separate computer as Victron can lag behind on released versions and I am already using it for a Home Control System, so I get the same 'feel'.
Nothing runs in the cloud, all inside the Motorhome.
It would appear that the Starlink Router is capable of MQTT (can't test, don't have one).
@Colin has a good solution, fire the Inject node on startup and send a message via Telegram or whatever method you choose. As for heartbeat, use an Inject Node to repeat every X seconds and send a message to/by whatever method you choose.
The problem I found, and this is using an external NR Installation, is that you have to trigger the VenusOS MQTT Server regularly to keep it running. I use this flow which use the MQTT and Change Nodes:
[{"id":"135e545a81bc113b","type":"comment","z":"59ad9240c5ae1350","name":"VenusOS MQTT Automatic keepalive mechanism without first knowing mqtt id","info":"","x":370,"y":420,"wires":[]},{"id":"5703de4b95dbf08e","type":"mqtt out","z":"59ad9240c5ae1350","name":" mqtt keepalive","topic":"","qos":"0","retain":"","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"","x":700,"y":460,"wires":[]},{"id":"8a98972cf5ca1742","type":"debug","z":"59ad9240c5ae1350","name":"mqtt Serial","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":375,"y":460,"wires":[],"l":false},{"id":"fc6238d65f08e1ad","type":"change","z":"59ad9240c5ae1350","name":"mqtt Keep Alive","rules":[{"t":"change","p":"topic","pt":"msg","from":"^N","fromt":"re","to":"R","tot":"str"},{"t":"set","p":"mqtt_keepalive","pt":"global","to":"topic","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":260,"y":460,"wires":[["8a98972cf5ca1742"]]},{"id":"18e6d53156b958d4","type":"mqtt in","z":"59ad9240c5ae1350","name":"Serial #","topic":"N/+/system/0/Serial","qos":"2","datatype":"auto-detect","broker":"","nl":false,"rap":true,"rh":0,"inputs":0,"x":110,"y":460,"wires":[["fc6238d65f08e1ad"]]},{"id":"dcfa3f743bcb187c","type":"inject","z":"59ad9240c5ae1350","name":"Keepalive","props":[{"p":"topic","v":"mqtt_keepalive","vt":"global"},{"p":"payload"}],"repeat":"40","crontab":"","once":true,"onceDelay":"10","topic":"","payload":"keepalive","payloadType":"str","x":520,"y":460,"wires":[["5703de4b95dbf08e"]]}]
Hope that might help.
That is exactly what I was planning to do, thanks, unless of course there was another way like if Node‑RED exposes a built‑in “restart event”
I will eventually have a MacBook Pro running constantly, but I could never rely on that for the critical functions that I use constantly, like automation for charging times, connecting and disconnecting the grid for charging the batteries (since I stay off-grid other than for charging).
I could never afford to have those implementations, as well as my dashboard, running on a different machine; I need to make sure that everything critical runs under the same umbrella so that, only if the GX were to stop working, I would have issues.
I only use NR for deterministic logics, safety‑critical flows, system‑level automation, failover, redundancy, real control loops, not to display data in fancy dashboards; my custom NR dashboard is plenty sufficient for that, simple and clean.
Thanks for providing me with your flow, which I read carefully and is exactly what I would need if I was forced to use an external device to run Node-Red for all functions however, as I said, I am working on adding a dedicated Macbook pro so not to overload the GX, moving all the less critical functions to the external machine and only keeping the essential one within the GX.
I understand.
Reliability is a concern when your lifestyle requires the charging and discharging of Batteries from the Grid.
In our experience, and I am sure I speak for all, Node-RED is a very reliable and stable platform. Good luck with your projects and I hope that we have given you some ideas on how to track a Node-RED or indeed, any restart.
