I recently see logs about the network congestion being really high. So I want to switch from channel on my SkyConnect using ZHA.
I noticed that in ZHA, you can switch channel. Has anyone tried this before and did it work? Did you have to re-connect all devices? I mainly have Aqara sensors and some Blitzwolf power plugs. I prefer not to have to re-connect every device. 
It will still depend on your Zigbee Coordinator and your specific Zigbee devices if you need to repair some devices and especially battery-powered Zigbee devices are known to be bad at changing channels so some or all of those may need to be re-paired if you change the channel. See my comment here:
This new experimental feature that puddly added now allows users of the ZHA integration to perform Zigbee channel migration directly from the UI for all supported radio types without the need to re-pair all devices or have any entities changed.
ZNP (Texas Instruments) based devices currently has the best implementation of Zigbee channel changing as it allows the Zigbee Coordinator to change Zigbee channels after having a few chances to send out the broadcast to all the devices. Other Zigbee Coordinator adapters (e.g. Silicon Labs EZSP and Dresden Elektronik’s deconz based radios) instead migrate/change the Zigbee channel almost immediately, giving Zigbee End Devices (e.i. battery-powered devices) a smaller window of receiving the channel change request broadcast, however, such devices still have a chance of finding the network again if they detect that they have been orphaned.
Modern mains-powered devices should normally all change channels without any problems. After waiting a while for all devices to change channels automatically the general recommendation is then to perform a power cycle of devices that did not automatically change channels (usually simply by removing and replacing the battery) before just re-pairing those devices in the ZHA integration.
“Currently, ZNP implements the best version of this API because it allows the coordinator to change channels after having a few chances to send out the broadcast. Other coordinators (EZSP and deCONZ) directly react to the loopback request and migrate almost immediately. This rudimentary version has been implemented in zigpy-cli for some time and has been used by a few people to migrate their networks. From what I can tell, if an end device does not react to the channel change broadcast, it definitely won’t with a unicast request. But it still might find the network again after detecting that it has been orphaned.”
PS: You should however note that changing the Zigbee channel is not a magic bullet for reception/transceiving-related issues, so users probably want to refer to ZHA integration documentation’s new troubleshooting section on interference and range/coverage optimization tips as well as this related discussion → Guide for Zigbee interference avoidance and network range/coverage optimization
Thanks. I made the switch. The battery powered devices had to be re-paired indeed. The powered devices switched immediately. It all runs now.
So far it has increased the network stability and increased the signal strengths so far.
Agan, be sure to follow Guide for Zigbee interference avoidance and network range/coverage optimization