Add min/max color temperature capabilities to channel state descriptions #17638

andrewfg · 2024-10-27T11:08:26Z

andrewfg · 2024-10-27T11:09:08Z

andrewfg · 2024-10-27T13:11:01Z

Having now studied the code of the bindings mentioned above, the following is my proposed list of actions:

AVMFritz

Supports fixed min/max of 2700 K / 6500 K.
Action: modify the channel type xml description.

AmazonEcho

Supports fixed min/max of 1000 K / 10000 K.
The system.color-temperature-abs uses this range, so continue to use it (i.e. no further action needed).

Dali

Supports fixed min/max of 1000 K / 20000 K.
The current maximum colour temperature in ColorUtil is 10000 K.
Proposed Action: continue to use system.color-temperature-abs (i.e. no further action needed).

Deconz

Supports dynamic min/max in Kelvin.
Already implements a dynamic state description provider (i.e. no further action needed)

Govee

Supports fixed min/max of 2000 K / 9000 K.
Action: modify the channel type xml description.

Hue

Supports dynamic min/max in Kelvin.
Implement a dynamic state description provider -- already work in progress -- see #17637

Lifx

Supports dynamic min/max in Kelvin.
Action: implement a dynamic state description provider.

MQTT:EspMiLightBulb

Supports dynamic min/max in Mirek!!
@lolodomo can you please give your thoughts if your PR can read the min/max in Mirek?
Or shall we modify the binding to use Kelvin as a base unit?

openhab-addons/bundles/org.openhab.binding.mqtt.espmilighthub/src/main/java/org/openhab/binding/mqtt/espmilighthub/internal/EspMilightStateDescriptionProvider.java

Line 64 in abe8199

    
           builder.withMinimum(BIG_DECIMAL_153).withMaximum(BIG_DECIMAL_370).withStep(BigDecimal.ONE)

NanoLeaf

Supports dynamic min/max in Kelvin.
Action: implement a dynamic state description provider.

Zigbee

Supports dynamic min/max in Kelvin.
However the only exposed channel is in percent of the min..max range.
Action: TBD -- see openhab/org.openhab.binding.zigbee#867 and openhab/org.openhab.binding.zigbee#868

lolodomo · 2024-10-27T16:27:13Z

Supports dynamic min/max in Mirek!!

What is the difference between mired and mirek ?

lolodomo · 2024-10-27T16:42:18Z

MQTT:EspMiLightBulb

Supports dynamic min/max in Mirek!! @lolodomo can you please give your thoughts if your PR can read the min/max in Mirek? Or shall we modify the binding to use Kelvin as a base unit?

This is not yet clear for me too.
I assume the unit defined in pattern implicitly defined the unit of min/max ?
I will have to test to understand the unit I retrieved with the method I am using and if this unit is consistent with the min/max values in the state description.

There is also the choice of unit done for the item. What happens if the unit is set to Kelvin but state description is in aligned to mired.

Here are all the conditions: to consider

Unit or not in sitemap label
unit or not in the item label
Unit for the item
State description or not on the item, aligned to mired or Kelvin

andrewfg · 2024-10-27T16:51:32Z

What is the difference between mired and mirek ?

Actually they are identical. Originally Mired was defined ("micro reciprocal degree"). However the term "degree" is not properly defined. Therefore, subsequently, and properly, the SI committee defined the unit as Mirek ("micro reciprocal kelvin"). The problem is that many people are stuck in the past with Mired, whereas we should look to the future proper SI unit.

lolodomo · 2024-10-27T16:59:42Z

I own two models of hue lights. None of my things expose a color temperature channel. I will give you the models so that you can confirm this is expected.

I have a Matter bulb with color temperature but te current channel is currently only a 0%-100%.

So not ideal test but of course I can set a state description on any virtual item.

lolodomo · 2024-10-27T17:30:24Z

@andrewfg : I plan to simply use the unit in pattern of the state description to infer the unit of min)max of the state description.
Can you please confirm that each time a pattern is provided and it contains mired or K?

We could also list all bindings having a relative color temperature channel to potentially extend them with an absolute color temperature channel. WDYT?

lolodomo · 2024-10-27T17:39:20Z

I own two models of hue lights. None of my things expose a color temperature channel. I will give you the models so that you can confirm this is expected.

First is model RB_265 from vendor INNR.
Second is model LLC011 from vendor Philips.

Normal that I have not colour temperature channel?

