Let’s not go that far!
This would most likely break other things or make other things more difficult…yes/no?
But devices will never send status to another device - not unless that other device has interrogated said device, and configured its association groups so that it sends out the status. It’s not impossible that the device does this, but it’s unlikely I think as discovering association groups in non ZWave plus devices and configuring them is more problematic.
Or maybe it’s just using the promiscuous mode where it is listening to all traffic - this is not meant for devices though so I would be even more surprised if it uses this as it would hear all traffic in what is basically a debug mode of the controller.
Controlled devices do not send such broadcasts so again I’m not really sure what it’s looking for.
It would send a status update (say, a BASIC_REPORT) to the controller - but ONLY if an association is set. Otherwise it doesn’t know if there is a controller, let alone what node number it is.
No - I’ve never seen any device send a status broadcast. It’s not to say no devices do it, but it’s certainly not a standard ZWave feature. Note that broadcasts are not routed, so any broadcasts sent are not guaranteed to be received by the controller.
Yes.
I don’t know - obviously the manufacturer can program whatever they want into the firmware, and if they have designed it to primarily work with their other devices then they could come up with different ways of doing things - that doesn’t make it standard though.
okay, but when I look at all the 68 devices within my entire ZWave network…the vast majority of devices do not have any associations.
Node 22 to 31 are these Leviton devices…node 61 is 1 of 5 drapery motors that you helped me get into the database last week, and node 67 is a battery powered door lock. None of the other 60+ nodes require any association in order for the primary controller to know their status.
Are you saying that the primary controller learns of their status only by polling? If so, then that may be true, but the later versions of zwave hardware has tried to get away from polling because it bombards the network with excessive data packets. The later approach was to have the node individually report their status as a broadcast when their status changed, reducing the network traffic required for polling.
Polling was the demise of all early zwave networks that contained 50 or more devices…then battery powerded device came and batteries would only last a couple months.
Well, it stops the binding setting these things automatically, so yes, it makes it more difficult.
There is another method that was used on older systems, and that is the HAIL command class. The device can send a HAIL command to a controller that tells the controller to request its status.
Yes. For example, battery devices will never send out their battery status to “random” addresses.
Of course - this uses association, and specifically the lifeline association group. You are asking about old devices unless I misunderstand the question (sorry).
This would flood the network. I’ve personally never seen this in many years of programming with ZWave.
I don’t disagree - polling is bad. But there is either polling, associations, or hailing. Maybe you are right, and some devices send broadcasts with their status - I’ve just personally never seen this myself, and never seen it in any log that someone has sent in the last 8 years of writing the openHAB binding, so if it happens, it’s not very common and it’s not in the ZWave docs as a standard requirement as far as I have seen.
If you have a log that shows that this is happening, then I’d really (really!) like to see this.
Polling of 50+ nodes would create 10 times the network traffic compared to 50+ nodes that update their status when and only when their status changes…
unless of course you are talking about me and my wife…she leaves the lights on and I get up 2 milliseconds later and turn them off…over and over again!
Would this actually be in the log of the binding? I think that this activity would be at a lower level of the hardware architecture. Much like Ethernet networks…there are several layers of architecture in place…much of the first layer of the network protocol is invisible to anything other than the hardware itself. For the Aoen Z-Stick or any other primary controller, this would be part of the hardware/firmware responsibility to deal with. A layer or two down from your bindings responsibility.
I’d be happy to look/send any logs, but I agree with you, there’s probably nothing in it that indicates any device to controller communication, outside of actual on/off activity, or polling, or the HAIL you referred to which I am aware of.
I’m not sure how you come to this number - the ratio will depend on the polling rate and the rate of change in the system. In any case - it’s irrelevant - I do not disagree that polling is bad and I’ve said that repeatedly above.
My point is that this is not done. There are 3 mechanisms for updating - polling, hailing, and associations. Hailing is not used much these days, and ZWave plus introduces and mandates the use of the lifeline concept.
Yes - of course. If it’s not, then how would you ever expect a device to respond?
No - in ANY network system, these messages must be passed up the layers, otherwise applications cannot respond!
Absolutely not. The stick is only handling the lower layer - it knows nothing about the state of the application.
If you have logs that show these requests, and they must be there, then please provide them.
So, maybe we are saying the thing again…you are saying that new (not limited to ZWave+ devices) would use the lifeline (group 1) to update their status and that actually eliminates the need for polling?
I could agree with that…certainly you’d know best.
If that is all true, then we are really now able to focus on the zwave database setup of these particular devices I am working with.
It gives me motivation to try and edit my local database with the instructions that were sent to me to validate whether I can have my cake and eat it too.
I have my devices working perfectly on my integrated Zwave network, but without openHAB knowing about them (outside of me doing my backwards approach of learning which scene is running based on specific node status as mentioned in an earlier post).
If I can remove the node 1 association from the groups, then possibly openHAB will still be able to know of the active Scene. But again the problem will become that openHAB will probably only know of the “latest” active scene, it will not know that scene 1, 2, and 4 are active…it will only know that the latest scene is active.
I will keep playing and report my success or failure!
Yes - absolutely. I have stated this in many places - I can’t say often enough that polling, in general, is bad! There are some exceptions, but it should not be used for general updates - associations are absolutely the way the system should be used.
Okay so, what about my very typical network that has the majority of devices, mostly new within the last few years, probably a 50% blend of Zwave and Zwave+ devices that have almost zero associations?
Are these associations a given and therefore ignored from the reporting software and this association is invisible to your binding or any other software that can view the devices/controller setup? I repeat, almost all of my devices do not indicate any association to node 1 except for ones that I manually assigned, or ones that were mandated by the zwave binding database…yet openHAB knows of the status of every node. How did it know the status if there’s no association to node 1?
Are you saying that these devices report their status via HAIL or they are polled? I would disagree with those options.
What is your question exactly? All new devices that are ZWave+ certified are required to have the lifeline association group or they will not be certified.
I don’t know what you mean? What is the reporting software you talk of?
No - they are of course visible.
I don’t know anything about your network - really - how can I answer these questions. I’ve repeatedly asked for log files as this is the only way that I can see what is happening. Otherwise you can tell me anything, and ask me any question, but I can only guess the answer. Sorry, but without more information I can just keep repeating the same thing which is the standard way that things are supposed to work, and how I’ve seen them working over the past 8 years of supporting this binding. Your system may of course be completely different to others, but without the logs, I’m unable to say!
No - I’m saying I don’t know since you haven’t provided the logfile.
What are you disagreeing with? Please provide the logs to support whatever you are disagreeing with and I will comment. Otherwise, I’m just providing information on how things normally work and not how they may work on YOUR system!!!
An interesting read:
Why? It doesn’t say anything new.
Please provide the logs for your system.
It essentially says that once the patent expired in 2016 that more devices other that Lutron were capable of offering zwave devices that included instant status reports without the need for polling…now maybe this is the introduction to ZWave+, but I don’t think so. Leviton and Cooper introduced this into their devices in 2016.
I’m not sure really what you’re getting at? This is quite well known issue about the patent, but isn’t really much of an issue since most suppliers were using associations to provide instant status well before this. I have many devices in my house dating back to 2010 and the ALL have association support.
ZWave Plust added the concept of the lifeline association group as a standard way to report status to the controller, and this is always group 1, and it is mandatory. Before that, manufacturers were free to do what they like.
Again though, I feel I’m repeating myself 
I fully agree again, associations have been around forever…instant status has been around for a long time…
Going back to my scenario, and the majority of the people who I’ve seen on the forum who have these devices…and have been unable to get them to work…these VRCS4 devices we have do not require a forced node 1 association to each button because they are going to perform their “Instant Status” update to the primary controller. Forcing the association in each group for each button, breaks the device itself.
I don’t want to alienate you or argue about semantics…I’d like to move on and keep experimenting.
I appreciate your expertise and really don’t want you to think I am questioning it.
I’m just a guy who’s enjoying the process and am hoping to help others with their setup as well.
Part of my learning is to question logic and think outside the box so I apologize if I have rubbed you the wrong way.
Cheers,
Terry
Maybe not - I think we agree here. I have repeatedly asked for a log - I’ll ask once more - please provide the log showing what is happening - ie what the device is requesting. There MUST be something requested since devices do not report status otherwise.
The only exception to this is that they are NOT reporting status, and the VRCS4 is assuming that the status changed when it sent the command. This is actually how ZWave is meant to work (as stated by ZWA!) and devices are not meant to send a status update when they are commanded remotely.
Please provide the log.
Okay, I have 6 of these devices.
I will configure 2 of them identically…except one of them, I will manually remove all associations to node 1 using the “other software”.
Then I will try and press the exact buttons on device 1 and device 2 equally so we can see if there is any difference.
Not today though…maybe tomorrow!
1 Like
Contrary to that…in my long winded post…Scene controller monitors everything in its association groups
Lets say for example:
Button 1 of the Scene controller was programmed such that node 5 was to be at 40% dimming and node 6 was to be at 80% dimming and node 7 was to be ON.
If I were to go no where near the scene controller, but use openHAB, or walk up to the physical switches themselves and set the dimming or ON/OFF states exactly equal to what I listed above, then immediately, the Scene Controller lights its indicator light. This would happen regardless of the primary controller node.
These devices were originally intended to be programmed using a programming device owned by an electrician. The programming device is essentially the primary controller. When the electrician is done, he takes his programming device home, so there is no longer a primary controller on the network.
What are these other devices that are reporting their state? Are they made by the same company as the VRCS4? (who is that by the way?)
Maybe these are not using standard ZWave features. Some manufacturers will add their own extensions. I’m pretty sure that if you added a Fibaro device for example that it would not work unless the VRCS4 set an association.
Also, does this work if the VRCS4 is not in direct range of the device in the mesh?