So I’m looking in to this whole Node Red thingy and I’m quite unsure if I should continue down the rabbait hole or not. The main advantage I can see right now is that way faster to load new automations and often much easier to visualize the flow in Node Red. I also kind of like the idea of having things separated. (Hopefully the integration won’t break, then it won’t be as fun anymore)
I think I’ve found a way to recreate my main light rule (perhaps in an even simpler way than in HA) but as it’s written right now it would spam HA to turn on the scene as soon as the conditions become valid. I could of course check if one of the lights in the scene are off before sending. But then I’d have to remember that if I make any changes to the scene. This feels sub-optimal. Another idea is to create an input select that “saves” the state of the scene and then have Node Red call a script instead of the scene directly.
Or is all this way to much effort for way too little gain?
Are there other ways to solve this conundrum? Or is it even so that Node Red might not be for me? Any guidance in this issue is greatly apprectiated
I’m not sure what your specific use case is, but I’m using Node Red exclusively for all automations, and have no problems. Some of the things I like:
Easier to build and maintain mainly due to being more visual.
Use of flow variables, versus in native HA I found I was creating new ‘input_*’ fields for the same purpose.
Easier to debug using the debug node.
Use of Node Red without HA. For example, I’m also using a (free tier!) Node Red cloud service (Bluemix) to route Google Home requests to my local MQTT server.
Since you’ve gone all in on Node Red automations perhaps you could give me hints or suggestions on how to deal with this:
I have created a rule that will send a timestamp every minute which is then piped in to a sun position function so that I get the suns elevation. If the elevation is below 2 it will turn on a scene in Home Assistant. This part works great.
My problem is that the way it is constructed right now it will spam Home Assistant with “turn on the scene” (which in turn spams the lights etc) every minute as long as the sun elevation is below 2. So I need some kind of state check and while I could solve this by checking if one of the lights in the scene is one I’d rather not. I’d prefer if they were decoupled so that I can change the contents of the scene with worrying of breaking the automation.
So what is the best way to make Node Red aware that the scene is turned on and it shouldn’t try to do it again (unless it is turned off)?
A simplistic solution would be to use a flow variable - when you turn on the scene, also set a variable (eg. flow.scene_activated = true). The main issue here is that if Node Red restarts, or you re-deploy, the flow variable will be forgotten. However, I’ve read there is an update coming where it will remember flow and global variables.
I do something similar for a couple of cases. One similar to yours, where I store the date/time in a flow variable, so I don’t repeat an action within a couple of hours. I also use flow variables as a convenience, since reading HA state blows away most/all of the msg (and I’m to lazy to do joins all the time). In this case, I have one flow responding to state changes in HA, and then copy the current state into a flow variable. Then I can just reference the flow variable in a switch.
This is how I connect everything from Google Home to my devices. I initially did it to connect devices that GH can’t control. However, I found that it’s more reliable to control my Hue lights this way too, so now I’ve removed all devices from GH and control everything the same way. There’s a few options for how to do this, and most people seem to expose HA to the Internet. I’m way too nervous about that, so I installed Mosquitto (MQTT) within Docker, and exposed that instead, on the assumption that much less damage could be done. GH talks to IFTTT pretty easily, but IFTTT has no support for MQTT, so that’s why I use Node-Red on Bluemix. I know GH -> Google -> IFTTT -> Blumix -> Mosquitto -> HA -> Hue sounds ridiculous, but the latency is only a second or two and very consistent. Whereas GH -> Google -> Philips -> Hue generally takes the same time, but it often very slow. There are a few down-sides - you have to specify every way of phrasing commands in IFTTT, which is tedious; you only get one static spoken response per command so you can’t ask if the lights are on for example. IBM also cancelled my Bluemix account because the “30 day trial” expired although their website says the Lite plan is “develop for free with no time restrictions”. I think it was just a stuff-up, but they went through some whole palaver of wanting copies of my drivers licence, which was very bizarre and highlights the difference between a 100 year old bureaucracy and Amazon/Google/Paypal etc. I just created another account. Anyway, I waffle.
Depends on what you state you think I should check. My rule is triggering a scene, not individual lights. Scenes do not have a state so I can’t check the scene.
Now the scene contains individual lights so I could of course check the state of one of them. But one part of why I’m using scenes is that I want to be able to change the automation action without having to update the automation every time. If the automation assumes some content of the scene it means that I either have to remember to never change that device or that I have to change the automation if I change the “wrong” device. I want neither.
Thank you for the flow variable tip. Using that I’ve replicated my light rules in Node Red as a first step. So far I think the rules came out better in Node Red than in Home Assistant.