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}}]
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) [?:?]
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.
// 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?
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⁻¹
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.
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…
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.
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.