Compound Item types and/or states

I currently have a fairly complex set up regarding lighting control. One of the things that I do is to have light temperatures change throughout the day depending on the time.

Historically I have done this using ColorItems and the ‘proxy pattern’ of having one item receive commands (such as ON) and forwarding them to the real item after conversion (HSB value for 2700K). This maps colour temperatures onto an HSB space internally and controls the bulbs with this space.

However, bulbs are often RGBCCT type, so that they have 5 types of LED, including cool and warm whites which are not typically used when sending HSB colors to them. Instead these bulbs can operate either on 3 dimensions R/G/B, H/S/B etc, or 2 dimensions colour temp/brightness. So when they are told to go to an HSB colour, they switch to this mode and have 3d state, or if they are told to go to a colour temperature then retain a 2d state and forget about HSB etc.

More recently, I have switched my implementation to use the bulbs’ colour temperatures (and hence their white LEDs). To do this I have introduced a NumberItem (to represent colour temperature) alongside the ColorItem for each bulb. If the colour temp is changed, the color is set to UNDEF, and vice versa. Of course in my case there is an additional proxy NumberItem so continue with the proxy pattern, so now 4x items for the bulb.

I have now however realised that I don’t have any control over brightness when operating colour temperature. To have this, I would need to add another item (a DimmerItem), and in my case, likely a proxy DimmerItem, with the requisite logic to keep the state consistent across these items, knowing the logic in the bulb.

Before introducing the NumberItem for colour temp, I first tried to create my own Item and State objects that would mirror this compound behaviour (in an add-on). I didn’t get very far here as I immediately hit a point in Core which has the list of state types hardcoded. I assumed that it had been decided a long time ago that Item/Command/State/Type were closed/sealed hierarchies and add-ons could not extend them.

So I wanted to ask - is it the case that we don’t want these types to be added to, or is it accidental? And if it is deliberate, does anyone have any suggestions on how to model an RGBCCT bulb with the existing types?


I have a few ZigBee RGBCCT bulbs, and what the ZigBee binding does is expose only two channels, one color channel and one dimmer (which controls the color temp). All other functions is handled by the color channel, since it can handle OnOffType, PercentType (for changing brightness only) and HSBType.

Like your bulbs, the color is reset if I change the color temp and vice versa, but changing the brightness works regardless as long as it’s a PercentType that’s sent to the color channel. See here for how it’s handled in code.

I use three items for my setup: an unlinked Switch that (via a rule) sets the bulbs to a preset color temp and full brightness when turned on, and one item linked to each channel. Then I can have two widgets that controls the color item, one for color and one for brightness.

Hope it helps!

Thanks for the advice!

I did actually think about reusing the B part of the HSB state for the ColorItem for brightness, instead of adding another item. In this case though, what do you do with the other parts of the HSB state? I would guess that either you leave it as-is, or you set it H & S to zero? Neither option is great, because the ColorItem then misrepresents that actual state of the bulb? (I do use the current state.)

Just to clarify, are you developing a binding to communicate with a new type of device/service, or are you just asking how to model items for use with existing bindings?

In the former case: if the device/service has a way of changing the brightness only (without setting color/color temp at the same time), you could just use that when a PercentType is received by the color channel. In this case there are no H and S values. If not it would depend on the protocol/api used.

If you’re just trying to figure out how to model Items it probably depends on which binding(s) you are using. ColorItems supports receiving OnOffType and DecimalType commands in addition to HSBType, but it depends on the binding how this translates to the communication with the actual device. Generally though, sending a DecimalType (or PercentType) to the ColorItem should indicate a desire to change only the brightness, and leaving hue and saturation as is. But different bindings might handle it differently (which perhaps is the problem you’re trying to solve?)

1 Like

You ought to be able to merge the two into one comprehensive widget. There is at least one (maybe more) on the marketplace already.

I would expect the binding to keep the Item linked to the Color channel up to date with the state of the bulb no matter how it’s commanded. So if you send a command to the color temp channel the color Item’s HS would be updated as appropriate based on the color temp. If you send a PercentType command to the Color Item only the Brightness will change anyway so the HS and color temp Item should remain unchanged.

