👋 Introducing VisualAlert – A Smart Flashing System Designed by a Deaf User for Real-Life Needs

⚙️ Custom Apps and Drivers Custom Apps
1

Hi everyone! :wave:

I'm Deaf since birth, and like many of you in the smart home space, I’ve been building automations to help make my environment more accessible. One thing I needed was a way to visually detect different types of events around my home — not just a flash for everything, but a unique flash pattern depending on what triggered it.

So I created VisualAlert, a Hubitat app designed for people like me who need more than just a simple flasher. :tada:

:link: GitHub: GitHub - TechBill/visualalert

:wrench: Installation

  • :white_check_mark: Install via Hubitat Package Manager
    (search for VisualAlert — or manually add the packageManifest.json)
  • :white_check_mark: Or install manually via Apps Code

:bulb: Why I Built This

Yes, I know there’s already a flasher app out there, but I had a very specific goal:

I wanted a flashing system where each event has its own pattern, so I can tell what triggered it — without using colors or RGB bulbs.

  • :door: Doorbell: short-short-pause
  • :fire: Smoke or CO: rapid pulsing
  • :package: Mailbox open: slow fade
  • :person_standing: Motion: soft blink
  • ...all from just the ceiling lights or regular smart switches

This is super helpful if you’re Deaf or hard of hearing like me, but I imagine it could be just as useful for others — like in noisy environments, homes with kids or elderly parents, or places where discreet visual cues are better than sound.

:test_tube: What Devices Work Best?

  • Works great with on/off or dimmable switches
  • :white_check_mark: RGB bulbs work okay for simple flashing
  • :warning: But rapid flashing on RGB bulbs can sometimes cause flickering or missed flashes — best to use custom patterns and tweak timing for your bulb type

:house: My Old Setup vs VisualAlert

I used to flash my entire room’s ceiling light using Z-Wave switches, and have a floor lamp with an RGB bulb that lit up in color based on the trigger — but it never gave me flash-based feedback about what happened.

Now, with VisualAlert, the flash pattern itself tells me what triggered it — and I don't need to rely on colors anymore. It’s way more reliable and doesn’t require expensive RGB bulbs.

:pray: Try It Out & Share Feedback!

This app was coded with the Deaf community in mind, but I truly believe others may find it useful for different needs too.

Feel free to give it a try — I’d love your feedback or ideas. I do have some features I’m considering adding, but I want to run some tests first to make sure it doesn't push the Hubitat hub too hard performance-wise.

Thanks for checking it out — and stay alert! :wink:
– Bill

31 Likes
2

Sounds like this will be fun, thanks very much for your addition to the community!

3 Likes
3

Very nice app. So many options yet very clear what everything does.

I've already replace some flashing sequences with your app. Would it be possible to add an option to trigger if something turns off? e.g. One child app will flash once if the door opened switch turned on. Another child app would flash twice if that switch turned off. Maybe a toggle at the top of Trigger Sources?

One small issue. If the light is already on, and Restore Previous State after Alert option is on, when the flashing is complete, the light doesn't return back to being on. I might be misinterpreting that option?

2 Likes
4

I can try adding that feature in the app — I didn’t think anyone would find it useful, but it actually makes a lot of sense. I’ll look into it when I get some free time to work on improvements. Thanks again for the suggestion — really appreciate it!

Thanks! Glad to hear you're finding it useful — I really appreciate the feedback. :pray:

:arrows_counterclockwise: Restore Previous State

Yes, that option is meant to do exactly what you described: restore the light to its original state (on/off, level, color, etc.) once the flashing is done.

There is a brief delay before the restore happens — that's expected — and I’ve also noticed that on the first run right after installing the app, flashing behavior can be a little off. But after that first test, everything usually stabilizes and works reliably going forward.

If your light isn’t returning to the correct state, here’s what I recommend:

  1. Go to Advanced Configuration in the child app.
  2. Enable Debug Logging.
  3. Trigger a flash.

In the log, you should see something like:

  • “Saving current state…”
  • And later: “Restoring previous state…”

If you don’t see those entries, or it’s not restoring as expected, let me know — I’d be happy to look into it further when I get the time to do so.

5

:rotating_light: VisualAlert v1.1.5 Released!
New feature + bug fix update :tada:

:link: GitHub - TechBill/visualalert

:white_check_mark: What’s New in v1.1.5

