WTH is so difficult to make a light blink for a couple of seconds?

Archive Month of "What the heck?!" 2022
,
1

I have a simple use-case: I have notifications that I want to be handled by blinking lights. For instance, I might not hear the doorbell if I’m far away from the entrance, or if I’m listening to music using headphones. Thus, I can integrate my doorbell to my RPi (already done that using GPIO and a reed switch) and use HA to blink lights in my house (this is difficult).

However, Why The Heck is it so difficult to make a light blink?

What I expected: A service, something like light.blink, that would accept some parameters (duration, how many blinks, how fast to blink, color/temperature… yeah, stuff like that). Such service would work on ANY kind of light, and have the same behavior across all lights. After blinking, the lights would return to their previous state (on/off, transitioning from one brightness/color to another, whatever). Maybe the lights could have a new blink state besides on and off. Maybe it could just be an attribute blinking.

What we have now: A flash: short parameter to light.turn_on service. It seems to be handled by the light itself, which means the behavior across Philips Hue bridge and ZHA is different, and some lights don’t support it at all (e.g. Nanoleaf lights).

WTH, blinking a light should be something simple!

2

There are many use-cases for quickly blinking a light (or a set of lights):

  • Doorbell notification (there is someone at your front door).
  • Kitchen timer (it’s time to get the food out of the oven or turn down the heat of the stove).
  • Laundry finished (the washing machine or the drier has finished working).
  • Light selection (we could have one remote control controlling many lights individually: one button would “select” the next light (which should blink briefly to indicate the selection), and the up/down buttons would control the selected light).
  • Et cetera… Essentially, anything that deserves a notification could use a blinking light.

Over 1½ years ago, I started researching how to make a light blink. It’s not easy, and I took note of several links:

I was also thinking… If blinking a light can be implemented, maybe something I call “light animations” could be implemented as well. In my mind, “light animations” are a superset of the “blinking”. It would work like this…

The user would be able to define an “animation”, which is a sequence of light states. Something like “set light brightness/color to a certain state, followed by waiting for ‘x’ seconds”, and that repeated as many times as wanted.

Then, the user would be able to request HA to “play” a light animation either once or a few times. After playing, the light should return to the previous state.

With this basic framework, one would be able to easily define:

  • Basic blink: “turn on, wait 1 second, turn off, wait 1 second”
  • Blink 3 times: play “basic blink” 3 times.
  • Bright blink: “turn on 100% brightness, wait 1s, turn off, wait 1s”
  • Police-style blink: “turn on red, wait 0.5s, turn on blue, wait 0.5s”
  • Morse-encoded message: "turn… " okay, you get the idea, just adjust the wait times and then you can morse-encode any message

Like I said, this “light animation” framework would be able to create any blinking style. Still, there is value in providing a simplified user-friendly API (i.e. service call) to just blink without having to worry about too many customization options; but those options would still be available as part of the “light animation” feature.

In conclusion, while I believe this can be very powerful and very useful, I understand this can be “feature creep”. So, just having a basic “blink” would already create the most amount of value for users (and that’s what this thread is requesting anyway).

EDIT: Maybe, just maybe, this blinking feature should be extended beyond the light domain. Imagine having a smart plug that shows up as a switch. Then you can connect something dumb like xmas lights to the smart plug. Then… blinking the switch would blink the light. (I think recent HA versions added support for switches to behave like lights, no? I don’t remember, as I never had this use-case.)

11 Likes
3

Agreed! Here are a couple more use cases:

  • Blink all lights then turn all on when the home alarm is triggered
  • Blink bathroom lights when basement drain is flooding into the basement (aka drain is blocked). This one saved us 6 times in the last year… Long and dirty story.
4

I’ve helped users create scripts/automations that toggle a light repeatedly (i.e. “flash”/“blink”). It’s fairly straightforward and is based on a repeat statement and light.toggle service call.

A problem some users have encountered is that the fast, continuous stream of on and off commands serves to flood their communications network (zigbee/Z-Wave). The problem’s severity depends on the network’s robustness.

As a consequence, some commands fail to be received (resulting in an erratic flashing effect) and/or other commands sent at the same time are impeded. When faced with this issue, reducing the flashing frequency helps but then it doesn’t produce the user’s desired flashing behavior. It’s a YMMV situation; when it misbehaves it’s due to issues that are beyond the light integration’s control.

To ensure the flashing behavior is reliable and predictable, Home Assistant’s light integration relies on the device’s native ability to flash. Just one command is needed to instruct the light to toggle repeatedly. Obviously, this only works for devices that support this capability.

3 Likes
5

