VRC0P & Z-Wave Razberry-Pi GPIO Card

A while ago here made the VRC0P a secondary to the Z-Wave Razberry-Pi GPIO card.
 
The VRC0P is connected to the Leviton OmniPro 2 panel.
 
Currently I cannot see the Z-Wave node changes done by the VRC0P on the Razberry-Pi GPIO card and vice versa.
 
I can control all of the Z-Wave nodes fine with either the VRC0P (basement) and the Razberry-Pi GPIO card (attic).
 
I did notice while doing a Z-Wave node network scan with the Razberry-Pi GPIO card it picked up the VRC0P as a node with neighbors.
 
Does this mean that the primary Razberry-Pi GPIO card is using the secondary VRC0P as a transport medium for the neighbor Z-Wave nodes it sees?
 

pete_c said:

I did notice while doing a Z-Wave node network scan with the Razberry-Pi GPIO card it picked up the VRC0P as a node with neighbors.
 
Does this mean that the primary Razberry-Pi GPIO card is using the secondary VRC0P as a transport medium for the neighbor Z-Wave nodes it sees?
 

VRCOP.jpg

Click to expand...

I do not see why not.  Either  controller can act as a repeater node for a packet initiated by another controller, if need be, unless the sigma boys screwed up again.

Thanks VC1234.

The short answer is yes.
 
The way that Z-Wave routing works is that slaves/controllers finds neighbor nodes using a broadcast address when either an “inclusion” or “heal” procedure is executed. The controllers know how send a command either directly or indirectly to neighbor node. The slave nodes know how to send a packet to destination based on their routing table. If the packet is not ACK’d, the slave/controller sends packet to different neighbor.
 
The reason you are not being notified is that Razberry has not programmed any reverse associations.
 
The "heal" or update routes procedure helps build multiple alternatives to reach a destination - especially when environmental conditions change. In some cases, a packet may not reach destination because of RF interference or its as just the maximum distance. This is Levition recommends updating route using a lower DB.

So can I make the Razberry GPIO card a secondary to the Leviton VRC0P?

pete_c said:

So can I make the Razberry GPIO card a secondary to the Leviton VRC0P?

Click to expand...

I do not believe you can because vrc0p is a secondary controller itself.

d.dennerline said:

The slave nodes know how to send a packet to destination based on their routing table. If the packet is not ACK’d, the slave/controller sends packet to different neighbor.

Click to expand...

 In my experience, the controller is the only one that makes routing decisions.  I.e., the controller specifies the exact new route inside the frame if the previous route failed and the routing slaves merely obey and do not try to choose a different route.  What is worse, if the communication is initiated by a slave node, e.g. a thermostat, it never tries to choose a new route but just silently fails after 5 attempts (usually).  Only after a new route has been chosen by the controller, the slave will send unsolicited messages using that new route.
 
Now, the sygma geniuses might have modified this behavior in GEN5, I do not know. What I described takes place in my network that has only pre-gen5 old devices.

I do not believe you can because vrc0p is a secondary controller itself.
 
Understood.
 
I originally made it a secondary controller to the RPi2 GPIO Z-Wave me device to replicate all of the devices there.
 
I was able to also to replicate the Z-Wave network to the remote Leviton Z-Wave device from the ZWave GPIO device goofing around some.