andrewfg · 2024-10-27T18:05:44Z

I plan to simply use the unit in pattern of the state description to infer the unit of min)max of the state description.
Can you please confirm that each time a pattern is provided and it contains mired or K?

Apart from the EspMiLightBulb, all the other ones seem to have state min/max in Kelvin.

So there are two options:

You make UoM conversions in your code. Whereby if the state pattern contains UoM "K" or no UoM then assume Kelvin as default, or if the state pattern specifically contains UoM "mired" only in this case convert Mired => Kelvin.
I make a PR change to the EspMiLightBulb binding so that the state pattern is Kelvin rather than Mired.

andrewfg · 2024-10-27T18:19:14Z

Normal that I have not colour temperature channel?

I would not say "normal" but it is certainly possible.
In my experience there are four classes of lights from Hue (and other Zigbee providers):

On/Off only e.g. smart plug
On/Off plus Brightness at fixed Color Temperature i.e. CT channel not supported
On/Off plus Brightness plus Color Temperature
On/Off plus Brightness plus Color Temperature plus Full Color

First is model RB_265 from vendor INNR.

Yes, I think this is indeed class 2. above

Second is model LLC011 from vendor Philips.

I think this should be class 4. above.

As I recal it, you are using Hue Bridge v1 (round one). So this can't support Hue API v2. So the lamps cannot declare their capabilities dynamically, Which may mean that the CT channel is no available in your case. Or??

andrewfg · 2024-10-28T07:14:11Z

@ccutrer I wonder if you can please give your thoughts about potentially changing the state description of EspMiLightBulb from Mired to Kelvin as mentioned in this comment => #17638 (comment) -- whereby the proposed change would be as follows. I guess this could be considered as a breaking change, but perhaps not a very major one? => WDYT?

builder.withMaximum(BigDecimal.valueOf(1000000 / BIG_DECIMAL_153.intValue()))
        .withMinimum(BigDecimal.valueOf(1000000 / BIG_DECIMAL_370.intValue()))
        .withStep(BigDecimal.valueOf(100))
        .withPattern("%.0f K");

lolodomo · 2024-10-28T07:56:45Z

So there are two options:

You make UoM conversions in your code. Whereby if the state pattern contains UoM "K" or no UoM then assume Kelvin as default, or if the state pattern specifically contains UoM "mired" only in this case convert Mired => Kelvin.

I make a PR change to the EspMiLightBulb binding so that the state pattern is Kelvin rather than Mired.

Option 1 is the preferred. I see no reason to force using Kelvin.
No reason to change EspMiLightBulb.

andrewfg · 2024-10-28T08:57:08Z

Option 1 is the preferred.

Ok. (Just a tip to remember that min and max become reversed when Mired is inverted into Kelvin).

ccutrer · 2024-10-28T14:49:22Z

I highly lean towards option 1. Besides ESPMilightHub, many (most?) things coming in via MQTT use mired, not Kelvin. In particular, Home Assistant explicitly specifies color temperatures are in mireds only. It would be non-trivial to plumb a change of units all the way through from device discovery to the mqtt.generic value wrappers - we rely on core to do exactly that when we get a command, or post updates! And if you're using a Homie device that supports color temperature (in mired), it would be even more special casing, since Homie has no higher level concept of lighting or color temperature - just a number that just happens to have a particular unit.

andrewfg · 2024-10-28T16:22:21Z

@ccutrer thanks for your feedback.

Home Assistant

I am not sure that this is really relevant. ?? In OH we have UoM QuantityTypes with (to be specific) conversion both ways Mirek <=> Kelvin. However I would ignore this comment, since it certainly does not relate to this Issue here.

Homie has no higher level concept of lighting or color temperature - just a number that just happens to have a particular unit.

In OH many bindings produce such bare numbers. However IMHO that does not prevent using UoM since the "particular unit" is known at the time of writing code. But again I would ignore this comment, since it certainly does not relate to this Issue here.

Conclusion: I shall not touch EspMiLight. And @lolodomo will handle the state description min/max values based on the unit provided in the state description pattern.

maniac103 · 2024-10-28T16:37:38Z

And @lolodomo will handle the state description min/max values based on the unit provided in the state description pattern.

When doing decisions here, please don't think only of what BasicUI can do, but make sure the REST API response contains enough details to also make other clients work. I'm thinking of cases like min/max in Mirek in state description, item value in Kelvin and min/max specified without unit on the widget level. Since state description and item units can differ, it's not clear to me yet what unit to assume for the sitemap widget.

