I’ve turned off an unused wifi access point in the house and would like to relocate the Zigbee channel that Hubitat uses. I have a strong 2.4ghz signal on wifi channel 1 which is overlappping Zigbee channel 14 that my Hubitat is currently using; i’d like to move it to 18 where there is nothing going on.
I see where the channel selection is made; what is the process to use to make it take effect? When a new channel is selected in the dropdown, it reverts to its current channel. I assume that is what the Reset checkbox and red Reset button are for but just want to verify before just trying something. The text on the page says that a rejoin of devices is required; does that mean they need to be re-paired as well? I figure I might as well get this out of the way while I currently have just a few devices on the hub.
Thanks for the info on reset, my better instincts told me to avoid hitting that button.
However I just tried the channel changing procedure that you described and I can’t get it to work. Changing the channel in the drop down doesn’t stick (I’m using Chrome browser, in case that is relevant) it still shows 14; I hit ‘update’ and it still shows the same thing. I rebooted the hub and it still shows the original channel (I tried this twice). I’m on .678 of the hub software. Anything else I should try?
Successfully changed my Zigbee radio channel with the 694 firmware installed. In my case it took about 2.5 hours for the devices to reconnect with no intervention (I only have a half dozen Zigbee devices paired at this time).
For the record, just to see what would happen I tried replugging one Iris Smart Plug immediately after the channel change just to see if that would speed things along (it didn’t); I reset and re-paired one device (basically to make sure my radio was still working; that did work to immediately reconnect at the new channel). For the rest I just let time pass and let them do their thing.
I tried to change my Zigbee channel this past weekend from 21 to 15, and after 48 hours no Zigbee device had found the new channel. When I changed the hub back to 21, all the devices immediately started functioning again. Is there something else I need to do? Channel 21 overlaps with a WiFi AP close by.
In theory that’s all you need to do; in reality something obviously didn’t work as designed.
What should happen AFAIK (@JDRoberts feel free to correct any misinformation) is the devices (repeaters and end devices) should try to reconnect to the network by scanning all the Zigbee radio channels that they are capable of receiving (for the ZHA profile devices that should include channel 15; I believe only some old ZHA devices will not scan on Zigbee 11, and 24-26; if the device is some kind of private profile they don’t have to support any specific set of channels). This takes some time because some of the devices aren’t always awake and even when they are will wait for a number of failed communication attempts before deciding something is wrong and needs re-configuring.
Without knowing how your mesh configured itself its hard to say what went wrong.
Do you have repeaters in the network? Possibly none of the end devices are routing directly through the hub but instead through a repeater; they may still be linked to it on their original channel, buffering packets in a repeater that failed to initiate a scan to reconnect, thereby making the whole Zigbee network inaccessible.
You should be able to force the reconnect for any device on a new channel right away by putting your hub in ‘add devices’ mode (assuming it has established the network on the new channel-- I’m not sure how long this takes but I don’t think it is very long; since the channel is being specified the hub doesn’t have to do an ‘energy scan’ to pick an optimal channel on its own) and then resetting the device and putting it into pairing mode. The channel scan happens whenever a newly reset device is put into ‘join’ mode. You wouldn’t delete any devices from the hub before doing this; they will just re-join (assuming the new channel works) and be available to all their apps as they were before.
I would do this for the repeaters (AC powered devices) first. On reset / re-pair they should re-join on the new channel immediately (assuming the channel you picked is available to that device and no local interference is causing it to have issues). The end devices (battery operated ones) can be reset and rejoined in-place in a similar manner.
Tony, Thanks for the detailed explanation. I’ll try putting the hub in discovery mode after I change the channel to see if that helps the process along.
Regarding my mesh, the first challenge is that I’m in an urban environment with lots of competing WiFi and Bluetooth signals in the 2.4 GHz band. Second, I’m in an old house with plaster walls, and generally no power to the wall light switches. Therefore my mesh is mostly Zigbee light bulbs, with three Zigbee outlets and a few motion detectors. All but the motion detectors are powered, but I recall reading that light bulbs are not reliable repeaters do to their limited buffer memory.
I’m trying to change the Zigbee channel, because so far the mesh isn’t reliable and I’m thinking that changing the channel may help. Although any one light appears to turn on and off reliably, when turning them on or off in groups, 20 percent of the light bulbs will fail to react. Under ST I didn’t experience these problems, so I know it is possible for a configuration like this to work reliably.
Sounds like a fairly challenging environment, interference and signal propagation-wise. Note that you would essentially be resetting and re-pairing each individual device to force the channel change which is a lot of work; maybe there is some interference on channel 15 that was preventing the process from completing with that channel by itself.
Have you tried using a program such as InSSIDer; there are paid and free-to-try versions available-- to see what kind of wifi networks (other than your own) are nearby that may be competing for the spectrum? That program will show you what wifi channels are in use as well as how strongly they are being received (you can walk around the house with a laptop to take an inventory) and it may allow you make the best choice. Sounds like the ST hub picked an optimal one; have you tried turning it off (if that is an option for you) and setting your Hubitat to use the same one?
Also as you said there are many reports of Zigbee bulbs having issues acting as repeaters; some of them (especially with older firmware) are unreliable in forwarding packets in a network with more than a few devices (there were threads on the ST community discussing this). Since you had it working with SmartThings its possible the mesh had configured itself so that your non-bulb repeaters were doing most of the routing, with the bulbs paired as end-devices to them.
OK, they will repeat for each other, but may have trouble repeating for your other ZHA devices. so to minimize the possibility of their being selected as the parent for any of your other devices, you want to add all the other devices first. Then add the bulbs. Then in the future when you were going to add more zigbee devices, power off all the bulbs before adding the new device.
It appears that this issue has reappeared to some extent in the current Hub version, 706.
Today I decided to try resetting the Zigbee stick to see if it would help with my ongoing device pairing issues.
After the reset, I tried setting the channel back to 13 as I had it set before, and a seemingly random channel is selected every time I attempt to change the channel.
Prior to the reset of the Zigbee stick, changing the channel worked as expected. In order to get channel changes to follow my selection, I had to reboot the hub.
Interestingly, before I realized that the channel wasn’t changing to my selection, I was able to pair the four Xiaomi buttons and the Securifi Peanut Plug that had been refusing to pair for the past week and a half. But that was on channel 20, not 13 as I thought I had changed to.
Thanks for all of the help. I was able to change the zigbee channel but it did require re-pairing all of the devices. I do use an Android app that tells me where all of the WiFi channels are in my environment so I choose the new channels wisely, although there are no great options.
The bad news is nothing really helped. Even after trying both of the least congested zigbee channels (15, 25), the Osram Lightify lights are still unreliable. Any single bulb seems to work well, but if you turn them off in a group greater than three, one or more will fail to react. Based on some of the ST threads this may be due to the limited buffer size of the bulbs. Packets just start getting dropped.
The frustrating thing is that these bulbs did work well on ST. Although, I get the feeling that some code specific to these bulbs and their limitations was required in St. Any ideas?
I have two Hubitats. One is in a remote location with an almost empty RF spectrum and consequently a very weak Internet connection via a cell signal. It is a largely Zwave Plus installation and Hubitat works great.
The troubling installation is in an urban area and is ZigBee. It’s been a real pain. I really don’t want to run ST in one place but Hubitat in the other. Plus I’ve really gotten spoiled on the local control and flexibility of Hubitat.
Do you have ZigBee repeaters in the mix? It could just be a signal strength difference between the SmartThings hub and the ZigBee in the usb stick. You might need a plug in smart receptacle that works as a ZigBee repeater.
Apparently the Lightify bulbs are crappy repeaters due to a firmware bug, so they might be acting as repeaters for each other and causing problems due to a limited buffer size. I’m not actually sure what you can do to fix that, short of limiting the number you turn on/off at a time. You could do a staggered off, send a message to 3-4, then wait 1 second, then the next batch, and see if that solves it for you.