:new: New Features:

  • In Trigger Sources, you can now choose whether to trigger the alert when a switch turns ON or OFF (instead of just ON).
  • In Disable Alert, you can also now choose whether the disabling switch should stop alerts when it turns ON or OFF — gives more control over how alerts behave.

:beetle: Bug Fix:

  • Flash patterns should now work on the first test after installing a new child app — no need to enter and exit the pattern configuration to "kickstart" it anymore.
1 Like
6

I updated the app with that option where you can pick if the switch is either in on or off state to trigger it.

2 Likes
7

I was seeing that and a lot of really thorough debugging log. Well done!

I see the new update. I'll try it and let you know.

1 Like
8

:rotating_light: VisualAlert v1.2.0 Released!

Custom Pattern Builder + Reliable State Restore :tada:

:link: GitHub: GitHub - TechBill/visualalert

Version 1.2.0 includes powerful new features and a major reliability improvement for restoring previous light states after an alert.

:new: New Feature: Advanced Custom Pattern Sequences

You can now define complex flash patterns using a simple text input field like this:

ON:1000,OFF:500,ON:200,OFF:1000

Each pair represents a step in the flash sequence. You can create as many steps as you want and the pattern will loop during the alert. Great for things like:

  • Doorbell (quick burst)
  • Smoke/CO alerts (long pulses)
  • Mailbox or motion (gentle ping)

:hammer_and_wrench: Major Fix: State Restore Now Reliable

In previous versions, restoring the device’s previous state after a pattern ended (or was stopped manually) could sometimes fail.

This update completely overhauls the restore logic:

  • Uses atomicState and JSON to safely store and retrieve device states
  • Adds a reliable stopRequested flag to ensure the correct process restores the device
  • Handles all exit cases: manual stop, physical button, and finite pattern completion

Result? :100: Your lights should now return to their correct state every time, as long as the "Restore Previous State" option is enabled.

:wrench: Other Improvements

  • Added new helper libraries for JSON handling
  • Improved UI instructions in the custom pattern section
  • Cleaned up edge-case behavior for pattern builder inputs
3 Likes
9

Made an another change on restore previous state logic .. hope this one work better than previous logic.

1 Like
10

Whoops .. I forgot to git push the update. Now it's published on Github or use HPM to update.

1 Like
11

I can't begin to fully understand how important the flashing patterns are for you and the real-life needs, so please take my comments in that context - if my comments deviate from your intended design, then feel free to ignore me.

Couple of findings with 1.2.0:

  1. works great when the light is already off. When it's initially on, it's still not restored. Currently, it will turn OFF, then do the one ON then OFF sequence and remain OFF.
  2. If there is more than one light to flash, they seem to do it one after the other instead of simultaneously/in parallel. This is just FYI. I don't need multiple lights to flash at one, and if I did, I would probably create a group for convenience.

As an example of my use case and the testing I'm doing: when a particular status switch turns on, my method in rules was toggle, wait 1 sec, toggle. That works regardless of the current state and to me that is one "flash". Probably "cycle" is a better term? When that status switch turns off, it's toggle, wait 1 sec, toggle, wait 1 sec, toggle, wait 1 sec, toggle - or two "flashes". This probably would not be appropriate for the signaling for which your app was designed.

12

Thanks so much for the thoughtful feedback — and I really appreciate how clearly you explained your use case!

Quick question: were you testing this on a smart bulb or a switch/dimmer?
Most of my testing has been on switches (Z-Wave dimmers and regular on/off devices), so it’s possible the restore behavior behaves a bit differently on bulbs. I haven’t had a chance to do deep testing with RGB or Zigbee bulbs yet.

If you’re using multiple bulbs, you might try creating a device group using the built-in Groups and Scenes app in Hubitat. That way, the group acts as a single device, and the flashing logic might behave more in sync across multiple lights.

As for the restore issue when the light is initially ON — that’s great to know. I’ll dig into that further and see if there’s a reliable way to account for the ON state more consistently across all device types.

Thanks again for testing and sharing — it really helps make this more reliable and flexible for everyone!

1 Like
13

On/off switches. No dimmer switch testing yet. Don't get me started on trying to get smart bulbs, like the Hue which I have 5, to blink! The slow 1.5 second fade in and fade out makes it useless to blink. Looks cool for pulsing, though it's hard on the Hubitat hub and mesh. Better to have native scenes that are stored on the bulb or the Hue bridge, so there isn't a command sent every 1.5 seconds. The two Singled bulbs in the bedroom are better. Eventually, I'll want to use them for signaling, but only after thoroughly testing this app! Need to keep the WAF high. :wink:

