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 ColorItem
s 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?
Thanks!