Yes. I understand that. But by now, there should be a CAUTION NOTE on the Release Page that advises Users of these problems, and perhaps suggesting that they hold off using Long Range until the problems are resolved.
I'm not so sure about that part... Other LR supporting hubs aren't having this specific issue.
But the end result is the same either way.
1 Like
Do you know if they are using Z/IP or the Unify Gateway? Supposedly some of the LR issues are stemming from the Z/IP Gateway.
Neither. Zwave JS uses their own, and Z-Way uses their own.
Neither use z/ip or unify gateway as is. Similar to how hubitat did it before they went for certification and forced them to go Z/IP.
Although I did talk to a dev that uses the unify gateway the other week in Austin, and is not having any obvious issues.
2 Likes
Yeah I had to look back at a discussion I was having with someone elsewhere, and they were also having problems with LR using Z/IP, along with another company they work closely with who also uses Z/IP on a hub. They said the same thing about Z-Wave .Me and Z-Wave JS not having any issues, but also knew they are not using Z/IP. Common theme seems to be the Z/IP Gateway 
2 Likes
The only reason anyone used Z/IP is because they were forced to in order to get certification for a long time. I don't know anyone that has worked with it and liked it.
That said, I admit that I've only talked to maybe a half dozen Z-Wave developers that directly used it. So maybe that isn't a big enough sample to draw a firm conclusion.
I don't think anyone will be using it within the next year since it is basically end of life. Well, not if they want things to actually work right. 
2 Likes
I am trying to understand the practical basis of this problem so that I can publish a warning to other HE Users, since Hubitat does not seem inclined to do so.
Everything was working fine with my Long Range devices, UNTIL, a Cloud Backup failed and indicated that the ZWave Radio backup failed. It was after Recovering my network using one of the Cloud Backups that said the ZWave Radio was properly backed up, that everything went south. The Long Range Devices were recovered, but he Zwave Radio information for the Long Range devices was not recovered.
Sooo, does the Long Range network generally work OK as long as you don't ever need to make a backup and/or recover from a failure?
Does the Z/IP issue (which I do not understand) primarily affect the ability of the Hub to transfer complete Long Range devices information to a backup?
After this failure, will we ever be able to add Long Range devices, again?
And since Hubitat has not even acknowledged there is a problem, when will we know it is "safe" to use Long Range devices, again?
Yes it has generally been working OK for most people. There is an issue (unrelated to this) where the nodes become hidden from the details page but the devices keep working. Seems to not have any other side effects really. Otherwise has been working fine.
Also, I have been told that the backup/restore typically works and it has only been a few cases where the LR devices do not transfer over.
Not sure exactly but that seems to be the stance for most of the current issues. Not sure that would impact the ability to make/restore a backup but I also am not a z-wave engineer.
The backup restore failure to recover the LR nodes is not directly related to the bootstrapping issue. You just happened to get hit with both of the issues right after the other, but has not been the case for everyone. Might be a fix, I already said they are trying to figure out a fix. If there is no fix the only way to recover from the bootstrapping problem currently is a radio reset.
1 Like
Interesting that you mention bootstrapping...
As part of my recovering from this debacle, I performed a factory reset on each of my LR devices and then Included them again in Mesh mode. When performing the Inclusion, every one of the devices displayed something I have never seen before when Including a device. I didn't write down the text, but as soon as the Hub recognized the new device, it said something about the device going through a bootstrap process. It then finished the Inclusion like the normal process.
The bootstrapping is a normal part of the device onboarding. Possibly a message about it is new, have not noticed myself. The error with pairing the LR devices is just saying that process failed and why it is not able to pair it.
1 Like
Does that mean that I can no longer make these specific LR devices work as LR, or that I can no longer make any LR devices work as LR?
Probably that no device will pair as LR with the current state of your radio. Myself and a couple of others are stuck like that as well at the moment.
1 Like
So if I were to migrate my C8 to a C8Pro, would the problem flow to the C8Pro?
I would urge you to add devices with SmartSart and then to use @jtp10181 SmartStart App. It will make managing the adding of devices much easier in the future.
This problem is unfortunate for sure. I hit it as well along with some other weirdness. In the end I ended up reseting the radio and adding everything back. Mine was related to a restore for a migration from a C8 to a C8 pro. It all worked fine on the C8 in Beta. I am sure they will work the kinks out before to long, but this is all the very cutting edge on Hubitat.
1 Like
Probably would, not certain though.
Just wanted to chime in and say I have the same issue on a new C8-Pro that was migrated from a C7 (that was migrated from a C5). I'm unable to add LR devices with the same error:
Z-Wave device id: 0 failed S2 bootstrapping - Unknown status code - the device needs to be excluded then included again to use securely.
Having to do a full radio reset to resolve the issue has to be a joke. No one has time for that. The only reason I upgraded hubs was for LR support and now I can't even use it.
1 Like
I am not sure that a full radio reset actually "resolves" the problem. It just addresses the symptoms (can't add LR devices). And the problem could happen, again. There is no resolution for the problem at this time.
I think what the reset does is clean up the Zwave DB. I think this may be needed as something(not a device) that previously got added improperly cause a bad record and that bad data was irrelevant before new features with LR.
Simply put i think LR is calling out DB's that have improper data in the DB. I also think in some cases the zwave backup restore is part of the culprit. I think the current backup/restore of zwave is a little messed up when LR is involved.
Yes. A Zwave reset would (should) clean up the database. But why can the database continue to be corrupted?
I tend to agree with you. Database "corruption" seems to be an ongoing problem with Zwave. It has certainly gotten better over the years. But it does not seem to enforce referential integrity in writes to the database that would eliminate database corruption. Hence the corruption. I really wish there was a way to edit the Zwave database to delete "orphan" records, etc. That is, extract each of the Tables from the database, edit them, and return them to the Zwave chip.
The vast majority of problems I have experienced with ZWave over the years (orphans, etc.) seem to be a function of the Silicon Labs Zwave firmware, not Hubitat.
2 Likes
The staff have made vague nods here-&-there that they are working with SiLabs on both ZW and ZB issues, so I'm really hoping those discussions are steadily progressing toward real improvements for both protocols.
Both my ZW and ZB are working well right now on my 8Pro (knock on wood!), but I can't shake the feeling both are hanging by a thread.
2 Likes
