Color temperature item control in kelvin

Add-ons Bindings
1

I’m trying to get color temperature items to control in kelvin as that seems to be what alexa wants. I’ve set units on both the thing channel and the item but regardless what I do the outgoing command on the item (which I set as kelvin) goes directly out to the broker as the same value - it never gets converted to mired. Anyone have an example of this working - I’ve tried things files (preferred) and also through the UI. Do I need to do the conversion within the output transformation? If so … why? The value displays correctly - shouldn’t the command also know the item is in Kelvin and convert to Mired before going out? Thank you!

Thing:

Thing mqtt:topic:mqttbroker:Group_Office "zigbee2mqtt Group_Office" (mqtt:broker:mqttbroker)
{
	Channels:
		Type number:ColorTemperature "Color Temperature"[unit="MK⁻¹", commandTopic = "zigbee2mqtt/Group_Office/set", formatBeforePublish = "{\"color_temp\":\"%0f\"}", stateTopic = "zigbee2mqtt/Group_Office", transformationPatternOut ="JS:outColorTemp.js", transformationPattern = "JSONPATH:$.color_temp"]
		
}

Item:

Number:Temperature Group_Office_CT "Group_Office CT" (Group_Office)  {alexa = "ColorTemperature", channel = "mqtt:topic:mqttbroker:Group_Office:ColorTemperature",unit="K" }

Out Transformation:

(function(i) {
    var payload = {};
    
    payload.transition = 6;

    payload.color_temp = i;
    
    return JSON.stringify(payload);
    
    })(input)

Forgot to mention - I’m on OH 5.0.1 though I’ve also tried this on 5.0.0 with the same result.

2

It may be just the special power to the minus one character, so try the alternates unit="mired" or unit="mirek" instead of unit="MK⁻¹"..

3

That wouldn’t make sense though because it converts correctly to display the item. It is only the outbound commands that don’t process the conversion. If I add the calculation into my outbound transformation it works - but that is after the item has sent it to the thing channel. I can also say I’ve tried “mired” and “mirek” as well to no avail.

4

@ccutrer I did not look at the binding code, but this might be indicating an issue using QuantityType.toUnit() instead of QuantityType.toInvertibleUnit() (and maybe provides another argument in favor of my current PR..)

1 Like
5

Yeah I noticed the documentation specifically mentions the to invertible unit use. Can you link your PR here so I can watch for it to be merged?

6

My PR is not directly related to your issue. It concerns a potential architecture addition to OH.

7

but if it relates to mqtt and the use of toUnit rather than toInvertibleUnit it would relate no? I guess I can dig into the mqtt code to see what its doing at some point

8

Hmm, I haven’t tried anything color temperature with just the MQTT Generic binding as you’re using here, so it’s quite possible there’s a bug in there (which yes, could be as simple as not using toInvertibleUnit). Can you please file an issue on GitHub for me?

BUT… since you’re clearly using Zigbee2MQTT @jfrank1845, I would highly recommend using Home Assistant auto-discovery instead of manually configuring generic MQTT things and channels. That sub-binding specifically handles lots of little things like this so that you don’t have to worry about them. In particular, lights can be quite complicated, but it’s also really nice for any device with a lot of channels to not need to configured each channel individually. You also don’t need to worry about writing your own transformation in order to get the proper format (which in the case of Zigbee2MQTT is JSON). Though I do see that you’re setting the transition option in our transformation, which isn’t supported via Home Assistant discovery. And also Home Assistant discovery doesn’t support sending just a color temp without also turning the light on, even if the device does (via the color_options.execute_if_off device setting). So if you’re relying on those, you’ll either need to continue to use custom defined MQTT things, or in your rules directly use the MQTT publish action.

1 Like