Hi.
Using mqtt_room to determine mobile is in room (office) vs. not_home.
I have an automation that turn on light based on zigbee motion sensor.
I want to leverage the ESPresense module to determine that if my mobile phone is in the room, to NOT turn off the lights.
The reason is that the motion sensor doesn’t always detect my motion so it turns off the lights while I’m in the room.
I also don’t want to use the automation to turn on the lights based on espresense, because it’s too hard to calibrate it.
So I thought why not utilize motion detection and espresense to decide if and when to turn off the lights.
The problem is that I’m not successful in creating the automtion.
I get If: Error: undefined when viewing the Trace Timeline.
Don’t nest If/then actions, use a Choose action instead.
Take care with you selection of conditions. Using a state condition re-checks the state. This may not be an issue most of the. But, when you are using something that is “hard to calibrate” or that changes often enough that you need to use a mode other than “single”, and you’re using the same entity as the trigger… consider using Template conditions based on the trigger variable or a Trigger condition.
Another option would be to add a for/duration to the state condition so that momentary bounces of the occupancy sensor don’t cause unexpected results.
I don’t know how to create a for loop. I’m still learning this automation bit.
nesting the if/then statements seems logical, why is it not recommended?
how does one know when to use templates? how did you create it?
p.s. - may I DM you for assistance with another automation of a rotating knob controlling light hue/temp? willing to pay for your time.
p.p.s - I just tested the automation you kindly provided. I covered the motion sensor and made sure my phone is not in the room (== not_home).
What I got was:
expected: turn off the lights.
could it be that I’m using the sensor.galaxy_s23 incorrectly? this entity has only a distance attribute.
The not_home is something I wrote manually. It’s not auto populated by HA in the drop-down menu.
There are no loops in what you posted. Please clarify.
I don’t know if there is a technical reason or if it’s more an anti-branching philosophy… but, the docs specifically say:
This action supports nesting, however, if you find yourself using nested if-then actions in the else part, you may want to consider using choose instead.
The automation I posted using choose could be simplified/reorganized a bit more to reduce the number of condition checks necessary.
Templating is one of the most powerful and useful features in HA, but it isn’t necessary for most automation. You could accomplish the same thing using a Trigger condition. But, once you learn to use templates, you may find that you use them everywhere because they are more flexible and faster to set up than other options.
Yes, it could definitely be an issue if you are requiring a state that the sensor is never going to be in… What integration did the sensor originate from? Post a screen shot of the entity’s info from the Developer Tools > States tool and/or post the Trace json so we can see exactly what happened (From the Trace viewer, go to the top right and click the 3-dot expansion menu, then select “Download trace”. Copy/paste the contents of the json file to a new forum post)
I don’t use Espresence, but you likely want either a Not condition…
- not:
- condition: state
entity_id: sensor.galaxy_s23
state: gil_s_office
or a Template condition that does the same type of thing…
- condition: template
value_template: "{{ not is_state('sensor.galaxy_s23', 'gil_s_office') }}"
Looking at the trace, the sensor’s state when the automation was triggered was gil_s_office, so you may need to just turn off the phone for a few minutes before you test again.
Is there a case where the phone becomes not home and you want the lights to stay on? If so, you may need an automation/script to handle that side of the light control with it’s own logic. If not add that as the trigger instead of chaining triggers and waiting. There are definitely cases where waits and delays are needed, but most of the time using the event closest in time to your desired action is the best option.
just to test the scenarios of switching on, then the automation doesn’t work at all.
I expected the lights to turn on without a scenario of switching off.
Second, And conditions only act on the conditions that are nested underneath them. An And with only one condition listed under its conditions is functionally the same as not having an And condition.
#And conditions work as follows
- condition: and
conditions:
- condition: sun
before: sunset
after: sunrise
before_offset: "-01:00:00"
- condition: template
value_template: "{{ trigger.to_state.state == 'on' }}"