I have wrestled with this problem for weeks trying to get the Ikea Bilresa switches to be reliable. They paired OK into HA, and worked at first, but when they went to sleep, they would become unresponsive - until some time in the future when the backlog of events fired through into HA.
My setup is as follows:
A lan-connected Sonoff Dongle Max running Thread RCP
Open Thread Border Router running in a docker container on an Ubuntu server (using bnutzer/otbr-tcp:latest, because I couldn’t get the openthread version to work over IP)
Home Assistant running in a docker container on a Synology DS920+ (network_mode: host)
Matter integration in HA
Thread Integration in HA
OTBR Integration in HA
Everything appeared to connect and talk to each other but when left for a while, they became very unresponsive.
With the help of Gemini and ChatGPT, I spent hours tracing logs ipv6 routings, ot-ctl commands, etc but ended up going round in circles.
So just in case anyone else is going round the same circles - here’s what my problem was and what solved it.
My ufw config defaults to “Drop” for anything that hasn’t got an explicit rule. After some time, I’m guessing that the IP traffic was no longer ‘related’ and so came in as new requests on the wpan0 interface, and were duly dropped by the firewall. It was only when OTBR sent out a ‘are you still there’ message that the events were able to come through.
So the solution was simple - add a new rule to allow all traffic from the thread ipv6 range on the wpan0 and the responses from the switches became reliable.
I'm running into the same problems with my Bilresa double button switches.
They work fine and then become unresponsive, until they suddenly do become responsive again.
From what I understand, you have managed to fix this. Can you help me get an understanding of what you did or how you added this rule? I'm pretty new to Home Assistant and have no knowledge of programming, however, I can paste a command somewhere
Could you perhaps explain what the steps are in dummy language?
@pk1966 I made an account just to thank you for this solution. I had been stuck on this issue for a while too, but the closest I got to solving it was extending the UDP packet timeout.
@Homeassistant7051 You didn’t mention what OS or firewall you use.
Nftables (modern) and Iptables (legacy) are backend firewalls that can be run stand alone but if paired with a frontend like ufw (default for Debian and Ubuntu) or firewalled (default for Fedora, RHEL and CentOS) then you should interact with the frontend instead of the backend.
Assuming you are using the default bash shell, run the following command to find out what firewall you use:
if systemctl is-active --quiet firewalld; then
echo "→ firewalld is active and managing rules. Use firewall-cmd."
elif sudo ufw status 2>/dev/null | grep -q "Status: active"; then
echo "→ ufw is active and managing rules. Use ufw commands."
elif sudo nft list ruleset 2>/dev/null | grep -q .; then
echo "→ No frontend active, but raw nftables rules exist. Use nft directly."
elif sudo iptables -S 2>/dev/null | grep -qv '^-P'; then
echo "→ No frontend active, but raw iptables rules exist. Use iptables directly."
else
echo "→ No active firewall rules detected on this system."
fi
@Homeassistant7051 - apologies for the delay - I’ve been away and not on this forum, but @rd5hd has answered it already (he includes a nice script to determine which firewall you are using)
As I mentioned in my post, my OTBR container is on Ubuntu Linux and I use ufw for the firewall.
If your OTBR container is running on Linux, you can check if you are using ufw by typing
sudo ufw status
If it says “Status: active” at the top, then lists a series of rules, you can use the following command
sudo ufw allow in on wpan0 comment 'Allow all traffic in from Thread network'
(the “comment ‘Allow all traffic in from Thread network’” is optional - it just helps you keep track of firewall rules)
