The two time sync should not be necessary unless it is bugged.
The second sync is just to check if it is bugged or not.
You saved my day, doing this and Nuki smart lock added (that is the only device I have right now!
Hey, thanks for the input and sorry for the long delay. Life came in between.
I just wanted to mention that I did what you suggested and have also updated to HA core 2025.9.1 and HA OS 16.2 but I still have the same messages in the logs. But the devices works without issue, sometimes the become unavailable for a bit (which is annoying) but I’m not sure it is related.
You’re a legend, saved my week. I had the same issue and this solved it, thanks!!!
You’re a legend, that solved my issue, thank you !
THANK YOU! That did it for me too (2x renewing thread credentials in Android app). Didn’t even look in this corner of the config. Using an old Sonoff E stick to play with Matter/Thread and the new Ikea Matter devices I thought everything is looking good, but could not add anything. And all of this after spending hours on using a Echo4 as the thread router, which failed misserably. Completely abandonded Echo as thread router and tried the Sonoff. Sonoff is working now just fine.
Hey @WallyR,
Jumping into an older thread here, but you mentioned something here that caught my attention. I appear to have a working Thread installation, though I do see similar errors re: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ....
I do have HA multihomed, which is easy enough to disable, but I’d like to understand what the reason for this is and the impact. I have my network segmented to IoT devices with a different network policy, but it isn’t clear to me why that would impact my Matter-over-Thread devices.
Appreciate the insight here.
Just thinking it through, I could disable IPv6 on one of the interfaces on my HAOS host, but is this something that could be addressed in the software re: ensuring that the mDNS broadcasts are only sent on the appropriate interface? My read of this error message is that we’re trying to bind to a local address to send mDNS packets (I imagine on UDP:5353), but we’re conflicting with another service that’s also bound to this port? (Maybe I need to take this question upstream to the OTBR project.)
Thanks,
Ben
I am not sure why it can not assume gn an address, unless the network is not actually set up at the time it tries to do it.