I was writing that no device is supposed to be powered but not included and it dawned on me that this entire time I was sitting at my desk there was an Zooz 4 in 1 sensor that refused to properly include (lots of zeros in raw description, and security errors in app)… and it had been sitting there for a few weeks waiting for me to get to it.
I tried including it with the classic app but once again it was added like this:
Sorry for the E1 distraction, it was active because I was sitting right in front of it all this time… but I have to say this confusion was ultimately due to my previous difficulty in pairing this Zooz 4 in 1 sensor. To be fair I had not reset it in a while as I could not remember how, so maybe that was what was wrong… a sensor issue of some sort. For posterity, and myself next time I forget, all I did was open the back, remove the battery, press the zwave button and insert the battery. Once reset it paired right away in the new app even though I picked the incorrect brand for it.
(Unnecessary detail: I paired my Zwave Toolbox, and found device 225 (0xE1) and it said it was a “Notification Device” which tipped me it was a sensor… and then it dawned on me…)
Yeah, it’s a little different for each router/switch/etc, but often you can find information for your particular hardware on the Wireshark community. This is the general page for setting up Ethernet capturing: https://wiki.wireshark.org/CaptureSetup/Ethernet
The most useful option would be a capture of the port that the hub is connected to, since that will let me see all traffic going to the hub and coming from the hub without having to filter out other traffic on the WAN. A lot of it won’t be readable because of TLS encryption, but I can at least see the general flow of network messages and lower level things like DHCP. But I would take anything I could get and if WAN is the only option I will absolutely make it work.
Another thought for anyone who has network problems and has network hardware that supports exporting a config backup (such as the Unifi controller) - if you’re willing to send us your config we might be able to recreate issues here by setting up our own hardware to match your config.
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?
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
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.
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
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 S device 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.
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.
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.
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?
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:
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.
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.)
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.
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.