ccutrer · 2024-10-28T16:55:49Z

I am not sure that this is really relevant. ?? In OH we have UoM QuantityTypes with (to be specific) conversion both ways Mirek <=> Kelvin. However I would ignore this comment, since it certainly does not relate to this Issue here.

It's relevant because it's a binding that provides a state description with mireks, and not in your list of bindings doing so.

Homie has no higher level concept of lighting or color temperature - just a number that just happens to have a particular unit.

In OH many bindings produce such bare numbers. However IMHO that does not prevent using UoM since the "particular unit" is known at the time of writing code. But again I would ignore this comment, since it certainly does not relate to this Issue here.

It's not a bare number. It's a quantity type, with a unit provided by the end device, and that unit could be either mirek or kelvin. If the color temperature picker can't handle mirek, it would exclude using it with any of these devices.

Conclusion: I shall not touch EspMiLight. And @lolodomo will handle the state description min/max values based on the unit provided in the state description pattern.

👍

Since state description and item units can differ, it's not clear to me yet what unit to assume for the sitemap widget.

I'm also a little confused here. Currently, I have items with an item unit of mired, with a (final - because I'm explicitly setting it) state description using K because in my sitemaps that's more familiar. I most of my color temp items are linked with channels that provide it in mired, but I think a couple use Kelvin - but I don't really care because the item ends up as described above. I leave the item in mired because it's easier for doing math with in my rules that automatically adjust color temperature throughout the day. But someone else might prefer keeping it in Kelvin, and only converting to mired to do the math.

BUT... this whole paragraph is more relevant to the root issue of openhab/openhab-core#3891 (because it's about items), and less relevant to what state descriptions bindings provide (which is only a guidance to when the item is created).

andrewfg · 2024-10-28T17:28:05Z

@ccutrer / @maniac103 for the avoidance of doubt, the issue is the following: A typical binding with a colour temperature absolute channel (a channel of type Number:Temperature or just plain Number) would have a channel type description as shown below.

There is NO PROBLEM concerning the main live value of the channel because it is a QuantityType:Temperature which carries a UoM and can therefore be presented in Mirek or Kelvin and cast both ways.

Our problem is with the minimum and maximum colour temperature values for the light in question. Which we need to set the two ends of the colour gradient in the color temperature picker widget. The current plan is to get those from the min and max attributes of the XML state element. Unfortunately those attributes are BARE numbers i.e. without any UoM attached. So the issue is how to interpret what they mean.

	<channel-type id="color-temperature-abs" advanced="true">
		<item-type>Number:Temperature</item-type>
		<label>Color Temperature</label>
		<description>Controls the color temperature of the light in Kelvin</description>
		<category>ColorLight</category>
		<tags>
			<tag>Control</tag>
			<tag>ColorTemperature</tag>
		</tags>
		<state min="2000" max="6500" pattern="%.0f K"/>
	</channel-type>

There are a number of uses cases as follows:

<state min="2000" max="6500" pattern="%.0f K"/> => widget gradient goes from 2000K/500mk to 6500K/153mk
<state min="2000" max="6500" pattern="%.0f"/> => ditto
<state min="2000" max="6500" pattern="%.0f aardvark"/> => ditto
<state min="2000" max="6500"/> => ditto
<state min="153" max="500" pattern="%.0f mirek"/> => ditto (but note that min/max must be swapped to calculate)
<state min="153" max="500" pattern="%.0f K"/> => ERROR !!
<state min="2000" max="6500" pattern="%.0f mirek"/> => ERROR !!
<state pattern="%.0f"/> => => widget gradient goes from 1000K/1000mk to 10000K/100mk (default)

andrewfg · 2024-10-28T17:37:47Z

@ccutrer in reply to your above..

also a little confused here

Hopefully my post above makes it clearer.

relevant because it's a binding that provides a state description with mireks

Aha!! I though you were referring to the Home Assistant platform (in contrast to OH). But I now realise you are talking about the mqtt:homeassistant sub- binding. => I will look at that further and give more comments if any.

It's a quantity type, with a unit provided by the end device

I now realise you are talking about the mqtt:homie sub- binding. => I will look at that further and give more comments if any.

less relevant to what state descriptions bindings provide (which is only a guidance to when the item is created)

I guess this is true. But it is still important to set the right guidance IMHO..

