My Openhab 2.5.12 runs on Raspberry Pi very well and stable.
Unfortunately last days I discovered that switching IKEA lights is not executed by GW.
In my Thing list everything seems to be OK. Gateway online, Bulbs online
IKEA app works perfectly
Trying to switch IN/OFF the light with Paper UI or BASIC UI or HABPanel sends the comand properly but the light is not reacting at all.
I chacked karaf console and I do not see duplicated things howewer in my control panel can see doubled channels (right side on the pic. you see same thing channels on the left side of the pic.)
What more strange is; when I controll the light with the IKEA app. I se status updated on the openhab. Other way control does not work
Openhab restart did not resolve the problem.
TRADFRI Gateway firmware: 1.17.19
TRADFRI Bulbs firmware: 2.3.087
Device type: Colour Temperature Light - 0x0220
Any idea how to firgure out where the proiblem is?
Maybe this is related: I observed connection issues after updating the gateway to 1.17.19. Maybe the cause is the same (did the protocol change after updating the gateway?) and the error handling of OH 2.5 and 3.1 is different?!
Hello Patrick,
it seems that my GW is online all three leds on it are lighting properly.
But if sth on protocol changed this might cause problems I observe.
I can see the openahb status (Paper and Basic UI) is being changed whenever i send the command from IKEA app. I just cannot see reaction on any command sent to my bulbs through GW
did you found something out? I’m seeing the same behaviour since a few days. Everything is online as always and the states change in openhab but the GW is ignoring the changes from OH.
Unfortunately without a change since a while. I gave up thinking Openhab is not supporting 2.5 anymore. Or at least the effort is reduced.
I am thinking about excluding IKEA from my network completely.
Hm, seems this is affecting me too. It works fine using HASS and the Ikea app. The weird thing is openhab says it modified the status
2022-02-09 00:49:50.439 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Outlet_Power' received command ON
2022-02-09 00:49:50.446 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Outlet_Power' predicted to become ON
2022-02-09 00:49:50.458 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Outlet_Power' changed from OFF to ON
The outlets and tradfri bridge all show up as online in the things section of the paper ui
There’s no indication in the software that it doesn’t work, but the outlets do not turn on or off using OpenHAB. Makes this hard to troubleshoot.
Only thing openHAB complains about is the bridge not having an IP address, but that was never an issue before.
After removing all tradfri things and items from openhab 3.2, re-configuring the bridge, un-ignoring all tradfri devices and re-adding them, this is my new result:
[ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.tradfri.internal.handler.TradfriPlugHandler@1d3a5c7': null
java.lang.NullPointerException: null
at org.openhab.binding.tradfri.internal.handler.TradfriThingHandler.set(TradfriThingHandler.java:139) ~[?:?]
at org.openhab.binding.tradfri.internal.handler.TradfriPlugHandler.setState(TradfriPlugHandler.java:58) ~[?:?]
at org.openhab.binding.tradfri.internal.handler.TradfriPlugHandler.handleCommand(TradfriPlugHandler.java:73) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
at com.sun.proxy.$Proxy233.handleCommand(Unknown Source) [?:?]
at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:80) [bundleFile:?]
at org.openhab.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [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:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
Makes this hard to troubleshoot.