Colors and JSON issue

Heya, I just updated to 4.3 and since then I cannot change the color temperature of my deconz bound lights.
Logs say:
2024-12-18 13:21:03.115 [WARN ] [ernal.handler.DeconzBaseThingHandler] - Sending command 4000 °C to channel deconz:colortemperaturelight:raspi4:Deckenlampe_Hobbyraum_Mitte:color_temperature failed: 400 - [{"error":{"address":"/lights/2/state","description":"body contains invalid JSON","type":2}}]

Thing:

Bridge deconz:deconz:raspi4 [ host="<ip>", httpPort="8090", apikey="<key>", port="4431" ] {
        colortemperaturelight   Deckenlampe_Hobbyraum_Mitte                             "Deckenlampe Hobbyraum Mitte"           @ "Hobbyraum"   [ id="2" ]
}

Item:

Number:Temperature          Deckenlampe_Hobbyraum_Farbtemperatur
                "Farbtemperatur Deckenlampen Hobbyraum"
                <colorpicker>
                (Deckenlampen_Hobbyraum, Lampen_Farbtemperatur)
                ["Control", "ColorTemperature"]
                {
                    stateDescription=" "[
                            min="250",
                            max="454",
                            step="1"
                        ],
                    unit="mired",
                    homekit="Lighting.ColorTemperature" [minValue=250, maxValue=454],
                    nightshift= " " [startzeit="21:00"],
                    channel ="deconz:colortemperaturelight:raspi4:Deckenlampe_Hobbyraum_Buecherregal:color_temperature" [ profile="ruby:mired_to_kelvin" ],
                    channel ="deconz:colortemperaturelight:raspi4:Deckenlampe_Hobbyraum_Mitte:color_temperature" [ profile="ruby:mired_to_kelvin" ],
                    channel ="deconz:colortemperaturelight:raspi4:Deckenlampe_Hobbyraum_Schreibtisch:color_temperature" [ profile="ruby:mired_to_kelvin" ],
                    farbtemperatur=" " [
                            tageslicht=250
                        ]
                }

According to Error handling - deCONZ REST-API error “2” means “This will be returned if the JSON in the body couldn’t be parsed.”

No idea what I should do with it. :flushed:
Any recommendations?

See reply here…

Hey, I just upgraded to 4.3.2 so see whether the issue is solved. It does not seem so. I receive now the following error message. The configuration is still the same as in my previous post from Dec 18th.

