LZW31 LED Bar Off Color

Suggestions & Wishlist
#1

I would like to be able to choose a different color for the LED bar (or any other LED indicator on Inovelli products) when the dimmer is off. For example, when a switch is off, the bar could be a dark blue, but when it is on, it could be a bright white-ish amber. Even with the intensity being separately set to a low value it sometimes can look like a mistake or an error since when a dimmer is off the bar fully illuminates top to bottom.

A minor quibble… but it would be nice :face_with_monocle::

Thanks,
Richard

#2

What hub/platform are you using? You can sort of already do this, unless you’re on Wink or another severely limited platform. There is a Z-Wave parameter (parameter 13) that corresponds to the “regular” (on or off, not notification) LED color, so you could use your hub to automate changing that parameter value as the switch sends on/off state reports. Not quite the same as the switch doing it on its own (since the hub needs to get involved), but it would work without them needing to tweak the firmware, which might be unlikely given limited resources on the device.

Alternatively, I haven’t tried this, but the (separate) parameter of the LED bar level when off (parameter 15) says it should accept level values from 0-10, with 0 being off. So if you’d rather just have it off instead of a different color, that is something you can already do with just the dimmer itself.

Hopefully one of these ideas is helpful!

#3

@BertABCD1234 I use Hubitat. I looked for a custom command/action but cannot access this programmatically. I can set it in the preferences on the device page of course but cannot change it on the fly in rule machine or otherwise. It seems like it would not be a heavy duty driver change to add such a custom command/custom action whereas creating a different off vs on color as a feature would be a heavier lift.

Any ideas for a Hubitat user as to how to achieve this? Would it be possible to use a global variable and just set that as the situation changes? It would be something I would want to be uniform throughout my home.

– Richard

#4

I actually wrote a set of drivers to do exactly that. :slight_smile: You’ll need the “parent” driver for whichever switch you have (LZW30-SN or LZW31-SN), and optionally the child drivers for the “Default,” “Off,” and “Notification” LEDs. The Default LED device lets you treat the “regular” LED bar (when on or sometimes when off) like a an RGB bulb, adjusting its color and level with standard commands. The “Off” LED is a level-only device (color comes from the default LED, per the way the devices actually work) and allows you to set the level of the LED when off. The “Notification” LED driver lets you treat the notification LED like an RGB bulb, this time adding the little-used Hubitat “LightEffects” capability to allow you to start a notification with almost no custom commands (except setDuration if you want).

You don’t have to use the child devices (or install the drivers); all of this is also exposed as a custom command on the parent device. In your case, setDefaultLEDColor is the command I’d probably pay the most attention do. It takes an “Inovelli-scaled” color value 0-255 (scaled either up from Hubitat’s typical 0-100 hue model or down from the standard 0-360 model where both extremes are red). You could create something in RM that sends this custom command to the device whenever the switch turns on/off. You can adjust the level if needed with setDefaultLEDLevel and setOffLEDLevel if needed as well; both take values from 0-10 (0 is supposed to be off, though I haven’t tested that). If you use the child devices, you can also just treat these like “standard” devices and use an app like Simple Automation Rules/Simple Lighting to do this instead.

As I said on a Hubitat thread where I announced these drivers, I can’t decide if treating the LED bar (and its various states) as a mostly-standard RGB bulb or dimmer was such a great idea that I’m surprised no one else tried it first or such a crazy idea that someone thought about it and dismissed it. :slight_smile: Personally, I like it.

Here’s the folder where I’m keeping these:

#5

This is extremely exciting of course. I will have to take a deep look or test drive. Three questions:

  • What happens to the “native” Inovelli LED notification system? Do you support both or is it universally a more manual mechanism (which could be automated with rules of course but not in quite the same conveniently named way)
  • If I were to switch to your driver, test drive for a while, then have to switch back (or to something else) what happens to my rules, device preferences, dashboards, etc. across the driver changes? I am starting to amass quite a few layered and woven rules. So there is some risk here. Changing button numbers is no big deal but losing entire flows or logical steps would be a heavy setback.
  • Have you (or anyone else Inovelli inclined) considered somehow connecting to Hubitat’s inbuilt Notification system, API, or app? I am familiar with Hubitat’s Notification app and it seems to only support text, audio and speech devices. But that seems like an opportunity to expand or a suggestion that there is an underlying notifications API?

I am not a Hubitat developer but I am starting to see clues to the engineering behind the platform. There is a lot here!

– Richard

#6
  • The “native” Inovelli notification system, if you mean the child notification devices you can turn on/off to set notifications, do not work with this driver. This driver replaces that with its own way of handling notifications, for which you have two options:
    • The “Set Indicator” command on the parent device (this matches the command name Hubitat used on the native Inovelli drivers they wrote, which does not include this one, and the parameter you need to supply is the same: the calculated 4-byte parameter value you could get from this tool or manual calculation); or
    • Modifying the (optional) “Notification LED child” device for that dimmer/switch like it’s a smart bulb: set it to a specific level or color with standard commands, then turn it on using the standard “Set Effect” command on that device with the appropriate effect number (you can see what number is what under “Current States” and the value of the lightEffects parameter). That being said, the “LightEffects” capability in Hubitat that this relies on is not often used, despite being standard, so you might need RM with a custom command at some point, anyway, which you’d also need if you want to adjust the duration with the “Set Duration” command (the only custom one I had to use because I wasn’t sure how that could fit in any standard capability).
  • Any rules/apps you used with Inovelli’s driver should mostly work with mine; as far as I know, they both implement all the same commands that you might use, like “On,” “Off,” and “Set Level.” Features specific to each driver (like Inovelli’s pre-configured notification child devices or the “Set Indicator” command or LED child devices that only exist on mine) will not work when you switch from one to the other, so the only thing you should have to re-do are specific rules that rely on these driver-specific implementations.
  • Hubitat’s “Notifications” app is really mostly meant for sending push notifications (or SMS if you have Twilio or another service) in response to events (door opening, motion detected, etc.). I could see where setting an Inovelli switch/dimmer notification LED would be something you might want to do in this case too but think Hubitat is unlikely to add this feature for a specific device. The Notifications app doesn’t have an API, but a different app (Rule Machine for sure, but Simple Automation Rules/Simple Lighting would also work in many cases) can easily be configured to do this instead. Someone could also write a custom app tailored exactly for these devices that acted a bit like the Notifications app (“set the Inovelli notification bar to these settings if this door stays open for more than 2 minutes” or something), but the exact implementation would need to be different depending on whose driver the device is using.
#7

Exciting to say the least! I am very interested to give this a spin but just went through a hellish nightmare performing a simple driver update much less a driver “swap.” See this thread:

Before I do anything else driver wise I will want to dig deep to be sure I know how to prevent this from happening again. Suggestions?

– Richard