For anyone else looking to use this app with their new mmWave switches, I've added support for them here:
I'm also going to add support for alerts from custom hsm rules soon....
EDIT: hsm custom monitoring rule support added. Also added support for the On/Off switch
This is great @JustinL !!! Any chance you can put this into Hubitat Package Manager? Thanks so much!!!
At the moment, I’m not planning on taking over management of this app, so I do not plan on adding to HPM.
Thanks @JustinL , Sorry for the newbie question, how do I properly install this on my Hubitat? I am assuming is copy and paste of the code in the Apps Code section, but should I do the manager or the child or both? Thanks!!!
You will need to copy/paste the code for both the manager and the child, each as their own app. Then when you install them, it will pick them up properly.
Thanks so much!!! Got it working!!! Love it!!! MUCH MUCH Better than trying to use Rule Machine. Thanks @JustinL for updating this and thanks @Sebastien for the confirmation on how to install it!!! Now start playing with lights 
@ericm — picking up post #298 from last September. You'd suggested looking at group commands as a possible workaround, but weren't sure if Hubitat supported them. I want to come back to the underlying behavior because I don't think groups would solve it cleanly even if they work.
The core issue: when a switch is running an ALL LED notification and the app sends a segment command (LED 1–7), the segment command is silently ignored. To make it work, the app has to send a stop ALL first, wait for the ack, then send the segment command. I built this sequence into the LED Mini-Dashboard app and it works reliably — but it doubles the commands per state change.
That's the part group commands wouldn't help with. Groups could cut down dispatch fan-out across many switches, but every All→segment transition still costs 2 commands instead of 1, plus the wait between them. On dashboards with frequent state transitions the cumulative delay is visible.
What's frustrating is the asymmetry. All→All transitions work fine — colors and levels swap smoothly without any clear. Only All→segment requires the stop-and-wait sequence.
Is there any chance the firmware could be changed so that an incoming segment command automatically supersedes an active ALL effect, the way an incoming ALL command supersedes a previous ALL? That single change would let the app drop the stop-and-wait entirely, and would benefit any app driving these switches — not just mine.
I'm having an issue with the red series mmwave switches (VZW-32SN). For some reason, the top priority notification does not appear for 15-30 seconds after being triggered. I have 19 switches, and in the logs I see it both sending the command from the app, and receiving the command in the switch, but it actually executes 15-30 seconds later.
Lower priority notifications execute immediately with no problem.
I have some blue series fans set with the exact same triggers, and it executes immediately with no problem.
Any ideas?
The way the firmware is designed is that all led notifications take priority. So, if you have a single led notification running and an all led notification is sent, the single led notification won't be seen until the all led notification is cleared. This is intentional because the original use case was that the user will set single led notifications based on lower priority events (like a door being open), and then all led notifications will "take over" for more important alerts (for example an alarm going off). Is your request that the priority be reversed?
@yooshaw I am not sure if the latest fw will resolve your issue but I believe there are some notification related tweaks included. Have you tried fw 2.02 yet? Also, if you send the commands outside of the app (through the device page for example) is the behavior the same?
Any chance that it could be user configurable? That would be awesome!
@ericm I sent you a request for the 2.02 firmware, haven't gotten it yet. Would love to try it. Direct commands outside the app are almost immediate.
I can check to see how complicated it would be to make this change.
@yooshaw you can get the file from here: Index of /firmware/VZW32-SN/Beta/2.02
Hi Eric,
I've significantly rewritten the LED Mini-Dashboard so it works with the firmware behavior I'm aware of instead of fighting it. The app now handles segments, priority, and clearing correctly — transitions between scenarios are clean, lower-priority single LEDs sit underneath an active All ready to appear when it clears, and clearing happens in the right order so the user never sees a flash of unwanted state. Now that I've done that, I'm honestly not sure I still need the All/segment behavior changed at all.
#1
One thing I noticed during testing — there's a speed difference I can't explain:
Any idea what's behind that?
#2
Looking at the driver, I can see ledEffectOne accepts digit-string LED numbers like 1234567 to target multiple segments — but internally it just iterates and sends one zigbee frame per segment, 100ms apart. So from the firmware perspective it's still one command per segment.
What would actually help is firmware-level support for batching:
Across 21 switches a clear sweep currently sends 168 frames (1 All + 7 segment stops per switch). A bulk-clear command would cut that to 21. The reduction in mesh traffic would be significant for setups like mine, especially when slow or multi-hop switches are involved.
#3
Is there a way to query a switch and find out what's actually showing right now? Which LEDs are lit, what colors, brightness, effect — all of it. Being able to read the actual state from the switch would help a lot.
#4
At the firmware level, do all commands sent to the switch send an event back to the hub? I see events come back when an effect stops, but I don't see anything when an effect starts. Just trying to understand what feedback the firmware sends so I know what I can rely on.
Thanks
Download the Hubitat app