ccutrer · 2024-10-28T17:43:28Z

Somewhat relevant to this discussion: openhab/openhab-core#4079. I hadn't yet seen this, and perhaps need to go add it to my bindings?

andrewfg · 2024-10-28T17:50:41Z

Somewhat relevant to this discussion: openhab/openhab-core#4079.

Indeed! The UnitHint would indeed be an alternate source for the UoM for the state min/max attributes, => @lolodomo WDYT?

andrewfg · 2024-10-28T18:31:50Z

@ccutrer here is my further feedback on the other two mqtt sub- bindings:

EDIT: Oops! I should have looked further in the code .. I see that there is already an MqttChannelStateDescriptionProvider in mqtt:generic .. which I believe does indeed do what we want here. Please ignore the prior version of this post

lsiepel · 2024-10-28T18:33:14Z

Have seen contributors struggle with similar but more common cases where temperature is used (fahrenheit vs celsius) and the min/max (and what about step) is not having a unit set. The state pattern is not usable in those cases as it usually is set to %unit%, the unitHint is in most cases set, but not always.

I'd like to have some @openhab/core-maintainers to join the discussion as this still feels a bit hackish. and maybe there are idea's from core on how to solve this.

andrewfg · 2024-10-28T18:50:20Z

Apropos UnitHint: It is currently implemented at the level of the ChannelType/StateChannelTypeBuilder and NOT at the level of StateDescription/StateDescriptionFragment/StateDescriptionFragmentBuilder. As we are here discussing the state description and various providers thereof, then unfortunately UnitHint seems to be located in the wrong place. Or??

lolodomo · 2024-10-28T23:32:16Z

Sony projector

The color temperature channel just allows choosing one of predefined color temperature. Choosing a precise temperature value is not relevant for this binding.
I guess it is the same for the Epson projector binding even if I have not verified.
Probably also for TV bindings.

lolodomo · 2024-10-28T23:45:15Z

And @lolodomo will handle the state description min/max values based on the unit provided in the state description pattern.

When doing decisions here, please don't think only of what BasicUI can do, but make sure the REST API response contains enough details to also make other clients work. I'm thinking of cases like min/max in Mirek in state description, item value in Kelvin and min/max specified without unit on the widget level. Since state description and item units can differ, it's not clear to me yet what unit to assume for the sitemap widget.

@maniac103 : I have not checked but I believe the item state description is part of the API response, no ?
What we are discussing should absolutely not impact the current way to determine the unit of the widget. This must remain unchanged.
What we are discussing here is just how to determine the unit of min/max from the state description and the idea is to consider the unit in state description pattern.

maniac103 · 2024-10-29T08:04:15Z

maybe it is as simple as adding an xml attribute next to min max step and rangeUnit solely used to describe the unit for the min max step?

Or allow UoM for the min/max/step values.

maniac103 · 2024-10-29T09:24:49Z

I have not checked but I believe the item state description is part of the API response, no ?
What we are discussing should absolutely not impact the current way to determine the unit of the widget. This must remain unchanged.
What we are discussing here is just how to determine the unit of min/max from the state description and the idea is to consider the unit in state description pattern.

@lolodomo It does contain it, I'm just unsure how to mix'n'match the response values. For reference, here's a sitemap JSON response for a Slider widget bound to a (Hue) absolute color temperature channel:

        {   
            "widgetId": "010102",
            "type": "Slider",
            "visibility": true,
            "label": "Decke Farbtemperatur abs [- K]",
            "labelSource": "SITEMAP_WIDGET",
            "icon": "colorlight",
            "staticIcon": false,
            "pattern": "%.0f K",
            "unit": "K",
            "mappings": [
                    
            ],      
            "switchSupport": false,
            "releaseOnly": false,
            "sendFrequency": 0,
            "minValue": 2000.0,
            "maxValue": 6000.0,
            "step": 100.0,
            "item": {
                "link": "http://<ip>:8080/rest/items/BathroomCeilingLightAbsColorTemperature1",
                "state": "NULL",
                "stateDescription": {
                    "minimum": 1000,
                    "maximum": 10000,
                    "pattern": "%.0f K",
                    "readOnly": false,
                    "options": [
            
                    ]
                },
                "unitSymbol": "K",
                "type": "Number:Temperature",
                "name": "BathroomCeilingLightAbsColorTemperature1",
                "label": "Farbtemperatur",
                "category": "ColorLight",
                "tags": [ 
                    "Control",
                    "ColorTemperature"
                ],
                "groupNames": [
                    "BathroomCeilingLight"
                ]
            },
            "widgets": [
            
            ]
        },

