You can also look it up at the Zooz knowledge base, there’s an article on how to perform factory reset for every device (http://www.support.getzooz.com/kb/article/71-how-do-i-perform-hard-reset-on-my-4in1-sensor/)
2 Likes
To avoid a cross post - reported an issue on the release topic which I’m seeing in the general release hub:
EDIT: This issue was resolved, see this topic:
Unfortunately, I had to reprogram all my devices into Smartthings Hub. I mage to get all devices to work except two Fibaro motion sensor and my Schlage Connect Door lock. The Fibaro motion sensor are saying that I need to sync or are offline. The Schlage could be included in the network but is doing nothing due to network problem or appears offline. All these items were working perfectly but now whatever I do, I cannot make them work again. Anyone having the same problems?
I posted in the wrong thread so linking to correct post.
Are you running a custom DTH? If so, you could try deleting it and using the default.
This is my investigation result to your comments and concerns about the your switches status not being updated as fast as 0.24.X. I had discussed this in private message with you, but since you asked about it again, I figured maybe there are useful information for others.
How Z-Wave Local Polling Works:
A given network has Z-Wave Devices (X), and there then exists (Y) devices that are of listening type and mains powered that the the hub will poll. Due to an old and expired since 2016 Lutron patent, some older Z-Wave devices (Switches) could not notify a change in their state to the hub, so we must poll these special devices at a faster rate so when there is a change in their state, we can catch that change. Z-Wave switches that support Association (0x85) command class do report the change in their state.
The Y devices are compromised of the following group following types:
-
Fast Polled (
F): Each device will get polled again if 10 seconds has elapsed since last poll. The devices that fall under this group are the devices that do not report the change in their status as discussed earlier. -
Slow Polled (
S): Each device will get polled again if 15 minutes has elapsed since last poll or activity. Only devices that are listening and mains powered fall under this type of polling. Import to note, that switches that do report a change in their state fall under this type.
So Y = F + S
Then there is also another rule and Z-Wave specification rule that we must abide by
- There needs to exist 1.25 seconds difference between two consecutive polls (
t(n) >= t(m) + 1.25 seconds; where n, m is any node)
So basically, when you have “Y” Nodes that need to be polled, the fastest that we can poll another device in the F is the largest value between the following
-
10 seconds(Fast Frequency Interval) 1.25 seconds * F
Example 1:
So, let’s say that a given network have 50 Z-Wave devices, 30 of these devices are listening devices (Y = 30), 10 of 30 devices are switches that need to be polled (F = 10, S = 20) at a fast rate, the fastest that a non reporting switch will be polled again is 10 * 1.25 seconds = 12.5 Seconds.
Example 2:
A network has 100 devices, 60 of those are listening devices (Y = 60), 45 of the 60 devices are switches that need to be polled at fast rate (F = 45, S = 15).
This gives us the fastest a switch can be polled = 45 * 1.25 = 56.25 seconds
However,
I have tried to emphasize that those calculations are the FASTEST calculations and if everything ideal
- Polling messages have lower priorities than users messages, so if there is a user/cloud command those are executed ahead of polling messages, so that means the next poll can be delayed
- Some devices could take longer than 1.25 seconds to complete a polling session which includes there request and a response.
- Some cases, the slower devices (
S) will need to be polled as well (15 minutes has elapsed). - In some cases, if a
Sdevice has missed many polls, the device is no longer polled at faster rate to avoid slowing down polls for other devices.
Also, this behavior has been the same since 24.X and has not really changed, I even have put some hubs using the old framework (in 25.X we have a new Z-Wave framework while having the ability to put hubs on 24.X framework so essentially running 24.X in some sense) and noticed 25.X is faster in terms of behavior.
Suggestions
Replace your older Z-Wave switches with newer ones, and make sure they do support Association Command class (Most of the Z-Wave Plus switches do support Association) or in general the newer devices do, otherwise you could possibly be getting the same issue where the state is not reported when you expected.
8 Likes
was a solution found for the issue with August locks? I just tested mine and have similar issues.
For me… removed it, performed a general device exclusion, reset the lock and then added it back and it still didn’t work. I believe I performed 5 or 6 exclusions and pairing it again before it finally worked after 2 days. Go figure!
For my second August lock which fell offline later that day, removed it, performed a general device exclusion and paired to ST again and it has been fine since.
just tested a few times locking or unlocking from classic app, and after not working for about 10 minutes, the lock now is operating as expected… perhaps cloud is having issues?
I have two sensors and both are using the default Fibaro Motion Sensor ZW5 device handler with execution location local. Both are offline and shows no activity. The sensors themselves are reacting to motions. If I use the Z-Wave Motion/Temp/Light Sensor device handler or a custom one, they are staying offline.
@Kianoosh_Karami your post was awesome and very useful for those of us who like to dig deeper into our networks. If I understood fully, I can limit unnecessary traffic on my network by eliminating all devices that require polling. I’ve likely already eliminated most of them when I replaced all/most(?) classic zwave devices with plus versions.
What is the easiest way to check what capabilities are supported? I know I can see them using Sigma Design’s PC Controller software but was wondering whether the IDE exposes them too… maybe in the raw description?
Also, does the DTH have to specifically handle it somehow?
@JDRoberts - Posts like this gem by @Kianoosh_Karami need to be saved in an FAQ as they are super valuable in helping troubleshoot zwave mesh networks. Do you already have an FAQ dedicated to this type of info?
The zwave alliance site lists them for each device.
1 Like
Really appreciate the detailed info. It still does not explain the huge difference in behavior in my Z-Wave devices before and after the FW update. The ONLY thing that changed was the FW update and now I have the issues I have described.
I’ll leave this here too … others are now seeing the same as me on locks:
2 Likes
Note that the Lutron patent never applied to switches ( binary on/off devices). It only applied to dimmers. (Called “Multilevel switches“ in the Zwave command specification.)
Manufacturers could license the Lutron patent for zwave dimmers, and both Leviton and Cooper did. This was implemented in the Z wave specification as the “hail” command, since deprecated but still used.
Method 1 for “instant status
As of 2018, there are two different ways to implement “instant status.“ The first is not simply association, but rather association to the hub. That’s an important distinction because there are devices, such as the Leviton and Cooper local scene controllers, which use association but did not necessarily notify the hub.
Once you get to Z wave plus devices, The whole meaning of association changed and almost all zwave plus certified devices are now required to report status to the “Lifeline Association group.” ( The data required to be reported varies by device class.) See the community FAQ For details:
Method two for instant status
The other method is “central scene commands.“ this works very well, and can be found in both fourth and fifth generation Z wave devices, but is optional and left up to the manufacturer to implement or not. The Homeseer dimmers use this.
So before you run out and start replacing existing devices, note the following:
-
the only devices that should be candidates for replacement under this goal would be classic Z wave dimmers that do not support the hail commandset. This will mostly be GE, Enerwave, TKP, and linear. But not Eaton Cooper or Leviton.
-
Supporting association is not enough to remove a device that would otherwise be a candidate. It has to be set up so that the hub is in the primary association group. If it’s a Z wave plus device, no problem: this is now mandatory under the specification. But if it’s an older device, it may have implemented association in a group that did not include the hub.
Note that the official entry at the Z wave alliance products site will usually specify not just the command sets supported by a device but the specific associations allowed. That’s what you want to look at to see if association is being used to update status to the hub.
https://products.z-wavealliance.org
-
A device that supports central scene commands should not be a candidate for replacement in this group even if it doesn’t support association. Central scene commands in and of themselves are enough to notify the hub.
-
In wall micros that are dimmers were not subject to the patent for some really complex technical reasons. However, they typically have a parameter that Has to be changed in order to implement instant status. So you want to make sure that that is set the way you want it to be. If the parameter is not exposed in the official device type handler You can temporarily use the Z wave tweaker, reconfigure the device, The settings will be saved in the device’s firmware, and then you can change back to your regular every day DTH.
If you want to replace your older GE dimmers with newer Z wave plus devices, have at it. 
( i’m really tired today, and I may have skipped a couple of things, but most of these issues have been discussed previously in the forums, including Zwave alliance references and contributions by some smartthings staff, so you can dig those out if you’re interested.)
Any community member can add to the wiki section of the forum, so feel free to add whatever you Think would be helpful.
4 Likes
Also, one more important point.
Z-Wave switches that support
Association (0x85)command class do report the change in their state.
In addition to the issue of whether they are associated to the hub, this statement is only partially true. To understand why we have to go back to the original patent.
Lutron is primarily an engineering company focused on lighting. They hold many different patents and they were the ones who invented the original analog dimmer switch.
The patent applied to any radio frequency dimmer switch (zigbee, zwave, Bluetooth, WiFi, whatever) that wanted to allow the device to report its new dim level when it was manually changed at the wall device. This was actually a really big deal at the time.
OK, that patent and a second related patent were licensed by most of the more expensive device manufacturers (including control4 and Leviton) And popularly called “instant status.”
There were two ways to get around it without violating the patent: association, which meant that anytime the dim level was changed, a command would be sent to the devices in the Association group Telling them to change to that same dim level. Hubs like smartthings were able to capture that information if they were included in the association group.
And central scene commands work in a completely different way And so also didn’t violate the patent for technical reasons. (Instead of sending the new dim level, The device sends a central scene number, which gets around it.)
Here’s the thing, though. The patent only applied to The mechanical movement of switches on the wall. That’s why the micros didn’t have to license it. It wasn’t needed for situations where you were adjusting the dim level in the app, because in that case the hub would know about it before the dimmer switch knew about it.
Voice commands that go through the hub should also be OK, because again, the hub will know about it before the dimmer switch knows about it.
But here’s a fun one: three ways. (switches or dimmers) If you do these with direct association, it is possible, even if the master dimmer is zwave plus, that the hub will not get updated with the status of the auxiliary If the auxiliary Is not zwave plus. Because the auxiliary won’t tell the hub and the master is only telling the hub about its own change in status.
And for some complex technical reasons if the auxiliary initiates the change, the master may not tell the hub about its own change because it comes in as a “network command“ and the master thinks the hub already knows. But if that network command came in from a Z wave classic device, the hub might not know.
And the second case can apply even if the auxiliary is connected with a physical traveler wire. Because remember the original patent only applied to the device on the wall. Some masters mistakenly interpret an instruction from the auxiliary as a “network command.” So again, they don’t bother telling the hub.
You may remember that Leviton had this problem with some of their models, where the status didn’t get updated. They eventually released a firmware update which fixed the problem. We discussed this at the time.
Devices using central scene commands will not have this problem Because it will be the hub that sends out the change commands to the other devices. So the hub will obviously know about them.
Devices using local scene commands will often have this problem because by definition the hub is not being told.
Devices using association May have this problem for the target device even if it supports association with the hub because of the confusion about where a “network command“ originated. And the same is true for devices that have an auxiliary connected with a physical wire. Which is why you still have to poll them every once in a while.
3 Likes
Thanks for the great and detailed info, specially about the patent. I did not know all the details around the patent, I am going to bookmark this and derive another write up. To be fair to my original statement, I tried to generalize the situation to explain the local polling mechanism, Perhaps the recommendation could have used a bit more description and clarity.
We do NOT qualify switches with Hail command class as self reporting, this is a change we can make maybe in future releases to drive the F: Fast polled devices down.
4 Likes
Hail is complicated, but it does follow the patent method. It doesn’t send the new dim level immediately. Instead, it just tells the hub, “I have new information for you.” Then the hub is supposed to poll the device as soon as it can to get the new status. Hail was intended to be a very lightweight burden on the network, essentially polling on request but allowing the hub to still schedule the poll. The hail method has both advantages and disadvantages when compared with association, but it does require that there be a second round of communication.
Some previous discussion of the SmartThings implementation of hail in the following thread:
The hub does automatically generate a Basic Get message when receiving a Hail command for a given device. I was wondering if we should drop those devices from the Fast Polled Devices. That means removing unnecessary polls.
2 Likes
That would make sense, but I don’t know if there’s anything else in the smartthings implementation that might be affected. Or if, as indicated in the old thread I just linked to, some of the stock device type handlers had hail commented out, meaning the device should be using it but smartthings wasn’t always.
Definitely, though, the whole purpose of hail was to reduce the need for polling. The “polling on demand” concept.
One thing that used to be true with zwave classic devices, but I don’t know if it’s still is, is that the SmartThings hub would automatically add itself to Association group one when the device was included in the network. That wasn’t always a good thing since, as mentioned, some manufacturers reserved association group one for other purposes, but it was the default. You can go in and change the associations later if required for a specific device.
Then with zwave plus, The specification itself was changed to require that the hub always be included in association group one. And this method will, as noted in the old thread, be quicker than hail because it no longer requires two rounds of communication. The dim level information is sent with the first message instead of depending on “poll on-demand.”
So the question now is what happens with a Classic device that supports both hail and association. Or even a Z wave plus device that supports both hail and the mandatory lifeline Association group.
And the answer, as often happens with zwave, is that there are some differences by manufacturer.
Aeon Labs, for their nano dimmer micro, made this decision that the user could set a parameter that would send either a hail or a notification frame.
https://products.z-wavealliance.org/products/2095
But Leviton, for their Z wave plus dimmer, made the decision to send the notification frame to the lifeline group, while still supporting hail separately. This is necessary to maintain backwards compatibility with their local scene controllers. But it can definitely be confusing because now the hub is going to receive multiple notifications for the same event.
https://products.z-wavealliance.org/products/1910
So with the Leviton, now you have a device using two different methods intended to reduce polling but if they get used at the same time may actually be increasing the polling traffic. 
I suspect this is why the hail processing is sometimes commented out in the stock handlers. ( but if you do comment it out, then those dimmers won’t work properly with the Leviton local scene controllers.)
And in either case, if you add your own platform – dependent “fast polling” on top of that you would then be getting three sets of traffic from the same device. The Notification frame from the lifeline group, the hail from the device, and the fast polling.
I don’t know enough about the smartthings zwave implementation to know if anything else would be affected if you took the devices off of the fast polling group, but I certainly agree it would theoretically make sense to do so. I’m just concerned about the possibility of DTHs out there that have removed the hail command processing for whatever reason.
4 Likes
When playing in the ide with the new homeseer zwave plus dimmers and Ge zwave plus dimmers, it looks to me that they were returning status using the basicSet or setlevel, unsolicited push, and not central scene.
They may also send central scene, but they are also sending basicSet which he SmartThings hub can use.
In looking at the SmartThings code, it does not seem any built-in SmartThings devices handle the central scene commands.
Again, it seems central scene is not used in built-in SmartThings device handlers.
Also, while the homeseer was sending double/triple etc clicks using the central scene command, the Ge zwave plus dimmer seems to send a double click using the value in the setlevel command to the hub which also exposes a SmartThings bug.
According to the zwave standard the setlevel dim value was from 0 to something before 255. So GE was free to use 255.
SmartThings using a simple greater than 0 check to see if switch is on.
Which means, double clicking a Ge zwave plus dimmer, which does NOT turn on the dimmer, makes the SmartThings hub think the dimmer is on, which it is not.
The multiple tab for homeseer is just ignored.
@JDRoberts you mention that the patent did not cover switches, the patent just covered dimmers.
This May be true, but all of the older zwave switches, that I have played with, seem to be NOT instant status.
Both older zwave switches and dimmers were not instant status.
Reporting status using a zwave plus switch is much more reliable than the older classic zwave switches.
I think the zwave classic switches are simply being polled for status.
1 Like