2025-01-16 09:47:14.914 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.deconz.internal.handler.LightThingHandler@18adc60a': °C is non-linear, cannot convert
java.lang.UnsupportedOperationException: °C is non-linear, cannot convert
	at tech.units.indriya.unit.ProductUnit.getSystemConverter(ProductUnit.java:321) ~[bundleFile:2.2]
	at tech.units.indriya.AbstractUnit.getConverterToAny(AbstractUnit.java:327) ~[bundleFile:2.2]
	at org.openhab.core.library.types.QuantityType.toUnit(QuantityType.java:290) ~[bundleFile:?]
	at org.openhab.core.library.types.QuantityType.toInvertibleUnit(QuantityType.java:325) ~[bundleFile:?]
	at org.openhab.binding.deconz.internal.handler.LightThingHandler.handleCommand(LightThingHandler.java:250) ~[?:?]
	at jdk.internal.reflect.GeneratedMethodAccessor267.invoke(Unknown Source) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:569) ~[?:?]
	at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:147) [bundleFile:?]
	at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
	at jdk.proxy1956.$Proxy2147.handleCommand(Unknown Source) [?:?]
	at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:95) [bundleFile:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:569) ~[?:?]
	at org.jruby.javasupport.JavaMethod.invokeDirectWithExceptionHandling(JavaMethod.java:285) [bundleFile:?]
	at org.jruby.javasupport.JavaMethod.invokeDirect(JavaMethod.java:152) [bundleFile:?]
	at org.jruby.java.invokers.InstanceMethodInvoker.call(InstanceMethodInvoker.java:24) [bundleFile:?]
	at org.jruby.java.invokers.InstanceMethodInvoker.call(InstanceMethodInvoker.java:86) [bundleFile:?]
	at org.jruby.ir.runtime.IRRuntimeHelpers.unresolvedSuper(IRRuntimeHelpers.java:1488) [bundleFile:?]
	at org.jruby.ir.instructions.UnresolvedSuperInstr.interpret(UnresolvedSuperInstr.java:123) [bundleFile:?]
	at org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:363) [bundleFile:?]
	at org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:66) [bundleFile:?]
	at org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:82) [bundleFile:?]
	at org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:201) [bundleFile:?]
	at org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:188) [bundleFile:?]
	at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:220) [bundleFile:?]
	at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:242) [bundleFile:?]
	at org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:314) [bundleFile:?]
	at org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:66) [bundleFile:?]
	at org.jruby.ir.interpreter.Interpreter.INTERPRET_BLOCK(Interpreter.java:118) [bundleFile:?]
	at org.jruby.runtime.MixedModeIRBlockBody.commonYieldPath(MixedModeIRBlockBody.java:136) [bundleFile:?]
	at org.jruby.runtime.IRBlockBody.call(IRBlockBody.java:66) [bundleFile:?]
	at org.jruby.runtime.Block.call(Block.java:148) [bundleFile:?]
	at org.jruby.RubyProc.call(RubyProc.java:335) [bundleFile:?]
	at org.jruby.RubyProc$INVOKER$i$call.call(RubyProc$INVOKER$i$call.gen) [bundleFile:?]
	at org.jruby.internal.runtime.methods.JavaMethod$JavaMethodZeroOrOneOrTwoOrNBlock.call(JavaMethod.java:377) [bundleFile:?]
	at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:291) [bundleFile:?]
	at org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:324) [bundleFile:?]
	at org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:66) [bundleFile:?]
	at org.jruby.ir.interpreter.Interpreter.INTERPRET_BLOCK(Interpreter.java:118) [bundleFile:?]
	at org.jruby.runtime.MixedModeIRBlockBody.commonYieldPath(MixedModeIRBlockBody.java:136) [bundleFile:?]
	at org.jruby.runtime.IRBlockBody.yieldSpecific(IRBlockBody.java:76) [bundleFile:?]
	at org.jruby.runtime.Block.yieldSpecific(Block.java:158) [bundleFile:?]
	at org.jruby.ir.targets.indy.YieldSite.yieldSpecific(YieldSite.java:161) [bundleFile:?]
	at etc.openhab.automation.ruby.$_dot_gem.$9_dot_4_dot_9_dot_0.gems.openhab_minus_scripting_minus_5_dot_34_dot_0.lib.openhab.dsl.thread_local.RUBY$method$thread_local$0(/etc/openhab/automation/ruby/.gem/9.4.9.0/gems/openhab-scripting-5.34.0/lib/openhab/dsl/thread_local.rb:45) [bundleFile:?]
	at org.jruby.internal.runtime.methods.CompiledIRMethod.call(CompiledIRMethod.java:139) [bundleFile:?]
	at org.jruby.internal.runtime.methods.CompiledIRMethod.call(CompiledIRMethod.java:162) [bundleFile:?]
	at org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:185) [bundleFile:?]
	at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:257) [bundleFile:?]
	at org.jruby.runtime.callsite.CachingCallSite.callIter(CachingCallSite.java:270) [bundleFile:?]
	at org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:337) [bundleFile:?]
	at org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:66) [bundleFile:?]
	at org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:88) [bundleFile:?]
	at org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:238) [bundleFile:?]
	at org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:225) [bundleFile:?]
	at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:228) [bundleFile:?]
	at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:291) [bundleFile:?]
	at org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:324) [bundleFile:?]
	at org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:66) [bundleFile:?]
	at org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:128) [bundleFile:?]
	at org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:115) [bundleFile:?]
	at org.jruby.gen.OpenHAB$$Core$$ProfileFactory$$Profile_394511131.onCommandFromItem(org/jruby/gen/OpenHAB$$Core$$ProfileFactory$$Profile_394511131.gen:13) [bundleFile:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:569) ~[?:?]
	at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:147) [bundleFile:?]
	at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
	at java.lang.Thread.run(Thread.java:840) [?:?]

Can you link to your previous post please.

This seems to have occurred inside your ruby profile. Can you post the code?

Sure, sure. Link to the previous post.
The profile:

profile(:mired_to_kelvin) do |event, callback:, state:, command:|
  next if command.nil?

  case event
  when :command_from_item
    callback.handle_command((command | "mired" | "K").to_i)
  when :state_from_handler then callback.send_update((state | "K" | "mired").to_i)
  else next true
  end
  false
end

Why the profile? Apple Homekit sends and receives values in Mired. openHAB expects Kelvin though. I wanted to avoid a proxy item per color temperature and the profile does its job conveniently in OH 4.2.

