So you put that action last in your list of actions or use a separate automation.
Tom, I would have thought better of you.
When you set up a complex set of triggers, modified by a labyrinthine set of conditions, then you waste it on one simple act when it could be used to drive many.?
Edit: There’s a lack of elegance and poetry in such a thing
Then use a python_script. You’ll get more flexibility.
Automations can be used to do many things but there are some tasks it can’t do (or do elegantly) … like looping or altering program-flow. There are hacks available to work around some of its limitations but they’re hacks; it may be functional but not particularly elegant.
So you’d recommend appdaemon above node-red every time?
Not sure how to answer that question given that I never mentioned either of them (and only have experience with one of them).
Also, 95% of my home’s automation logic is not handled by Home Assistant …
but there are more than 1 services here, guess that’s the whole point. Doing nothing is an explicit service.
Maybe not for humans (though I tried to proof otherwise with a poor analogy above…), but machines must be instructed to do nothing in certain cases, this being one of them. Do nothing and continue.
Agree on the conditions, that’s why I suggested
script.{{'lock' if is_state('lock.hm_sec_key', 'unlocked') else 'dummy'}}
maybe I should rename the script.dummy to script.continue to better explain what I try to put across. Has a more positive ring to it also
script.{{'lock' if is_state('lock.hm_sec_key', 'unlocked') else 'continue'}}
No it isn’t.
Doing nothing is exactly that. It’s not an action or a service. It’s nothing. Stop. Finito.
If you only have one service to run conditionally dont use a service template. If you think you need to then you need to restructure your logic. For example:
Don’t do this:
trigger:
triggers
conditions:
conditions
action:
- some actions
- a service template
- a service that runs conditionally or...
- a service that does nothing
- more actions
Do this instead
trigger:
triggers
conditions:
conditions
action:
- some actions
- more actions
- a condition
- a service that runs conditionally
i may have worded this incorrectly, as I see what you mean.
What I maybe should have said, is one never knows if you catch all conditions. Either because one simply doesn’t know all conditions, or, maybe because of system issues (eg an entity not yet being initiated) arise.
In this case there’s 1 service to be run under 1 known condition. One could leave it at that, and that could work out fine. Yet, conditions might arise. In which case the else clause takes care of that. It instructs the system to go on.
That is what I meant with a do nothing instruction. It is a positive instruction, a service to do nothing and continue. And thats why Id say there are more than 1 service.
Instead of simply not doing anything without an instruction, which could be a loop of infinity just as well, or any other system malfunction or deadlock.
Still , I see your point and maybe we should return to the OP’s question (…) and see if that can be handled by your solution, as I read his response it didn’t work out for him yet.
My problem is solved as I mentioned above. I used the dummy/continue script in the else block, which worked fine.
In my case I couldn’t place the condition as the last action, because there are some more actions which I can’t run first. So I would prefer some way to continue after a condition.
As said in my first post above I come from openHAB. The rules there are way more flexible and allow such things. I understand that there are a lot of differences between openHAB and HA and I don’t want to compare, but in my opinion this is an elementary functionality HA should have. My two cents.
Thanks to everybody in this thread for their time and the good discussion here!
Cheers
Norman
Because openHAB’s Rules DSL is more like using Home Assistant’s python_script and not the YAML-based automations.
That’s by design. You may have noticed that there’s virtually no python coding required to write an automation. It’s more like filling out a form. Naturally, that ‘form’ has its limitations and can’t be used to handle all situations. The next ‘degree of freedom’ is provided by python_script but it also has limitations (you can’t import modules). The ultimate flexibility is provided by AppDaemon. Plus there’s Node-red (also available for use with openHAB).