Ciao
I have added approx 20 identical Z-wave locks to my V3 Hub all coming up with ZWAVE_S0_DOWNGRADE and a RAW string with “good” values and the Z-wave locks are working 100%. Now, when I am adding new identical Z-wave locks on the same hub it shows ZWAVE_S2_FAILED and the RAW string have “no” values so the Z-wave lock does not work at all.
I know for sure it is not the lock since it works and pairs with S0 when using another V3 Hub.
Is there any settings on the V3 hub to “force” it to S0 downgrade mode?
MArta
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
2
Tagging @Kianoosh_Karami this may have changed how it works in 25.x - it should be seamless if the lock doesn’t support S2, it should use S0. Maybe Kianoosh can throw some light on it if that’s not the case.
If the raw description is full of 0’s that indicates that the Node Information Frame request wasn’t successfully processed by the lock. Try to reboot your hub and bring your lock closer to your hub and try it again after excluding it.
Thanks
I believe the lock supports S2 as it has a DSK code printed on it, but to my knowledge the ST v3 hub did not implement S2 (at least until now?).
The locks are only 10 cm from the hub so it is as close it can get.
I have also rebooted 10x without any success. We did also try the Secure mode toggle in the App (in the device->hub) without seeing any difference.
I agree that full of 0’s indicate that the frame request wasn’t processed correctly, but at when I try to pair the same lock on another identical hub it works (resulting in Zwave_S0_Downgrade). As I explained, the first 15-20 locks was paired successfully with ZWAVE_S0_Downgrade but it seems the hub got a switch (stuck in Secure/S2 mode?) as all locks now gets S2_Failed. Even if I unpair and repair a S0 paired lock it ends up with a S2_failed scenario.
Thanks
Perhaps the Secure mode toggle in the App should have the same label a Zigbee allow/disallow unsecure Join?
Regarding the hub it was new today and the first thing after unboxing was that it was upgraded to new firmware (25.x). All the first 20 locks was paired Zwave_S0_downgrade with this firmware before it stared to pair with Zwave_s2_failed.
Rebootet the hub 10x, and also factory reset the locks 10x.
If DTH is devicehandlers we don’t have any. The account was also new today and everything is basically untouched.
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
7
True, send a note to support so they can fix it in the next update
You may have to reach to ST staff or support, they have the tool necessary to see what’s going on. I think you’re past the debugging from an end user perspective. All you can try is to reset the hub.
Every device on your account has a DTH (device type handler), that’s how the messages to the device get formatted properly.
SmartThings has a standard library of “stock” DTHs that get distributed to all customer accounts. If you didn’t specify a custom DTH, then your devices get matched to one of the stock DTHs at the time they are added to your account.
So you do have a DTH for each device, it’s just not custom code. If you look at the device listing for your account in the IDE, you can see which DTH has been assigned to each device.
I just wanted to clear that up, because support staff will probably want to know which DTH has been assigned to each lock, even if it was automatically assigned from the standard library.
Also, we will need to know the brand and model of the locks. I’m sure that will be the first question that @Kianoosh_Karami asks.
Zigbee Insecure Rejoin
Samsung has a bad habit of using the same term two different ways, which can be very confusing. They already had location.mode and security.mode (Smart Home Monitor Armed State), each of which is often called just “mode” in the documentation, even though they are two completely different things.
Then when they released the new app, they changed the name of zigbee insecure re-join to “security mode” even though that is one more different thing. So now
a) “security mode” refers to zigbee join default
b) , “security.mode” of “Home” refers to smart home monitor armed state but is usually just called Mode, and
c) Mode also refers to “location.mode,” which might also have a value of “home” but is a completely different variable.
There were two different major platform changes in the last 10 days.
First, there was a new hub firmware update which revealed some new bugs and required a couple of patches.
Second, changes are being made to the SmartThings implementation of Zwave and the platform abstraction of it in order to get ready for S2 security. This has introduced some other issues.
Some other customers have reported that during this time. They are having problems with devices that have the option to pair securely, like some aeotec sensors. They are seeing similar messages to the one that you are seeing, but I don’t know if it’s related to your specific problem. I haven’t heard of anyone else having that many Z wave locks on a single hub before, so it might just be a problem specific to The number of devices.
Thanks JDRoberts!
Know I know the DTH abbreviation and that we are using the “Z wave lock out of the box” DTH. I will in some hours take another Hub and pair 10-20 new locks to see if the problem occurs again on another hub. If it does it seems to be some kind of problems when a certain number of locks are paired. My goal is to have approx. 200 locks to one single hub.
Marta
2 Likes
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
10
Incredible! Let us know how it goes and be sure to have lots of repeaters around.
What is the physical layout like? Since Z-Wave can only jump through 4 repeaters, what’s the maximum distance from your hub to the 200th lock?
1 Like
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
11
FYI ST is aware of this issue and is working on a fix (it’s internal)
Can I ask why you are trying to accomplish that with a single hub? Smartthings is not a very stable system to begin with, and certainly not something I would deploy in a commercial installation like a school or an apartment building because of all the unexpected glitches. It’s just not commercial grade. They have told us many times that their typical customer has 15 or fewer devices total and never uses any custom code at all.
You might take a look at the following thread if you get a chance:
There was one community member who had deployed it for an apartment complex with about 200 units, but they wrote their own management software to run above it, and to be honest, I don’t even know if they’re still using the same system, that was a couple years ago.
Also, they have told us that the classic app will be going away, although there’s no timeframe for that yet. And with the new app, you are quite limited in control of smart locks. You used to be able to trigger the locks with any smartthings event, including Geopresence, A keyfob device, etc.
But with the new app they changed their design philosophy with regard to security devices, and now you have to open the app and use that to unlock the lock. But perhaps that fits your use case, and you are just using the app to set codes and track usage.
Different things work for different people. But 200 locks is certainly testing the limits of the system. And just the fact that you cannot delay or defer updates isn’t typically a good match for a commercial use case.
Also, are you planning on having a repeating device for each lock? Because I am sure the hub cannot handle the message traffic from that many locks all at once. And one thing about locks is that you tend to get “traffic jam“ periods where most of the locks in a multiunit building are all being used at about the same time.
And 200 locks + 200 repeaters would be 400 devices, which is more than any zwave network can handle ( there is a hard limit of 231 zwave devices for a single hub) . So that’s not even technically possible.
The locks (approx 150 actually and not 200) will be deployed on one floor and not in a small area. It might be that we need more than 1 hub as the locks does not include Z-wave repeaters. I am still testing in our lab and got the S0 / S2 problem after 20 locks.
Will keep you posted!
Because of the complexity of lock messaging and the issue with the “traffic jam“ time periods I mentioned previously, I would not put more than 50 zwave locks on one master hub and I would use one beaming repeater for every two locks. That would give you a total of 75 zwave Devices per hub And you would need three master hubs (not A “sub hub” like you get on the Samsung Wi-Fi mesh system) for your 150 locks.
Just a question: have you considered using zigbee instead? Many of the locks which are commercially available including most Yale and Schlage models can take either a zwave or a zigbee radio module. And a zigbee network can handle hundreds, even thousands of devices. As @Automated_House Points out below, there is still a repeater requirement with the SmartThings Hub if you go above 64 battery powered zigbee devices , and I can’t guarantee That smartthings itself doesn’t have additional maximum count limitations you might run into.
I still wouldn’t put more than 50 locks on any one hub because of the traffic jam issue, and you still have all the basic instability challenges of SmartThings, but it might be another option to consider.
Thanks, I blanked out for a minute and was thinking of a commercial system.
But I believe the V3 hub does have the 64 device limit, So I think you could do 50 zigbee Locks with no repeaters and it would be a more efficient system than zwave for this particular use case. As long as they’re all within range of the hub, of course.
Thanks for all replies and suggestions so far! Seems I need to get another Z-wave hub. When I tested with another Smartthing V3 hub, this time the first 13 locks was paired with S0_Downgrade. Then the next 2 was paired with S2_Failed. I really see that this system is very unreliable. Perhaps I need to buy a Fibaro HomeCenter 2 or similar. Do you have any suggestions for a new hub?
Marta
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
20
Yes, your issue with the lock pairing is being looked into and they a patch in the works, it’s a platform issue AFAIK.
If you look at the device listing for your account in the IDE, you can see which DTH has been assigned to each device.