There were some changes in 4.3.2: [deconz] Support QuantityType Color Temperature command by andrewfg · Pull Request #17942 · openhab/openhab-addons · GitHub

Can you try removing the profile from your link, and simply set your Item to have a mired unit? I wonder if homekit will work with a dimensioned item.

It looks like your item is producing a value in Celsius (??) which won’t convert to Kelvin or Mirek.

So, I removed the profile and changed the configuration as follows:

Number          Deckenlampe_Hobbyraum_Farbtemperatur
                "Farbtemperatur Deckenlampen Hobbyraum"
                <colorpicker>
                (Deckenlampen_Hobbyraum, Lampen_Farbtemperatur)
                ["Control", "ColorTemperature"]
                {
                    stateDescription=" "[
                            min="2200",
                            max="4000",
                            step="100"
                        ],
                    homekit="Lighting.ColorTemperature" [minValue="2200 K", maxValue="4000 K"],
                    nightshift= " " [startzeit="21:00"],
                    channel ="deconz:colortemperaturelight:raspi4:Deckenlampe_Hobbyraum_Buecherregal:color_temperature",
                    channel ="deconz:colortemperaturelight:raspi4:Deckenlampe_Hobbyraum_Mitte:color_temperature",
                    channel ="deconz:colortemperaturelight:raspi4:Deckenlampe_Hobbyraum_Schreibtisch:color_temperature",
                    farbtemperatur=" " [
                            tageslicht=2200
                        ]
                }

According to the Homekit Addon documentation the following configurations are allowed:

// Number item presumed in mireds
Number light_temp (gLight) { homekit="Lighting.ColorTemperature" }

// Number item explicitly in mireds
Number:Temperature light_temp "Temp [%.0f mired]" { homekit="Lighting.ColorTemperature" }

// Number item explicitly in Kelvin
Number:Temperature light_temp "Temp [%.0f K]" { homekit="Lighting.ColorTemperature" }

// Dimmer item, with allowed range given in mireds
Dimmer light_temp { homekit="Lighting.ColorTemperature"[ minValue=50, maxValue=400 ]}

// Dimmer item, with allowed range given in Kelvin
Dimmer light_temp { homekit="Lighting.ColorTemperature"[ minValue="2700 K", maxValue="5000 K" ]}

// Dimmer item, where 0% represents "warm" instead of "cool" (i.e. if it's backed by a channel
// that's ultimately interpreting the value in Kelvin instead of mireds)
Dimmer light_temp { homekit="Lighting.ColorTemperature"[ minValue="2700 K", maxValue="5000 K", inverted=true ]}

I opted for Dimmer light_temp { homekit="Lighting.ColorTemperature"[ minValue="2700 K", maxValue="5000 K" ]} but this did not work at all as the Dimmer type always resulted in NULL values independent from what I defined as color temperature in Kelvin.

The configuration I posted above looks like a good compromise. It is a Number type which gives ranges of Kelvin for the Homekit configuration. This configuration works on openHAB side without any errors. So on the main UI I can set the color temperature and it gets set. But then the Homekit App seems to interprete things wrong again. It assumes the values are in Mired and I cannot set them correctly because it sends out values from range 250…454 which openHAB then interpretes as the lowest allowed temperature and that is 2200 K.

Something seems to be odd with the Homekit Addon configuration or did I misunderstand something?

The minValue and maxValue should probably be simple numbers without “K”…

@jabra_the_hut concerning color temperature there is probably a bug in OH core

2 Likes

Hmmm, but why is the Color temperature at all represented in Degree Celsius on my side? When does the conversion into it happen?

I guess you probably forget to define the item unit.

No, according to my original post it is defined as „mired“ with the unit property.

Edit: And in the original post the used type is Number:Temperature but now I only use Number only. Still the same issue though.

That is unlikely. The deconz code is as follows. As you can see it has two branches – a) for Number:Temperature Items with QuantityType state values, and b) for plain Number Items with DecimalType state values. Your original log error message is shown below; it would only be possible to have such an error in case a) whereas case b) would definitely not produce such an error.

Can you please post your exact Item configuration?

2025-01-16 09:47:14.914 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.deconz.internal.handler.LightThingHandler@18adc60a': °C is non-linear, cannot convert

