Physical Events Not Logging Consistently

I'm seeing a lot of confusion about both some of the zwave standards and the Lutron patent in this thread. And I know smartthings never explained any of it, so just to add a little clarity:

  1. The Lutron instant status patents never applied to binary on/off switches. Only to dimmer switches which are physically manipulated. But it did apply to every RF protocol: zigbee,, zwave, Lutron, etc.

Zwave implemented this with the Hail commandset. If the Z wave device doesn't support hail, it isn't using the Lutron patent.

  1. There are two separate ways that zwave manufacturers got around the patent up until mid 2017: direct association and central scene. Direct association bypasses the hub and therefore in most systems the hub will get out of sync as far as what the status is for the devices. Central scene does report to the hub so status should be more reliable in the devices that are using that.

  2. Z wave direct association changed significantly with Z wave plus. Very significantly. See the following:

Note also that the hail command class was deprecated for the newest Z wave plus devices, and they should be using lifeline association instead. But because zwave is required to be backwards compatible, hubs should continue to support hail so the older devices will continue to work.

See Section 4.17 in the Management Commands documentation.

http://zwavepublic.com/sites/default/files/command_class_specs_2017A/SDS13782-5%20Z-Wave%20Management%20Command%20Class%20Specification.pdf

  1. when a message goes through a repeater, the fact that the initial action was "physical" rather than "digital" is often lost, but it depends on the exact model that does the repeating. This tends to mess up a lot of rules engines that are trying to trigger off of physical. It also means that you can get inconsistent results depending on exactly which repeater any one message goes through.

SmartThings recognized eventually that this was causing a lot of their customer support questions so they changed their stock device type handlers about six months ago simply to remove reporting anything as physical. (Without announcing the change). This at least produced consistency because it no longer mattered which repeater a message had routed through, but it did cause quite a bit of code to break.

  1. as those of you who know me from the SmartThings forum know, I hate polling, so I'm not even going to discuss the multiple issues involved in that. (Which also apply to refresh)

  2. if we think of devices as falling into good/better/best, the GE switches are in the good category.

If you want an efficient zwave network with full Synch, choose Devices that use central scene commands.

If you want to use the older (now discontinued) GE models, you'll either have to do a lot of polling or a lot of planning to get everything working through the right repeaters.

If you have changed your network configuration, which is what happens when you only move over a few devices at a time, you can expect that you may have different results if you are relying on physical reporting from older GE switches.

  1. while the homeseer switches which offer double tap (which fall into the "better" category) use central scenes, the newer GE devices do not. They rely on the new Z wave plus association capabilities. That means if you want to sync them with the hub, you have to include the hub in the correct Association group and even if you do that if it's more than 1 hop away you may lose some information.

GE Switch association matrix (model 14294)

https://products.z-wavealliance.org/products/2105/assoc?noFilename=True

Not sure if any of that is of any help, but I thought I would mention it. :sunglasses:

@patrick @mike.maxwell

6 Likes