I was using ioBroker for several years and decided to check alternative systems which are more user friendly, more international, better usability, etc. I finally ended up with my first HA installation a couple of days ago. First impression: WOW - what a brilliant implementation of a IoT middleware. UI performance, speed, usability, easy installation (I run it as a VM within Proxmox) etc. are very impressing.
I am having a typical environment with 100+ devices, multiple manufacturers (Hue, Xiaomi, Sonos, Shelly, …), etc.
My plan is now to transfer all of my automation from ioBroker over to Home Assistant.
Questions regarding current best practices for automation:
Scenes: e.g: say “Alexa, it is cinema time”, then certain lights are being changed, TV is being switched on.
Triggers, conditions, and following actions: e.g.: motion in bathroom detected (between 6:00-8:00am Mon-Fri, brightness is < x) → turn on light and play certain music.
Re 1-Scenes: Is Configuration > Scenes the best way to implement and easily maintainable there? Or better Node-RED?
Re 2: Should I primary use Blueprints? Or Node-RED? Or …?
Sorry for asking, and I guess this was asked many times before, but could not find current best practices thru forum search and I understand Home Assistant is developed and extended so rapidly so forum responses from a year ago may not be current any longer.
The reason I am asking is that I would like to plan properly before I go ahead and transfer tons of JavaScript from ioBroker over to Home Assistant.
I personally use a mixture of scripts, automations, scenes and Node-Red. For the simple things I mainly use HA, for the more complex stuff I use Node-Red. For me the biggest issue with HA is the “reloading” of scripts, automations etc. and sometimes the need to restart HA in order for those changes to take place. With Node-Red you do not have these issues, you can just build and debug on the go which for me saves a lot of time when building more complex automations.
I would like to hear your explanation of the Deploy button.
There’s no needs to restart Home Assistant in order to load new scenes, scripts, or automations. All can be reloaded in Configuration > Server Controls. If you compose an automation using Home Assistant’s Automation Editor then it automatically reloads automations when you save your modifications.
A blueprint is effectively a template for an entire automation. A blueprint is typically used to create other, nearly identical automations.
For example, imagine you have created six automations that do virtually the same thing but use different entities. If you want to change the automation’s logic, you will have to make the change in six separate automations. However, if you encapsulate all the logic within a blueprint, it can serve as the ‘parent’ to create six ‘child’ automations. The ‘parent’ maintains the logic and the ‘children’ contain references to different entities. If you want to change the logic used by the ‘child’ automations, you only need to change it in the ‘parent’, namely the blueprint.
A blueprint can also be used to create a single automation (there’s no requirement that it must create more than one ‘child’). However, it’s real strength is when it’s used to create more than one. It also provides the means of creating a UI for selecting entities that will comprise the contents of the ‘child’ automation.
Automations can be composed with the UI-based Automation Editor and they are stored in YAML format (in automations.yaml). You can also create them with a text editor, directly in YAML. Alternately, you can use the Automation Editor to create it in YAML because it allows you to switch between UI-mode and YAML-mode.
Automations can also be debugged (via a trace generated each time the automation is executed).
If you prefer a completely visual, flowchart-style of creating automation logic, then you should consider using Node-RED. A complete set of nodes exist for interfacing Node-RED with Home Assistant (via websockets).
@123 -
I am fluent in script languages like JavaScript (node.js) and don’t need visual / flowchart style.
Used Node-Red in the past within ioBroker but figured out I am faster in JavaScript (node.js) - which is used in ioBroker as script language.
Would you recommend using Python scripts in HA in my case? I have not written a single line of code in Python yet, but can learn new script languages fast, and Python seems to be pretty straight forward.
Or would you recommend using YAML and only using Python for very complex issues? Python Scripts - Home Assistant (home-assistant.io)
That’s what I do. I’m a strong Python programmer but quickly got used to the YAML capabilities and now only use Python for a handful of super complex things.
You are right, but in Node-Red I still have everything I need on one flow, no need to go back and fourth. Also, I do not like working with the UI editor that much in HA. It’s personal preference.
I would recommend you first try creating an automation using the Automation Editor and, when you’re done, switch it from UI-mode to YAML-mode to see the automation’s structure.
It’s important to understand that, despite everyone referring to it as “YAML code”, YAML is a markup language and not a “programming language”. You’ll see little similarity between it and Javascript or even python. There’s no native support in YAML for many things you would expect in a programming language and what you do see (like variables, choose, repeat, delay, wait_for_trigger, etc) are all unique to Home Assistant’s application of YAML. In order to provide more flexibility, Home Assistant also allows for the use of Jinja2 templates within the YAML statements.
Here’s a simple automation:
alias: My First Automation
trigger:
- platform: state
entity_id: input_boolean.whatever
condition:
- condition: sun
after: sunrise
action:
- service: 'light.turn_{{ trigger.to_state.state }}'
target:
entity_id: light.my_light
All this automation does is turns on a light when you turn on an input_boolean and turn off the light when you turn off the input_boolean, provided it is currently after sunrise.
After it has been loaded, the automation’s entity_id will be automation.my_first_automation
Automations have three “sections”: trigger, condition, and action. The condition is optional.
There are many kinds of triggers and this one uses a State Trigger. It will trigger when the state of input_boolean.whatever changes from off to on or on to off.
The trigger section can have more than one trigger. Multiple triggers are logically ORed.
There are many kinds of conditions and this one uses a Sunrise/Sunset Condition. It will permit execution of the action only if it the current time is after sunrise.
The condition section can have more than one condition. Multiple conditions are logically ANDed by default but you can make it ORed (or whatever combination of AND, OR, and NOT).
The action section calls a service. The service it calls will either be light.turn_on or light.turn_off. Which one depends on the result produced by the Jinja2 template. The entity_id that will be controlled is light.my_light.
An action section can contain many other things other than simply calling a service. It can define variables, pause using delay, wait_template, or wait_for_trigger, and control execution flow with choose or a condition, and iterate with repeat.
The Jinja2 template (everything within the double braces) references the trigger variable (also known as the Trigger State Object). It contains the state (and other properties) of the entity_id that triggered the automation. In other words, the template will return on if input_boolean.whatever changed its state to on. It’ll be off if the input_boolean changed to off.
There’s more to automations that what I described (mode, id, description, etc) but that should be sufficient to get a feel for its basic structure.
No need to do that either if you use the Automation Editor (it automatically reloads automations when you save a newly composed/modified automation).
Indeed it is and that’s why I felt it was important to correct your misleading statement about what does/doesn’t require reloading/restarting. For Acqua to make informed choices, the strengths/weaknesses of the available systems should be presented fairly and accurately.
I want to caution you about something that can cause you frustration.
When you create an automation with the Automation Editor, it will store it in automations.yaml. All the automations created via the Automation Editor are stored there.
You are allowed to edit this file with a text editor and modify the existing automations, including adding/removing automations. However, modifications done this way require that you manually reload the automations using Configuration > Server Controls > Reload Automations.
HOWEVER, before you manually reload automations, you should execute Configuration > Server Controls > Check Configuration and fix any reported errors first. The usual problems are incorrect indentation (because YAML, like python, is highly “position dependent”) and unpaired quotation marks. If you skip this step, and attempt to reload automations with errors, Home Assistant will reject it.
In addition, when you manually add automations to automations.yaml, they are all likely to be reformatted the next time you save with the Automation Editor. That’s because it follows a very specific style-guide. For example, double-quotes are converted to two single-quotes. If you added extra lines or a comment to the file, they will be discarded.
NOTE
Should you ever get to the stage where you would prefer to keep your manually-created automations separate from the ones created via the Automation Editor, it’s possible to do it like this:
