Matter Binding

simon10 · September 17, 2026, 4:36pm

ikea Myggbett Matter events stop arriving after a few minutes

Hi everyone,

I’m having an issue with three IKEA Myggbett Matter devices in openHAB and would appreciate some help interpreting the logs or identifying what might be going wrong.

Setup

openHAB 5.2.1
An OpenThread Border Router (OTBR) is used as the Thread Border Router.
I use chip-tool to commission the Matter devices initially.
After commissioning, I use Matter multi-admin to add/transfer the devices to openHAB.
I have three IKEA Myggbett devices connected via Thread.
I also have two other IKEA Matter devices on the same setup. These do not show the problem and continue to work normally.
The openHAB Matter binding is running with DEBUG logging.

The network and Matter setup itself appears to be working correctly. Commissioning the devices worked without any problems, and the Myggbett devices are initially fully functional.

The problem

After restarting the openHAB Matter binding, the Myggbett devices work normally for a few minutes.

Their Matter events are received by openHAB and the corresponding states are updated.

However, after a few minutes, the Myggbett events stop arriving at openHAB.

Interestingly, I don’t see an obvious error when this happens.

The other two IKEA Matter devices continue to work normally.

I can also still communicate with the Myggbett devices using Matter reads, so this does not appear to be a complete loss of Thread connectivity.

Log

I have attached a log file covering approximately 8 minutes.

The log starts shortly after manually restarting the Matter binding, when everything is working, and ends with a manual test where I trigger the Myggbett after the problem has occurred.

The logging level is DEBUG, so I would expect there to be quite a lot of information available.

One potentially interesting observation is that after the last successfully received Myggbett event, I don’t see further logging related to these nodes — not even an obvious error or timeout.

The lack of subsequent events should not be interpreted as the devices simply becoming idle: I deliberately trigger the sensors during the test at the beginning and again manually at the end. The purpose of the final test is to verify whether an event can still reach openHAB after the issue has appeared.

Thanks!
Simon
matter-logs-shortened.txt (440.6 KB)

MikeJMajor · September 17, 2026, 8:06pm

I see the same behaviour with MYGGSPRAY.

For me it works fine up until the point my OTBR is restarted or temporarily loses WiFi. Prior to 5.2.1 rebooting my WiFi router would make it work properly again.

Since 5.2.1, the only way I’ve found to make it work again is to perform the following steps.

Turn off all 7 of my IKEA matter lights
Reboot the OTBR
Remove and insert the batteries from MYGGSPRAY
Wait for it to go online before turning the lights back on

Initially I didn’t have a problem pairing it, but now after a factory reset I can’t seem to get it to pair successfully with Alexa without turning the matter lights off.

digitaldan · September 17, 2026, 9:00pm

If you could enable TRACE logging, you will get much more verbose low level matter logging. If these are battery/sleepy devices, it may not be obvious if we loose a connection, but i would need to see trace logs for more details.

That being said, one thing we could try which would help…

Try and grab the IPV6 address from the thing in the main UI when the devices are working (there will be a couple, trace logs show which one its using) , then confirm you can ping it from the openHAB box (use ping6 or similar, you may need to append the interface to it, i would google or ask ai about this) .

Then when they stop responding, see if you can ping it again. This “sounds” like its possible the openHAB box is not getting its route announcement update (RA, there’s some info in the README on this), so it works when restarted, but then the TTL on the route expires… but its just a guess.

If you can still ping it when it stops responding, then i’ll need to look through the trace logs to see if there’s another issue.

simon10 · September 18, 2026, 3:37pm

Hi Dan,
first, thanks for your time and response!

I did reproduce the error in trace logging mode and also tested the IP-connectivity. my findings are:

