Looking For Clarification Of Z-Wave Features

[upstatemike]

I have been critical of Z-Wave because of the popcorn effect and the lack of useful keypad options but in reviewing details of the protocol I am confused on why these things are so bad. The Z-Wave protocol includes Assigned Association which should let you link multiple switches or keypad buttons even if they are not in direct range of each other. Once linked I would expect they would all operate in unison the same way linked Insteon switches do. Z-Wave also has Groups. I would expect that all switches assigned to the same group should respond in unison without any popcorn effect because they are all responding to a single command instead of individual commands sent to each switch.

With these two features included in the protocol can anyone explain why Z-Wave switches can't be made to behave exactly the same as Insteon switches?

[lilyoyo1]

1 hour ago, upstatemike said:

I have been critical of Z-Wave because of the popcorn effect and the lack of useful keypad options but in reviewing details of the protocol I am confused on why these things are so bad. The Z-Wave protocol includes Assigned Association which should let you link multiple switches or keypad buttons even if they are not in direct range of each other. Once linked I would expect they would all operate in unison the same way linked Insteon switches do. Z-Wave also has Groups. I would expect that all switches assigned to the same group should respond in unison without any popcorn effect because they are all responding to a single command instead of individual commands sent to each switch.

With these two features included in the protocol can anyone explain why Z-Wave switches can't be made to behave exactly the same as Insteon switches?

The current system does not set the associations needed for those to work properly.

The new matter board is supposed to fix that. With that said, you are limited in that your controlling device must be scene capable and the responders must also support those associations if you want 2 way communication. 

In addition, you're limited to 5 devices max (some devices may support more) and in the case of direct associations all devices must be within line of sight. If they have to go through a repeater, then it will not work. In the case of a 3 way, you'll want to set up the association on both devices so both must support it (not that big of a deal with newer devices but could be an issue in mixed installations).  

Assigned association is a whole different mess. Once again, your controlling device must be capable of doing so since it must set its own repeating path. In order for 2 way communication, all devices must support the same association (and setup on all devices) in order for it to work both ways. 

Confused yet? Let me make it even worse. If you decide to use S2 security, both devices will need to be at the same level in order to work so make sure both devices support it.

Unless your device supports multiple groups, you'll be limited to on/off control in a mixed environment. Trying to mix your environment with relays and dimmers can cause issues should you try to dim some devices while turning others on/off. 

 

[upstatemike]

I'm not sure I understand the point of direct association. The chances of two devices that you want to associate being in direct range of each othe seems remote except in the smallest, obstacle free and interferance free environments. I would expect Assigned Association to be the standard. I can't think why any Z-Wave device would be designed to only support one group so this also should not be an issue. I understand the S2  security requirement but if the enrollment process was designed to only allow devices to be added at the same level as existing devices there should not be much chance to get into trouble there either.

It still looks like the protocol can do what is needed if implemented correctly. Maybe there needs to be more safeguards to prevent manufacturers from not implementing the full feature set and to restrict users from implementing settings in a way that could disable those features.

[lilyoyo1]

1 hour ago, upstatemike said:

I'm not sure I understand the point of direct association. The chances of two devices that you want to associate being in direct range of each othe seems remote except in the smallest, obstacle free and interferance free environments. I would expect Assigned Association to be the standard. I can't think why any Z-Wave device would be designed to only support one group so this also should not be an issue. I understand the S2  security requirement but if the enrollment process was designed to only allow devices to be added at the same level as existing devices there should not be much chance to get into trouble there either.

It still looks like the protocol can do what is needed if implemented correctly. Maybe there needs to be more safeguards to prevent manufacturers from not implementing the full feature set and to restrict users from implementing settings in a way that could disable those features.

There are many reasons for direct association. Multi way switches, sensor to devices (ie:motion to light switch). Reality is that most people control devices within a room vs across a home. At our level the chances increase for whole home control but at that point, the need/benefits of direct association is limited especially with it's inherent device limitations. 