What if the light integration using a light.blink waited until it got the state change update before doing another toggle? Would that make it more manufacturer/protocol independent?

@123 have you tried that in a previous implementation in order to avoid specifying a repeat frequency and just using a repeat iterator?

6

Receiving an acknowledgement is already part of zigbee/Z-Wave communication protocol. Failure to receive a prompt acknowledgement implies a communication failure and causes Home Assistant to set the entity’s state back to its previous state.

FWIW, all my lights support native flashing (i.e. hardware-based flashing) so I have no incentive to experiment with various software-based techniques.

1 Like
7

And how do you ensure the lights return to their previous state? What if one “blink” command interrupts another already-running blinking? Does it mean having auxiliary helper entities? How many? (And doesn’t it sound like too much work for something simple?

Fair point, I suspected this could happen, but I still don’t know the bandwidth of such networks. (And I never researched that.)

However, there are lights that are Wi-Fi-based, which shouldn’t have bandwidth limitations like that.

To address both use-cases, the “blink” service call could have a parameter to prefer using “efficient”/“native” blinking, which would conserve bandwidth for such protocols. The key word here is “prefer”: if the light has no bandwidth problems, or specially if the light doesn’t have native blinking (e.g. Nanoleaf integration), then HA should handle it automatically. Because when the user wants a blinking light, the user doesn’t want to care about special cases for each lamp: HA should simplify that and unify it into a single sane API.

1 Like
8

I imagine they would also want the technique to work reliably and that’s likely why developers have focused on making it available exclusively to devices that support flashing natively.

I’m not necessarily disagreeing with your proposal. I’m simply pointing out that implementing it requires a fair bit of work that may ultimately produce a result that falls short of expectations. You said users don’t want to care about special cases, but I’m sure they’ll care if the software-based flashing effect is erratic or inconsistent.

3 Likes
9

Can’t you use light.toggle in a repeat loop?

If you repeat in an even number of times the light will end up in the same state it was at the beginning. And this will be a solution to support multiple lights regardless their settings.
You can create in a script and it will be very similar to what you are asking for.

repeat:
  count: "6"
  sequence:
    - service: light.toggle
      data: {}
      target:
        entity_id: light.bathroom_mirror_light
    - delay:
        hours: 0
        minutes: 0
        seconds: 0
        milliseconds: 250
4 Likes
10

Kind of what I was thinking too. If you make this into a script blueprint and pull out the repeat count, entity ID and delay time into inputs I feel like that’s your light.blink service right there.

11

Ok, just realized other people suggested the same.

12

Yes, it’s common to employ repeat.

Your example uses a delay of 250 milliseconds (4 commands per second per light). If your lights are based on zigbee, try your example on several lights to see how well they behave. It may work with one light but as you add more lights it increases the number of commands per second and you may start to notice degraded performance.

3 Likes
13

You are right as usual, @123. As I add lights and reduce the delay it starts behaving really odd, but most likely for blinking a couple of lights in a not so short interval it would work fine.

I’ve tried as an automation blueprint:
Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

1 Like
14

Yeah, it makes more sense as a script:

image
image1508×916 39.8 KB

As a script:
Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

2 Likes
15

FWIW, the same situation occurs when attempting to emulate transition. There are scripts that ramp brightness and they work reasonably well with a light or two. However, as you’ve discovered for emulating flash, increasing the number of lights can cause erratic behavior due to substantially increased zigbee network traffic.

That’s why transition and flash are implemented exclusively for devices that support the features natively.

1 Like
16

A side point to consider when changing the state of lights… there may be other automations tied to the changing state of the light(s). You run the risk of causing a cascade of other actions.

This is among the reasons some lighting systems have a specifically separate security or flashing state, so something that tracks the light being turned on, or off, won’t misinterpret the flashing as repeated on/off changes.

1 Like
17

Hello @EdwardTFN! I’m trying to import this blueprint into my HA and it shows an error saying “No valid blueprint found in the topic. Blueprint syntax blocks need to be marked as YAML or no syntax.”

I also tried to copy and paste this into a script (Scripts > Add Script) and it says “Message malformed: extra keys not allowed @ data[‘blueprint’]”.

I’m really interested in implementing this method in my HA, could you point me on the right steps to follow?

Thank you!
Rodrigo

18

I don’t know why the original links are failing,mbut please try those (using GitHub instead):

As an automation:
Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

As a script:
Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

Please let me know if you still having issues with those links.

19

I tried with both links and they show this message:
image
In the meantime, I was able to import another script using the same method, so it seems that the problem is with these specific URLs…

R.

20

Mmmm…

Those 2 links are working for me.

Let me investigate a bit more…