I’m trying to set up the SkyConnect as Thread only.
Of course I want to change the channel it uses.
I want to use something else than channel 15, like channel 20.
I go and set it to 20, it says it will take 5 mins.
I wait 5 mins, if I press the Info it shows:
If I press the ‘change channel’ it shows ‘20’, so something HAS changed, but does the ‘Info’ not show the right channel?
I’ve also gotten a ‘Yellow’ running here, set up as multiprotocol, and that shows the right channel?
Not sure, but do you have another TBR on the same Thread network?
When you tell HA Thread integration to change the channel, it is also changing the dataset. The dataset change has to be coordinated with the other devices and TBRs on the same Thread network. I may have this incorrect, but I think a change in the dataset has to go through the Thread Leader before it is propagated, so maybe there is another TBR that is the Leader and its refusing the dataset change request, but I’m not entirely sure.
Ok, how many devices do you have on the network, because before the change is done on the coordinator all devices need to have received the new configuration and successfully implemented it, so it can take some time on a large network or a network with devices that are not online that often.
Sometimes it can help to activate the battery powered devices, like opening the door to activate the door sensor and so on.
Make sure you get the USB stick away from the USB-ports with an extension cable.
The USB port chips, especially those for USB3 is known to cause havoc.
Also try to make some distance to other radio chips/sticks, like Zigbee, WiFi and so on, because some of these will use the same frequency band.
The only other thing I can think of that could possibly explain what is happening is that at one time, the Yellow-Multiprotocol OTBR was seen by your current system through “discovery” and the Yellow-Multiprotocol became the “preferred” Thread network on you current system; so when changing the channel, your current system is trying to talk to the Yellow-Multiprotocol OTBR which is turned off, so fails to work. If that is not the case, then I don’t have any other ideas why its not working.
Do you use the multi-protocol setup?
If you do, then remember that both Zigbee and Matter have to use the same channel and it can be a bit tricky to change them both at the same time, which is essentially want must be done.
I remember now that I had issues with the channel when I tried to use the stick with a Matter only setup, but with a multi-protocol firmware.
I do not know if it was the firmware as such or the fact, that the firmware had been configured to multi-protocol at one point.
Since I did not need it for Zigbee I chose to install a Matter only firmware on it.
It is set up to be ONLY thread, but I think the problem is that OpenThread Boarder Router can’t handle that I have two home assistant’s running on my network, from the addons log:
Default: mDNSCoreReceiveResponse: Received from fe80::a871:66ff:fe93:4277:5353 24 7.7.2.4.3.9.e.f.f.f.6.6.1.7.8.a.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR homeassistant428.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding 23 7.7.2.4.3.9.E.F.F.F.6.6.1.7.8.A.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR homeassistant-2.local.
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::3bf7:1e86:dd6a:aa39/VLAN60/9524
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::3bf7:1e86:dd6a:aa39/VLAN60/9524
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::3bf7:1e86:dd6a:aa39/VLAN60/9524
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::3bf7:1e86:dd6a:aa39/VLAN60/9524
Default: mDNSCoreReceiveResponse: Received from fe80::3bf7:1e86:dd6a:aa39:5353 24 9.3.a.a.a.6.d.d.6.8.e.1.7.f.b.3.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR homeassistant428.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding 23 9.3.A.A.A.6.D.D.6.8.E.1.7.F.B.3.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR homeassistant-2.local.
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::3bf7:1e86:dd6a:aa39/VLAN60/9525
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::3bf7:1e86:dd6a:aa39/VLAN60/9525
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::3bf7:1e86:dd6a:aa39/VLAN60/9525
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::3bf7:1e86:dd6a:aa39/VLAN60/9525
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::3bf7:1e86:dd6a:aa39/VLAN60/9525
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::3bf7:1e86:dd6a:aa39/VLAN60/9525
Default: mDNSCoreReceiveResponse: Received from fe80::3bf7:1e86:dd6a:aa39:5353 24 9.3.a.a.a.6.d.d.6.8.e.1.7.f.b.3.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. PTR homeassistant428.local.
Default: mDNSCoreReceiveResponse: Unexpected conflict discarding 23 9.3.A.A.A.6.D.D.6.8.E.1.7.F.B.3.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. PTR homeassistant-2.local.
I just noticed after pasting it here, it says VLAN60, I had at some point a VLAN60 on a seperate NIC, but that is gone, how come it still shows up here???
Ok, so that is not the problem, weird. No I would like two seperate networks.
But when I look in the logs of my production machine, I see a lot of errors about an interface on vlan60
I no longer have an nic with an ip for HA in my VLAN60.
I can of course try to create that again to see if that helps?
But currently I’m stuck.