@123 No problem toggling it in Developer tools although probably shouldn’t go faster than 2 sec delay. Part of the problem may have been the delay but I also did a Run Actions with the sensor state=off (rather than on). WIth the sensor on (or the condition changed for testing), and a 3 second delay, it appears to be working. Thanks for your help.
That’s why I asked which integration you are using for the light. Some lighting technologies are unable to effectively control a device when commands are sent rapidly.
The other reason why I asked is that some lighting technologies have a native ability to flash a light (without having to receive a stream of on/off/on/off commands).
You’re welcome!
Please consider marking my post above with the Solution tag. It will automatically place a check-mark next to the topic’s title which signals to other users that this topic has been resolved. It will also place a link under your first post that leads to the solution post. All of this helps users find answers to similar questions.
@123 I am finding that sometimes the light is left in the on state even after the trigger is off. I thought that the while loop would be active toggling the light when the sensor was on and would turn off the light when the sensor was off.
alias: Flash light when gate is open
description: ''
trigger:
- platform: state
entity_id: binary_sensor.gate_sensor
to: 'on'
condition: []
action:
- repeat:
while:
- condition: state
entity_id: binary_sensor.gate_sensor
state: 'on'
sequence:
- service: light.toggle
target:
entity_id: light.gate_snd_lte
- delay:
hours: 0
minutes: 0
seconds: 2
milliseconds: 0
- service: light.turn_off
target:
entity_id: light.gate_snd_lte
mode: single
In theory, that should not happen. The repeat iterates only while the gate_sensor is on and ceases when the gate_sensor changes to off. The next action after repeat is a service call to turn off the light.
I recommend you add an id to the automation (and then Reload Automations). That will permit Home Assistant to create a trace each time the automation is triggered. Whenever the automation fails to turn off the light, quickly examine the last trace (there will be several) to examine what it did.
alias: Flash light when gate is open
id: flash_light_abc123
description: ''
trigger:
As an alternative, you can try this version which effectively does the same thing as the original version except it employs a repeat - until. It iterates until the gate_sensor changes to off and then turns off the light. I doubt this will work any better than the original version so my recommendation remains that you examine the trace to gain insight into why the final service call isn’t turning off the light.
alias: Flash light when gate is open
description: ''
trigger:
- platform: state
entity_id: binary_sensor.gate_sensor
to: 'on'
condition: []
action:
- repeat:
sequence:
- service: light.toggle
target:
entity_id: light.gate_snd_lte
- delay:
hours: 0
minutes: 0
seconds: 2
milliseconds: 0
until:
- condition: state
entity_id: binary_sensor.gate_sensor
state: 'off'
- service: light.turn_off
target:
entity_id: light.gate_snd_lte
mode: single
The light just turned on although the automation was not triggered, so I presume something else is turning this light on although I have no idea what. It is controlled by an X10 switch and the x-10 command is sent from an Omnipro which is integrated with HA via the Omnipro Bridge.
Ouch! Toggling an X10 device every 2 seconds? Small wonder it was unreliable when the delay was 1 second.
FWIW, I switched from X10 to UPB many years ago to get better reliability and functionality. UPB supports blinking a light natively. In other words, I can send a single command to start blinking a light and the device takes care of the rest.
Although I replaced the majority by either UPB or WiFi devices, I still have a few stalwarts:
Two outlets mounted outdoors (had three but that one failed 2 winters ago).
Two light switches in a 3-way circuit (slated to be replaced soon).
One heavy-duty plug that controls a 220VAC pool pump (over 12 summers of service so far).
I have a couple of UPB modules and the interface module. They are connected to the Omnipro but I can’t seem to get them to work when I send commands from the Omnipro. The Omnipro bridge has added them to HA but, obviously they cannot be controlled from there either. I thought perhaps I wolud take them off the Omni and put them on HA directly to facilitate troubleshooting but it has been a long time since I installed them and I don’t recall how to do it.
Thanks. I clearly don’t get to the developers page much.
Sadly, none of the dozen bulbs in my HA system from 4 manufacturers flash.
Plus, there’s a programming thing I cannot figure out, and might not even be possible in HA.
So the current plan is to simply build a standalone device, entirely outside of HA. Seems a shame, but I’ve already spent more time trying to program this (simple) functionality than if I’d just built it.
What exactly are you trying to do? Pretty much anything is doable in HA. You don’t need the bulbs to have a built-in flash function to get it to flash, as shown in the example above.
I have an aeration pump for my Koi pond. This pump NEEDS to be running 7x24 or the fish will die. (The pond is smallish for the number of fish and size of the fish.)
So I bought the nicest pump I could find … German and just a jewel of a device.
And yesterday it stopped pumping, nit because of a failure in the pump but because the GFCI powering it failed.
I was lucky enough to catch it in time THIS time, but next time …
So my plan is (was) to just plug in a Zigbee smart plug to the same power source and monitor for online/offline status of that plug using an automation.
Flashing with a repeat and toggle is easy enough, as described above. And triggering on offline is similarly easy.
But I CANNOT figure out how to get the “Until … Online again” to work. (I don’t want the lights to continue to flash away if all is in fact OK.)
The YAML editor finds fault with almost everything I’ve tried. The things it was OK with didn’t work.
At this point, a wee bit of external hardware from the scrap box is looking pretty good.
For those that might not yet know: The logbook correctly captures these events, you will see the on/off changes recorded. One method to prevent this is to exclude the related sensor from the recorder - this has the benefit of reducing wear on your storage (SD card, HDD, SDD etc) and keeps the logbook tidy. See the instructions here.