Could it be caused by “data”:“undefined”? Looks like it’s happening here.
2025-12-28 11:56:58.072 [DEBUG] [al.controller.MatterControllerClient] - onWebSocketText {"type":"event","message":{"type":"eventTriggered","data":{"path":{"nodeId":"8328560261268724710","endpointId":0,"clusterId":56,"eventId":0,"eventName":"dstTableEmpty"},"events":[{"path":"undefined","eventNumber":"197003","priority":1,"deltaSystemTimestamp":5,"data":"undefined"}]}}}
2025-12-28 11:56:58.073 [DEBUG] [.controller.devices.types.DeviceType] - onEvent: No converter found for cluster: 56
2025-12-28 11:56:58.074 [DEBUG] [al.controller.MatterControllerClient] - eventTriggered message {"path":{"nodeId":"8328560261268724710","endpointId":0,"clusterId":56,"eventId":0,"eventName":"dstTableEmpty"},"events":[{"path":"undefined","eventNumber":"197003","priority":1,"deltaSystemTimestamp":5,"data":"undefined"}]}
2025-12-28 11:56:58.078 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at path $
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:523) ~[?:?]
at com.google.gson.Gson.fromJson(Gson.java:1359) ~[?:?]
at com.google.gson.Gson.fromJson(Gson.java:1472) ~[?:?]
at com.google.gson.Gson.fromJson(Gson.java:1443) ~[?:?]
at com.google.gson.internal.bind.TreeTypeAdapter$GsonContextImpl.deserialize(TreeTypeAdapter.java:200) ~[?:?]
at org.openhab.binding.matter.internal.client.MatterWebsocketClient$EventTriggeredMessageDeserializer.deserialize(MatterWebsocketClient.java:678) ~[?:?]
at org.openhab.binding.matter.internal.client.MatterWebsocketClient$EventTriggeredMessageDeserializer.deserialize(MatterWebsocketClient.java:1) ~[?:?]
at com.google.gson.internal.bind.TreeTypeAdapter.read(TreeTypeAdapter.java:95) ~[?:?]
at com.google.gson.Gson.fromJson(Gson.java:1359) ~[?:?]
at com.google.gson.Gson.fromJson(Gson.java:1472) ~[?:?]
at com.google.gson.Gson.fromJson(Gson.java:1416) ~[?:?]
at org.openhab.binding.matter.internal.client.MatterWebsocketClient.lambda$2(MatterWebsocketClient.java:298) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
at java.lang.Thread.run(Thread.java:1583) [?:?]
Caused by: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at path $
at com.google.gson.internal.bind.JsonTreeReader.expect(JsonTreeReader.java:184) ~[?:?]
at com.google.gson.internal.bind.JsonTreeReader.beginObject(JsonTreeReader.java:101) ~[?:?]
at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:512) ~[?:?]
... 17 more
After upgrade to OH 5.2.0-SNAPSHOT the dimmer item works out perfect now. Thanks for this fix.
Looking for my CO2 sensors from Netatmo, i am not yet successful. Adding metadata to the CO2 item, i expected something like “Air Quality Sensor” under Matter device type?
Netatmo says, that the sensors are Matter compatible, even without a pairing code. If i understood it right, the OH Matter controller needs a pairing code in order to discover such sensor as a real Matter device, right?
All matter devices require pairing codes for commissioning, there is nothing openHAB specific about it. AFAIK, Netatmo does not have any Matter CO2 or air quality compatible devices, if you have a link showing matter support, i would be curious to read (the only thing i could see was a Matter motion detector). Also i just added CO2 support a few days ago, so it would only be available if you were using openHAB nightly builds as of a day or two ago (although this would not affect adding the device, its just those channels that would not show up).
With regards to this: Is it possible to distinguish between unlocking and unbolting/opening the door?
I have usecases where I just want to unlock/lock the door lock whereas in others I want to open the door as well. Would this be possible, and if so, how?
My major goal isn’t to pair Netatmo CO2 sensors (understood that this is not possible). Instead of this i have hoped for a Matter bridge function in order to expose the existing “non-Matter” Netatmo CO2 sensors to Alexa. Is this something which could be implemented based on your CO2 sensor enhancement or not? I apologize if this question makes no sense for you.
I wanted to try the Matter binding with IKEA Dirigera hub and few window contacts (MYGGBETT) and motion sensor (MYGGSPRAY), but I still can’t get them to work properly.
I updated firmware in Dirigera so it supports new Matter devices and paired one contact and motion sensor. Then according to README, I setup the IPv6 parameters in my Raspberry Pi 5 (connected via ethernet) with openHAB 5.1.
I added new Matter controller thing and was able to pair new devices with pairing code generated from IKEA Home Smart app. First strange thing was, that when pairing got me the result “Successfully paired and new thing added to inbox” I was not able to see anything in inbox. But after a minute or two new thing finally appeared there so I could add it to OH and link to new Items.
I considered it success, Items were changing their states properly. But after a while Items stopped to change their states, like the devices were disconnected. At first only window contact and after another while also the motion sensor.
Controller and sensor things remain ONLINE, but updates do not work anymore.
When I disable and enable the sensor thing and it gets ONLINE, the state updates work again for a while.
Do somebody have an idea what to check and how I can diagnose it and what to fix so the Matter devices work normally? Could it be only wrong network setting or some problem with my IKEA devices or with the binding itself?
Sorry if this is not clear, and this is in the Readme, but the binding acts as a client, so connecting to matter devices, and there is a table of everything we support there. The binding also acts as a bridge, so exporting items as Matter devices, and there is another table of supported devices again in the README in the bridge section. Thats whats supported, if its not there then we need to add it.
Alexa does not support CO2 sensors right now AFAIK, just Carbon Monoxide sensors (seem odd i know). In any case we do not support exporting CO or CO2 sensors (or any Air quality related sensor) in the bridge, although that is on the top of my list to add soon.
So I’m assuming the Dirigera acts as both a Matter client and a bridge. When you generated a code, was it for all devices (likely a bridge), or specific to one device (direct pairing)?
If its a bridge, do you have a lot of devices? I can see an issue where we pair, but then take a minute to actually read all the devices and channels which could cause a delay.
If its a pairing directly to the device, then yeah, thread is rather slow and it can take a min to scan the device after pairing, which would cause a delay. I’ll see if i can fix that feedback somehow.
So devices not receiving updates but still online is not something i have run into, that part of the code is pretty robust, although these are battery (sleepy) devices, so that could be a new twist (we don’t constantly ping those for obvious reasons). If you put the binding in TRACE mode, there will be ALOT of debugging, you can PM me that from the time the device is online to when it has issues. Its ok if its a lot of logs.
Also when its not working in openHAB, does the Ikea app or Dirigera show those updates as they are happening (which is different then maybe afterwords viewing the sensor which may try and poll or wake the device) ?
I generated pairing code directly on one sensor, so it should be direct pairing. I have not tried to pair the whole bridge yet, I’ll probably try it too, if there is any difference.
I bought the Dirigera just recently so I only have there two devices (window contact and motion sensor) both Thread sleepy devices.
IKEA App shows the status updates normally also when the openHAB Items do not react for updates.
I’ve done the test now to capture the TRACE log for you and I’ve found out that when the pause between status changes was about 5 minutes then there are no more TRACE logs for Matter binding.
HI, running OH5 via docker on Ubuntu 24 installed on Proxmox. Just installed the Matter binding to add my leviton dimmers on my OH. I read the readme, installed the controller thing, it is online, I managed to add my first dimmer and it works great. But as soon as I try to add a second one using the same process (put in pairing, do the pairing thing in the controller), I ge the message “The reconnection process for the device failed, please reset the device and try again”. Tried with multiple dimmers, always getting the same error. I reset everything, reinstalled the working dimmer, and got the exact same error when tried to install the second one. Anyone have any idea to troubleshoot.. I’ve been working on that with Claude for the last 2 hours and ready to explode!
what process? Are you using the Leviton app, how are you getting a code, what “exact” steps are you taking?
Pairing a Leviton Dimmer/Switch mean 1) using the Leviton app to generate a unique code for the dimmer you want to commission 2) Physically putting the dimmer into pairing mode by holding the dimmer up for 10 seconds until it blinks amber 3) using that unique code in openHAB to discover the switch.
What does “reset everything” mean ? what are you resting? the device ? the openHAB controller?
I have over 25 Leviton dimmers and switches and have not had any issues. If you could be very clear about the steps you take to add the first dimmer, then the second, that would be helpful, please try and be very clear and specific.
