I don't mean no string, I literally mean change it from == to 'is not empty'. If anyone has an idea on how to fake a failed initialization I would appreciate it other than just clearing out certain parts of the message. I don't even know what format pops out when it fails so idk if that would be a good test.
Is there a way to automatically cause a full deploy of node red flows after a system restart?
After a reboot (kernel updates) of my node red server all of the hubitat nodes are "uninitialized"
Only a flow or full deploy refreshes their state.
I'm aware of using an inject node for HE nodes but there's got to be a better solution.
Doing a full redeploy every time seems like an expensive (resource-wise) proposition and likely not the "approved" Node-RED approach - but maybe check with the folks over on the NR community site to be sure. It's like doing a full recompile each time you restart?
So there are various ways to do intialization.. You can use a single inject node and then the "Link In" and "Link Out" nodes to connect all the processes that need initialization. I use global vars and MQTT processes to handle it.
Another thing you can do use is implement file storage context.. with this you can store your global and context variable on the HD that can persist across restarts etc.
1 Like
I don't restart the NR server that often but if it was due to a power outage none of my automations would work.
The bigger question is why the Hubitat nodes are uninitialized after a restart.
I found a documented way through NR admin API so I suspect its "approved".
However it reloads all flows which ends up causing an infinite loop of reloads, have to figure out how to reload just some flows rather than all.
That seems strange - mine are fine after a Node-RED restart / server reboot... all three hubs in fact. It does take a second or two to rebuild the caches but all good.
if you reboot HE then make sure in the HE Nodes config under advanced you have "Rebuild cache on Hubitat systemStart event" checked.
1 Like
It's not an issue with a hubitat restart only the node red server. And I'm referring to a full system restart not just restarting the NR service.
Just did a test again and all my hubitat nodes are "Uninitialized"
I don't think there's a question at all... because it's intended to work this way OR work with a cache refresh... your choice, although it's global to the hub.
I have the option enabled for each of my hubs.
Additionally, I have many Inject nodes:
where a Msg is sent some time after a NR restart or Deploy.
Between the two, power fails are not a concern in this area. MY problem with power fails is that my DHCP and DNS are function several minutes after my hubs and NR are alive. So I usually have to reboot them anyway OR, if I'm aware of the power outage, I can turn off the power strips that control those fast booters 
1 Like
I have the rebuild cache checked. No issue when my hub restarts.
I do use some inject nodes exactly as you to initialize some logic gates. I was just trying to avoid having "wires" all over the place.
My dns/dchp/nr/mqtt/zigbee2mqtt are all on the same server. Dell 4th gen i5 8gb ssd usff I picked up on ebay for about the same cost as a RPi/case/ps/sdcard
So temporarily disable your Node-RED service.. then reboot and manually start Node-RED do you get the same behavior? Maybe it's some sort of race condition..
1 Like
On further investigation it's only the device nodes and it doesn't seem to affect the operation of the flow.
Once the device generates an event it updates its status in the flow.
@erktrek I will try what you suggest.
1 Like
I have a NR flow that subscribes to a HE hub restart event and restarts a NR flow that has the event node on it. I did this primarily to fix an issue with capturing HE logs via a a websocket node. What would happen is that while the node would show connected, it was not getting any data. Maybe something like that would work for you?
[{"id":"c00b82c.f11e5","type":"link in","z":"f8301745.84255","g":"ed35d08.60c2eb","name":"Restart NR Flow - In","links":["900f7db3.900b9"],"x":284.9524230957031,"y":2290.5239181518555,"wires":[["e7d89981.94d008"]],"l":true},{"id":"45ea655a.87abf4","type":"inject","z":"f8301745.84255","g":"ed35d08.60c2eb","name":"Manual restart NR Flows","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":576.6192016601562,"y":2222.85733795166,"wires":[["bd7872ea.ff2788"]]},{"id":"e7d89981.94d008","type":"switch","z":"f8301745.84255","g":"ed35d08.60c2eb","name":"Scheduled Reboot?","property":"scheduledReboot","propertyType":"global","rules":[{"t":"false"},{"t":"null"},{"t":"true"}],"checkall":"true","repair":false,"outputs":3,"x":526.619140625,"y":2290.857177734375,"wires":[["bd7872ea.ff2788"],["bd7872ea.ff2788"],["cca233d5.227588"]]},{"id":"bd7872ea.ff2788","type":"function","z":"f8301745.84255","g":"ed35d08.60c2eb","name":"Node-RED http header","func":"msg.url = 'http://localhost:1880/flows';\nmsg.method = 'POST';\nmsg.headers = {};\nmsg.headers['content-type'] = \"application/json; charset=utf-8\";\nmsg.headers['Node-RED-Deployment-Type'] = \"reload\";\nmsg.headers['Node-RED-API-Version'] = \"v2\";\nmsg.payload = {\n \"flows\": [\n {\n \"type\": \"tab\",\n \"id\": \"7b994e31.f24a6\",\n \"label\": \"Hubitat Events DB\"\n }\n ]\n};\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":886.2862396240234,"y":2224.52481842041,"wires":[["766ea13b.52fee8"]]},{"id":"766ea13b.52fee8","type":"http request","z":"f8301745.84255","g":"ed35d08.60c2eb","name":"Reestart Node-RED flows","method":"use","ret":"txt","paytoqs":"ignore","url":"","tls":"","persist":false,"proxy":"","authType":"","x":1147.2866668701172,"y":2224.525062561035,"wires":[["5cd01c6e.ed7d7c"]]},{"id":"5cd01c6e.ed7d7c","type":"change","z":"f8301745.84255","g":"ed35d08.60c2eb","name":"Delete Payload","rules":[{"t":"delete","p":"payload","pt":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1376.2864227294922,"y":2224.858070373535,"wires":[[]]}]
The function node creates the header that calls a NR API to restart that flow.
Hope this helps.
for every flow that starts with a motion or contact trigger, I also have an init node that initializes the flow after a node-red restart. additionally I have a link in node that re-evaluates the flow on a hubitat hub restart.
this keeps all the flows up to date in case of power outages, hub updates, restarts, etc.
Also setting up a file storage context is a good thing too... store your global/flow variables on disk for persistence.
2 Likes
If you aren’t doing this, I’d recommend it highly. It also basically eliminates the need to use inject nodes at NR startup to repopulate flow and global variables.
1 Like
Did you get the function to actually restart a single or all flows?
I tried that exact function and it restarted all the flows. I was not able to restart the declared node. And I did use the correct label and id.
And reading further through relevant threads on the NR forum it appears the reload on line 5 of the function causes all flows to restart. It ignores the "flows" payload. It appears as the author of that function was trying to adapt the admin api that allows individual flows to be changed through api calls.
@erktrek & @aaiyar & @jrau272 I think that may be my best option. However in my case/flows it seems to be mostly cosmetic as as soon as a device event occurs the device node is populated and doesn't affect the operation of the flow. And the few nodes/flows I have where it does matter I am using an inject node 15 seconds after.
A few simple examples of persistent variable as it relates to device nodes would be helpful. TIA New area of NR to learn.
Thanks for all the suggestions.
1 Like
Yeah - unfortunately that does seem to be the case. However, for me that was the only way to get the websocket node connected and the log data to start flowing.
you don’t really need persistence with device nodes — Hubitat will keep track of that. persistence is useful for global/flow variables. I use many of these throughout my flows. Globally I set things like “mode” (day, evening, away, etc). a practical example of a flow variable is a “manual override” if a wall/virtual switch is flipped. also counts — I count how many times the mail box has been opened to determine if the mail has been delivered/retrieved.
Persistent variables prevents these from being reset during a reboot/restart. Otherwise, every time I’d restart node red, I’d get a push message that the mail was delivered.
1 Like
That's what I determined, I actually think I am encountering a situation where the node red service is started before the network is after a reboot. If I just restart the node red service all the devices are initialized.
I haven't really encounter a personal need to use a persistent variables, and I really don't restart NR that often.
2 Likes
That's fair enough. Practically speaking, I have not observed a performance penalty between keeping context storage solely in memory v/s on the local filesystem. It is also possible to use multiple context stores - and then choose between memory and local filesystem at the time of variable creation.
FWIW, this section from the node-red documentation on context storage is worth perusing:
1 Like
If using systemd search for and edit "nodered.service" (or whatever your service name is) and under [Unit] add this line:
Wants=network.target
1 Like