To elaborate…
Channel is in Mired → link to Number:Temperature → Item uses Units of Measurement.
Then set the unit parameter of the Item (Add Metadata…) to a reasonable value (best option here is K as you want the color temperature) and set State Description Pattern (also Metadata) to something like %.0f K or maybe %.1f kK which will result in a display state in K or kK instead of °C. No need fro any rule or manual transformation.

If the channel is part of a generic thing (like http or mqtt generic) you’ll have to set the channel unit Parameter to MK⁻¹

1 Like

Indeed. And when such a Number:Temperature Item is created then by default its unit is set to “Celsius” or “Fahrenheit” depending on the system locale. That means that when such Item sends a new color temperature value to the binding, it will cause a °C is non-linear, cannot convert resp. °F is non-linear, cannot convert error in the log.

Setting the unit on a Number:Temperature Item should override the default “Celsius” or “Fahrenheit” unit to the given one e.g. “Kelvin”. And that should indeed prevent any °X is non-linear, cannot convert errors.

I‘m a little lost. I posted everything in previous posts. I can try the 4.3.2 update again and show the behaviour when using Number but if I remember correctly this configuration threw the Degree Celsius error.

Edit: Will test it again in the next 1-2 hours.

So, this is the only configuration which does not throw errors. I commented out the “mired” unit and the conversion profiles. Then I can set the temperature without issues on OH side. But maybe I repeat myself: Homekit Addon is not able to set the color temperature anymore. As soon as I set any value in the Homekit app the item receives values smaller than 2200. Of course, because the Homekit app sends out the values in Mired. OH takes this value and moves it to 2200 K as this is the smallest allowed value. Means for me, I need to work with proxy items for each color temperature item until the Homekit Addon is behaving differently. Lovely. I will play around a little more tonight, maybe there is a configuration flaw which I have not identified yet…

Number          Deckenlampe_Hobbyraum_Farbtemperatur
                "Farbtemperatur Deckenlampen Hobbyraum"
                <colorpicker>
                (Deckenlampen_Hobbyraum, Lampen_Farbtemperatur)
                ["Control", "ColorTemperature"]
                {
                    stateDescription=" "[
                            min="2200",
                            max="4000",
                            step="100"
                        ],
                    //unit="mired",
                    homekit="Lighting.ColorTemperature",
                    nightshift= " " [startzeit="21:00"],
                    channel ="deconz:colortemperaturelight:raspi4:Deckenlampe_Hobbyraum_Buecherregal:color_temperature",// [ profile="ruby:mired_to_kelvin" ],
                    channel ="deconz:colortemperaturelight:raspi4:Deckenlampe_Hobbyraum_Mitte:color_temperature",// [ profile="ruby:mired_to_kelvin" ],
                    channel ="deconz:colortemperaturelight:raspi4:Deckenlampe_Hobbyraum_Schreibtisch:color_temperature",// [ profile="ruby:mired_to_kelvin" ],
                    farbtemperatur=" " [
                            tageslicht=250
                        ]
                }

Edit: Is this in any way related to [knx] Allow color temperatures specified in mired by holgerfriedrich · Pull Request #18004 · openhab/openhab-addons · GitHub ?

Try setting unit=“K” in here. At the moment, your item definition will use °C as a unit, which indeed (at the moment) is not convertible to mired (or the other way around). There is discussion to make it work with °C as well, but I am not even sure it is a good thing. With your definition, your stateDescription also works in °C, and this is probably not what you expect.

I added the Unit K:

Number:Temperature          Testlampe_Hobbyraum_Farbtemperatur
                "Farbtemperatur Testlampe Hobbyraum [%.0f K]"
                <colorpicker>
                (Testlampe_Hobbyraum)
                ["Control", "ColorTemperature"]
                {
                    unit="K",
                    stateDescription=" "[
                            min="2200",
                            max="4000"                            
                        ],
                    homekit="Lighting.ColorTemperature",
                    channel ="deconz:colortemperaturelight:raspi4:Deckenlampe_Hobbyraum_Buecherregal:color_temperature"                                        
                }

This configuration seems to be in harmony with the Homekit Addon documentation. But it does not work at all on my phone. When I change the color temperature on my phone I can see the slider on OH side moving within the boundaries of 2200..4000. That is a step forward!

But the physical color temperature of the light stays in the warmest setting which is 2200 K. When changing brightness on my phone the slider of the color temperature jumps back to 2200 without any interaction by myself. This is such an odd behaviour! I start to believe that something is wrong on Homekit Addon side.

By the way, what I just described I did with OH 4.2. So this is not related anymore with the OH 4.3 milestone discussion.