It should stay in sync with the device. If it’s not then either there is some technical limitation in the binding preventing it (e.g. the bulb doesn’t report back its current state) or the binding is not implemented correctly (IMO). The expectation is if the device can report back, all Items linked to that Thing should be updated to reflect the actual state of the device.

What isn’t clear is what happens to the Color Temp Item if you command the Color Item. I don’t mess with color in my lighting so am not sure what makes sense. Is there a color temp value for every possible HS combination?

Anyway, the main reason I wanted to chime in here is that this looks like a fantastic place to implement and post rule templates and widgets to the marketplace. When/if you figure it out it’d a benefit to the community to post it as such so future users only need install it instead of figuring it out themselves.

@pacive I am asking how to model via items. (However my code is actually running as an add-on so I am happy to create custom classes / rules etc.)

You suggested sending a DecimalType to a ColorItem, however the problem reading back the state - I don’t believe that it’s possible to read a DecimalType (only) back from a ColorItem - other than explicitly asking for brightness only - however internally it would be storing hue and saturation, so at this point you cannot tell whether the bulb is actually in color or color_temp mode. The state of the bulb is something like:

Brightness AND (ColorTemp OR (Hue AND Saturation))

However it’s not really possible to model this with an HSBType + DecimalType as whilst it’s possible to set the DecimalType to UNDEF (e.g. bulb in color mode), it’s not possible to set the Hue and Sat (but not the brightness) to UNDEF in the HSBType.

@rlkoshak regarding keeping the ColorItem updated, I don’t think that this is really possible. This is because I have found that whilst different bulb manufacturers typically implement color temp the same way (sending the same temp results in the same color emitted), they don’t have much consistency in the color space. For example two bulbs may look the same when you both ask them to show 2700K, but they require different HSB values to show a color that matches the 2700K value they’ve shown (I have code that will map this for a few different manufacterers). Another problem is that the brightness differs between each mode - there are newer Hue bulbs that are much brighter when in color_temp mode, but their color mode brightness has not increased, and only reaches about 60% of the brightness of the color_temp mode. And to answer your question - no there is not a color_temp for every possible color. Also saying this, even if all these were true, the bulb is still operating in one state or another (color vs. color_temp) which would not be represented in the items, and hence this piece of state would be lost. (An example of why you don’t want to lose it is that some bulbs (e.g. OSRAM) cannot transition cleanly between the two states, so if you are wanting a slow transition you need to know both the current and target state.)

I had some observations in this area a while ago: Flexibility of framework supplied types.

Reality is - openHAB uses compound types where it doesn’t have and there is no will to touch anything in this area. A primary example could be a DateTimeType which is either date, time or date with time. The HSBType is likewise. On other end we have OnOffType and OpenClosedType which can’t be grouped together even if they are scalar values. As a cherry on top of cake - we have a toggle command which is implemented in rest layer since ages: openhab-core/ at main · openhab/openhab-core · GitHub. Any attempt to move these parts forward are simply teared down by endless discussions or proposals to embed all logic in rules or even better a rule template in marketplace! Sadly you are not first one who got into this trap.

Now, given all above sober I can bring maybe some partial answer I found for some of troubles I had. Its trivial. Find better workaround than a rule or named workaround for framework shortages called “design pattern”. For me issues with BACnet priorities were solved with profiles. While it is not most convenient way it gives you a chance to inject a specific command kind into your binding without necessity to touch openHAB core. Maybe with a bit of move in UI you will be able to glue also a necessary command in a custom widget which will save your users fair bit of troubles? [while giving them another bunch with profiles]

[be careful its GPL code :wink: ]
I come to the point where I needed multiple profiles on single item link and with some sacrifices I managed to get it working as well. I also found a way to inject more types into OH core with little changes to core itself, but that’s other story [you know you can wave Java code at runtime? :wink: ].

Overall - look at elements you have cause you might be able to survive without multiplication of channels and without too many “proxy” items while staying very close to your hardware. I have no clue of HSB and how color LEDs are working, but your assumption that binding can’t have own commands is not valid. It can, it just needs to twist them in own profiles. This way you can have your own subset of commands which is consistent with hardware without necessity to fight endless discussions to move core forward! :slight_smile:

I wish you luck!

Have you looked at how this quandary is addressed in, say, Ziigbee binding?

Yes, it’s terrible that I try to help people use openHAB with what’s actually implemented and available to use right now.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.