Complicated, or would you prefer simple?

Less is often more: good automations are above all simple, logical and therefore self-explanatory. First of all, a few points that I would do differently in new automations.

Lessens learned

• I would not create an automation for every trigger, e.g. switching a device on and off can be implemented with just one automation.
• Conditions in the "But only if (optional)" area can be ignored, these are rarely useful ...
• A repetition of the trigger in the "If-then" actions can usually be solved more elegantly.

Create automation

A new automation can be added in the settings and "Automations & Scenes".

The concept: Trigger (-> condition) -> action

Automations are started by one or more stored triggers (=When), for example at a certain time or when the status of a sensor or device changes. Before executing one or more actions, the automation could be checked for certain conditions (And if). Could, because the "And if" conditions are usually better placed in the actions (Then do).

Here is a short overview of the possible triggers for starting an automation:

Trigger: When -> Start automation

The triggers in the automations initially do nothing other than start the automation.

Conditions (optional: And if)

Optionally, the started automation can be checked for certain conditions.

If the defined conditions are met, the defined actions are executed:

Then do

An action can be executed on a specific device or a specific service. To simplify access to the possible services, the "ADD ACTION" wizard contains lots of shortcuts to the underlying action: "Call service". A specific logic for automation, such as conditions or additional queries or decisions, can be mapped using the existing building blocks .

Actions

Building Blocks

YAML

When creating an automation in the visual editor, a YAML text with all relevant information is created in the background. The YAML text can be edited and customized in a text editor.

Traces

In addition to the history, the processes of already executed automations can be analyzed in detail:

The number of saved sequences can be adjusted via the stored_traces variable in the YAML file:

trace:
  stored_traces: 100

When using multiple if-conditions, the traces were originally relatively difficult to interpret, as there was no indication of the condition or its entities: although the step details showed the result of the queries, they only gave an indication of which condition led to the result by means of internal numbering: 

My problem with the concept: trigger - condition - action

As simple as the concept of Home Assistant Automations is, the implementation in practice was initially unclear to me. My issue with the Automations can be described with a simple example: with a temperature sensor and a heater. If the temperature falls below a certain value, the heating should be activated and switched off when a certain target temperature is reached. The implementation requires two triggers for the two temperature values. The associated actions are then switching the heating on and off. To ensure that the triggers start the correct action, two automations can be created: one for switching on, one for switching off.

Alternatively, both triggers and the associated actions could be stored in one automation. After both triggers only start the automation, the actions now lack the information which of the two actions should be started. One possibility is to use an additional if-then query. The "If" in the if-then query often repeated the threshold values of the trigger in my first automations. e.g. If the temperature is higher than a certain value, I used the temperature values in the trigger and "If" in the actions. At the latest when using conditions, such as different temperature values for day and night, an automation could quickly become confusing. Since the conditions are used for the complete automation, the conditions area is not very helpful here. But also several automations for e.g. switching on during the day, switching on during the night and switching off and on during the day do not really make the implementation clearer.

Combining multiple triggers and actions? Possible solutions at a glance

• 👎 Only one action per automation:
  Advantage: Separate conditions and triggers can be used for each action.
  Example: Switching a device on and off in separate automations: One automation for switching on and one automation for switching off.
• 👍 Triggers with IDs executed in an If-Then or Select action:
  If an ID is added to a trigger, it can be linked to an If-Then or Select action in the actions.
• 👍 Regular start of the automation via a time pattern
  If an automation is started regularly, the logic can be completely mapped in the actions: Certain checks with if-then or select allow the respective action to be linked directly and clearly.
• Another option would be to use templates in the triggers, which would allow the logic to be implemented as soon as it is triggered: An update on this will follow.

Switching on and off: one automation or two?

As an alternative to two automations for switching a device on and off, an ID can also be assigned in the triggers and used in the actions:

By means of the ID, the actions can be reacted to in an if-query and the device can be switched on or off accordingly:

Trigger regularly and use only the actions?

To keep track of more complex automations, they could be started regularly and the logic within the actions could be mapped. For this approach, a "time pattern" can be used as a trigger, e.g. to start the automation every 5 minutes:

If the automation is started on a regular basis, all conditions can be directly linked to the actions by using multiple "if-then" or "choose" actions:

The disadvantage of using a time pattern is certainly the possible delay until the automation is started the next time. For time-critical actions, an additional trigger could be added at this point. Another disadvantage of the time pattern is that a new entry is saved in the sequences each time it is triggered, even if nothing has changed in the actions. Nevertheless, the advantages of a time pattern outweigh the disadvantages: A significant advantage is that the actions are not dependent on specific triggers. If, for example, certain statuses are set in the actions, such as switching on a relay or switch, the automation can be started at any time, even if it has missed a certain status change. Without a dependency on the triggers, the conditions used in the if-then actions can also be tested more easily:

Alternative approaches or ideas can be discussed at any time in the comments ...

Alternatives?

Even if an additional automation platform, such as Node-Red, certainly offers a better overview for more complex processes, I still try to stick to the Home Assistant automations, admittedly mainly to avoid the overhead and the additional dependency on another service. Home Assistant's mobile app also offers a better way of optimizing the automations on your cell phone.

Practice

Here are a few practical examples of how I have implemented certain automations:

Conclusion

A smart home solution only develops its full potential when certain devices can be controlled automatically. The intelligent control of individual devices can not only increase convenience, it can also save electricity or use it more wisely. The automations in Home Assistant initially seemed tidy and easy to understand to me. Using it in practice then had a few pitfalls. Once I got used to the idea of leaving the conditions area to one side and implementing the logic with if-then or select actions, I am able to put together even more complex automations clearly and sustainably with Home Assistant, For example, the override of my heating system.