You see 2 sets of min/max values (widget vs. item), 2 patterns (I wasn't aware of a pattern in Widget so far, is this new?), 2 units (same, is this new?) and 2 states (widget as part of label vs. item combined of item state and item pattern).
From discussion here I gather it should be safe to apply item pattern to item minimum and maximum values, but is the same thing safe for minValue and maxValue as well? FWIW, the Android app currently does just that. This means that if the item pattern is given in Mirek (btw, @andrewfg the short unit is MK⁻¹, not mirek), either explicitly (%.0f MK⁻¹) or implicitly (%.0f %unit% with unit taken either from widget state [if present] or item state), sitemap widget specifications also would need to follow that unit.

Thinking about it, to make things simple from a user's POV and for ease of documentation, I'd prefer if we'd settle on Kelvin at least for state description. That way, specification of the sitemap element becomes free of surprises.

andrewfg · 2024-10-29T10:04:08Z

adding an xml attribute next to min max step and rangeUnit solely used to describe the unit for the min max step

Yes. I think that would be a good way forward. A new attribute would not break any legacy code.

allow UoM for the min/max/step values.

These xml attributes are of type "decimal" rather than "string". So adding a UoM to them would risk breaking a lot of legacy code.

andrewfg · 2024-10-29T12:04:24Z

the short unit is MK⁻¹, not mirek

Two things:

The unit named "mirek" (with 'k') is simply an informal abbreviation, and its official unit designation is MK⁻¹
The unit named "mired" (with 'd') is derived in code from MK⁻¹ (see below), so its official unit designation is also MK⁻¹

Therefore for color temperature state descriptions there are just two allowed unit designations -- K or MK⁻¹ -- and the designations mired resp. mirek are NOT allowed. => @lolodomo do you agree?

If so, the MQTT:EspMiLight code here is in fact wrong. And presumably the analog code in MQTT:HomeAssistant and MQTT:Homie is also wrong. => @ccutrer do you agree? And if so, would you like me to add such corrections to this PR?

Units.MIRED = MetricPrefix.MEGA(tech.units.indriya.unit.Units.KELVIN).inverse();

lolodomo · 2024-10-29T12:22:33Z

Therefore for color temperature state descriptions there are just two allowed unit designations -- K or MK⁻¹ -- and the designations mired resp. mirek are NOT allowed. => @lolodomo do you agree?

Our documentation is mentioning "mired" as symbol:
https://www.openhab.org/docs/concepts/units-of-measurement.html#list-of-units

My tests were done with unit=""mired" set on an item and I got no warning.
But I will check that it leads to Units.MIRED.

I also see unit tests using "mired" as symbol.

I will log Units.MIRED.getSymbol().

lolodomo · 2024-10-29T12:30:16Z

MK⁻¹

With a simple basic editor, I am not sure how you enter such an exponent!

I will prefer keeping "mired".

andrewfg · 2024-10-29T12:40:14Z

log Units.MIRED.getSymbol()

It is confusing. EDIT 1: but it seems to confirm the "mired" is in fact OK. EDIT 2 and QuantityType.valueOf("123 /MK") too!!

        for (Unit<?> unit : List.of(Units.KELVIN, MetricPrefix.MEGA(Units.KELVIN).inverse(), Units.MIRED,
                QuantityType.valueOf("123 mired").getUnit(), QuantityType.valueOf("123 /MK").getUnit())) {
            System.out.println("id=" + unit.toString());
            System.out.println("name=" + unit.getName());
            System.out.println("symbol=" + unit.getSymbol());
            System.out.println("baseUnits=" + unit.getBaseUnits());
            System.out.println();
        }
    }

// ===

id=K
name=Kelvin
symbol=K
baseUnits=null

id=mired
name=null
symbol=null
baseUnits={MK=-1}

id=mired
name=null
symbol=null
baseUnits={MK=-1}

id=mired
name=null
symbol=null
baseUnits={MK=-1}

id=mired
name=null
symbol=null
baseUnits={MK=-1}

andrewfg · 2024-10-29T13:17:18Z

