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)
As a final thought, this method of controlling the indicators should, in my mind, really be an “every product” strategy - i.e., the user of multiple endpoints where one is a RGB for the indicators is supported by pretty much all the protocols - Matter, Zigbee, Z-wave - and this would allow a end-user to treat your devices the same regardless of which one they have. I.e., I routinely mix both Z-Wave and Zigbee - I’d like to control them the same way. This would me to control the RGB LED strip on one of your Zigbee dimmers and Z-wave the same. With that in mind, maybe its part of a 2.x firmware series for your Zigbee / Z-Wave devices.
The only sticking point I can see is that the new devices have 7 individually addressable LED’s. So would that mean exposing 7 additional light entities? This may cause issues with hubs like Smartthings where they have a maximum device limit for the hub.
Yes, if multiple lights each individually controlled, each should be a light entity. I think this will be particularly important in Matter for platforms that don’t let you write custom drivers – i.e., Apple, Google, Alexa.
As for platforms with a limited number of permitted endpoints, you’ll end up no worse than you are now. For example, in something like Hubitat, when you get a parse event from a device, you’ll get the endpoint and the event - you could direct messages from different endpoints to the same “custom” device in those platforms if you had to.
So, you get “standardization” for platforms that expect and limit you to that, and you can still customize drivers for platforms that permit that.
I’m not talking endpoints. I’m thinking platforms like Smartthings.
If the light is exposed as a device, then each individual LED is it’s own device, and assumingly a group device for all LED’s together you end up with 9 devices per switch.
That means you are maxing out the location’s allowable device limit of 200 devices with 22 switches.
Understood - my point (maybe not clearly expressed) is on a platform like SmartThings, you could still set things up as you do today - perhaps with all 9 LEDs as a single device driver using custom attributes though you would have the option of an endpoint-based 1:1 map from LED to device.
This idea just provides an implementation that at least has a better chance of expanding that individual LED control to devices where you can’t write your own driver (Apple / Google / Alexa / etc.). In those cases, either the device will have to conform to what the defined standards allow, or you lose.
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.