I got an ALPSTUGA and 3 TIMMERFLOTTEs connected to a ZBT-2 the ALPSTUGA is working fine but the TIMMERFLOTTEs will only stat online for 4-8 hours and I have to take the batteries out and put them back in to reconnect them. I am testing having an automation ping there identify every 2 hours to see if that keeps them online, like was mentioned for the Badring. Is anyone else having this issue or knows how to fix it?
I also have this problem with ZBT-2 and one of my TIMMERFLOTTE sensors. One of the sensors is working just fine and the second one becomes unavailable every couple of days. Both are running the latest firmware.
Could you share the automation ? Same problems here.
Same here.
IKEA TIMMERFLOTTE: Matter subscription loss — sensors go unavailable and cannot self-recover
Summary:
IKEA TIMMERFLOTTE temp/humidity sensors (Matter over Thread) frequently become unavailable and cannot recover without a full OTBR restart or battery pull. Firmware 1.0.21 (latest as of Feb 2026).
Setup:
• 11× TIMMERFLOTTE (all FW 1.0.21)
• 3× Eve Energy Thread router plugs (always-on, same mesh)
• Home Assistant OS 17.0 (Core 2026.1.3) on Raspberry Pi
• OpenThread Border Router (SkyConnect), sole border router
• IPv6: automatic (SLAAC)
• No DIRIGERA — pure OTBR/HA
Problem:
Sensors randomly become “unavailable” and do NOT recover on their own. Typically 3–5 of 11 sensors down at any time. The same sensors drop repeatedly. Eve Energy plugs in the same mesh: zero outages.
Recovery: OTBR restart (brings back some, not all) or battery pull (always works).
Data (16-day monitoring, Jan 31 – Feb 15, 2026):
• 21 OTBR restarts needed
• 8 of 16 days affected
• Worst day: Feb 6 — 9 restarts, ALL 11 sensors unavailable
• 4 specific units drop repeatedly
• Eve Thread routers affected: 0
Observations:
- Not distance/coverage: sensors drop 4m from OTBR with line of sight, and right next to Eve router plugs. More routers helped slightly but didn’t fix it.
- Not IPv6 routing: SLAAC configured, Thread routes established via wpan0.
- FW up to date: all report 1.0.21.
- Complete communication breakdown: unavailable sensors also lose firmware visibility.
- Sleepy end device specific: always-on Eve plugs never affected.
Expected: Sensor should re-establish Matter subscription autonomously after network interruption.
Requested fix: Robust reconnection mechanism in TIMMERFLOTTE firmware, similar to how Eve devices maintain reliable connectivity.
Environment: FW 1.0.21, SkyConnect OTBR, 3× Eve Energy routers, HAOS 17.0/Core 2026.1.3, no DIRIGERA/Google hubs.
I also have this issue, connected to ZBT-2. Several other devices (MYGGBETT, BILRESA, KAJPLATS) that is working fine. I only managed to get a hold of one but was planning on buying 8-9, gonna have to check with IKEA first on what’s going on.
Me too.
First time this has happened to me since installing a couple of months ago, but today had 3 Timmerflottes drop off (out of 7 on the network).
Restarts of OTBR (an Espressif Thread Border Router board in my case) and/or HA would not recover them.
It took battery removal of the sensors to get them to recover.
Newby here and I thought it was just me. Not only do they seem to go unavailable, they seem to swap entities all the time! I’m using the Aqara M3 hub. I believe everything is up to date as well.
Bill
I also have 5 Timmerflottes with a ZBT-2 border router. The Timmerflottes that are connected primarily to the ZBT-2 drop offline and don’t come back without pulling the battery. The ones that are primarily connected to plain router devices, like the Air quality sensor, have never gone offline. I’ve had them for about 2 months now. One of them is about 4ft from the ZBT-2, and the other is about 10ft through a wall to it; both have strong connections. One of them, I pulled the battery and moved closer to a Matter/thread light bulb, and now it’s connected to that primarily. We’ll see if it’s the device or the connection directly to the border router. Although it takes up to a month to go offline. I’ll be getting more Ikea plugged-in devices soon. That will change things up again. I suspect they stay connected to other Ikea devices better than to the ZBT-2, but that’s just a theory. We’ll see. Of course, all devices are the latest firmware. The Timmerflottes had only one update since installing them.
Known resubscription issue in current Ikea Matter firmware for most of their battery powered devices. The Matterjs server beta significantly better at keeping these connected than the EOL ‘stable’ python server, but will require more Ikea firmware updates to fix.
1 Like
Same here using Amazon Show/Dot as board router, TIMMERFLOTTE seems going offline after few hours/days from the pairing
Hi, I faced the same problem since yesterday.
I guess there is no way to report this issue to Ikea except their Reddit channel. I heard the some devs of Ikea sometime have a look into Reddit.
Or is there any other solution in the meantime?
Same symptom on an Apple-based setup — with some Thread-level diagnostics
I’m seeing the same thing with a TIMMERFLOTTE, but on a different controller stack, so it may be useful to compare.
Setup: Apple Home is the primary Thread fabric (Apple TV as border router). Home Assistant runs separately on k3s with the matter.js server. In addition, I have an SLZB-MR3 running OTBR that I joined to the same Apple Thread network using the operational dataset, but configured as routereligible disable — so it sits in the mesh as a plain child and does nothing except let me run ot-ctl diagnostics from inside the network.
What I can measure while the device shows “No Response” in Apple Home:
meshdiag childtable: link quality 3, frame error ~2.3%, RSS -61 dBm,conn-timeseveral hours with no reattachdns browse _matter._tcpshows the device’s SRP registration is alivedns resolve <MAC>.default.service.arpareturns a valid OMR address with TTL 300ot-ctl pingto that address: 10/10 packets returned, RTT 575 ms to 14.5 s, all delivered in a single burst (the parent buffers until the sleepy child polls)
So the device is joined, registered, resolvable and reachable at IP level — while the controller reports it as unavailable. That puts the failure above the Thread and SRP layers.
I’ve also tried a battery pull on the TIMMERFLOTTE. It rejoins the mesh immediately and shows a healthy link in the child table, but Apple Home still reports “No Response”, so power cycling doesn’t help.
One data point that may matter: I had exactly the same behaviour with a MYGGBETT contact sensor and same pattern shows up on a KAJPLATS bulb. The last one mains powered and acts as a Thread router — it’s the parent for all my sleepy end devices and routes fine — yet it intermittently goes unavailable in Home as well, while ot-ctl ping to its OMR address keeps answering with 0% packet loss. I’ve also shared the KAJPLATS with Home Assistant (matter.js server). It’s on the same Thread network and the same radio link, but from Home Assistant I can turn the bulb on and off reliably while Apple Home still shows “No Response” for it. Since the device is controllable from one Matter controller while another reports it unavailable, this looks like a controller-side issue rather than a device or network problem.
Follow-up: the same device is stable on a different Matter controller
Since my last post I’ve been able to narrow this down further, and I think it points away from the device itself.
I removed the TIMMERFLOTTE from Apple Home and commissioned it directly into Home Assistant instead (matter.js server, same Thread network, same border router, same parent router). It has been working there without interruption ever since — temperature and humidity updates come through normally.
I then shared it from Home Assistant back to Apple Home. It was added successfully, and went to “No Response” within minutes. So right now the exact same device, on the exact same Thread mesh, is simultaneously working in one fabric and unreachable in the other.
I see the same pattern with a KAJPLATS bulb: “No Response” in Apple Home, fully controllable from Home Assistant at the same time.
One more data point: before I moved my setup to Apple Home as the primary fabric, these devices ran for months on the older python-matter-server with a self-hosted OTBR, and I had none of these problems.
I also ruled out the environment as far as I can:
- Removed and re-added the device from scratch — same result
- Ran for 11 hours with my own OTBR and matter.js server both shut down, leaving Apple as the only controller — the TIMMERFLOTTE still dropped out, while my other devices stayed up
- Rebooted the Apple TV several times — it comes back briefly and then drops again
- Thread link quality stays at 3 with ~2% frame errors, and the device answers pings from inside the mesh the whole time
Given that it works on one controller and not the other, this looks like a controller-side interoperability problem rather than a fault in the device or the network.
Just to chime in, saying using an all HA Matter/Thread/ZBT2 setup, my Timmerflotte’s go offline about every 3 weeks (or so) and never come back.
My timmerflotte have been fine since I got half a dozen of them over a month ago, but two suddenly became unavailable at the exact same time now. i tried pulling and replacing the batteries as suggested above and that doesn’t even resolve it simply.
im wondering if we need to set static ipv6 addresses, the devices being paired at the same time dropping off at the exact same time and not responding to ha ping seems like a lease issue to me.
Same here. Every few months some of my Timmerflotte devices become unresponsive at the same time.
The only way to bring them back online is to power cycle them by removing the batteries.
I’m using an Ikea Dirigera as my TBR.
P.S. There is another thread about this topic, but it also doesn’t have a solution.
Fix is to stabilise the Thread Network with more Router devices (like plugs/bulbs). Keep in mind that the battery devices have rather weak radios and are prone to radio interferences from 2.4 Ghz WiFi, Zigbee and Bluetooth networks in the vicinity.
Deactivate Autochannel in your WiFi Router for the 2.4 Ghz Band and choose a channel that doesn’t interfere with Thread and Zigbee (keep in mind that Zigbee/Thread channel naming differs from WiFi, e.g. Zigbee/Thread channel 11 is within the range of WiFi channel 1).
Don’t rely on the Thread Border Router (radio) to connect to all devices, it’s the routers (like plugs) job. Battery devices should be close (same room) to the next router device (sometimes even one wall between them can be to much).
From my 50 Thread devices 28 are routers and the rest are battery driven. So even my Timmerflottes are stable and only dropped off once since i got them.
Good luck
IMHO its not a signal integrity issue. My Timmerflotte and 4 Klippok’s have good link margin to their attached parents, and these are pretty much the only devices that have this problem. Other Ikea battery devices I have are pretty solid.
1 Like
I disagree, I have more routers than end devices, and the place is small, so not out of signal range.
1 Like
In my case the registration error caused the network. I have two VLANs, and the Apple TV was on another VLAN then OTBR. Of course I opened the two VLANs at firewall level, but it was not enough. After I moved Apple TV to the same VLAN of OTBR, almost every error gone. Now I can’t add the Timmerflotte to the Apple Home (it is working very well with homeassistant), but myggbett, kajplats and aquara FP300 is working with both Apple Home and Home homeassistant.
So my opinion is to work with thread-matter-world you have to make sure that all devices belong to the same network, same VLAN, even the commissioniner device (like iPhone).
1 Like