Hi,
Please check out:
I have created an empty service that does nothing. It can be used in service templates within automation to skip actions in specific case.
3 Likes
I use a script called script.dummy for that purpose. It only contains a 1 millisecond delay. What is the advantage of a custom empty service?
It is true that scripts can be used instead, at least for me use of empty service feels more natural than starting dedicated script. It was my small project and my intention was to share my approach to the problem in case someone finds it more convenient.
From performance perspective service call triggers function, which in custom service case does nothing and immediately replies, so no impact on CPU resources to perform any more actions.
My use of this service:
- alias: ''
service_template: >
{% if is_state('binary_sensor.someone', 'on') %}
{% if is_state('switch.entrance_camera_motion_detection', 'on') %}
camera.disable_motion_detection
{% else %}
none.none
{% endif %}
{% else %}
{% if is_state('switch.entrance_camera_motion_detection', 'off') %}
camera.enable_motion_detection
{% else %}
none.none
{% endif %}
{% endif %}
data_template:
entity_id: camera.entrance_camera
You can also use conditions within an action to permit execution of the service only if the correct conditions are present.
In your example, the service is executed only if the binary_sensor and switch have the same state. If they do not, then no service should be executed. So all we need is a condition that ensures the binary_sensor and switch have the same state (i.e. if they do not have the same state then execution stops at the condition and does not proceed to evaluate the service).
- alias: 'Example'
trigger:
- <your trigger>
action:
- condition: template
value_template: >
{{ states('binary_sensor.someone') == states('switch.entrance_camera_motion_detection') }}
- service_template: >
camera.{{'disable' if is_state('binary_sensor.someone', 'on) else 'enable'}}_motion_detection
entity_id: camera.entrance_camera
1 Like
I have some rather complex conditions and need to execute multiple independent actions within automation (it is just one of them). Conditions resulting in False stop the execution and creating multiple automation with same trigger creates a lot of duplicated code, which gets time consuming with modifications. In my case it is simpler just to skip action within one automation.
There are different options for sure, i’m just sharing how i solved it in my case with custom service.
If anyone else wants to use it, it is available on github.
There are cases where service or script would be better then conditions, but yes, conditions also work.
Everything you said is true but my response was for the example you provided, not as a general response to every possible use-case.
The community appreciates the addition of your custom component. Emphyrio and I simply pointed out that there are existing built-in methods to handle this situation. Now there is yet another way, using your custom component.
Agreed, it is nice to have options. My personal preference is to stick as much as possible to options that are available in core Home Assistant.
Thank you for this. I was struggling to get some presence driven automations working and none.none solved my issues!
This is an old topic and since it was posted there are new, more flexible ways of calling services that eliminate the need for an ‘empty service’.
I searched for solutions for what I was trying to do and couldn’t find anything but this. Can you point me in the right direction to what you’re talking about?
Just from my experience some services accept additional junk data and done don’t. For example I had complex templates with a lot of IF statements and only in specific conditions one or another service had to be called, or none at all. Also I had multiple stages and interrupt automation with condition meant duplicated code of templates, which I often tuned. As result I created this empty service for my specific case. Now I changed automation to python script instead.
So there are multiple ways to go around the problem: change automation structure, use empty script or this service, switch to python scripts etc.
For as long as it works and you are happy with a result you may select any
The simplest way is to include a condition that rejects all cases that need to call a dummy service. The condition can also be located within the action (examples are shown above).
For more complex situations, use choose. It allows you to define multiple choices where each one can call a different service. If there is no match for any of the available choices, it can either finish with a default choice (a ‘catch-all’) or simply exit without doing anything (equivalent to calling a do-nothing dummy service).
1 Like
Triggered by @123’s response, a bit of rationale to the following: Home Assistant has matured and there are better ways to define your automation logic. Below I’ve added the “do nothing” script mentioned in the thread before, however, there are other ways to solve this.
Choose
Have a look at the choose action, it should enable you to avoid the case in which you want to do nothing by building a better automation logic all together. Script Syntax - Home Assistant
Empty Action
Within an automation or within one option of a choose action, you might want to permanently or for testing purposes pass without any action. In that case you can define an empty yaml list:
action: []
# or
sequence: []
Do nothing Script
The above should solve all use cases. If you are still not happy, you can consider the following helper script as a intermediate solution:
script:
do_nothing:
alias: "Placeholder service that does absolutely nothing (pass)"
sequence:
delay:
milliseconds: 1
This topic is ancient and showing people how to conveniently create and use a dummy script is not doing them any favors. A dummy script is an anti-pattern.
The use of a “do-nothing” script is a kludge from Home Assistant’s past, before choose became available.
The best practice is to structure the logic’s flow correctly (potentially using choose) to avoid
“programming oneself into a logical corner” and calling do-nothing scripts.
@123 all topics, ancient or from one day before, are here to exchange and store knowledge. The above thread did not conclude with a final example of the dummy state solution, which I have added.
Is there a better way to solve most problems people (especially beginners) might have, most certainly! Are there specific use cases for a “do-nothing” action that doesn’t do anything but holds logical meaning? Most certainly! I will however admit, that I have found a better solution for my specific use case and I have edited my post above accordingly.
I admire your passion but please do not assume that every intended behavior can yet be flawlessly be represented by Home Assistant’s automation building blocks.
It (the do-nothing) remains bad advice for new users.
I enjoy learning new things so please provide a few examples that have no other solution but to employ a do-nothing script.
1 Like
Updated above.
Sure, I’ll summarize my use case. Within an automation I use the choose construct to differentiate 6 possible states of an entity. The default is used to error out on any invalid states and report to the log.
Among the valid states the sixth state is the “disabled” state. It is a valid state but the automation shall not trigger any service, while in it. that is where I needed the “do nothing” action, however I realized later that an empty yaml list will satisfy the linter and my logical expectations 
Hope that helps
?
If one of the six states requires no action, why include it as a choice in choose? Each choice is for doing something. If there’s nothing to be done when it occurs, don’t include it as a choice.
Well think about it. Most importantly, the sixth state is a valid state and might get some action at a later point. Hiding it from the logic will make maintenance and evolution of this code harder. Secondly, if not added as an option the state would be caught be the default clause.
Each choice is for doing something.
Nope, that’s just bad software engineering
Maybe think about this: The pass Statement: How to Do Nothing in Python – Real Python (the same construct exists in all other languages. Even in C a simple ; will to the trick)
We’re still taking about Home Assistant’s scripting language, right? The one that only received rudimentary flow-control in July 2020?
To put this into perspective, the majority of users here are challenged by writing a basic Jinja2 template and you’re promoting software formalism using an old hack whose origin had nothing to do with best practices. 
True. The traditional way to exclude it would be an “inline” condition within default. Easy-peasy.
However, I will grant you that making it an option provides better visibility and is effectively self-documenting: “this state is known and valid but is ignored here” (heck, even creaky old VBScript’s select case supports that). All the better, and cleaner, if achievable with an empty sequence as opposed to explicitly calling a do-nothing script (which remains a crufty old hack).