Thank you for using the Z-Box Hub!
Update your system to the latest version to take advantage of new features, improved performance, and important fixes.
Major Upgrade: Z-Wave Long Range Support
This update introduces Z-Wave Long Range (ZWLR) support to the Z-Box platform!
ZWLR enables direct hub-to-device communication, offering:
Unmatched network coverage
Faster and more stable connections
To use Z-Wave Long Range, ensure the device you’re including supports ZWLR. Then simply use the SmartStart scanner during inclusion and select Z-Wave Long Range when available.
What’s New
Devices
Added support for HeatIt Z-Temp3
Added support for Fantem Home Energy Meter Gen 8
Added support for Aeotec Home Energy Meter Gen5 2P (US region)
Added option to change HVAC device icons
System
Improved system boot-up performance
Plugins
Added support for Satel Integra 256 (older firmware revision)
Scenes
Updated default behavior: No devices selected by default in predefined scenarios
Bug Fixes
Access
Installers no longer see system notifications meant for administrators
Backup
Fixed a rare issue that could cause errors when uploading a cloud backup
Cameras
Resolved issue where local preview didn’t work in Safari for some cameras
Devices
Custom icons now display correctly for CO Detector types
Fixed bug in Thermostat Linked Device where the same device was assigned to both cooling and heating
Corrected handling of the optional temperature sensor in Qubino Flush Dimmer 0-10V
Restored previous icon sets for several device types
We recommend updating your hub to enjoy the latest enhancements. If you need help with the update process or want to learn more about Z-Wave Long Range, feel free to contact our support team.
Easy firmware update from the Beta release. Have had it running here for a number of days with no issues.
For those of you who haven’t tried the ZWLR support, it is extremely easy to add new devices & move existing devices from legacy Z-Wave to LR (although it requires the device to be removed & re-added).
Now, I’ve just got to move more devices to LR…
I don’t know that move is the correct word there. It’s more like starting over unfortunately. I’ve been trying to get motivated to do it, but it’s over 90 devices, and over 90 scenes to redo in my case.
It sure makes me wish there was an actual conversion process.
If your Z-Wave mesh network is working well, there’s no need to make any changes But if you’re interested in experimenting with Z-Wave Long Range, it’s best to start with devices located at the edges of your network.
Right now, I’ve got over 60 devices connected to my Z-Box hub at home, with only a few of them using Long Range. I’ll be adding a couple of ZSE70s outside soon, and those will definitely be included as Long Range devices Other than that, my mesh is running smoothly, so I don’t plan on making any changes!
Occasionally (enough to be kind of annoying) we have a considerable amount of lag before something happens. That’s why I thought about changing over to long range, as I thought maybe communicating directly with the hub, rather than through the mesh, might eliminate the lag time.
“Occasionally (enough to be kind of annoying) we have a considerable amount of lag before something happens.” – If this happened next time, could you please download the system logs right away and send them to our support?
We would love to check if there are still issues with the Silicon Labs SDK (Z-Wave Library) or maybe something different is happening in your larger network.
First, the justification–or lack thereof–for moving devices…
Yes, it would be a lot easier if removing/moving a device simply “broke” an automation and the scene where it was (formerly) deployed would simply be disabled and flagged. One would know which scenes need “fixing.” (This is how it is handled on SmartThings, which was my platform before the Z-Box.) But for now, we don’t have a “where used” capability for devices–or I don’t know of it if there is a way to do that.
That’s actually what I’ve been targeting, Bartek. A ZSE41 on an exterior door farthest from the hub, out in the garage. A couple of ZSE42 water leak sensors in the basement. (In both cases, there is considerable insulation between the devices and hub. We have a “net zero” home built with 10-inch thick walls full of insulation, as well what’s usually in a wall like wiring. Probably more signal attenuation than many places.)
It will also be interesting to see if battery life changes at all.
This is something I’ve wondered about for a long time. It isn’t just on Z-Box, as I also saw it on my two former SmartThings hubs and my son has seen it on his Hubitat–which certainly could point to library code or the details of how the Z-Wave protocol handles unexpected events.
But I’ve also wondered about collisions. Take, for example, a Z-Wave switch device two hops away from the hub. A message to turn on said switch is sent by the hub and it happens the transmission is coincidental to an asynchronous event, such as a “sleepy” device waking up to send a battery report or a temperature sensor attempting to tell the hub the temperature has changed or even a burst of RF “noise” that disrupts communications. There would be three, separate transmissions as the command hops through the mesh before finally reaching the device–hence 3x as many chances for a collision.
Now, I’m woefully ignorant of the design of the Z-Wave transport protocol: does the sender wait on a reply & try again? Is the message lost and the hub (i.e., the Z-Wave library) realize there was no on/off status message from the switch in response? Any function with a timeout would have a duration of at least 10x (or more) the expected propagation time–and I’ve seen code where waiting on completion was repeated at a higher level perhaps ten times before returning an error! All of this is effectively a delay before some error handler does something about the collision–if the error is caught at all.
Logic says there would be fewer collisions on a ZWLR connection, as there’s only one hop from device to hub or vice versa.
Am I way off on this line of thinking, @BartekZooz? (And thanks for the request to dump hub logs when it occurs! I’ll keep an eye out for it…)
I had the same thought. I’ve disabled as much of my reporting as I could (some of them I actually want). I know most of my scenes I added delays in between everything now. In my thought process originally, I would have scenes turning off, 18 different lights. Now I have a delay in between each action. Originally not everything would complete successfully sometimes and I thought perhaps it was everything trying to happen all at once. Some of my scenes are 1 second delays between actions, some are 2, but it seems to help? Perhaps it’s just placebo? Is there any actual logic to this @BartekZooz ?
I’ll try and trigger it or at least keep an eye out and forward them. As it happens fairly often to us. Maybe it’s nothing of use to you, but I’ll forward what I can.