14

Thanks again for all the great testing — really appreciate the insights you've been sharing! :pray:

Would you mind testing it on just one switch to see if Restore Previous State works as expected? That might help isolate whether the issue is related to handling multiple devices at once.

I believe I mentioned in the README that not all bulbs will behave well with flashing. I have an older RGB bulb that only does fade on/fade off and can’t even be set to instant on/off — totally useless for signaling. It’s now just lighting my coat closet because it couldn’t even stay connected to Hubitat reliably. :sweat_smile:

I do have Sengled and Hue bulbs as well — I’ve done some testing with Sengled for color features, but I haven’t deeply tested either with flashing yet.

:bulb: Regarding the restore issue and sequential logic:

I think I might understand what’s happening on your end — when you’re flashing multiple switches, the app currently flashes them sequentially. That means it runs one switch’s flash pattern at a time, which can affect how their states are saved and restored.

In my own setup, I use Hubitat’s Groups and Scenes app to control multiple lights together — that way, everything flashes at once. Hubitat handles all the behind-the-scenes performance and optimization, which works especially well with bulbs that might otherwise fall out of sync.

:wrench: What’s Next

I could refactor the app to flash devices in parallel instead of sequentially, but I’ll need to think through how to save and restore each device's state independently in that model. It's definitely possible — just takes some time and testing to get it right.

In the meantime, I’d suggest:

  1. Try testing with one switch only
  2. Then create a Group of all the devices you want to flash and assign that group in the app

That setup should give you much more consistent results, especially with bulbs.

Thanks again — this kind of real-world feedback is exactly what helps me keep improving VisualAlert! :smile:

15

I am only testing on one switch. GE Enbrighten. That's what I used for testing 1.2.0.

I do use groups. Haven't done that for testing. I can test it if you want, but I don't have much use for it.

16

One note about smart bulbs, when I was creating The Flasher, I found that certain bulbs were completely unreliable. I had to slow the whole process down or commands would be missed or just skipped by the bulb, including saving/restoring states. I ended up making a user defined 'pause' between each command. That way the end user could play around with how much time it took between commands to make their specific device work.

Conclusion: If you want fast and reliable bulbs there is only one choice... Go with Hue, worth every penny!

Hope this helps

3 Likes
18

Your reply is a bit puzzling. In the other post, you mentioned the bulbs were flashing sequentially instead of in parallel—but now you're saying you only tested with one switch?

I’m currently looking into the logic to have them flash in parallel. I can see where the issue is happening: when more than one switch or bulb is added to the trigger source, the previous state can't be saved properly, so it's getting ignored.

If I manage to find a solution, I’ll post an update.

19

Sorry, may have mistyped. I meant "lights" not "bulbs" flashing sequencially.

20

:rotating_light: VisualAlert v1.2.5 Now Available!

Parallel Flashing + Improved Restore Logic :tada:

:link: GitHub - TechBill/visualalert

:new: What’s New in v1.2.5

:bulb: Flashing Now Runs in Parallel!
All selected devices now flash at the same time, rather than one after another. This results in a more consistent and unified alert — especially helpful when multiple devices are used together.

:warning: Note: While the flashing logic now runs in parallel, real-world timing may still vary slightly between devices due to network or device response times. It may not be "perfectly" in sync, but it does run in parallel nonetheless.

:arrows_counterclockwise: Improved Restore Logic

  • "Restore Previous State" now better supports RGB bulbs
  • Color, brightness, and on/off states should now restore more reliably after alerts

:warning: Additional Notes:

  • :clock3: State Restore Is Still Sequential
    While flashing runs in parallel, the restoration process goes one device at a time. You might see a slight delay (2–3 seconds total) as each device returns to its previous state.
  • :rainbow: RGB Bulbs & Color Delays
    If you're using RGB bulbs and assign them a different color for alerts:
    • The first flash may be missed while the bulb changes color
    • It will then follow the rest of the pattern in sync
  • :last_quarter_moon: Slow Brightness Changes on Some Bulbs
    Some RGB bulbs have built-in fade behavior. If you're flashing between two brightness levels, the bulb may appear not to flash at all due to slow transitions.
    :exclamation: This is hardcoded in the bulb firmware and can’t be overridden by the app.

Let me know how it’s working for you — and thanks again for continuing to test and improve VisualAlert with your feedback!

1 Like
21

New update .. try it out ..