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.
No, it’s my first one. I have a yellow (which has thread set up) which I use for testing, but that is currently turned off.
If your other yellow is part of the Thread network, then it still needs to be contacted for the change to happen.
Other than that remember to restart addons and then integrations in HA to make sure the change is stored.
Well, it’s two seperate networks, and the other network is running on channel 22, so not on 15, so it shouldn’t ‘lock’ it to that channel.
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.
I don’t have any, trying to add the first one 
I had to restart all involved addons and integrations to make it work and that was all.
Good to know I’ll try it again.
I have some challenges in reaching with the network, I’m talking about 20m, how is your experience with that?
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.
Yeah, I know, I did that, I tried both with a very long USB3 cable, and the included USB2 cable, but thanks for the reminder 
Other than that, add repeater devices to built a solid mesh network.
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.
Could be, I’ll try and remove everything, and see what happens if I start over.
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???
Do you want them to form one network, or two separate networks ?
This is 3 HA instances merged into 1 thread network:
Out of curiosity, how does one set the name of an OTBR?
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.