The IP-address does not change, when the communication breaks, so the ping still works even after the communication is gone. Remark: I also still get updates all few minutes which seem to be triggered by regular pulls (all values of the node are updated, not only the OpenState)
I do still not see any error in the log that helps me. Maybe you could have a look? You can find the sucessfully retrieved events when searching the log for the string onWebSocketText {"type":"event","message":{"type":"attributeChanged","data":{"path":{"endpointId":1,"clusterId":69 → L.646 is the first successfull test and L. 958 is the last successfull try. First unsucessfull try was roughly at 17:05:00, which would roughly euqal L.1080 - 1100

Just in case you are wondering about missing lines and for transparancy: I scraped away some probably unnecessary lines to minimize the file length using:
docker logs openhab3 --since "2026-09-18T16:52:00+02:00" --until "2026-09-18T17:06:00+02:00"| grep -i "matter" | awk '!/MatterFirmwareProvider/' > matter-logs-shortened.txt

digitaldan · September 18, 2026, 4:55pm

So the ip address would not change, you box would not have a route to it, thats what Route Announcements are, the OTBR says “route this IPV6 address (the matter device) through my IPV6 address” at a regular interval. We don’t poll for updates for anything but wifi and thread radio stats, so i’m a little confused if you are getting updates or not, and i’m not clear if you are able to ping the ipv6 that we actually connected to (its in the trace logs) when its actually not reporting.

I don’t see any logs posted, if you could post those or PM those i can look.

MikeJMajor · September 19, 2026, 9:37am

After having problems getting a newly purchased esp thread border router board working with the image on your website, I built and flashed the esp thread border router example v1.3.

I swapped out the old one which was using the image from your website with the new one and it seems to have solved all my thread problems.

I have an IKEA TIMMERFLOTTE which I was never able to pair previously and this paired first time. The IKEA MYGGSPRAY still seems to lose connection when the OTBR restarts, but it now reconnects instantly after pulling the batteries.

simon10 · September 19, 2026, 1:08pm

i’m not clear if you are able to ping the ipv6 that we actually connected to

The ping does work, even when the devices stop send events.

We don’t poll for updates for anything but wifi and thread radio stats, so i’m a little confused if you are getting updates or not

This is interesting. Let me try to describe, what I observe:
In the first minutes, all events come in within less then a 1 second. When the events stop, then I do not see any immeadiate reactions to opening/closing the door anymore. But even in this state, the state gets update every several minutes (I would say, ~ every 10 minutes, there is an update of the openstate.) I assumed this to be “regular polls”, because in the logs I can see not only one single attribute getting updated, but multiple attributes get updated within the same millisecond. It looks like this (filtered for “onWebSocketText” messages to reduce duplicates):

2026-09-18 17:23:29.920 [DEBUG] [al.controller.MatterControllerClient] - onWebSocketText {"type":"event","message":{"type":"attributeChanged","data":{"path":{"endpointId":0,"clusterId":53,"attributeId":22,"attributeName":"txTotalCount","nodeId":"8082645224342129931"},"value":89486,"version":1403052080}}}
2026-09-18 17:23:29.924 [DEBUG] [al.controller.MatterControllerClient] - onWebSocketText {"type":"event","message":{"type":"attributeChanged","data":{"path":{"endpointId":0,"clusterId":53,"attributeId":23,"attributeName":"txUnicastCount","nodeId":"8082645224342129931"},"value":89484,"version":1403052080}}}
2026-09-18 17:23:29.929 [DEBUG] [al.controller.MatterControllerClient] - onWebSocketText {"type":"event","message":{"type":"attributeChanged","data":{"path":{"endpointId":0,"clusterId":53,"attributeId":25,"attributeName":"txAckRequestedCount","nodeId":"8082645224342129931"},"value":89484,"version":1403052080}}}
2026-09-18 17:23:29.932 [DEBUG] [al.controller.MatterControllerClient] - onWebSocketText {"type":"event","message":{"type":"attributeChanged","data":{"path":{"endpointId":0,"clusterId":53,"attributeId":26,"attributeName":"txAckedCount","nodeId":"8082645224342129931"},"value":89453,"version":1403052080}}}
2026-09-18 17:23:29.937 [DEBUG] [al.controller.MatterControllerClient] - onWebSocketText {"type":"event","message":{"type":"attributeChanged","data":{"path":{"endpointId":0,"clusterId":53,"attributeId":28,"attributeName":"txDataCount","nodeId":"8082645224342129931"},"value":8786,"version":1403052080}}}
2026-09-18 17:23:29.941 [DEBUG] [al.controller.MatterControllerClient] - onWebSocketText {"type":"event","message":{"type":"attributeChanged","data":{"path":{"endpointId":0,"clusterId":53,"attributeId":29,"attributeName":"txDataPollCount","nodeId":"8082645224342129931"},"value":80700,"version":1403052080}}}
2026-09-18 17:23:29.944 [DEBUG] [al.controller.MatterControllerClient] - onWebSocketText {"type":"event","message":{"type":"attributeChanged","data":{"path":{"endpointId":0,"clusterId":53,"attributeId":39,"attributeName":"rxTotalCount","nodeId":"8082645224342129931"},"value":11824,"version":1403052080}}}
2026-09-18 17:23:29.946 [DEBUG] [al.controller.MatterControllerClient] - onWebSocketText {"type":"event","message":{"type":"attributeChanged","data":{"path":{"endpointId":0,"clusterId":53,"attributeId":40,"attributeName":"rxUnicastCount","nodeId":"8082645224342129931"},"value":11810,"version":1403052080}}}
2026-09-18 17:23:29.948 [DEBUG] [al.controller.MatterControllerClient] - onWebSocketText {"type":"event","message":{"type":"attributeChanged","data":{"path":{"endpointId":0,"clusterId":53,"attributeId":42,"attributeName":"rxDataCount","nodeId":"8082645224342129931"},"value":11761,"version":1403052080}}}
2026-09-18 17:23:29.949 [DEBUG] [al.controller.MatterControllerClient] - onWebSocketText {"type":"event","message":{"type":"attributeChanged","data":{"path":{"endpointId":0,"clusterId":53,"attributeId":48,"attributeName":"rxDestAddrFilteredCount","nodeId":"8082645224342129931"},"value":14,"version":1403052080}}}
2026-09-18 17:23:29.951 [DEBUG] [al.controller.MatterControllerClient] - onWebSocketText {"type":"event","message":{"type":"attributeChanged","data":{"path":{"endpointId":0,"clusterId":53,"attributeId":49,"attributeName":"rxDuplicatedCount","nodeId":"8082645224342129931"},"value":49,"version":1403052080}}}
2026-09-18 17:23:31.584 [DEBUG] [al.controller.MatterControllerClient] - onWebSocketText {"type":"event","message":{"type":"attributeChanged","data":{"path":{"endpointId":1,"clusterId":69,"attributeId":0,"attributeName":"stateValue","nodeId":"8082645224342129931"},"value":false,"version":2312224322}}}
<even more of this ....>

I don’t see any logs posted, if you could post those or PM those i can look.

My bad, seems I forgot to attach the file

matter-logs-shortened.txt (346.2 KB)

Levin1 · September 23, 2026, 3:27pm

Hi

I’m new to Matter and successfully integrated my Ecovacs X11 Omnicyclone.

It works pretty good. However I’m missing a few features like “cleaning speed (standard, deep cleaning, …)” or “suction power”.

Ecovacs support told me that this is basically implemented in the “RVC Clean Mode Cluster”. But I have only functions like “vacuum only”, “vacuum and mopping” etc.

So I wonder if this is a Binding limitation or if Ecovacs support ist not very aware of their Matter implementation.

This is what I get from the trace logs:

Endpoint: controller-1c5bb481f3-0.@1:d76bb3dd04f0102.ep1 ready endpoint#: 1 type: RoboticVacuumCleaner (0x74, rev 3) behaviors: ✓descriptor ✓identify ✓powerSource ✓rvcRunMode ✓rvcCleanMode ✓rvcOperationalState ✓serviceArea

Cluster RvcCleanMode={“id”:85,“name”:“RvcCleanMode”,“clusterRevision”:3,“featureMap”:{“onOff”:false,“directModeChange”:false},“supportedModes”:[{“label”:“Vacuum & Mop”,“mode”:0,“modeTags”:[{“mfgCode”:null,“value”:16386},{“mfgCode”:null,“value”:0},{“mfgCode”:null,“value”:16385}]},{“label”:“Vacuum-Only”,“mode”:1,“modeTags”:[{“mfgCode”:null,“value”:16385},{“mfgCode”:null,“value”:1}]},{“label”:“Mop after Vacuum”,“mode”:3,“modeTags”:[{“mfgCode”:null,“value”:16386},{“mfgCode”:null,“value”:16384},{“mfgCode”:null,“value”:16385}]}],“currentMode”:0,“attributeList”:[0,1,65528,65529,65531,65532,65533],“acceptedCommandList”:[0],“generatedCommandList”:[1]}

deserializeEndpoint adding cluster RvcCleanMode to endpoint 1

simon10 · October 4, 2026, 8:30am

Hi Dan,
did you get a chance to look into this topic? Or maybe you have any ideas, how I could further investigate?

ranielsen · October 4, 2026, 1:39pm

@simon10, here’s an analysis by AI, hope it helps until @digitaldan can do his analysis.

Analysis of IKEA Myggbett Contact Sensor Behavior (`matter-logs-shortened.txt`)

This analysis covers the reporting delay observed with IKEA Myggbett contact sensors in openHAB, based on matter-logs-shortened.txt and the discussion in community thread 164601.

Executive Summary

In matter-logs-shortened.txt (and the follow-up log snippet in forum post 650), the IKEA Myggbett sensor (Node 8082645224342129931) displays two distinct operational phases:

Initial Real-Time Phase (16:54:41 – 17:02:12):
- Following the openHAB Matter binding restart at 16:52:12, the sensor re-established a secure CASE session and entered an initial 10-minute Matter ICD Active Mode / Fast-Polling window.
- During these first 10 minutes, all 9 door open/close events were delivered and acknowledged immediately with < 1-second latency.
Sleep / Delayed Batch Phase (17:02:12 onwards):
- At 17:02:12.517 (exactly 10 minutes post-restart), the sensor transitioned from Active Mode into Long Idle Mode (deep sleep).
- When manually triggered at ~17:05:00, no packets reached openHAB.
- At 17:23:29 (21 minutes later), openHAB received a scheduled subscription heartbeat report containing 11 Thread diagnostic counter attributes followed by stateValue: false.
- The cluster data version jumped from 2312224319 to 2312224322 (+3). The sensor never dropped intermediate events; it recorded them locally, but buffered transmission until its scheduled subscription keep-alive triggered.

Crucially, incoming Matter reads still work during this sleep phase (as noted in post 644), and ping6 works throughout. This disproves network or Route Announcement (RA) failure—the sensor remains reachable, but defers spontaneous push transmissions while in deep sleep.

Timeline & Evidence from `matter-logs-shortened.txt`

Timestamp	Event / Log Detail	Significance
16:52:12	`ControllerHandler` restarts node server	Clean restart and session recreation.
16:52:21 – 16:52:36	`matter-server` restores cached devices	Restores nodes from disk cache without requiring remote re-interview.
16:54:41.258	`BooleanState: stateValue = false`, version `2312224311`	Instant delivery (<1s). openHAB sends `StatusResponse Success(0x0)` and receives `StandaloneAck`.
16:54:43 – 17:02:12	8 additional state reports delivered	Alternating open/close events delivered with <1s latency.
17:02:12.517	`BooleanState: stateValue = true`, version `2312224319`	Last immediate event. Exactly 10 minutes after startup.
17:02:12 – 17:05:52	Sensor triggered manually at ~17:05:00	0 UDP packets arrived from the sensor; device has entered Long Idle Mode.
17:23:29.983 (Post 650)	Burst of 11 `ThreadNetworkDiagnostics` counters	Sensor wakes for scheduled subscription heartbeat report.
17:23:31.026 (Post 650)	`BooleanState: stateValue = false`, version `2312224322`	Data version jumped by 3 (`...19` → `...22`). Buffered state changes sent in bulk.

Root Cause Analysis

1. Matter 1.2 ICD (Intermittently Connected Device) Sleep Dynamics

The IKEA Myggbett is a Thread Sleepy End Device (SED) implementing the IcdManagement cluster:

idleModeDuration: 1800s (30 minutes)
activeModeDuration: 1000ms
activeModeThreshold: 1000ms

When a session is established or reconnected after binding startup, the device remains in a fast-polling active mode for an initial window (typically 10 minutes). Once this duration expires, the device drops into Long Idle Mode, where the Thread radio sleeps to conserve battery.

2. Attribute Change Buffering vs. Urgent Events

In the Matter Interaction Model, BooleanState.stateValue is an attribute, not an urgent event.
While in Long Idle Mode, the sensor’s firmware buffers dirty attribute updates rather than waking the Thread transceiver immediately.
The buffer is only flushed when the subscription’s MaxIntervalCeiling (10 minutes + jitter in @matter/protocol for battery devices) expires. This accounts for the burst of Thread diagnostic counters and the delayed stateValue at 17:23:29.
Controller-initiated reads still work because incoming requests are buffered by the sensor’s Thread Parent Router and retrieved by the sensor on its normal periodic MAC data poll.

3. Thread Mesh Parent Router & OTBR Interoperability

As a Sleepy End Device (SED), the Myggbett cannot route packets; it must attach to a Thread Parent Router (either the OTBR or a mains-powered Thread device, such as IKEA bulbs as observed by MikeJMajor in post 645).
Known issues in older Thread Border Router firmware (such as earlier ESP-Thread-BR releases) cause indirect message buffering and poll synchronization to desync once sleepy children enter deep sleep. Flashing updated firmware (ESP OTBR v1.3) resolves these parent-child synchronization issues.

4. Multi-Fabric Configuration (chip-tool + openHAB)

The device is commissioned to two fabrics: Fabric 1 (chip-tool) and Fabric 2 (openHAB).
Under Matter ICD specifications, an ICD registers its Check-In client with a specific controller. If Fabric 1 is offline and openHAB (Fabric 2) has not registered an ICD Check-In client key, openHAB cannot instruct the sensor to enter active mode dynamically.

Addressing Dan’s IPv6 Route Announcement (RA) Theory (Post 646)

In forum post 646, Dan Cunningham hypothesized that the openHAB host might be losing its IPv6 route due to Route Announcement (RA) TTL expiration.

matter-logs-shortened.txt and the user tests directly disprove the RA expiration theory:

Ping continues to work: The user confirmed ping6 succeeds while events are stalled. If RA expired, the host would return Network is unreachable or No route to host.
Matter reads continue to work: In post 644, the user confirmed Matter reads to the Myggbett succeed even when events are not arriving.
Packets route successfully at 17:23: The sensor communicates over the same IPv6 address at 17:23:29, and openHAB acknowledges receipt without packet drops (txAckRequestedCount vs txAckedCount counters remain in sync).