You're absolutely right — and I agree with every bit of that.
I also found that smart bulbs (especially RGB ones) can be unpredictable depending on the brand, command timing, and mesh health. That’s why I included a Custom Pattern Configuration option in VisualAlert, which lets users fine-tune the ON/OFF durations. Some bulbs really need that extra breathing room between commands.
I’ve tested with both Sengled and Philips Hue RGB bulbs. Hue bulbs — especially when used with the Hue Bridge — perform nearly perfectly every time. Sengleds were a bit hit-or-miss with some apps, but after some tuning using custom patterns in my app, I was able to get them to flash almost perfectly as well.
Of course, performance can still vary depending on your Zigbee mesh strength, the number of hops, and other devices in the network — so having that flexibility in timing really helps.
Thanks for sharing your insight — it definitely helps others who are working through the same frustrations!
BTW, I tested this setup with two Z-Wave switches in different rooms and one Zigbee RGB Sengled bulb — all devices ran in parallel as expected and successfully restored to their previous states afterward.
I even tested the Sengled bulb by setting it to one color, then flashing it using a different color — it still restored back to the original color without any issues.
single flashing works great. On then off in quick succession.
multiple flashing works great. on off on off done.
When lights are on (no group):
simultaneous works perfectly on the initial off. The on, there is a 1 second delay. This is not a complaint. Just letting you know how it's working.
single flash. The lights turn off, then there is a long 8-10 second delay before they turn on again. I think the the initial 'ON' is getting lost (or inconsequential) because the light it already on.
multiple flash. Same thing about the initial "on" being ignored. Lights turn off, on, off, then delay before returning back on. I think you mentioned that restoration will cause a delay, so that might be expected?
Further testing: multiple flashes work great nearly instantly. It's the restoration to previous state that is taking the extra long time.
Turning off "restore previous state" didn't change the behavior of the flashing or the sequence. Light that was on returned on at the end. Light that was off, remained off at the end.
I’ve noticed something similar on my end—my RGB bulbs sometimes have a brief delay before starting the flash pattern, while my Red Series Inovelli switches flash instantly.
Regarding the “restore previous state” option, I actually forgot to link that toggle into the new restore logic when I rebuilt it. Right now, it’s not doing anything, which is why you’re seeing the same behavior whether it’s on or off.
When I first implemented full parallel restore, the hub would send all the commands too quickly, which overwhelmed the mesh network—especially on Z-Wave. It turns out Z-Wave needs a slight pause between commands to stay reliable. So I added a delay to slow it down, and that seemed to fix the issue. Now it’s restoring every device that was flashing more reliably.
One change I’m considering for the next version is to end the flash sequence with all devices turned on, then restore them to their actual previous state afterward. That way, we avoid ending a pattern in the dark—even if the last flash was “off,” it’ll briefly turn “on” before restoring to “off” if that’s how it started.
Thanks very nice, I'm not deaf nor am I hard of hearing but when working in the shop this will come in very handy.
Did not install it yet, but a feature I did not see (unless I missed it), would be to flash the selected lights only if they are already on. This way in some places like my shop, if the lights are on, most likely I'm in there and working. If they are off, I'm not there and no need to flash them for nothing. This of course would most likely be only in some situations and other lights still need to flash.
It doesn’t have that specific feature you’re looking for, but it will turn off the lights after flashing if they were originally off—if that helps. The app is designed to restore any switches or lights assigned to flash back to their previous state before the flashing started.
My family and I usually watch movies together in a dark room for family movie night, so we’re all in there with the lights off—making light flashing really helpful. Sometimes I also leave the lights off when I’m reading a book on my Kindle in dark mode. It’s easier on my eyes, and I can actually read without needing my reading glasses. So yes, having the lights flash even when they’re off definitely has its benefits!
I think I might have not explained it right, what I had in mind is...
If the lights are on, FLASH the lights when an event happens like the doorbell.
If the lights are off, DO NOT FLASH the lights as for sure no one is in that room.
Right, I caught that in your earlier post—where you mentioned that if the lights are off, the room must be empty, so there’s no need to flash them. But in my case, it’s a bit different. We often keep the lights off intentionally while we’re still in the room, like during family movie night or when I’m reading in dark mode.
Also, during the daytime, we don’t use the lights in rooms that get plenty of sunlight through the windows. But even then, we still want to be visually alerted—for example, when the doorbell rings or another important event happens. That’s another reason why we need the lights to flash even when they’re off.
For us, flashing is important no matter the light state. I rely on these visual cues to know when something is happening, and I’m sure there are others in the same boat—people who are using a reading lamp, desk light, or just a screen, with the main lights turned off. So I really think it’s helpful to have flexibility in how the flashing logic works depending on different real-life use cases.
Previously, if Restore Last State was off, devices would just stay on after the alert finished — which was confusing.
Now, when Restore is disabled, all devices will automatically turn off after the alert.
This makes the behavior simpler and more predictable.
Toggle Switch Logic Fixed
We updated the logic behind the toggle:
Restore Last State After Alert (disabled = all devices off after alert)
This toggle had broken in the last update when we reworked restore logic. It’s now fully working again!
Tested & Verified
Tested with 4 switches and 1 RGB bulb:
RGB bulb changed color during the alert
All devices returned to off (or restored state) as expected
Everything worked exactly as intended
As always, thanks for your feedback and testing — it’s what keeps making VisualAlert better with every update!
VisualAlert v1.5.8 Now Available!
What’s New in v1.5.8
Improved Behavior When Restore Is Disabled
Toggle Switch Logic Fixed
Tested & Verified
