For the most time, im using node-red. Its just way easier to build advanced automations. HA automations are mostly helpers or stuff that doesnt work as easy in node-red, like my tradfri-remote. I use directly a button press to restart HA or “translate” a button press into event, that i can use more easy in node-red as a native state-change.
Ok let me rephrase that then.
If you want to make complex automation it needs far more time and helpers to do the same in HA.
For instance adding a http request is not something you just can do in HA, you need to add it to the config and restart.
Some things just isn’t accessible in HA automations without lots of work in other windows.
If you want/need a helper then you need to open a new tab to add that, then you need to try out a template/condition, new tab with the template tool.
Sure it can be done but not in the same way.
Again, that depends on what you’re comfortable with. That’s your experience. It’s quite the opposite for me. Flow charts are a pain to read, configure, and it’s all gui clicking. 
1 Like
@Hellis81
I agree with Petro,
Most of what takes the time for me is deciding how I’m going to tackle the issue.
I decide that and the helpers are easy, I just copy the existing yaml and change the names of the guilty parties. The code goes together just following what I’d decided then I have to spend ten minutes after a restart (of the necessary bits) to check if any of the logic needs inversion and then it’s a proper test.
Two of my most complex systems are heating and music.
Heating has complex rules for set points based on doors/windows, times of day and distance from home - This worked first time and took me about an hour.
The music switches on and off according to time of day slots, manual activation, whether the house is occupied (turning off when we leave and comming back on when we return IF the conditions stiil ask for the music to be playing - That was thorny, is still took about ann hour to write but it took me another hour to debug (probably coz I was missing something obvious (can’t remember what it was, just so happy to get it fixed 
) )
2 Likes
So, bottom line @ByronCon : Use what you are comfortable with and always know that there are many of us in the community that will help you out no matter what you choose to do your automations in (and there is NO rule that states you can’t use multiple tools (NodeRed, native automations, pyScript, AppDaemon, etc) to make things work for your use cases.
1 Like
While it’s hard to disagree with code-in-progress, just take a look at who answered initial question: usually most skilled persons who already spent hours with HA, yaml etc. It’s pretty obvious they are super-comfortable with yaml.
I however can bet, that NR is easier to learn for beginners and more flexible at the end giving real programming language if needed. Yes, messaging needs a bit different approach but it’s more natural and better reflects reality (ie world is not static).
Also NR allows to deploy parts of its flows, or only changed entities. It allows to create HA sensors dynamically when needed without need of creating them in configuration (not speeking about the need of HA restarts for that. It’s not needed anymore since v.0.115 while NR been able to do that for long time already)
Personally my pov is, that yaml is evil’s creation. But in deep past I used to think the same about regular expressions 
. Anyway to newcomers I will recommend NR over digging through pretty confusing syntax of yaml.
2 Likes
Thanks for the thoughts. More than I expected!
Part of the reason I ask is that, like noted, removing an extra layer is often a good thing. I don’t think the automations are overly complex and consensus seems to be native is capable so I’ll start migrating some back and see how it goes.
As an example, turning on lights based on motion and illuminance with per room minimum illuminance, brightness, off timers. Not hard, but older ha made it a little frustrating.
It’ll be my office automations that go back first. That room acts as my Dev environment.
Thanks again.
Hmm, I disagree here.
I believe Yaml is easier for beginners, while Nodered expect people to have a reasonable skill in JavaScript.
I am an experienced programmer, and while NR looked easy, it took me a while to figure out how it works 
For me Yaml is just unlogical, it is not even a language, but a list of…commands?? or should i say variables?? or maybe just a list of words 
If we are speaking about beginners… basic flows in NR don’t require function nodes at all. Most things you can do with basic nodes. And at this point NR is like LEGO. There is a reason why LEGO can be easily played by children (and adult too).
While yaml… is " YAML Ain’t Markup Language". This name itself is recursive… Wiki says it’s human readable data-serialization language. Which makes a point: to express simple semantics you need to serialize it first into specific data format. It’s too much encapsulation IMO. And TBH syntax itself doesn’t help writing error-free code.
At this point NR is way easier to start with. And if in doubts it offers debugging console which allows you to monitor every point in your flow.
At this point I would like to be non-programmer to prove my point 
because I saw argument that NR is easier to programmers but not to non IT persons which I cannot refute. Maybe except the fact that HA itself requires so much IT skills that this argument seems to be empty.
1 Like
The thing that I like the most with node red is the fact that you can use a real programming language.
JavaScript (not Java, that is a completely different thing) is not my favorite language, probably the least favorite to be honest.
But I still like it better than yaml.
The reason is that I can build (kind of) functions in node red.
Yaml is as far as I know and have seen very static, one code can not easily share different triggers.
In node red you can have multiple triggers that can share all or parts of the code.
So the boolean can enter the same “code” from one side and share the code used by the sensor.
Since the message contains (or can include) what trigger it is you can then route the code differently.
Say you have a function node that calculates something then you can route multiple triggers in there and still separate them after the function node again.
Perhaps that too is possible in yaml but I’m quite sure it’s a lot messier. Or you would have to build several automations and or scripts.
Don’t get me wrong I love coding with text, I prefer that over blocks generally.
But yaml is kind of a let down to me, I see this interface and I’m thinking wow… I can build functions that I can call and the code will return bac… No I can’t…
I could replicate it with automation calling a script but then anything processed in the automation is lost when you enter the script.
If proper functions was available then it would gain a lot.
Just another perspective here. I’ve been using Home Assistant for a little over a year. I have a lot of physical devices connected to Home Assistant (300+) and I have a ton of automations. When I started moving from SmartThings to Home Assistant I was really concerned about the lack of features when it came to building automations as I had been using CoRE & WebCoRE with SmartThings for years.
Once I figured out I could use Node-RED, I jumped on it and didn’t even attempt to use the built in automation features or app daemons.
I spent days and days and days building and then even more time refining my automations once I figured better ways to do things. My favorite node ended up being the function node so I could just write a bunch of javascript.
In the end I felt like doing what should be really easy was too time consuming (not difficult) in Node-RED compared to WebCoRE.
After the 0.115 release, I decided to check out the built in automation functionality in the UI. I quickly realized that it was far from what I needed (though progress has been made). I decided to try out the yaml way of doing things since I prefer to keep most of my other config in yaml.
I started by moving a couple of my automations over that seemed to be having issues. For example, when motion is detected turn the light on. I would say these worked perfect 99% of the time, but that one or two times out of 100 annoyed the hell out of me and their was not real reason for it to not work.
After moving a couple of my automations to yaml and becoming a Jinja template expert (ok, level 1 expert) in the process, I’ve decided to move most of my automations to yaml as it is just easier and faster for me to build and maintain. Honestly I wish I would have done this a long time ago.
Some of my more complicated automations, I wasn’t expecting to move as I thought it would be too difficult in yaml. After thinking about it for a bit some of them were actually easier in yaml. I’m sure there will be a few things I leave in Node-RED, but I am going to try to move everything if I can.
Some other benefits to yaml over Node-RED…
- The UI for Node-RED was always a bit slow.
- No folder structure in Node-RED.
- Copy and paste with find and replace makes replicating things super fast in yaml
I’m sure there is more. I will say that debugging in Node-RED was a lot easier than yaml.
In the end this is based on my personal preference as which one is better than the other will always be based on your situation and is ultimately always going to be just an opinion, not fact.
1 Like
You can export the sequence/flow as json and do the search and replace there and then import the new updated sequence.
2 Likes
After reading this thread a bit, I spent a few hours trying to move a couple complex flows from Node-RED to the built-in automation system in Home Assistant.
Short result: I gave up. It’s much more difficult to create, maintain, follow, and debug.
It’s just too cumbersome to have multiple conditions and base actions on varying states. I ended up with 2+ automations for things that are really simple in Node-RED.
Take for example, my thermostat control:
- If the alarm system changes to disarmed or not disarmed, update, otherwise, update in the morning and evening automatically
- If I’m home, I want the house to be kept a little warmer than if I’m not
- If it’s not daytime, set a static night heating range
- If it is daytime, base the heat/AC on the current weather temperature and forecast
In Node-RED, this is fairly simple:
Here’s the code. If anyone can prove me wrong, I’d love to see the same result not be a complete mess with the built-in automations.
[{"id":"581cdae3.c14574","type":"time-range-switch","z":"d2f91ef0.ed955","name":"Daytime","lat":"44","lon":"-121","startTime":"06:00","endTime":"19:59","startOffset":0,"endOffset":0,"x":480,"y":160,"wires":[["18b59eb2.674d21"],["7f4f6dbb.084314"]]},{"id":"e963a4b4.093798","type":"api-current-state","z":"d2f91ef0.ed955","name":"Home?","server":"74d5538b.e0092c","version":1,"outputs":2,"halt_if":"disarmed","halt_if_type":"str","halt_if_compare":"is","override_topic":false,"entity_id":"alarm_control_panel.alarm","state_type":"str","state_location":"payload","override_payload":"msg","entity_location":"data","override_data":"msg","blockInputOverrides":false,"x":300,"y":180,"wires":[["581cdae3.c14574"],["8404e626.91e088"]]},{"id":"72989b88.5ce204","type":"api-call-service","z":"d2f91ef0.ed955","name":"Home heat","server":"74d5538b.e0092c","version":1,"debugenabled":false,"service_domain":"climate","service":"set_temperature","entityId":"climate.thermostat","data":"{\"temperature\":66,\"target_temp_high\":68,\"target_temp_low\":65,\"hvac_mode\":\"heat_cool\"}","dataType":"json","mergecontext":"","output_location":"payload","output_location_type":"msg","mustacheAltTags":false,"x":970,"y":100,"wires":[[]]},{"id":"7f4f6dbb.084314","type":"api-call-service","z":"d2f91ef0.ed955","name":"Night heat","server":"74d5538b.e0092c","version":1,"debugenabled":false,"service_domain":"climate","service":"set_temperature","entityId":"climate.thermostat","data":"{\"temperature\":60,\"target_temp_high\":68,\"target_temp_low\":58}","dataType":"json","mergecontext":"","output_location":"payload","output_location_type":"msg","mustacheAltTags":false,"x":690,"y":200,"wires":[[]]},{"id":"8404e626.91e088","type":"time-range-switch","z":"d2f91ef0.ed955","name":"Daytime","lat":"44","lon":"-121","startTime":"06:00","endTime":"19:59","startOffset":0,"endOffset":0,"x":480,"y":220,"wires":[["906a3ab9.2326f8"],["7f4f6dbb.084314"]]},{"id":"6f7b3816.eb54f8","type":"api-call-service","z":"d2f91ef0.ed955","name":"Away heat","server":"74d5538b.e0092c","version":1,"debugenabled":false,"service_domain":"climate","service":"set_temperature","entityId":"climate.thermostat","data":"{\"temperature\":65,\"target_temp_high\":66,\"target_temp_low\":62,\"hvac_mode\":\"heat_cool\"}","dataType":"json","mergecontext":"","output_location":"payload","output_location_type":"msg","mustacheAltTags":false,"x":970,"y":260,"wires":[[]]},{"id":"a874a8bb.5a4858","type":"vacation-timer","z":"d2f91ef0.ed955","name":"","lat":"44","lon":"-121","turnOffOnDaysOff":true,"midnightSchedule":true,"onTime":"06:15","randMinutes":"0","offTime":"20:00","randOffMinutes":"0","minOnHours":"0","minOnMinutes":"10","maxOnHours":"0","maxOnMinutes":"15","stopTab":"tab-2","onPayloadType":"str","onPayloadVal":"on","onTopicVal":"","offPayloadType":"str","offPayloadVal":"off","offTopicVal":"","suspended":false,"disableMax":false,"sun":true,"mon":true,"tue":true,"wed":true,"thu":true,"fri":true,"sat":true,"x":120,"y":240,"wires":[["e963a4b4.093798"]]},{"id":"aa4b933b.fb58a","type":"server-state-changed","z":"d2f91ef0.ed955","name":"Alarm change","server":"74d5538b.e0092c","version":1,"exposeToHomeAssistant":false,"haConfig":[{"property":"name","value":""},{"property":"icon","value":""}],"entityidfilter":"alarm_control_panel.alarm","entityidfiltertype":"exact","outputinitially":false,"state_type":"str","haltifstate":"","halt_if_type":"str","halt_if_compare":"is","outputs":1,"output_only_on_state_change":true,"x":110,"y":180,"wires":[["e963a4b4.093798"]]},{"id":"18b59eb2.674d21","type":"api-current-state","z":"d2f91ef0.ed955","name":"Weather","server":"74d5538b.e0092c","version":1,"outputs":1,"halt_if":"","halt_if_type":"str","halt_if_compare":"is","override_topic":false,"entity_id":"weather.weatherbit","state_type":"str","state_location":"payload","override_payload":"msg","entity_location":"data","override_data":"msg","blockInputOverrides":false,"x":640,"y":140,"wires":[["b45bf4ec.89cce8"]]},{"id":"b45bf4ec.89cce8","type":"switch","z":"d2f91ef0.ed955","name":"","property":"data.attributes.forecast[0].temperature","propertyType":"msg","rules":[{"t":"lt","v":"66","vt":"num"},{"t":"btwn","v":"66","vt":"num","v2":"75","v2t":"num"},{"t":"gte","v":"75","vt":"num"}],"checkall":"true","repair":false,"outputs":3,"x":790,"y":140,"wires":[["72989b88.5ce204"],["945b7c23.e7c68"],["241bd647.af062a"]]},{"id":"906a3ab9.2326f8","type":"api-current-state","z":"d2f91ef0.ed955","name":"Weather","server":"74d5538b.e0092c","version":1,"outputs":1,"halt_if":"","halt_if_type":"str","halt_if_compare":"is","override_topic":false,"entity_id":"weather.weatherbit","state_type":"str","state_location":"payload","override_payload":"msg","entity_location":"data","override_data":"msg","blockInputOverrides":false,"x":640,"y":260,"wires":[["f1c07471.0f3cb8"]]},{"id":"945b7c23.e7c68","type":"api-call-service","z":"d2f91ef0.ed955","name":"Off","server":"74d5538b.e0092c","version":1,"debugenabled":false,"service_domain":"climate","service":"turn_off","entityId":"climate.thermostat","data":"","dataType":"json","mergecontext":"","output_location":"payload","output_location_type":"msg","mustacheAltTags":false,"x":950,"y":200,"wires":[[]]},{"id":"241bd647.af062a","type":"api-call-service","z":"d2f91ef0.ed955","name":"Home cool","server":"74d5538b.e0092c","version":1,"debugenabled":false,"service_domain":"climate","service":"set_temperature","entityId":"climate.thermostat","data":"{\"temperature\":68,\"target_temp_high\":73,\"target_temp_low\":66,\"hvac_mode\":\"heat_cool\"}","dataType":"json","mergecontext":"","output_location":"payload","output_location_type":"msg","mustacheAltTags":false,"x":970,"y":140,"wires":[[]]},{"id":"f1c07471.0f3cb8","type":"switch","z":"d2f91ef0.ed955","name":"","property":"data.attributes.forecast[0].temperature","propertyType":"msg","rules":[{"t":"lt","v":"68","vt":"num"},{"t":"btwn","v":"68","vt":"num","v2":"77","v2t":"num"},{"t":"gte","v":"77","vt":"num"}],"checkall":"true","repair":false,"outputs":3,"x":810,"y":260,"wires":[["6f7b3816.eb54f8"],["945b7c23.e7c68"],["ca68bb13.7ba6f8"]]},{"id":"ca68bb13.7ba6f8","type":"api-call-service","z":"d2f91ef0.ed955","name":"Away cool","server":"74d5538b.e0092c","version":1,"debugenabled":false,"service_domain":"climate","service":"set_temperature","entityId":"climate.thermostat","data":"{\"temperature\":70,\"target_temp_high\":76,\"target_temp_low\":68,\"hvac_mode\":\"heat_cool\"}","dataType":"json","mergecontext":"","output_location":"payload","output_location_type":"msg","mustacheAltTags":false,"x":970,"y":300,"wires":[[]]},{"id":"74d5538b.e0092c","type":"server","z":"","name":"Home Assistant","legacy":false,"rejectUnauthorizedCerts":true,"ha_boolean":"y|yes|true|on|home|open","connectionDelay":true,"cacheJson":true}]
In HA Automations, the 3-condition weather temperature range that would toggle heat/ac/off I just could not get to work at all. The UI scrolled on forever and was not easy to follow the chain of conditions and events.
Switching to yaml mode wasn’t really better, to be honest. And using templates? Super cumbersome and the UI is not built for it at all. Whereas it’s very easy to get attributes like data.attributes.forecast[0].condition in Node-RED.
One of the other huge benefits of Node-RED: debugging. Once you’ve set up triggers and conditions in HA Automations, trying to trigger the action sequence may not be possible if your conditions are not met. Whereas in Node-RED, I can easily add an Inject node, deploy my changes, click the button, and toggle the flow from wherever I’ve added the Inject, skipping any various conditions. As well, the Debug node printing all of the state to the debug console helps me see what I’ve done wrong.
Maybe HA Automation editing in the UI will get better over time, but for now, it’s really just not there for a large system that’s truly automated with many variables.
3 Likes
Can you just explain each step? I’ll take a stab at replicating it but I 100% cannot read that, even in it’s json form (part of the reason this is user preference). I’m confident this can be replicated in HA code but I’d need to know what the Node Red is doing in the first place.
As a side note, I think I’d spend more time placing those fancy boxes symmetrically than I would making automations.
You can import the JSON into Node-RED via the menu in the top right > Import.
As a side note, I think I’d spend more time placing those fancy boxes symmetrically than I would making automations.
They snap to a grid and you can configure the automatic spacing.
I believe he meant he doesn’t understand what the blocks do.
But as I see that flow I think it could have been simplified slightly.
I haven’t imported it to look but just looking at the image it seems it could have been simplified.
Most of the nodes have “output” where you send the data to, with that it means you can have one branch instead of splitting it but still preserving the if home/away in the message, and then at the last step branch out to the actions.
So assuming the upper and lower branch checks for same conditions then you could have removed one “daytime”, one “weather” and one switch.
Yes. That is a big thing.
And you don’t only do it once, you do it several times!
First you sketch up a draft and it works.
Place everything where it needs to go, then you realize something and you need to add a node.
Everything has to move right.
Repeat a few times.
Then all bugs are fixed you start naming the nodes and the size of them change so you have to start over again with adjusting the position of them.
It’s fun…
Yes, it cannot be replicated from screenshot. But this is not intended. Even in case of more self-explanatory node naming, nodes contain lot options which are not visible from outside.
However the diagram gives overview of message flow. And this is great because you can get idea being not flooded by all details at once.
Also each node has specific meaning recognizable by its icon.
Maybe not obvious, but one message/state change can can be processed by more flows. Flows can communicate with each other. You can create local and glibal variables, deciding weather those are persisted to disk (ie survive restart) or not.
Now… do that in yaml
At the end, as @Hellis81 said, it’s fun to optimize a net of nodes to make them look nice and organized. Maybe it’s because I enjoy working with diagrams in general.
BTW recently I found that NR applies OOP paradigm to json variables. For example if I create flow.foo variable of type json, then copy it using change node to msg.payload, then modify this payload, it will change the flow.foo value. I didn’t expect that tbh.
One more thought about beginners. I doubt a beginner could write anything, even most simplistic automation in yaml not starting with copying example from forum. While I believe, in NR it easy (easier) to figure out what nodes do. At first most of them are intuitive. At second every node contain its description (though some of them could be more detailed). Even going through all nodes is easier than reading reference docs of yaml.
2 Likes
My own two cents here:
I think it may well depend on how much you’re a visual thinker. I definitely prefer using Node-RED to the native UI. I doubt that last bit will change much as I grow more familiar with all things HA, but I may eventually go to straight YAML coding and bypass UIs entirely.
For now at least, I like the way Node-RED lets me conceptualize the flow.
1 Like
You’re absolutely right. Native Automations are becoming easier and easier to write. choose, mode, and repeat, all added recently, have really pushed this forward.
Before the addition of choose one of the main pinch points in writing complex automations was that there was not an easy way to else on a condition. The solution was to write separate scripts for each possible condition, and a final script that checked all of those conditions and only ran if none of them met. Then, in your automation, call every script – only one of them would actually do anything.
Now that we have choose, this script spaghetti isn’t needed and makes things a lot easier. However, the YAML syntax for choose is cumbersome and verbose. Anything more than 1 or 2 levels deep is difficult to follow. In fact, everything is more verbose than it needs to be.
The final bit of “nasty” in Automations isn’t the YAML, but the Jinja Templates inside the YAML. Consider this very simple automation to turn on lights if it’s dark and I’m home:
- trigger:
- platform: template
value_template: "{{ is_state('binary_sensor.dark', 'on') and is_state('binary_sensor.home', 'on') }}"
action:
- service: light.turn_on
entity_id: light.front_porch
That’s not bad as far as automations go. But I wish Automations would just assume I’m using a template and assume undeclared variables are attempts at getting state. This would make it less verbose:
- trigger:
- binary_sensor.dark == 'on' and binary_sensor.home == 'on'
action:
- service: light.turn_on
entity_id: light.front_porch
In this simple automation, it’s 1 fewer line, 2 fewer dict keys, and the removal of 2 “function” calls and 2 sets of curly braces. Now, imagine doing something more complex.
For conditions, recent changes to Home Assistant has made it possible to omit quite a bit of previously required syntax when using a template condition. Curly braces and “function” calls are still required, but it’s much much more simple. Hopefully, triggers will get that same treatment some time soon, which would be a huge improvement.
1 Like