I am sure that this is easy, but I haven’t found an answer on the board.
I have drapes and blinds that are automated through InfraRED. The drapes are triggered from a Harmony hub and the blinds from a Broadlink Pro.
When HA restarts, it fires again the last command that was sent. This didn’t bother me too much for the drapes, but for the blinds, it grinding the plastic gears.
Is there something that I can put in my configuration/automation to stop the IR to fire back after reboot?
After more research, i have included “initial_state: False” in my automation.
Seemed to work for this first test reboot. Please let me know if you find or are using a different solution.
If you’re narrowed it down to an automation that is firing after restart when you don’t want it to, you might want to post that automation here. Maybe there’s something else that can “fix” it besides having it off at startup (which I assume you then have to turn on at some point somehow, probably through another automation.)
@pnbruckner - Thanks for your reply, that would explain why my blinds didn’t open up this morning. I see that the automation is “off”. So I guess I am still searching for a solution. Here is my automation, the first part is the automation to trigger just before sunrise, it turns off my input_boolean, the second one acts on the stage change of the input_boolean. I have a similar setup for closing the blinds as well.
What is happening is that after a restart or reboot, it seems like the application is trying to catch up and make sure that some of the recent event are executed, and it triggers them again.
- alias: "Office Blinds Open Dusk"
hide_entity: True
trigger:
platform: numeric_state
entity_id: sun.sun
value_template: '{{ state.attributes.elevation }}'
above: -1
action:
- service: input_boolean.turn_off
entity_id:
- input_boolean.office_blinds
- alias: "Office Blinds Open"
hide_entity: True
initial_state: False
trigger:
platform: state
entity_id: input_boolean.office_blinds
from: 'on'
to: 'off'
action:
- service: switch.turn_off
entity_id: switch.power_ease_office
- delay: '00:00:03'
- service: switch.turn_off
entity_id: switch.power_ease_office
I’ve kept the “initial_state: False” in this automation, but would love to find another solution. If I am forced, I may try to find a way to re-enable these automations a few minutes after a restart, but would rather do it the right way if possible. I just can’t have the gears grinding as it’s trying to close blinds that are already closed.
If anyone one have any ideas, it would be much appreciated.
Interesting. Just moments ago I was explaining to someone else how the numeric_state trigger works. 
Normally for a numeric_state trigger to fire the value has to “cross the threshold.” I.e., in your case the sun elevation would have to go from -1 or below to above -1. That’s because once the trigger has fired it remembers that the “condition” has been met (i.e., above -1), and the condition would have to become false (i.e., -1 or below) and then true again (above -1) for the trigger to fire again.
But at startup it’s a bit different. At startup the condition is tested and if it’s true the trigger will fire! It doesn’t have to first be false and then become true. So, when you restart HA, if the sun elevation is below -1 this automation will fire.
To me, this is a bug, but it’s worked this way so long that changing it now would probably break zillions of existing automations.
One way I’ve seen people deal with this is to enable the Uptime Sensor and then add a condition to the automation that the uptime must be above a certain value. That way when the automation’s trigger is first evaluated, even though it will fire, the condition will prevent the action from actually running. This will then “cock” the trigger so that it won’t fire again until its numeric condition becomes false then true again. Let me know if you need any help coding that.
@pnbruckner . Thanks again for your reply. I tend to agree with you that it seems like a bug, but I’m OK with a workaround. I wanted to take a stab at including this Uptime Sensor, so I am including my revised version below for your review and see what you think. I had an uptime sensor already created with a unit of measurement in hours. I would prefer to keep it that way as I like to see the uptime in hours, but I assume that I could also include a second sensor in minutes if need be … correct? The goal here is to not fire this automation unless Home Assistant has been up for 2.5 minutes or more. Hoping that this is enough time, but I can always re-adjust.
My Uptime Sensor setup:
- platform: uptime
name: 'HASS uptime'
unit_of_measurement: hours
Updated Automation:
- alias: "Office Blinds Open"
hide_entity: True
trigger:
platform: state
entity_id: input_boolean.office_blinds
from: 'on'
to: 'off'
condition:
- condition: numeric_state
entity_id: sensor.hass_uptime
above: 0.04
action:
- service: switch.turn_off
entity_id: switch.power_ease_office
- delay: '00:00:03'
- service: switch.turn_off
entity_id: switch.power_ease_office
Now that I look back at this again, did I put the condition in the right automation? Or should I put it in the entry that has the numeric state change, meaning the first one?
That should work, but yes, the condition should have been added to the automation with the sun elevation trigger.