I have been fooling around with NR all weekend. There is a lot to learn and I want to start off on the right foot; perse. I am creating flows based on rooms. So all functionality or capabilities I need to happen in a room with be in a room flow. BUT, there are global things I need to take into account. I was thinking of starting my first flow with variables I need to use across all flows: mode, lux, HSM. Are there others I should include to? Any examples?
If you choose to do it that way, also keep in mind what happens on abnormal operating situations.
Do you need the variables to persist a node-red reboot? If so then you need to setup persistent storage - it is not ON by default. And if you setup persistent storage as a secondary storage in node-red, you have to make sure you specify that new storage location on each variable.
Do you want the variables to do a manual refresh on node-red startup (say node-red has been down for long enough that mode, HSM, or some other variable you use has changed on the hub significantly)? If so then you may need some logic on that. If using the Hubitat node-red node set, it will rebuild cache on node-red start, so you may be ok - although you may need to do a trigger node on startup to force the nodes to refresh, too... It just depends on how you set it up and are using the variables.
Do you want the variables to do a manual refresh on Hubitat reboots? If so then you may need some logic on that. If using the Hubitat node-red nodes, there is an option in the configuration node (not ON by default) to refresh cache on hubitat system restart, which may help.
For global variables, I would say that node-red variables (sent to persistent storage) is the most common way to do it. The next most common is MQTT.
2 Likes
All valid points and thank you for the info! @aaiyar I will read up on this too!
Funny you mention MQTT. I just invested in a significant Eufy Security cam system and guess what? HA developers have been making progress with MQTT. So yes MQTT is something of significant interest. I already have a Mosquitto broker working in my environment that just supports some DIY projects. No HA currently...though this may change with my recent investment.
What my goals for NR is to replace all of my rules and simple/motion lighting so I have more control of the experience and also relieve the hub from this overhead. I am having lockup issues and I suspect it is CORE apps and not the 1-2 custom apps remaining as all other user apps have been moved over to a secondary hub.
Hence my question surrounding what I should do for a "Home" flow and asking what others are actually doing. I don't want to reinvent the wheel AND I want to use the KISS principle.
2 Likes
Makes sense. I moved ~100% of my logic over to node-red, and my hubs have never ran so good.
To be clear, I'm not saying that is "necessary" to move logic off of Hubitat, that there is anything wrong with RM or native Hubitat apps, or even that others will have the same experience I did. I'm just relating my experience.
For me, using node-red has been a great move. Very easy to implement new logic, very easy to edit logic, can see exactly what the logic is doing at all times, can upgrade to faster hardware if I want faster logic execution, and can copy/paste nodes/flows at will making similar logic a snap. Side benefit, if Hubitat went away, I could fairly easily swap out the in in/out nodes and use something else, without redoing all of my logic. In fact, I have already done exactly that 2x - one from Hubitat to z2mqtt, and once back. No logic rewritten - although some input/outputs massaging had to be done.
2 Likes
You and @aaiyar are the two most vocal with the logic being moved over to NR. Are you using global saved variables like I am suggesting? If you do could you share your global flow?
When I first came to hubitat I was xcited about getting rid if extra hubs and running everything on hubitat. I managed to bring 95% of integrations to the hub. My hub then started the regular lock up thing. It was only when I started moving stuff back to the pi that my hubitat stabilized.
2 Likes
I do both MQTT and persistent context variables in node-red. Depends on use.
2 Likes
Ok so here is what I am doing for global.lux:
I want to compare both the weather illumance and the my lux Zooz sensor. In the function I want to compare the two results and if weather is <1200 or zooz < 13 then lux true/false. Suggestions on the function code to compare?
My experience mirrors @cwwilson08.
My hubs haven’t needed rebooting outside of one power outage, several platform updates, and one factory recovery.
I think that HEs are very stable with well-written apps and RM automations. But the sloppy stuff I put together was just plain bad. Either NR, or the hardware I’m running it on, is more fault tolerant.
Also, everything @JasonJoel said about NR permitting automations to become controller agnostic was a huge motivation for me.
2 Likes
Function node is fine for that comparison. Could also do switch nodes chained together if you don't want code hidden in a function node.
I do both, with the # of nodes it would take to do it being the deciding point between individual nodes and a single function node.
If it is only a handful of nodes, I prefer to not do it in a function node. I like my flow operations to be visible from the flow overview whenever possible - connect the dots, as I say.
That is true for me as well for the most part.. although I have had a lot of flaky device issues recently (maybe due to recent storms etc) which have also caused slowdowns, hub weirdness so NR won't fix everything.
Also I would caution that it may be possible to spam HE with too many messages causing delays etc. Always good to add a random delay here and there.
I totally acknowledge @JasonJoel for getting me into this situation too!!! and also big and continuing thanks to you @aaiyar for your help, ideas and support as well.
2 Likes
Agreed. I often add a 50ms delay between command nodes.
If I think there is any chance of high frequency output, or I know for a fact I never want it to send an output faster than X/y time, I use a rate limiter between the flow and output node too.
2 Likes
I thought we are supposed to use the core function node sparingly - it runs in it's own sandbox so uses more resources/causes slight delays (maybe).
The alternative is to use the "unsafe" function node for more raw performance goodness... although I get that most sequences/flows aren't processing tons of messages at once anyway.
I refuse to use the unsafe function node. Just my choice/preference.
In general, my hardware is fast enough that the low amount of function nodes I use probably wouldn't ever be noticeable in terms of speed degradation.
But you are correct that the function node is porky/slower in general. Whether that is meaningful or not fully depends on the host hardware and the context of the logic being run.
2 Likes
Okay thx for that.. I converted over to using Unsafe Node for use in all my very extensive set of subflows a while back have not had any issues so far.. 
Any of those unsafe nodes are relatively simple though. If I were doing something more complex with loops and various get/sets I would probably use the core function node as well.. just to mitigate the risk...
How would you use a function to acquire (2) device illuminance, compare the two and send a new payload of true/false out?
Basically:
var zooz = zooz.payload.msg;
var weather = weather.payload.msg;
if(zooz < 12 || weather < 1200) then msg.payload = true
else msg.payload = false
return msg;
Not sure how to get the two var settings.
I also have moved all logic from HE to NR . The hubs only serve as a way to control the devices. The hub now works flawlessly, never any need to reboot except for updates. If it runs slower than Rule Machine, it is not a difference that I can detect. And editing flows is so much easier, to say nothing of visualization of flows.
There is a learning curve, but that is always the case with a new toy.
My only issue now is I have several Z-wave (not plus) switches that I'd like to replace as they can be troublesome at times, bu they work 95% of the time so I'm not too motivated. Also, my 3 old Kwikset locks (also old z-wave) are not real reliable.
2 Likes
Where I do that I store the values in context variables when they update, and then use multiple switch nodes for the comparison, or a function node to compare them (have to load the variables in the function node something like var1 = flow.get("var1").
2 Likes
