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.
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.)
Any community member can add to the wiki section of the forum, so feel free to add whatever you Think would be helpful.
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.
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.
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.
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.
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.
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.
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.
I believe The GE Zwave plus Devices use association groups for their double tap.
The Homeseer uses central scene:
COMPATIBILITY (with Non-HomeSeer systems)
The special features of this dimmer are supported using a number of different Z-Wave technologies. HomeSeer systems are de- signed to support these technologies and will provide the most seamless operation of these features. However, other systems may also provide satisfactory results depending on the level of support they provide for these same technologies. If you’re using a non- HomeSeer system, use the information below and consult with your system manufacturer to determine the level of compatibility.
Multi-tap Triggers: This feature uses the Z-Wave CENTRAL SCENE command class. If the system supports this command class AND
utilizes a general interrogation process for inclusion, this feature should work. However, if the system employs an inclusion process based on the Z-Wave product ID, then specific product support would need to be implemented.
Instant Status: This feature is supported using a Z-Wave MULTILEVEL REPORT and the CENTRAL SCENE command class. All Z-Wave certified systems should support the MULTILEVEL REPORT feature.
Note that the only association group they are supporting is the lifeline group:
As far as zwave switches reporting status when physically changed at the wall, they definitely used to: that’s how the original double tap logic worked. It utilized the difference between “is physical“ and “is digital.“ lots of conversations from 2013 through 2015 on this.
That said, there were several platform changes made after the discovery that when “is physical“ was sent through some repeaters it got changed to “is digital“ which threw everything off. Plus lag introduced by the cloud messed up the double taps anyway. So maybe they started ignoring the event reports from the switches.
Yes and yes, but I think homeseer does both lifeline and central scene.
If it only did central scene, (which SmartThings does not use with built-in) then there would NOT be instant status as far as SmartThings hub is concerned.
For Ge zwave plus, sure association for double tap, but the command that is sent for double tap is interpreted by SmartThings is a full on to full brightness which is not what the actual switch does. The actual switch does NOT turn on with a double tap.
Sorry, to be clear, all zwave plus dimmer switches should be using the lifeline group to report dim level , no matter what other methods they also use.
I was talking about how they implement double tap, not event change.
Yes and yes but…
As far as I could tell from testing, when double tap was supported, it only worked reliably with on/off switches and NOT dimmers.
The reason I think goes back to active polling. When a switch is tapped, SmartThings can poll and get the status, on.
When a dimmer is tapped, there is a lag as it ramps up or down, which means the polling may get an intermediate value.
The hub has to poll a dimmer multiple times to get the final ramp/dimmer value. The switch only needs one poll.
I think we are saying the same thing for multi-tap.
Homeseer uses central scene
and the Ge zwave plus adds to the, I forget whether it was setlevel or basicSet, but it was the value of 255 in the dim command which SmartThings interprets as full on brightness instead of double tap.
This would require an update not just to the DTH but also to the platform since there is no such event as “double tap” currently. Or It could be reported as two events in the DTH and then the SmartApp would need to search and handle those events accordingly. Or if ST decides to introduce new capabilities like double tap or triple tap etc new SmartApps would be required to process those capabilities.
Sorry, but I’m confused about what you’re saying here.
There are zwave manufacturers who are currently offering switches that support double tap, triple tap, etc. And they do work with SmartThings now.
Basic Concept: Tap patterns are converted by custom DTHs to button pressed events
In all cases, the different tap codes are presented as different buttons being pressed, like a regular button controller, and that’s how You can use them with smartlighting or webcore or a smartapp. The DTH does the heavy lifting of changing the information received from the device into a button number and then telling smartthings that that particular button was “pressed.” Like a double tap on the top of the rocker might be presented as button three, and a double tap on the bottom of the rocker be presented as button four.
There are no lag issues because it’s the device itself that captures the initial Pattern before anything is sent to the hub.
There are two different ways that this is being done.
Method 1: Central Scene Commands
The homeseer switches do it with the central scene command. The device captures the tap pattern and then send a scene number to the hub. The DTH gets the scene number and converts that to a button controller Event like “button four pressed.”
Method 2: Association Groups
The GE switches do it with association groups. Again, the device captures the tap pattern, but then uses association groups to send out a basic message. The hub will receive it if it is in the correct association group and again, the DTH converts it to a button press event.
There are custom DTHs already in the forum for these devices if you want to see exactly how it works.
There’s no need for the platform to add anything to process the information from these two methods. Unless you want to do it without the custom DTHs.