^
So, in summary, all of the following are Ok..

        QuantityType<?> a = QuantityType.valueOf("500 /MK");
        QuantityType<?> b = QuantityType.valueOf("500 mired");
        QuantityType<?> c = QuantityType.valueOf(500, Units.MIRED);
        QuantityType<?> d = QuantityType.valueOf(500, MetricPrefix.MEGA(Units.KELVIN).inverse());

        assertEquals(2000, a.toInvertibleUnit(Units.KELVIN).intValue());
        assertEquals(2000, b.toInvertibleUnit(Units.KELVIN).intValue());
        assertEquals(2000, c.toInvertibleUnit(Units.KELVIN).intValue());
        assertEquals(2000, d.toInvertibleUnit(Units.KELVIN).intValue());

maniac103 · 2024-10-29T13:48:24Z

So, in summary, all of the following are Ok..

That's good 👍 I went from core code, but missed this.

With a simple basic editor, I am not sure how you enter such an exponent!

I copied Unicode characters out of a character table ;-)

andrewfg · 2024-10-29T14:29:41Z

I copied Unicode characters out of a character table

Hmm. Two things:

QuantityType.valueOf("500 MK\u207B\u00B9") throws an exception; => what unicode characters were you trying?
QuantityType.valueOf("500 /MK") works fine!

but missed this.

@maniac103 perhaps we should consider adding the following line here?

SimpleUnitFormat.getInstance().alias(MIRED, "MK⁻¹");

maniac103 · 2024-10-29T15:27:39Z

QuantityType.valueOf("500 MK\u207B\u00B9") throws an exception; => what unicode characters were you trying?

I didn't actually try this in code.

perhaps we should consider adding the following line here

That sounds like a good idea, since MK⁻¹ is at least semi-official, while mired is our own invention.

ccutrer · 2024-10-29T20:15:21Z

