Im having a problem where I have two automations that are triggering however only the notify action is working when they are automatically triggered by the sensor the fan switch doesnt toggle. If I manually trigger the automations or manually change the state of the sensor both actions work fine.
The config:
- id: '1554661122087'
alias: Cool Media Closet
trigger:
- above: '89.9'
entity_id: sensor.vision_security_zp3111_multisensor_4in1_temperature
platform: numeric_state
condition:
- condition: state
entity_id: switch.media_closet_fan_switch
state: 'off'
action:
- data:
entity_id: switch.media_closet_fan_switch
service: switch.turn_on
- data:
message: Media closet too warm, turning fan on
title: Media Closet Fan
service: notify.ios_my_iphone
- id: '1554661346041'
alias: Cool Media Closet Off
trigger:
- below: '85.1'
entity_id: sensor.vision_security_zp3111_multisensor_4in1_temperature
platform: numeric_state
condition:
- condition: state
entity_id: switch.media_closet_fan_switch
state: 'on'
action:
- data:
entity_id: switch.media_closet_fan_switch
service: switch.turn_off
- data:
message: Media closet cool, turning fan off
title: Media Closet Fan
service: notify.ios_my_iphone
Both automations are enabled:
And I can see in the log book that the automation is trigger and im getting the notifications on my phone
While it doesn’t make any sense to see the results you are seeing in your automations, the only thing I notice that looks strange at all is that you are using a string instead of a number for the numeric_state in your trigger. Normally you would write those without any quotes around them. However, I would think that it would cause the automation to not trigger at all instead of just performing part of the actions.
but just as a test you could try to remove the quotes to see what happens. Other than that everything looks OK to me.
- id: '1554661122087'
alias: Cool Media Closet
trigger:
- above: 89.9
entity_id: sensor.vision_security_zp3111_multisensor_4in1_temperature
platform: numeric_state
condition:
- condition: state
entity_id: switch.media_closet_fan_switch
state: 'off'
action:
- data:
entity_id: switch.media_closet_fan_switch
service: switch.turn_on
- data:
message: Media closet too warm, turning fan on
title: Media Closet Fan
service: notify.ios_my_iphone
Those were created from the UI, so thats probably why they ended up that way. I just updated the config and restarted, I’ll report back here as it updates.
I reversed the order of the actions this morning now notify then switch and it seems to be working. I haven’t had a chance to look at the code yet, but i suspect this is a bug.
That’s one of two things done in the example I posted above.
I provided the example as part of an experiment to identify the cause of this issue. It not only reverses the order of the actions but integrates the original condition into the trigger. The goal here was for you to try the example as-is first. If it worked, the next step would be to put the actions back into the order you had (controlling the switch first, then issuing the notification). If that arrangement:
Failed, then it suggests there’s a quirk with the order of executed actions.
Succeeded, then it suggests the original condition caused the issue. Specifically, some sort of strange timing problem with a condition checking if a switch is in one state followed by an action that changes it to its opposite state (that’s the ‘long-shot’ I mentioned earlier).
If you’re not interested in trying the experiment then, based on your recent findings, it’s still inconclusive as to what is causing the problem. Moving the switch activation into the second position, effectively puts ‘distance’ (in terms of milliseconds of time) between the evaluation of the condition and activating the switch. This extra time may not be necessary if the condition is integrated into the trigger.
Knowing more about how this problem is caused is helpful when attempting to describe it as a GitHub Issue.
@123 your solution works as well. It also had the effect that constantly updates the switch rather than just triggering once (which is good & bad). Specifically if I want to turn the switch on at a lower temp, this doesnt allow that. But I could just disable the automation when I do that, so NBD.
Yes, the template will be evaluated whenever the temperature sensor changes state. However, don’t forget that the numeric_state trigger is effectively doing the same thing ‘under the hood’. Whenever the temperature changes it compares it to the above threshold.
Say the temp is 80 and I manually turn the switch on, this automation will instantly turn the switch back off b/c it triggers on the state of the switch + the state of the sensor. The original one only triggered when the state crossed the temperature threshold.
Thanks for the clarification. Yes, you’re absolutely right. The Template Trigger is now monitoring the switch as well. So if you manually turn the switch on or off, the Template Trigger will detect the change and evaluate the template (and potentially undo your action).
Like you said, that can be good or bad, it depends on the requirements.
Good if you don’t want to allow the switch to be turned off when the temperature is above the threshold. It will detect the switch was turned off and, because the temperature is still high, will turn it back on. Your original version can’t do this because it only monitors the temperature.
Bad because now you lose the ability to manually control the switch when the temperature is below the threshold. Your original version allows you to manually control the fan at all times.
Have you tried the second part of the experiment? Change the order of the actions in my automation so that the notification is last in the sequence.
If it fails then it means this issue is all about the order of the actions.
@123 Just tried reversing the actions, still worked. I’ve been triggering it by the switch and I want to make sure we test this with the temperature change as well. It’ll be a couple hours before the room is warm enough to trigger the fan. But I’ll update here when it does.
Thanks for performing all the tests. Interesting results! It appears the order of the actions is important when the automation uses a condition. Without a condition, the order is not critical.
The condition checks if the switch is off, then the first action in the sequence turns the switch on. This arrangement results in a problem (it fails to turn the switch on). Moving the action to be second in the sequence, cures the problem.
Without question it should not behave this way; the sequence order shouldn’t matter.
I tried to duplicate your results using an input_number and an input_boolean. The automation monitors this input_number:
However, the order of the actions was not critical and the first action was always executed. So this simple experiment failed to duplicate your results.
Maybe the platform your switch is using influences the automation’s behavior?
