Home Security Notifier via "LED" Control

One of my first use case when testing automation with the Gen 2 Red Switch was to Pulse the LED Red when one of the door sensor(s) would trigger open and reset when closed, but that soon turned into something much more… :crazy_face::dizzy_face::exploding_head:


Was to have Multiple LZW30-SN in obvious locations. ie Front Door, Garage, Mud Room, Back Door, Stairs, etc to show the status of the Home Safety Monitor and Alerts.

Caveat – My Automation attempts are my first “Large” scale attempt to generate more complex automation in Hubitat and as a relatively new user (4-6 weeks) I am fairly certain there could be more simple ways to manage this…

System Design:

1 – Automation Hub (Hubitat)

5 – Switches

5 – Notifications per switch (Identically Configured)

1 – Light Group per each notification (Total 5)

3 – Automation Rules

System Schematic:


Rule #1 - HSM Arm/Disarm Notification

Turns On specific notification light group based upon HSM Armed vs HSM Disarmed Status

Rule #2 – HSM Disarmed “Open Door Notification”

Turns on specific notification group if in disarmed mode and any door open, reset disarmed notification when all doors closed

Rule #3 – HSM Alert Notification

Turn on two different “Alert” Notification Group based upon Alert type (Intrusion or Water) and then returns to either Armed or Disarmed when the alert is canceled.

Within the Rules I chose to use Light Groups to simplify the rules also with the hope that if I ever needed to add switch (ie Red Dimmers) or swap switches in due to OTA Firmware updates it “might” simply the process at a later date…

Example Group:

Do to the nature of how the Inovelli Red Switch manages the LED notification (only one on at a time/next notification cancels previous) my rules only turn the lighting groups on as then the next lighting group is trigger by the next automation rule updates the LED indicator

Overall the automation seem to be spot on accurate, Arming/Disarming/Alert Canceling is done via other controls on the hub included button controls, presence sensor, and modes. WAF is high, and my little home brew security notifier is a hit…


I have almost exactly the same setup I just use blue flashing for water so I can differentiate between the HSM alerts. And I don’t have the green for armed but that’s a great idea!

@Terk We started with a LED color that was different for the Water notification, but settled on a red alert, that had a different flash option than that of the the normal HSM alert.

The switch is more of a traditional stop light Red = Bad, Yellow= Warning and Green = Good.

The blue for disarmed just allows for the switch to match the default colors of the Black switches I have that still have the default Blub LED color setting…

Overall this is really working good for us…

1 Like

Default LED state with no notifications on (Blue, solid)
LED Notification 1 (Yellow, flashing)
LED Notification 2 (Green, solid)

@Eric_Inovelli if I turn on LED Notification 2 the LED will be solid Green, I then turn on LED Notification 1 and the LED will be Yellow flashing. Now I turn off LED Notification 1 and would expect it to go back to solid Green since LED Notification 2 is still on, however it goes back to solid Blue as if no notifications are on.

Is this by design? In order to get it back to solid Green I have to turn off LED Notification 2 and turn it back on.

It would be nice to be able to have it revert back to another notification that hasn’t been addressed yet.


I originally was playing with the “capture” option in RM to attempt to capture the switch notifications states of the 5 notifications, but found that the restore would run notification by notification and would have an undesirable result…

@Terk to get around this behavior I had to write my rules in a way with the correct conditions to know what was Indication status before the change the each “condition” ran in my rule. You can see specific examples of this in each of my three rules, but rule 3 makes best use of this…

Thanks, I have addressed it in my rules as well, however it seems like something that should be addressed in a firmware update unless there was some reason they wanted it to always revert back to the defaults and ignore other notifications that are still on.

@EricM_Inovelli - do you know the answer to this?

One other thing I noticed is that after a power outage the LED reverts to the default solid Blue, even if one or more of the LED Notification child switches are on.

This one would be tricky if more than one switch is active because it might not activate them in the order they where turned on so it may load LED 1 flashing yellow (an alert) then load LED 4 solid green (alarm armed) and end up being solid green rather than flashing yellow as expected since that would normally be the latest switch to activate.

It would be great if there was 1 more field for each notification for priority were whichever notification has the highest priority gets displayed if more than 1 notification is turned on at a time.

1 Like

@Eric_Inovelli Yes, this is by design. Only one LED effect is active at a time. In this scenario you could activate notification 2, then notification 1, and then notification 2 again (instead of turning 1 off). This would leave you with notification 2 active at the end.

Is it supposed to turn off previous effects when you turn a new one on? I use groups to add all of my switches child objects in one place so those group switches don’t get turned off until whatever caused the first effect to get turned on has been resolved. I probobly don’t need to use groups since I had to make a master rule for turning these child objects so I’d still be setting them in one place, I’ll probably make that change if turning on one child switch should turn off a previous one automatically. Then I could get rid of the off commands before the on anyway.

I’m currently turning off Notification 2 then wait 1 second and turn it back on since it never turned off when another one was turned on, I have the delay since I wasn’t sure it would be effective otherwise. And since there is no way to handle priority I had to put the notification changes in my rule in order from least important to most important and all in one rule so the last to get checked and turned off and back on if needed is the most important alert.

Also during a brownout the switches will default to blue when it comes back from the power outage even though the hub is on battery backup and at least one notification child switch is on when the switch comes back on. The only way I could address that is by reevaluating my rules on a schedule like every 5 minutes or something like that, which I’m not sure I want to do for performance reasons.

For my use I don’t issue the Off Group Command as the next On Group turns of the previous group Device based upon the group settings. This setting didn’t really effect the reaction of the switch, but only the “group device” but it was helpful when I was debugging the rule will my dashboard test view…

Hey Everyone,

I wanted to share what I’ve built so far to give others ideas on how to improve their own implementations.

For my purposes, I want to use the notifications near all my main doors to reflect the current status of the HSM (Armed Home). I want to avoid having guests inadvertently open doors and set off the alarm at night.

I noticed that the notification LED would stop if the same light switch was used to turn on/off/dim a light. I implemented the following to resend the notification after 30 seconds.

It works beautifully. When one of the lights switches changes status (on/off/dim), it loses its pulsing RED LED notification. Then after 30 seconds, the RED notification comes right back as the rule triggers both during Arm Home/Night AND if any of the selected Dimmers is used.

1 Like

My on/off lights don’t have that issue the LED notifications will only stop when the notification switch is turned off. I wonder if it’s an issue with the driver, I know the dimmer driver was just updated but not sure if it had anything to do with that or not?

1 Like