This request is applicable to many of your products with the indicator light strip, but I’m particularly intersted for future Matter updates (I’m expecting to replace most of my current Z-Wave devices with your 2:1 Blue Series once Matter update is available).
Can you make the indicator lights their own endpoint on the device so they can be controlled like a RGB dimmable bulb?
I have some of the current LZW36 dimmers and controlling those indicators through parameter settings is not well supported by my hub. It would be a much more “natural” way to control them if they were treated as a RGB bulb - which they really are. I’d like something more like this when it comes to future Matter support.
You’re a Hubitat user, right? This is mostly a function of the driver. I once experimented with writing a driver for the LZW30/31-SN devices that exposed the LED bar and its “effects” as an RGB bulb-type device, but I didn’t find it as useful as I expected, and I’m not sure anyone else did too, so I scrapped that idea with my future re-writes. I never did anything like this for the LZW36, but it would be theoretically possible to extend the driver in this way. If you’re into writing drivers and wanted something to start with, here is mine: Hubitat/Fan-Light-LZW36-Advanced.groovy at master · RMoRobert/Hubitat · GitHub. Inovelli, of course, also has theirs, though I happen to be partial to mine. Hubitat also has a built-in driver for this, though it doesn’t support all functionality (notably, anything more than double-taps), and it’s closed-source.
I’m not sure what what driver you’re using now, but there may be options. Even without modifying it, controlling the LED bars can be done fully with Rule Machine or a custom app, though I realize that you might be looking for more “standard” app options as part of this request. A child device that looks like an RGB bulb (plus effects, though that’s such a little-used capability on Hubitat it’s unlikely to really help you use it anywhere…) might help.
With Thread, there might be something to be said for the separate endpoints so they can be theoretically directly exposed via Matter as discrete devices (certainly an interesting idea!); since Zigbee or Z-Wave need some sort of hub to handle that translation, something the above should work for this device … if you ever find something that actually supports Matter to use it with.
As for the use case, this request solves what will undoubtably be a common purchaser request - “How do I control the indicators on iOS Home, Google Home, Alexa, and others, and include the indicators in automations on each platform, particularly if I can’t write a driver on those platforms”
In addition, I think it may also be necessary to treat them as RGB bulbs to ensure the status is properly maintained in Matter where users make use of the (mandatory) multi-admin / multi fabric feature in matter.
Here’s a further explanation, focused on how it applies to Matter (based on my understanding from current review of the Matter standards), but similar benefits may be there for Zigbee / Zwave . . .
My expectation is that a future Matter device will often be joined to multiple fabrics. This concept of multiple “fabrics” is how Matter supports multiple different controller types, and Matter requires support for a minimum of 5. Its undoubtedly going to be common that you have scenarios where a dimmer / switch is simultaneously connected to ios Home, Google Home, Alexa, Hubitat/ Home assistant and others.
Users of each controller will want to be able to control the indicators from their automations and for some controllers - e.g., iOS Home, you can’t hope for a “custom” driver, so you need to make use of the standard.
With that goal in mind, there’s an obvious solution to allowing each platform full control of the indicators as each of these controllers will be able to understand endpoints and RGB bulbs and the most straightforward way to ensure that all the controllers out there “understand” how to work with the indicators is to treat them as what they are - RGB bulbs on their own endpoints. That’s a very obvious and natural fit for something that, in all substantial regards, is a RGB bulb.
Further, at least in Matter, as I understand it, if you are using multiple fabrics (multiple controllers), when one controller changes a device it will report to the other fabrics / controllers which is how all the controllers stay in sync and have the same view of all your home devices. To ensure that this synchronizing / reporting works properly, you should avoid any “custom” clusters / attributes - here, again, if you treat the RGB indicators as standard RGB bulbs each with their own endpoint, when one controller changes the indicators, they others should get updates of the change so all matter certified controllers will understand what is happening.
Also, as a matter of controlling the indicators, apps such as Rule Machine on Hubitat are very awkward to use with custom parameters and you should assume most users don’t know how to properly write a custom driver. And it isn’t even possible to do anything like a custom driver in iOS Home. So, make it easy for your users, and be able to expose the indicator functionality on many more platforms, and remove the need for customization by better exploiting what the standard allows.
Thank you for your consideration of this idea. I really hope it makes it into the product.
As someone who changes the default LED color instead of using the notifications, I can definitely see the benefits to this.
If the LED’s were exposed as a separate light entity, it would make the process incredibly simple to do. Create a light group with all the Inovelli LED’s, then simply send a single color/brightness change to the light group. I think there would need to be 2 light entities. 1 for when it’s off and 1 for when it’s on.
I’m also thinking things like “Alexa, set the Inovelli LED’s to red”. Or exposing the LED light entity to a dashboard to be able to use the color wheel to quickly change the LED’s on your phone. Even without the dashboard, being able to use colour names instead of a number like 165 or 0 would make it much more user friendly. This stuff could technically be done as-is but it would be a whole lot more complicated.
Here’s a quick overview of how I think this would work for a dimmer in Matter (and, with luck, your engineers are already planning something along these lines).
Endpoint 0
Standard Matter Endpoint for the device’s configuration information
Endpoint 1 - This one is for actual device to be controlled - i.e., the light to be dimmed
Device ID: 0x0104 - Dimmable Switch
On/Off Cluster 0x0006 - turns the controlled light on/off
Level Cluster 0x0008 - dims the controlled light
Switch Cluster 0x003b - use to generate single tap, double tap, triple tap, held, released type button events for the paddle (or maybe this goes on its own endpoint)
Endpoint 2 - This one is for the LED strip
Device ID: 0x010D - Extended Color Light
On/Off Cluster 0x0006 - Enable / Disable the LED strip
Level Cluster 0x0008 - Sets the intensity of the LED strip
Color Control Cluster 0x0003 - sets the color of the LED strip
Endpoint 3 - This is for the LED Strip
Device ID: 0x0027 - Mode Select Device
Mode Select Cluster 0x0050 - This sets the effects mode of the LED strip (solid, pulse, chase, etc.)
Endpoint 4 - This is for the dimmable switch (Endpoint 1)
Hubitat also has a built-in driver for this, though it doesn’t support all functionality (notably, anything more than double-taps), and it’s closed-source.