Just like with DA, there are many reasons why a mfg would minimize the number of groups they support- the first being cost. The more they add the more coding required in addition to potential support calls. Another reason is that a controller makes things much easier to setup and  manage. Why take the time to add a feature that increases costs (or cuts into profits) with little benefit for most consumers

It's easy to say what zwave should do in regards to strict adherence to the protocol. Not only does everyone have to be willing to do so, doing so can impact integrating new devices with older systems. If they judging by people's attitudes on here when it comes to device limitations- i can imagine the uproar should they restrict users ability to implement the behaviors they want. The irony is that the people it would impact the most are the heavy users and not the avg person since it's the heavy users that want the most control over their devices and system. 

Modern devices mitigate a lot of issues with associations though it's still not perfect.  With that said, mfg. can't count on every home being full of late +series or higher devices. There are many still using 300 series or 500 series devices that zwave must take into account which adds to the confusion. 

[upstatemike]

1 hour ago, lilyoyo1 said:

There are many reasons for direct association. Multi way switches, sensor to devices (ie:motion to light switch). Reality is that most people control devices within a room vs across a home. At our level the chances increase for whole home control but at that point, the need/benefits of direct association is limited especially with it's inherent device limitations. 

All of these things could also be done with Assigned Associations. There is no real value in having 2 different types of associations in the first place. Just use the one type type that covers all scenarios.

[lilyoyo1]

1 minute ago, upstatemike said:

All of these things could also be done with Assigned Associations. There is no real value in having 2 different types of associations in the first place. Just use the one type type that covers all scenarios.

Not really. Assigned uses more bandwidth whereas direct does not. If every setup was done with assigned, you'd run into issues since zwave uses routed messages and assigned does too. This can impact the system when multiple things are happening at once. 

By using DA, you lessen impact since the devices talk directly to each other. You don't have to be concerned about messages not going through or slowdowns (unless a particular controller is a repeater for something going on in that moment). 

[upstatemike]

I am surprised to hear that Assigned Associations use routed messages. I would think that it would use a multicast to all of the associated devices to reduce traffic and assure a synchronized response. What is the logic of using routed messaging for associations?

[lilyoyo1]

47 minutes ago, upstatemike said:

I am surprised to hear that Assigned Associations use routed messages. I would think that it would use a multicast to all of the associated devices to reduce traffic and assure a synchronized response. What is the logic of using routed messaging for associations?

It doesn't use multicast. The logic behind it was to stick to how the protocol works. Having 2 different ways of communication would cause more issues than it solves, in addition to potentially shutting down the network due to the amount of communication going on. 

[upstatemike]

Don't Z-Wave Group commands use multicast? I thought it was included in the protocol someplace. I also thought Home Assistant made an announcement that they were going to start supporting Z-Wave multicast last year?

https://community.home-assistant.io/t/ok-zwave-js-has-multicast-now-how-do-i-use-it/321223

 

 

[lilyoyo1]

28 minutes ago, upstatemike said:

Don't Z-Wave Group commands use multicast? I thought it was included in the protocol someplace. I also thought Home Assistant made an announcement that they were going to start supporting Z-Wave multicast last year?

https://community.home-assistant.io/t/ok-zwave-js-has-multicast-now-how-do-i-use-it/321223

 

 

Multicast is not the same as associations. It was designed to be used with all on/off commands for the whole network. Its limited to devices that are within direct communication of the hub. Unless they're referring to something different, Multicast is also depracated due to the issues it caused with networks and its limited benefits.

If you scroll down to the bottom of the page you linked, you'll see some of the problems (such as all the lights turning on vs the target device.

 

[upstatemike]

So Z-Wave really is unfixable! Let's hope Thread/Matter is able to avoid these problems. Also wondering how Zigbee 3.0 will do by comparison.

[lilyoyo1]

Just now, upstatemike said:

So Z-Wave really is unfixable! Let's hope Thread/Matter is able to avoid these problems. Also wondering how Zigbee 3.0 will do by comparison.

It is unfixable for our needs. I say this because it was designed with a weak foundation in mind. While theyve added things to make it better, they're limited to what it can do overall due to its base code.