This should not happen. Just a firmware update and reboot will not change the hub’s zigbee channel. If it did, many customers would have to re-add zigbee Devices every time there was a reboot.
Instead, the zigbee channel will remain the same unless you do a full factory reset of the hub, which is a very different process than just a reboot. And then you would have to rebuild your entire network.
So you shouldn’t have to worry about reboots causing Devices to get lost from the network.
There’s a totally separate issue that some accounts are experiencing where devices are being marked as off-line when they shouldn’t. But that doesn’t have anything to do with the zigbee channel or with having rebooted.
Support can confirm this if you have any further questions.
Many newer ZigBee devices do support frequency agility (changing channels) but we do not channel hop today as there are still a good number of devices which would not make the channel jump. The hub does an energy scan to do its best to pick a preferred channel with the lowest energy when the network is first setup (when you setup the hub the first time), but things on 2.4GHz tend to change over time.
On devices like the Samsung Connect Wi-Fi Router, we do additional steps to try to avoid conflicts by making use of communication between the Wi-Fi/ZigBee/Bluetooth chips to try to avoid conflicts from those spatially close transmitters on the same spectrum.
As noted by @JDRoberts, support can likely help in some ways including, potentially, selecting a different channel for ZigBee without requiring a full hub factory reset.
But the point is still that a firmware update on the SmartThings hub followed by a hub reboot should not cause the hub’s zigbee channel to change, right? It stays with whatever was assigned when the hub was first initialized?
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
632
If you are an RBoy Apps subscriber you can download the SmartApp from here. It’s still BETA and heavily depends upon on the device handler and it’s implementation. YMMV.
Since ST currently doesn’t report concurrent events (e.g. 2 up), so it will work as on/off double tap rather than on/on or off/off double tap.
Also note that the stock Z-Wave switch DTH bundled in the firmware doesn’t appear to be the same on as the one on GitHub. You will need to use the stock ST DTH on GitHub for this SmartApp to work.
I got the 18.22 and recently, including today, my hub goes inactive and then comes back. This is something new as of a few days ago.
It happened about 20 minutes ago. I received a notification that my home hub is now active. I check the notifications and at the same time it became disconnected and then active. There are actually two line items for the same active notification.
This has also happened in the middle of the night last night.
Last night it was about 10:55 PM central. I had to reboot again myself after to get all devices back online. It was a mess:
2017-09-06 10:56:20.593 PM CDT
18 hours ago HUB zwStatus ready Z-Wave is ready
2017-09-06 10:56:16.980 PM CDT
18 hours ago HUB hubStatus zw_radio_on
2017-09-06 10:56:16.974 PM CDT
18 hours ago HUB hubStatus zb_radio_on
2017-09-06 10:56:16.970 PM CDT
18 hours ago HUB hubInfo hardwareID:000D, version:13, ... hardwareID:000D, version:13, mac:xxxxxx, localip:xxxxx, localSrvPortTCP:39500, localSrvPortUDP:0, zigbeeFWMa...
2017-09-06 10:56:14.285 PM CDT
18 hours ago HUB hubStatus zw_radio_on
2017-09-06 10:56:14.278 PM CDT
18 hours ago HUB hubStatus zb_radio_on
2017-09-06 10:56:14.274 PM CDT
18 hours ago HUB hubInfo hardwareID:000D, version:13, ... hardwareID:000D, version:13, mac:xxxx, localip:xxxx, localSrvPortTCP:39500, localSrvPortUDP:0, zigbeeFWMa...
2017-09-06 10:56:12.850 PM CDT
18 hours ago HUB index:17, ip:7F000001, port:0BB8, requestId:2xxxxxx, headers:SFRUUC8xLj index:17, ip:7F000001, port:0... index:17, ip:7F000001, port:0BB8, requestId:xxxxxx, headers:SFRUUC8xLjEgMjAwIE9LDQpTZXJ2ZXI6IFZp...
2017-09-06 10:56:11.382 PM CDT
18 hours ago HUB ping ping ping
2017-09-06 10:56:11.324 PM CDT
18 hours ago HUB register register register
2017-09-06 10:56:11.310 PM CDT
18 hours ago HUB activity active Your SmartThings Hub at Home is now active.
2017-09-06 10:56:11.304 PM CDT
18 hours ago HUB hubStatus active Your SmartThings Hub at Home is now active.
2017-09-06 10:55:32.561 PM CDT
18 hours ago HUB hubStatus disconnected Your SmartThings Hub at Home is now disconnected. Please check your internet connection.
And I just looked in the logs again and see it happened at 4:07 PM central. This time it looks like everything recovered on it’s own.
2017-09-07 4:07:36.970 PM CDT
50 minutes ago HUB activity active Your SmartThings Hub at Home is now active.
2017-09-07 4:07:36.965 PM CDT
50 minutes ago HUB hubStatus active Your SmartThings Hub at Home is now active.
2017-09-07 4:07:20.153 PM CDT
50 minutes ago HUB hubStatus disconnected Your SmartThings Hub at Home is now disconnected. Please check your internet c
During an update do Zigbee devices fall off their position on the mesh, and the mesh then rebuild again? Last 3 updates I’ve noticed my furthest outlet is unreliable until a couple of days after each update.
The information about how to route messages through the network is rebuilt every time the hub reboots to apply a firmware update or for any other reason. If that furthest outlet doesn’t have a good connection to other routers (ex: the hub, outlets, bulbs and other mains powered devices) then I could see it taking some time to reestablish the route.
Intersting. That implies that the often-mentioned process of powering the hub off completely for 15 minutes or so to force zigbee devices in to panic mode is not necessary?
Powering the hub off for that long will cause any end devices that were connected directly to the hub to instead join through a nearby router if one is in range. At best this adds a bit of latency but at worst it adds network instability if the connection between the child and new parent is not great, or it the parent is one of the devices that are known to be problematic like GE Link bulbs that can just completely fail to route messages for its children.
When people experience zigbee network problems I typically recommend powering off any GE Link bulbs, OSRAM bulbs with outdated firmware, and any other router that is believed to have problems. The goal is to force end devices to join directly to the hub or to other routers in the network that are left powered on. After about 10 minutes a quick reboot of the hub doesn’t hurt as it ensures the routing tables are rebuilt according to the new network topology, and then you can power on all the stuff you powered off originally.
