Here's the tl;dr: There is a common problem with Z-Wave USB sticks that utilize 700-series chips, such as Aeotec Z-Stick 7. Basically, they communicate unreliably. You should not buy one. If you want a Z-Wave controller USB stick, get one with a 500 series chip.
My whole story:
I moved last year and wanted to build a new Z-wave network using Home Assistant, and the most recommended way to do that is with a USB Z-wave stick. So I bought the latest and greatest Aeotec Z-Stick 7.
The next 4 months, I had nothing but problems with Z-Wave switches and dimmers. They wouldn't add to the network reliably. They would take a long time to complete their "interviews" where the controller learns their capabilities. But most importantly, controlling them through Z-Wave was often slow, and sometimes would fail outright. I'd press a button to turn on a light, and it typically had a noticeable split-second delay. My prior Z-Wave experience however taught me this delay was absolutely not normal. I also programmed a z-wave button to trigger a Home Assistant automation that turns on 4 z-wave lights. Too often, nothing would happen. When it worked, the commands would be staggered and delayed, and often one or two of the lights would never get the command to turn on. While any Z-Wave command was awaiting a response, other Z-Wave commands got queued, definitely not sent concurrently as one might hope for a system with long command timeouts. I could look in the z-wave debugging log and see commands go out, not get a reply, and eventually time out, then the next command would be sent and the cycle would repeat. It was an awful system. And I didn't have some massive 60+ device network with lots of traffic. I only had about 10 z-wave devices on the whole network and packets were few and far between.
I couldn't tell for sure what the problem was at first. When I started, I had the system running on a Raspberry Pi 3b. So it was easy to move around and try the controller in different locations. No position really helped, an logically it shouldn't because Z-Wave builds a mesh network so each hardwired device is supposed to be capable of repeating packets to its neighbors. If the controller can reach one device reliably, and that device can reach others in a chain, then things should work.
I thought maybe this is an issue with the pi being such a slow device with little RAM. So I moved my Home Assistant configuration to a virtual machine on a fast server (thankfully, this is super easy with Home Assistant's backup and restore functions). I connected the Z-Stick 7 with an active USB extender and put it in the ceiling of my mechanical room. This change definitely sped up Home Assistant's web interface, but the communication issues were still there.
I also considered that maybe it was my new dimmer switches at fault; they could be faulty at relaying packets or something. But hell if I was going to replace all of those on a guess.
Fortunately, (or unfortunately?) lots of other people got pissed off about their bad Z-wave performance with these new sticks, and the github issue I linked above appeared. Evidently the Z-wave chip developers are aware of the issues and trying to fix them, but as of now there still isn't a viable fix (I've tried all the latest firmwares). So for now the workaround is to use an older 500-series USB stick. A Z-Wave-JS developer even went as far as to build a tool to convert a z-wave network backup from the newer format to the older format so that people could change to an older stick without rebuilding their network.
The popular Aeotec Z-Stick Gen5+ is getting harder to find, so I bought a Nortek HUSBZB-1 instead, thinking it would be equivalent. It is not. The HUSBZB-1 stick doesn't support the standard network backup and restore commands. Apparently this can be fixed with a firmware update, but to install the update you have to pop open the casing and short a specific pad on the PCB to ground at certain stages of the upgrade.
I decided that was a bit too risky, and with just a dozen or so devices on my network, I could just rebuild the network manually. This is done by running the exclusion and inclusion processes for each device, and then reconfiguring each of them as desired. The communication was MUCH more reliable this time. Devices added much faster. Their interviews completed much quicker. It still took me about 4 hours to get finished, but most of that time was reconfiguring the devices (setting minimum dim levels and stuff) and reconfiguring other software to deal with the changed device IDs. In that time I also discovered that the Zwavejs2Mqtt addon Release 6.5.1, as of a few weeks ago, was a bit bugged and unable to set certain device configuration properties, so I had to restore an older version of the addon from a backup before I could complete configuration.
Since rebuilding the network on the 500 series stick, performance has been good. I would not move back to the 700 series stick even if my 500-series stick had a compatible backup and restore mechanism (which it currently does not) because there would simply be no benefit.
My whole story:
I moved last year and wanted to build a new Z-wave network using Home Assistant, and the most recommended way to do that is with a USB Z-wave stick. So I bought the latest and greatest Aeotec Z-Stick 7.
The next 4 months, I had nothing but problems with Z-Wave switches and dimmers. They wouldn't add to the network reliably. They would take a long time to complete their "interviews" where the controller learns their capabilities. But most importantly, controlling them through Z-Wave was often slow, and sometimes would fail outright. I'd press a button to turn on a light, and it typically had a noticeable split-second delay. My prior Z-Wave experience however taught me this delay was absolutely not normal. I also programmed a z-wave button to trigger a Home Assistant automation that turns on 4 z-wave lights. Too often, nothing would happen. When it worked, the commands would be staggered and delayed, and often one or two of the lights would never get the command to turn on. While any Z-Wave command was awaiting a response, other Z-Wave commands got queued, definitely not sent concurrently as one might hope for a system with long command timeouts. I could look in the z-wave debugging log and see commands go out, not get a reply, and eventually time out, then the next command would be sent and the cycle would repeat. It was an awful system. And I didn't have some massive 60+ device network with lots of traffic. I only had about 10 z-wave devices on the whole network and packets were few and far between.
I couldn't tell for sure what the problem was at first. When I started, I had the system running on a Raspberry Pi 3b. So it was easy to move around and try the controller in different locations. No position really helped, an logically it shouldn't because Z-Wave builds a mesh network so each hardwired device is supposed to be capable of repeating packets to its neighbors. If the controller can reach one device reliably, and that device can reach others in a chain, then things should work.
I thought maybe this is an issue with the pi being such a slow device with little RAM. So I moved my Home Assistant configuration to a virtual machine on a fast server (thankfully, this is super easy with Home Assistant's backup and restore functions). I connected the Z-Stick 7 with an active USB extender and put it in the ceiling of my mechanical room. This change definitely sped up Home Assistant's web interface, but the communication issues were still there.
I also considered that maybe it was my new dimmer switches at fault; they could be faulty at relaying packets or something. But hell if I was going to replace all of those on a guess.
Fortunately, (or unfortunately?) lots of other people got pissed off about their bad Z-wave performance with these new sticks, and the github issue I linked above appeared. Evidently the Z-wave chip developers are aware of the issues and trying to fix them, but as of now there still isn't a viable fix (I've tried all the latest firmwares). So for now the workaround is to use an older 500-series USB stick. A Z-Wave-JS developer even went as far as to build a tool to convert a z-wave network backup from the newer format to the older format so that people could change to an older stick without rebuilding their network.
The popular Aeotec Z-Stick Gen5+ is getting harder to find, so I bought a Nortek HUSBZB-1 instead, thinking it would be equivalent. It is not. The HUSBZB-1 stick doesn't support the standard network backup and restore commands. Apparently this can be fixed with a firmware update, but to install the update you have to pop open the casing and short a specific pad on the PCB to ground at certain stages of the upgrade.
I decided that was a bit too risky, and with just a dozen or so devices on my network, I could just rebuild the network manually. This is done by running the exclusion and inclusion processes for each device, and then reconfiguring each of them as desired. The communication was MUCH more reliable this time. Devices added much faster. Their interviews completed much quicker. It still took me about 4 hours to get finished, but most of that time was reconfiguring the devices (setting minimum dim levels and stuff) and reconfiguring other software to deal with the changed device IDs. In that time I also discovered that the Zwavejs2Mqtt addon Release 6.5.1, as of a few weeks ago, was a bit bugged and unable to set certain device configuration properties, so I had to restore an older version of the addon from a backup before I could complete configuration.
Since rebuilding the network on the 500 series stick, performance has been good. I would not move back to the 700 series stick even if my 500-series stick had a compatible backup and restore mechanism (which it currently does not) because there would simply be no benefit.
