Hello,
I’m reporting an instability issue with an IKEA ALPSUGA air quality monitor (Matter over Thread) used with Home Assistant.
My setup:
Home Assistant (Docker container, up to date)
python-matter-server (Docker container, up to date)
Border Routers: Apple TV + 2 HomePod mini (Thread)
Other Matter devices (SwitchBot lights) are stable
IKEA ALPSUGA, firmware: 1.0.15 (latest, updated via Home Assistant)
Problem
The ALPSUGA regularly becomes unavailable, several times per hour: Device works normally for a while. Then all its entities become unavailable for 2-3 (sometime mora thant 15 minutes!). It eventually recovers by itself, or after restarting matter-server manually. The problem keeps repeating many times per hour.
What matter-server logs show
Subscription Liveness timeout
Repeated CASESession timed out errors
Device marked as unavailable
Long retry loops (sometimes >15 minutes) without any response from the device
mDNS discovery still works, but the device does not answer CASE / secure exchanges
After restarting the Matter server: Other Matter devices reconnect immediately. ALPSUGA often needs several CASE attempts before responding again. Subscriptions are finally re-established.
I have a full annotated log trace showing normal operation, device becoming unresponsive for ~15 minutes, recovery after Matter server restart, then failing again a few minutes later.
Complete log: Matter server logs. Issue with IKEA ALPSTUGA · GitHub
This strongly suggests the device stops responding at the Matter/Thread application level, while the network itself remains functional.
I moved the device around the house to bring it closer to the various border routers but it is still the same behavior. And I’ve set one border router as default instead of automatic in Apple Home, but it changed nothing.
I ruled out network issues (Wi-Fi, IPv6, Thread border routers), Docker networking (host mode), Home Assistant configuration problems, and Matter Server bugs, as other Matter devices remain stable. Only this device shows the issue, consistently.
Conclusion and help
This looks like a firmware / Matter-over-Thread instability specific to the IKEA ALPSUGA, where the device can enter a blocked state for several minutes and does not recover by itself.
I’m interested to know if others see the same behavior with this device, if this is a known issue on the Matter / CSA side or if there are recommended mitigations?
Hard to tell, but just an FYI, in my case I don’t see my Alpstuga (same fw version as yours) dropping out.
If the CASE is failing, then it seems to be more of a networking issue as the CASE session involves the Matter Server trying to connect to the device.
When Alpstuga becomes unavailable in HA, can you still see it in Apple Home? If no, then I would guess it is Thread network related.
I’m not using Apple Home anymore, so the device was not paired there. I’'ve just added it to Apple Home as well to check whether it also drops out there when it becomes unavailable in HA.
Yesterday evening I did a full factory reset on the Alpstuga (long press on the circular button), removed it from Home Assistant, and re-commissioned it as a new Matter device. Since then, I haven’t seen any unavailable state anymore, and there are no errors at all in the Matter Server logs so far.
Because of that, I’m currently leaning away from a pure networking issue. Before the reset, I had already tried moving the device to several locations in the house, including right next to an Apple TV / HomePod mini, and the behavior was identical each time.
I’m now curious to see if the issue comes back after a longer uptime (2–3 days), which seems to match the pattern I observed the first time before things started flapping.
I’ll report back if it reappears.
Just to illustrate the problem – before the factory reset – here is a graph of the temperature in Alpstuga yesterday where you can see the drops:
Quick update: after performing a full factory reset (remove from HA, hardware reset, re-commission as a new Matter device), the ALPSTUGA has been stable for 4 days now.
No more unavailable states and no recurring errors in the Matter Server logs so far.
It looks like the reset cleared a bad internal state.
Update (spoke too soon): after ~4 days of stability, the issue came back.
Following a full shutdown of my Raspberry Pi (HA + Matter Server down for ~20 minutes), the ALPSTUGA started flapping again (unavailable / recovered), with repeated CASE / subscription timeouts in the Matter Server logs.
So the factory reset improved things temporarily, but it doesn’t seem to be a permanent fix. It looks like when the Matter Server is unavailable for some time, the device firmware may re-enter the same faulty state.
I will try to find a fix without another factory reset.
EDIT: After many Matter Server restarts and multiple manual reboots of the ALPSTUGA, the issue kept coming back.
I eventually proceeded with another factory reset.
Its probably a Thread networking issue, that’s why I was asking whether Apple Home still sees the device or not. Anyway, there are known problems running multiple Thread Border routers, so if possible, unplug all but ONE of the Apple TV/HomePod-minis and see if the problem still occurs.
Also you mentioned you have a SwitchBot Light, does that do Thread?
Since my previous post, I’ve observed an interesting pattern: after restarting my Raspberry Pi, the ALPSTUGA could no longer reconnect, and one of the SwitchBot lights showed the exact same behavior (CASE timeouts, subscription failures, flapping unavailable/available). Both devices were perfectly stable before the reboot.
To rule things out, I performed a full reset of the Matter Server state (Docker container + storage), recommissioned all Matter devices, and then ran a series of controlled tests.
What I found so far:
Restarting only the Matter Server: OK
Restarting Matter Server + Home Assistant containers: OK
Rebooting the Pi (sudo reboot): devices reconnect, but occasional single liveness timeout may occur (2x), followed by immediate recovery
Powering off the Pi for several minutes (shutdown -h now) and powering it back on: now stable, no recurring flapping or CASE loops so far
This leads me to believe the issue may not have been specific to the ALPSTUGA itself. Rather, it may have been exposed by it: the ALPSTUGA reports data very frequently, whereas the SwitchBot lights are mostly idle/asleep. That higher traffic seems to make it much easier to trigger and observe an underlying Matter Server or fabric state issue.
At this point, the problem does not appear to be Thread-specific either, since a Matter-over-Wi-Fi device showed the same symptoms. It seems more related to a corrupted or inconsistent Matter Server state triggered by certain restart conditions.
I’m continuing to monitor long-term stability and will report back if the issue reappears.
After several days of testing, the system is now fully stable: no disconnections, no subscription timeouts, and no negative logs. I’ve found out what was wrong. Here is all the story!
The root cause turned out to be Thread radio coverage, not a Matter or device bug. The ALPSTUGA was operating with very little radio margin. When Apple Border Routers (Apple TV and 2 HomePods mini) became active or changed role, the Thread topology shifted and the device sometimes attached to a Border Router with worse radio conditions. Rebooting the Raspberry Pi (Matter controller) then triggered bursts of re-subscriptions and handshakes, which was enough to push the link over the edge and cause CASE timeouts, liveness failures, or even pairing issues.
This explains why simply turning on the Apple TV or rebooting the Pi could destabilize the network.
The final fix was to rebuild the Thread network using a dedicated Thread Border Router (ZBT-2) and, most importantly, carefully adjust the antenna placement. Once the radio link quality was sufficient, the network became completely stable and Apple devices no longer affected the topology.
The ALPSTUGA RSSI stays around -73 dBm which is not perfect but good enough for long-term stability.
In short: this was a radio-layer issue amplified by Border Router election, and Thread is much more sensitive to marginal RSSI than Zigbee, especially during reboots and commissioning.
Damn. And I thought Thread was built to be more redundant and failsafe as Zigbee.
So, the problem is, that when the Apple Hardware gets active, some action is going on in the Thread network, that may lead the Alpstuga to connect to the wrong border router, resulting in a very bad connection state?
That may seem also the explanation. I recently bought an additional HomePod to improve the coverage in m second floor. Since a few days I’m having a lot of outages in my Alpstuga in the basement. Perhaps the Alpstuga sees my HomePod 3 levels above and connects to it. But the signal strength is so low, that only sometimes a package comes through. My other Apple stuff is much closer to the Alpstuga, so before buying the new HomePod, it didn’t matter which border router it chose, as all of them were close enough.
So, when you rebuilt your network, how did you solve the coverage over a larger place if you don’t have additional routers? That’s why I have several border routers all over the house.
But it also sounds like a SW-Problem that may be solved by a firmware update of the Alpstuga, where it reevaluates constantly which Routing/Border Router is the best.
Yes, that’s exactly what I concluded after hours of testing and troubleshooting. In my case, I have two HomePod mini and one Apple TV. The ALPSTUGA was placed upstairs, right next to one HomePod mini. But whenever I turned on the Apple TV, the Thread network seemed to be recalculated and the ALPSTUGA would attach to it instead. Since the Apple TV is one floor below, the connection quality was worse.
What I still don’t fully understand is why this happens. In theory, Thread is a mesh network and traffic should be relayed between Thread routers. It shouldn’t route everything through a single device – especially not one with a weaker radio link than a closer device.
Because the Thread network managed by Apple devices is very opaque, I wasn’t able to dig any deeper. In the Apple Home app, I tried forcing one HomePod mini as the preferred border router, but it didn’t change anything. It looked like the Apple TV was still being elected anyway.
In the end, I created my own Thread network using a ZBT-2, and now everything is stable. Regarding coverage over a larger area, I didn’t really “solve” it: I had to place both the ALPSTUGA and the ZBT-2 antenna at a reasonable distance from each other. I use the ot-ctl neighbor table command to monitor the RSSI of the ALPSTUGA (it stays around -74 dBm), and it has been very stable.
My plan is to add more Matter-over-Thread devices over time to extend the coverage of this dedicated and fully controlled Thread network.
That said, I never experienced this kind of issue with my Zigbee network either. But to be fair, it contains many more devices, so the mesh is much denser.
Interesting, I have two Yale Matter over Thread locks that were mere feet away from a border router (eero and Google Home display) at opposite ends of the house. They have been constantly offline for the past couple weeks with the same errors. I’m curious if they were trying to connect to the opposite border routers, and if I need to put a router in the in between them as well.
I assume having multiple border routers simply doesn’t help. You need to have a sufficient dense mesh network at all (enough routers). In that case: it doesn’t matter which border router is used.
My solution will be adding an Eve energy somewhere in the first floor. Or an IKEA thread plug (as soon they are available).
And in 1-2 years when in-wall tiny relay actors become available, I will perhaps start replacing some of my Zigbee devices so I can create a dense Thread network next to my already very dense Zigbee Network.
Matter/Thread is definitely a work in progress. CSA and The Thread Group have their work cut out for them, and one of the underlying tenants is the big players cooperating on these standards. This convo shows how that’s going (or not)
Having lived through deploying enterprise Ethernet and the eventually wireless… both of those showed badly in a vendor mixed environment in their early stages because even with committee standards they all did it a little different. The same looks apparently true here.
I’m in sandbox mode with matter/thread. I do have 2 inovelli fan switches fairly remote from the the ZBT-2/HA Green border router that are working and a couple of alpstugas. Adding an eve outlet in the middle to strengthen the mesh and then sit back and wait until lighting products make progress.
