It would be like an ‘unnamed’ script that just performs some tasks on the fly, that’s unique and doesn’t step on the toes of another ‘unnamed’ script generated in the same way.
I’m interested to hear about that but i believe this is not the place… if you ever have the time to explain it in detail some time, just PM me, I’d love to hear about that.
Mainly I wan to know what the lambda function, or you, are trying to achieve
Please elaborate, I can’t believe that to be honest.
I think petro covered all the other points, I just want to emphasize that for me Node-Red is an additional, unnecessary layer, which can’t achieve anything that can’t be done with native HA capabilities. One more thing to maintain. I’m also not a coder and you don’t need to be a coder for HA.
Entity node
EDIT
It’s not been until recently that the choose clause and traces have been added. Before that, if you wanted to write a complex/branched automation you had to divide it into a number of automations instead a single flow. Debugging was, as I said, a disgusting waste of time.
It probably can achieve the same things. I like more the way NR achieves things. For every 20 lines of yaml, you need to write 1 line of code in NR, probably even less.
Thankfully things have changed for yaml.
You can do everything HA templates can and more in Node red and send it to an entity node.
An example of what you can’t do in HA but is possible in node red is to read the JSON files in the .storage folder and output something as an entity.
I use that to get a token/auth used in an integration.
This is not possible with yaml.
And you can scrape things from internet without creating extra entities and mid steps.
It can all be handled inside node red and it just spits out the end result.
And even though I would call my self rather decent in coding with 25 years of experience and probably 10 languages, I find Node red better.
I can split up things and get visual track of where the “code goes” and when I want to do proper coding I can just us a function node and use a much higher level coding language than yaml.
Before I started using it I thought it was a simplified way of coding and that it would be to much of a beginner tool than what I would want.
But I find it just perfect.
Easy to add debugs and last week I even found out how to debug the mystery function nodes, so now all my issues with Node red is solved.
I have no issues with yaml, but it takes much more to get the same result and when you open a old automation and try and change/debug it, it takes much longer to find the place you want to find.
In Node red you relatively easy find your way much faster even in larger automations.
And you have mental pictures of where it is, where as reading a wall of text is harder and you need to read/gasp more to find what you need.
But I understand it’s a preference thing.
This:
perfect for beginners and experienced people. Me that I don’t love coding I managed to create a pretty nice smart home without a single function node, with all the benefits @Hellis81 just stated and with very little coding.
NR gets you there with a lot less effort.
…otherwise you would know that additional layer doesn’t mean something inferior. In fact a lot of architectural patterns propose multi-layer solutions. Seems it’s proven nowadays (ohh maybe for last 20 years) that such approach has way more pros than cons.
From time to time I can see simmilar argument against mqtt. One forgetting about all benefits it bring comparing to blackboxed integrations.
I’m a programmer with some experience from assembler through C to modern OOP languages. Not my main skills today but nothing I couldn’t back to. The point is yaml is not a programming language. it’s data layer used to pass some constructs to the program (imagine a programming using json), hence kind-of dead end to me, not flexible, error-prone. I admit it’s possible to used to it, but why if there are more powerful tools?
Node Red is great but require some changes in a way of thinking, since it’s based on events rather than states. IMO this is the main obstacle for some newcomers.
I’m not talking about the past, I’ve been here for around 5 years back when GUI config/automations where not even discussed by anyone. I totally agree that in the past YAML automations were not very capable and sometimes a pain in the a**. That’s why I was using AppDaemon in the past for all my automations, but slowly YAML automations got more and more powerful and I started to move all automations back to YAML.
I just don’t like that people always suggest node-red for everything, even for stuff you can’t do with node-red as you did here.
Exactly, thank you.
@maxym I muted you long time ago for a reason, I don’t want to discuss with you anymore.
2 Likes
This is my pet peeve. For even the simplest problem… say converting a state… where it’s a one line template you can guarantee someone on Facebook will say node red. I wouldn’t touch NR with a barge pole. I haven’t found a single thing I can’t do in ha natively.
1 Like
99% of the time that I find myself having to do anything but the most simple stuff in NodeRed, I find a way to immediately offload as much as possible to PHP, which is MUCH easier to to what I want to achieve (eg fetching web data and parsing the JSON).
Example of how NodeRed is FAR more complicated than the YAML / GUI Automation editor:
I want to trigger something when something happens. So let’s say when a door is opened. But I want to wait to 10 minutes to see if the door is still open after 10 minutes. I then want to check if the outside temperature is below a threshold AND whether the house heating is on. If all these things are true then I want to trigger a notification.
In NodeRed this is a node to react to the door being opened, then a delay, then another node to check the state of the door, and another node to check the outside temperature and another node to check if the house heating is on. Then a function node so that the msg object has all the necessary data to pass to the call service node. And countless connections to a debug node to verify that everything is actually working as intended. Oh and don’t forget if I want to actually keep any of the data from the various state nodes, I have to use either a change node, or a function node to store that data before the next state node overwrites it.
In YAML / GUI editor. The 10 minute wait is done with the for: statement on the trigger entity, and the rest are all just conditions. Show Trace will make it reasonably easy to spot if something has gone wrong.
Though I will concede that when there are multiple choices or even nested choices - the trace screen that shows all the different entities and whether the result was was true or false, is next to impossible to follow
conditions/0/conditions/1/entity_id/0 is one of my more simpler traces, but still takes several minutes to pinpoint what that actually refers to…
You are all comparing simpliest automations made by users who already have experience with one method or another. Try to make complex automation and then compare. I did pretty advanced/customizable circadian lighting in NR. Don’t even try it in yaml.
Or even something liter like trash collection automation. Not saying its not possible at all (or will not be possible). But I would like to see this yaml code and how comfortable it is to maintain.
And then about using NR for trivial tasks.
At first, if one opted-in for NR, he probably will want to use it for everything regardless complexity. It’s seems to be obvious to have all at one place.
At second,
I would say it ussually means that the asking person already failed to achieve it with yaml. Which proves the later is not any better, even for trivial automations.
That’s just your wrong assumption and bias…
which part?
And who are you to judge what is correct or wrong? Aren’t you biased?
It usually means they have no idea how to use a template. I do have a bias towards not adding unnecessary extra components for no gain.
When your only tool is a hammer everything looks like a nail and the pat ‘node red’ answer for everything even a simple template doesnt server anyone well.
1 Like
…which is integral part of yaml automation in HA, making it even harded to grasp.
I ussually would say the same.
But NR isn’t extra component once you are using it for more complex things. And because for some people yaml is not comfortable or even capable to achieve some goals (while NodeRed is), it makes NR the default tool. Nothing extra.
And at this point why should I suggest or advice to use yaml while I’m more confident/skilled with NR?
alias: Daylight
description: Set Daylight Level
trigger:
- platform: time_pattern
minutes: /2
condition: []
action:
- service: input_number.set_value
target:
entity_id: input_number.daylight_colour_temperature
data_template:
value: >-
{% set steps = (as_timestamp(now()) -
as_timestamp(states.sensor.date.state + ' 08:30:00')) / 60 %}{% set
level_now = 50 + (steps * 0.8)|int %} {% if level_now > 498 %}{% set
level_now = 498 %}{% elif level_now < 0 %}{% set level_now =
states('input_number.daylight_colour_temperature')|int %}{% endif %}{{
level_now }}
mode: single
Job done - this sets an input slider to the mired colour between 8:30am and approximately 8:30pm.
alias: 'LUX: Set Master Brightness'
description: ''
trigger:
- platform: state
entity_id: sensor.sma_lux
condition:
- condition: numeric_state
entity_id: sensor.sma_lux
below: '8000'
action:
- service: input_number.set_value
target:
entity_id: input_number.master_brightness_based_on_lux
data:
value: >-
{% set val = trigger.to_state.state|int %} {% set min_in = 1 %} {% set
max_in = 3000 %} {% set max_out = 100 %} {% set min_out = 1 %} {% set
out = (101 - (max_out + (min_out - max_out) * (1 - ((val - min_in) /
(max_in - min_in))))) %} {% if out < min_out %}{% set out = min_out %}{%
endif %} {% if out > max_out %} {% set out = max_out %}{% endif %} {{
out|int }}
mode: single
This sets a master brightness slider based on the actual Lux level being reported by an outdoor Zigbee sensor. Each room that needs to, then updates it’s own brightness level relative to the master brightness.
alias: 'Slider: Master Brightness'
description: ''
trigger:
- platform: state
entity_id: input_number.master_brightness_based_on_lux
condition:
- condition: state
entity_id: input_boolean.house_in_night_mode
state: 'off'
action:
- service: input_number.set_value
target:
entity_id: input_number.livingroom_light
data_template:
value: ' {% set min = 15 %} {% set max = 82 %} {% set b = (trigger.to_state.state|int) -(100 - max) %} {% if b <= min %} {% set v = min %} {% elif b >= max %} {% set v = max %} {% else %} {% set v = b %} {% endif %} {{ v }}'
- service: input_number.set_value
target:
entity_id: input_number.hall_brightness
data_template:
value: ' {% set min = 10 %} {% set max = 75 %} {% set b = (trigger.to_state.state|int) -(100 - max) %} {% if b <= min %} {% set v = min %} {% elif b >= max %} {% set v = max %} {% else %} {% set v = b %} {% endif %} {{ v }}'
- service: input_number.set_value
target:
entity_id: input_number.greenroom_brightness
data_template:
value: ' {% set min = 15 %} {% set max = 90 %} {% set b = (trigger.to_state.state|int) -(100 - max) %} {% if b <= min %} {% set v = min %} {% elif b >= max %} {% set b = max %} {% else %} {% set v = b %} {% endif %} {{ v }}'
- service: input_number.set_value
target:
entity_id: input_number.store_room_brightness
data_template:
value: ' {% set min = 15 %} {% set max = 80 %} {% set b = (trigger.to_state.state|int) -(100 - max) %} {% if b <= min %} {% set v = min %} {% elif b >= max %} {% set v = max %} {% else %} {% set v = b %} {% endif %} {{ v }}'
- service: input_number.set_value
target:
entity_id: input_number.bedroom_brightness
data_template:
value: ' {% set min = 8 %} {% set max = 40 %} {% set b = (trigger.to_state.state|int) -(100 - max) %} {% if b <= min %} {% set v = min %} {% elif b >= max %} {% set v = max %} {% else %} {% set v = b %} {% endif %} {{ v }}'
mode: single
It’s really not hard.
And Yes - I did initially have it all in NodeRed and it was a mammoth task to create it, debug it, keep tweaking it. But the final point for me came (and it’s not the first time I have encountered this) - when deploying a flow, corrupted flows.json and NodeRed was basically dead. No it’s not on a Pi, no it’s not on a SD card.
I said complex 
have you seen this (just take a look at screenshots alone)
Why bother creating all that in Node Red when there is a HA component to do all the hard work for you? (Adaptive Lighting, which works perfectly)
Because I found the way it works doesn’t reflect reality nor daily life needs (and is not configurable in this regard). The biggest flaw I found was increasing brightnes since midnight, almost 8 hours before sunrise. This is how it started.
I described it with details in Motivation section of my article.
I don’t understand who (or why) someone wants their lights to be bright during the daytime and dimmer at night, I want lights to be dim during the day - except when it is dark outside - which is why I am reacting to a Lux sensor instead of the sun position.
Your project looks nice, but is useless for anyone who suffers from SAD or wants to maintain a healthy mental health state. You need a minimum amount of “daylight” every day, the reason we get depressed in the winter is because there is not enough daylight. Basing your rhythm on the sun - doesn’t fix this, it just mirrors it indoors.
That’s why my implementation simulates daylight for the same fixed period of time every day, regardless of what nature is doing.
1 Like