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.
