Scenes and groups does not talk to driver

💡 Lighting
1

I have a wierd issue with a multi endpoint device.
Endpoint 0A which is the color endpoint and endpoint 0B which is the white endpoint.

I have a driver which works on the dashboard, as well as the driver itself. I can select a color and turn the light on and off.

0B is the endpoint listed on the device itself. So i guess the Hub has somehow decided that's the one to go for. I actually don't care about that endpoint, and I would appricate if, in a later version, i could select the endpoint manually.

But when I try to save a scene then it saves the state from 0B, completely disregards the driver and taking a readout from the, effectively, wrong endpoint.

The same happens with groups. Groups talk with the "wrong" endpoint, which means I have no control over the colors on the device.

Is there a way to mitigate this, like forcing the Hub to use the other endpoint (would be so nice in this case) or something else?

2

What device is this, and what driver are you using for it? Often, multi-endpoint devices will use a parent/child device structure, with each child corresponding to one endpoint. If it's just RGB vs. CT, the parent (or only device) may be able to handle both since there wouldn't be much overlap in terms of necessary commands and reported attributes (except maybe level?), but it's had to say know without knowing what you're working with.

3

The device is a Dresden FLS-PP3 (RGBW)
It’s a dual endpoint device where RGB+CT is on one endpoint and a separate white channel is on another.

I’ve found a ST driver from Sticks18 and modded it to run on Hubitat.
I also modded the Generic Zigbee RGB driver from the Hubitat Public GitHub and got that working.
But the issue is that both the drivers assumes that the colour endpoint (0A) is the default endpoint, which is isn’t, and I therefor had to specify the correct endpoints in the drivers, to get them working.
I agree that I need some kind of parent/child setup, and I tried some stuff yesterday, but haven’t really had much success.

4

Can you share the actual code you're running (probably since it sounds like the source is open or self-created)? Or something you tried to do in your modifications that failed? It would be easier to help that way.

5
Dresden FLS-PP3 from Sticks18 found on a Smartthings forum. Adapted for use on Hubitat and for use with the color and white endpoint
Generic ZigBee RGBW driver found in the Hubitat public GitHub adapted to use the correct endpoint

I don't have a driver which creates child devices. I'm still trying to wrap my head around this programming stuff, with no prior experience :laughing:

6

Hmm, so that's an interesting way of doing it, but I think that dates from before SmartThings had composite (parent/child) device support based on the copyright date. On both ST or Hubitat, I'd probably do it that way nowadays. So, it looks like they just picked one endpoint to represent with the "standard" attributes and control with standard commands, then exposed the other/white endpoint via custom attributes and commands. If you wanted this to work as-is, it looks like, for example, switch (the standard attribute) will represent the color endpoint, while whiteSwitch will represent the white endpoint (both representing the respective state of the switch: on or off). For the custom attributes, you'd need to use a rule or custom app since most standard apps won't look for those. Groups and Scenes should also use whatever the driver does, again only for standard attributes and commands, if you're not using Zigbee group messaging on that group (scenes don't work with this right now so should use the driver for everything).

It does look like it should be possible to modify this driver to either move CT to the standard commands and color to custom commands (and attributes) if you want, or mix a little of both; though the best solution would probably be to split them into parent/child devices so you can control both endpoints separately. I'd be surprised if there weren't a community driver either here or there where someone already tried, but I don't know how popular this device is, so maybe not... :slight_smile: (I might be able to help a little, but it gets difficult without the device...)

1 Like
7

While the driver I'm using now gives me some functionality, I would seriously prefer that the driver was a parent/child setup. That, I think, would suite the device much more than a driver "hacked" together to give 'some' functionality.

With CT I assume you mean Color Temperature, which is in the same cluster as Color Control.
The White channel, not CT, just plain white, is the odd man out here. So CT and Color would be hard to separate.

Regarding the popularity, I have no idea. I don't even know if this is the only one, or there are other devices out there with the same approach. I do know that it's hard to find a driver which supports two endpoints and Zigbee :smiley:

8

I found this driver here that's for a switch of sorts. Maybe i can use that as a stepping stone?