Bulb won't stop flashing

Using Sengled E11-G23 bulbs with the Advanced Zigbee Bulb driver, with 2.2.6.139.

I inadvertently set off the HSM intrusion alert when I arrived home today, then disarmed the system using an Xfinity keypad. All worked as expected, except one bulb (living room lamp) of the five that flash on alert, continued flashing. Tapping the bulb's icon on a dashboard did nothing, nor did clicking On or Off from the device's menu page. The only way to stop it from flashing it was to hit the menu's flash button, twice.

This happened a very few times before on 2.2.5, however I never had the time to take a look at things. I recreated the condition by pressing an Iris V2 keypad's Panic button, then disarmed the system. This time the Front Door bulb would not stop flashing.

Looking at the Front Door Bulb's menu while the bulb is flashing, the state "flashing" setting was false, and like before ON and OFF buttons did nothing to the bulb, although the device's menu status current states "switch" status changed matching the On or Off press.

It should be noted that other than this issue, everything works well with the bulbs, they quickly react to commands, and there are sufficient zigbee repeaters in the mesh. Also, removing power from the bulb stops the flashing when power is restored. There are no errors in the log.

Bulb status while flashing
image

image

Tagging: @mike.maxwell

1 Like

There's a Sengled element classic driver for this bulb. Not sure if it will solve your problem but worth noting.

Yes, but it does not have the flash command :thinking:, nor the "power restore state" I use.

Well, since you're using an alternate driver, not the offical driver for that bulb, how about creating a rule that uses custom commands to activate the flash command in that driver for that one bulb and changes the HSM state. Then always use that to disarm HSM.

Not perfect, but usable.

HSM works well getting the bulbs to flash, and generally stops flashing on disarm. I suspect this is some sort of missed zigbee command in the bulb creating a condition that is then mishandled by the driver and or bulb.

I prefer not interjecting RM into the HSM alert process.

Far from the hub? Sengled don't repeat so if they're too far you need a repeater within range of them if they're not close enough to the hub. Another Sengled bulb won't repeat for them.

I see this same behavior after an intrusion alert. same bulbs same drivers.

I'm using a custom app for this. To start the flashing i was using the "flash" command and to stop the flashing I was using the "off" command. That was working.
Maybe i'll need to use the "flash" command again to stop the flashing and then "off" to turn the light back off.

1 Like

I have six zigbee repeaters in the house, including two getting signal into my almost Faraday cage like concrete garage. As I mentioned on my initial post everything else works with the bulbs, and they react quickly. Tap flash command twice when this occurs and it immediately stops the flashing.

The flashing won't stop issue also occurred a while back on a bulb about 7 feet of direct air space from the hub .

I use Sengled bulbs because they don't repeat.

few things, when changing drivers, particularly zigbee drivers, configure must be run.
The advanced drivers flat out will not work correctly if this isn't done.

State variables aren't updated dynamically like device current states, so trying to get meaning from these values while they are changing internally isn't going to help debugging.

When all the devices that have flash implemented are flashing, the device switch state is not updated while flashing is in progress.

In general all devices that have flash implemented should stop flashing when any of the following are executed, flash, on, off.

Before using this command in a driver that wasn't specifically designed for the device its being used with, make sure that flash behaves as described above via the device ui first.

That was done when I changed drivers back on 2.2.5.

That works except when the odd bulb continues flashing after an intrusion with flashing, followed by a disarm then ON and OFF have no reaction in the physical bulb

Have done this many times without an issue.

Just removed the bulb turn On with the Panic lighting alerts, tried it a few times and could not recreate the issue.

image

Spoke too soon. tried again and the switch repeaters, not bulbs but a switch with a bulb plugged in, one flashed, one remained on, but both reacted to the dashboard On and Off.

Update2: this is not a solution. Just tried it again and the Front door, living room, and office bulbs are flashing and wont react to On and Off commands :man_shrugging:

What does your Zigbee routing look like?

http://[yourhubIP]/hub/zigbee/getChildAndRouteInfo

Kind of strange. What's child 2 and child 4, anyone? Also many devices not showing on report.

the interesting bit here is that flash actually uses the device drivers on and off commands.
I would try this before giving up trying to use the sengleds with the advanced drivers, try changing the flash interval for these bulbs something like 2 to 3 seconds, see if that helps.

Don't see a flash interval setting.

Should that url work on all hubs / versions? I get a 404 when I try that command.

And I just found the On and Off commands work while the bulb is flashing priot to canceling the alert, but not if they fail to stop flashing afterwards

I set logging on the Living Room Bulb then tried the Panic alert a few times until the bulb would not stop flashing. It says it turned off, but it is flashing. Result follows:

Replaced this with your actual hub IP?

Here's an example where the bulb worked as expected in an HSM Panic event. When the system was disarmed at 16:01:30 there is an OFF command, followed in 3ms by a Flash, seems odd.

Yup. With 4 different hubs.