I note that the manual states that this controller requires that devices be associated to this controller - I guess that answers the question - it requires associations!
VRCS is the Scene controller by Leviton
It’s capable of working with any device…Leviton, Fibaro, Fortrezz, GE, Cooper…anything.
I have had 6 of them for a few years now…each have 4 buttons, plus a dim+, dim-
Most of my buttons control multiple devices, some of them control single devices.
One button in particular controls a Fortrezz Mimolite relay device for example that opens my gate 300 ft from the house. (Device inside house and a low voltage cable runs 300 feet to the gate)
https://www.fortrezz.com/io-modules
Another one control a Remotec dry contact module that operates a fireplace…
Several others control lights…multiple lights using multiple different makes and models of switches. For example, one button controls a Leviton DZ1KD dimmer switch , plus a VRE06 Scene capable dimmer, a GE ZW4005 Wall switch, plus a GE/Jasco 45605 wall plug. All on the same button within the same scene. So multiple manufactures and unlikely they are using the same “custom” non standard protocol.
Within direct range…that is a good question…currently in my test scenario, since I’ve moved to openHAB and not had the ability to get these devices functioning in OpenHAB there is a device that is probably not within range and it cannot operate it…but I should have the ability to manually specify the route. I haven’t manually set a route for it to attempt to reach this node yet. I was just very happy to actually get things working after removing the controller node and haven’t had a chance to try this yet. Clearly this is one of the features/benefits of the primary controller…it can store the routes for all nodes and always be able to find a way to the end device. But without the primary controller, things become more difficult. All nodes in between are repeating so you would think it would reach the end device but so far, it hasn’t…
To my earlier point about an electrician walking in with a programming moduel and then leaving with it…manually assigning routes should resolve the “not direct” issue…I hope.
That is the difference between Direct and Assigned Associations:
More work for tomorrow!
I’m assuming that this “programming module” is just setting the associations in the devices so that they send to the controller. This is also mentioned in the documentation I posted earlier.
Assigned and Direct are ultimately the same thing - it’s simply the way that they are programmed that is different here - not the mechanism for how they send reports which is what really matters.
correct, that’s a given…if and only if you want the LED indicators to light properly.
Without associating it to the actual devices but associating it to node 1, then you can get the latest scene update, you give up all of the scene controllers ability to control multiple scenes and you are limited to a single Scene managed by openHAB only.
Associating to the actual devices allows you to control and manage all 4 scenes independently, but once you force an association to node 1, then it breaks the scenes controllers ability to control anything.
It’s either one way or the other…I prefer to have both and think I can get there without the forced associations to node 1
I don’t know what this refers to?
That is clearly a device specific “feature” of this device.
It’s a given that associations are required if it is to control end devices on it’s own…that’s the only way it can do so.
A device specific feature of this device? Meaning you think it requires an association to node 1, or that it is using non-standard logic and that node 1 is breaking it?
You are now getting mixed up I think 
That is not what I am saying. The documentation states that the DEVICE needs to have an association set so that it can report to the CONTROLLER. I think you previously stated that the status reporting was not using associations in the device?
In the manual, when they refer to device, they are referring to the physical Zwave device that the scene controller is to control. When they refer to Controller, they are referring to the VRCS scene controller. It’s not referring to a Primary controller, because for that platform, there typically isn’t one remaining once the electrician leaves the jobsite.
Setting the associations is always done on the controller level (VRCS) because devices are dumb…they typically cant store this data on what it is associated to from what I know.
Exactly!!!
Earlier you stated that the DEVICE does not have an association set in order that it sends its state back to the CONTROLLER. The documentation seems to state that this is incorrect and that there “Must be” an association from the DEVICE to the CONTROLLER.
No, there is an association of the device on the controller…
The device does not know it is associated to anything
That is different to what is stated in the documentation, but you may be right of course.
You could have 500 controllers and each of them could have an association to the same exact single device and it wouldn’t know the difference. How could it possibly store those associations?
Of course I am exaggerating! lol.
I guess you could only have 231 controllers max! lol
232 less the one device!
No - a ZWave network does not support this many devices! Also, most devices only support 5 nodes in an association group (some less, some more, but often it is 5).
This sets a limit on all of this.
Anyway, I’m only going by what is in the documentation. To me it seems clear that the device requires an association to receive the status reports. Maybe you are right, and the documentation is wrong, but I’m just going on what I read and that is much more plausible than magic.
devices don’t have association groups…only controllers.
devices are associated and happen to belong to groups…they just don’t know it.
Sorry - but devices DEFINATELY have association groups! Most primary controllers don’t. Your controller does.
No - this is a total misunderstanding. If a device is being commanded by another device, then yes, this is right, but devices WILL have association groups so that they can send their status to other devices or controllers.
I keep stating this, but the lifeline association group is mandatory in ZWave+ devices - ALL devices.
I think we are saying the same thing…and it’s not relevant to the topic anymore…
What I am saying is that, of course things have associations…but the communication of the status from the end device doesn’t change regardless if things are associated or not…the only thing that changed was that the lifeline was mandated to be within Association Group 1 but most importantly … reported to node 1. This as a result made it a reasonable expectation to reserve Association Group 1 for devices to communicate for lifeline purposes so that controllers can more easily set their devices up with consistancy.
On more modern Zwave+ controllers, you will note that Association Group 1 is tied to lifeline stuff, and Association Group 2 may be used for Scene 1, Association Group 3 is used for Scene 2, etc etc. It just reserved Group 1 on controlling devices only so that it could identify a specific category of communication. Whereas mine has Group 1 to 4 assigned to buttons 1 to 4.
Zwave traffic is not like ethernet traffic through a switch where a specific data packet is routed to a specific port because the lower level hardware architecture of the switch knows that specific port has a device with a specific MAC address connected to it. In that scenario, Port 5 has no idea what is getting talked about between port 1 and 3. ZWave is always open air, wireless…there’s no “talking” directly to a node…it’s always “yelling” out loud. It’s up to each node to “listen” and determine whether this information is intended for them. Repeating nodes repeat the “yell”. Non-repeating nodes discard the yell if it’s not for them. Controllers, both the primary or secondary controller determine specifically what to do with the traffic. Primary controllers listen and repeat all traffic (if it wasn’t for them) and update whatever they need to…secondary controllers like what I have listen and repeat everything, but take note of whether the packet is coming from a node that is within it’s associated devices, and if so, records this status update for it’s own controlling purposes. If something was to send a packet to node 1, this packet is heard by any listening device on the network…it’s up to that device what it should do with that packet. So even if something were sending lifeline based communications, any controller will capture that and deal with the packet accordingly, associated or not.
It’s because of that fact that I make the statement that dumb devices don’t need to know whether they are associated to anything…they are just sending their messages and receiving messages which may contain commands for them.
If a device were to be relying on a lifeline type of communication packet, it would send a message to the general network, possibly with an intended recipient of node 1, because that is lifeline activity…if it were regular activity, like regular status updates…certainly it could still send it’s update to node 1 or whatever nodes are associated to Association Group 1…but all nodes still hear this and possibly have to repeat it in order for it to reach node 1…so there’s no talking directly.
I don’t think we are saying the same thing - sorry.
It is 100% relevant. The big question here is how a device sends its status reports - you state that it is just sent (magic 
) - my point is that it is configured through associations and this is also stated in the documentation for your device.
A device will only send its status to devices that are in its association groups.
We’re changing the topic now - but you are wrong. Broadcast messages are not repeated, and routed messages are sent unicast. You cannot assume that devices will receive data sent randomly on the network - it is not the way it works even in a wireless system!
I don’t plan to discuss this here as it is totally off topic!
No - this cannot be assumed for a load of reasons. For starters, there is security that may be employed.
Sorry, but I think you are misunderstanding a few points, but really I’ve tried to help, and it seems I’m unable to. My apologies.