While mired isn't an official SI unit, I wouldn't say it's our own invention. It's the unit Home Assistant uses. And I believe various Philips Hue integrations say mired instead of mirek or MK⁻¹ (at least in their documentation, even if the actual field/argument/parameter in the API is called "color temperature".

andrewfg · 2024-10-29T20:55:14Z

^
Yeah. It's quite a common usage albeit not a formal one. I guess that one day it will go the same way as Degrees Rankin though..

lolodomo · 2024-11-16T07:36:56Z

@andrew: one improvement would be to set unit hint to color temperature channel types. I will try to add it to the system channel type. Can you have a look for channel types defined in bindings ?
Without unit hint, °C (or °F depending on your region) is proposed as unit for the new item which is of course inappropriate for a color temperature.

andrewfg · 2024-11-16T08:29:38Z

set unit hint to color temperature channel types

Good idea. Will do.

lolodomo · 2024-11-16T09:35:35Z

I have updated your initial message in which you listed bindings that still require investigation. I am almost sure that tradfri or Yeelight require something for example. As explained, the Sony projector requires no change.

andrewfg · 2024-11-16T09:59:30Z

sure that tradfri or Yeelight require something for example

Not necessarily. Some bindings have only a dimensionless CT setting in percent (Number:Dimensionless / Dimmer) or even a low/medium/high setting (Number 1/2/3 etc.) .. and as I recall the Ikea lights are indeed of that latter class.

However I will look again at all of them..

Discussed in openhab/openhab-addons#17638. Signed-off-by: Laurent Garnier <[email protected]>

lolodomo · 2024-11-16T13:03:03Z

For Epson projector also, the value is 0, 1, 2, 3, 4, 5, 6, 7, 8 or 9. Not directly a Kelvin or mirek value.

lolodomo · 2024-11-16T13:12:31Z

Same for Samsung TV binding, the channel is not a value in Kelvin or mirek.

andrewfg · 2024-11-17T16:33:00Z

Re-closing this issue since it is now tracked in #17754

andrewfg added the enhancement An enhancement or new feature for an existing add-on label Oct 27, 2024

andrewfg self-assigned this Oct 27, 2024

andrewfg added the awaiting other PR Depends on another PR label Oct 27, 2024

andrewfg mentioned this issue Oct 27, 2024

[various] Lamp handlers expose min/max Color Temperature in state description #17641

Merged

lolodomo reopened this Oct 29, 2024

lsiepel mentioned this issue Oct 29, 2024

Ranges (min,max,step) should be provided with a unit openhab/openhab-core#4432

Open

andrewfg changed the title ~~Add min/max colour temperature capabilities to channel state descriptions~~ Add min/max color temperature capabilities to channel state descriptions Oct 29, 2024

andrewfg mentioned this issue Oct 29, 2024

[Units] Add MK⁻¹ unit alias openhab/openhab-core#4433

Merged

lolodomo closed this as completed in #17641 Nov 1, 2024

lolodomo reopened this Nov 16, 2024

lolodomo added a commit to lolodomo/openhab-core that referenced this issue Nov 16, 2024

Add unit hint to color-temperature-abs system channel type

56f3cb0

Discussed in openhab/openhab-addons#17638. Signed-off-by: Laurent Garnier <[email protected]>

lolodomo mentioned this issue Nov 16, 2024

Add unit hint to color-temperature-abs system channel type openhab/openhab-core#4451

Merged

andrewfg mentioned this issue Nov 17, 2024

Add unitHint for color temperature channels #17754

Open

27 tasks

andrewfg closed this as completed Nov 17, 2024

Add min/max color temperature capabilities to channel state descriptions #17638

Add min/max color temperature capabilities to channel state descriptions #17638

Comments

andrewfg commented Oct 27, 2024 • edited by lolodomo Loading

andrewfg commented Oct 27, 2024

andrewfg commented Oct 27, 2024 • edited Loading

AVMFritz

AmazonEcho

Dali

Deconz

Govee

Hue

Lifx

MQTT:EspMiLightBulb

NanoLeaf

Zigbee

lolodomo commented Oct 27, 2024

lolodomo commented Oct 27, 2024 • edited Loading

MQTT:EspMiLightBulb

andrewfg commented Oct 27, 2024

lolodomo commented Oct 27, 2024 • edited Loading

lolodomo commented Oct 27, 2024

lolodomo commented Oct 27, 2024

andrewfg commented Oct 27, 2024

andrewfg commented Oct 27, 2024

andrewfg commented Oct 28, 2024 • edited Loading

lolodomo commented Oct 28, 2024

andrewfg commented Oct 28, 2024

ccutrer commented Oct 28, 2024

andrewfg commented Oct 28, 2024 • edited Loading

maniac103 commented Oct 28, 2024

ccutrer commented Oct 28, 2024

andrewfg commented Oct 28, 2024 • edited Loading

andrewfg commented Oct 28, 2024

ccutrer commented Oct 28, 2024

andrewfg commented Oct 28, 2024

andrewfg commented Oct 28, 2024 • edited Loading

lsiepel commented Oct 28, 2024

andrewfg commented Oct 28, 2024

lolodomo commented Oct 28, 2024

lolodomo commented Oct 28, 2024 • edited Loading

maniac103 commented Oct 29, 2024

maniac103 commented Oct 29, 2024

andrewfg commented Oct 29, 2024

andrewfg commented Oct 29, 2024

lolodomo commented Oct 29, 2024 • edited Loading

lolodomo commented Oct 29, 2024 • edited Loading

andrewfg commented Oct 29, 2024 • edited Loading

andrewfg commented Oct 29, 2024

maniac103 commented Oct 29, 2024

andrewfg commented Oct 29, 2024 • edited Loading

maniac103 commented Oct 29, 2024

ccutrer commented Oct 29, 2024

andrewfg commented Oct 29, 2024

lolodomo commented Nov 16, 2024

andrewfg commented Nov 16, 2024

lolodomo commented Nov 16, 2024 • edited Loading

andrewfg commented Nov 16, 2024

lolodomo commented Nov 16, 2024

lolodomo commented Nov 16, 2024

andrewfg commented Nov 17, 2024

andrewfg commented Oct 27, 2024 •

edited by lolodomo

Loading

andrewfg commented Oct 27, 2024 •

edited

Loading

lolodomo commented Oct 27, 2024 •

edited

Loading

lolodomo commented Oct 27, 2024 •

edited

Loading

andrewfg commented Oct 28, 2024 •

edited

Loading

andrewfg commented Oct 28, 2024 •

edited

Loading

andrewfg commented Oct 28, 2024 •

edited

Loading

andrewfg commented Oct 28, 2024 •

edited

Loading

lolodomo commented Oct 28, 2024 •

edited

Loading

lolodomo commented Oct 29, 2024 •

edited

Loading

lolodomo commented Oct 29, 2024 •

edited

Loading

andrewfg commented Oct 29, 2024 •

edited

Loading

andrewfg commented Oct 29, 2024 •

edited

Loading

lolodomo commented Nov 16, 2024 •

edited

Loading