That’s due to a minor mistake I made when I converted one of the actions in your automation. I left the option scene: in place and should have changed it to service: (and I have corrected the example posted above).
Those statements appear to be based on a very limited understanding of the capabilities of Home Assistant’s automation and templating language.
Do you mean like your original example? The one that is negatively affected by a restart/reload?
Of course not. that is/was because of a long wait.
I searched and found “choose” operation. After investigating a bit i found several alternatives:
Main idea is to avoid stoping if not running. This happens if the trigger is set to “soc>91”. This happens every day while the sun is charging the batteries. Ideas:
Two automations:
… the start automation enables the stop automation. Stop runs only if the start was running beforehand
… the stop automation disables it self
… disadvantage: two independent/depended automations make the maintenance a bit more difficult.
One automation with two triggers:
… One to start (soc<88).
… one to stop (soc>91)
… action part using “choose” to select appropriate actions
… disadvantage: stop runs always, even the start never happened, hard to prevent.
Two automation
… start as usual (soc<88)
… stop using condition to test the state of the switch which makes the generator to start and run (dry contact) is “on”
One automation with a long wait until soc>91
… most elegant solution, but may be cancelled by HA …
… no extra tests needed, strait forward.
The example I posted above demonstrates that choose isn’t even necessary. It simply needs a template to select the appropriate scene entity_id. The use of a template to do this is an established practice in Home Assistant.
choose is typically employed when the type or quantity of actions may vary. That’s not the case here where the service calls are consistent and only the value of their options change. Using choose would just create duplicated code.
If that’s a requirement, use an input_boolean to serve as an indicator. Turn it on when the start occurs and turn it off when the stop occurs. Only allow the stop to occur if the input_boolean is on.
Alternatively, if the scene is turning a switch on/off, use the switch’s state as an indicator instead of a separate input_boolean.
Honestly, there really isn’t much of a technical challenge to solve here.
This is now my solution: Using input_boolean to prevent running the off-part of the choose sequence when the generator is not running (as said the soc reaches 91% when charging from the sun).
The start-sequence is always needed, this indicates battery charge level is low.
For me this code is understandable by most computer affines. Although the YAML syntax is very special.
I would like to add some comment lines explaining what is going on here. So i placed #comment but i realised that these statements get flushed when saved!! Deleted!!! Why??? The description line is not enough to document the code. If there is no logical explanation for this i will forward an incident.
You’re welcome, but I am not sure why you are thanking me because your example still employs a choose even though I already demonstrated it’s unnecessary.
Because if you use the Automation Editor, whenever you save any automation, it removes all comments you may have added manually in automations.yaml. This is a long-standing behavior of the Automation Editor.
The only way to avoid it is to separate the automations you create manually (containing comments) from the ones created using the Automation Editor.