Anyone need a visualization?
A 'real' Motion Sensor sees motion and the corresponding 'real' driver (blue) will interpret the Z-protocol, resulting in an injected Event via sendEvent(). HubConnect App will detect the Event and send it over the LAN to the connected hub. The Event includes the device and therefore the corresponding 'stub' driver gets the Event. For the most part, there's nothing to alter in the event, and the Universal (stub) driver (orange) will simply inject a sendEvent() into that hub. The injected Event is seen by HubConnect App and reflected back over the LAN to the originating hub.
In the other direction, an automation may turn on a Light. The Event is seen by HubConnect App and reflected over the LAN to the Connected Hub. The Event includes the device and therefore the corresponding 'real' driver gets the Event. The 'real' light is turned on and that is another Event which is reflected over the LAN to the connected Hub. The mirrored device is turned On. Positive feedback.
In the Device Info page of a 'real' light device, clicking on or off is entirely local and the light works. HubConnect mirrors the event to the connected hub and the Device Info page will show the correct state.
If the 'highway' between the 'real' device and the virtual device on the connected hub is damaged, the Device Info page will not show the correct state. On the other hand, clicking on or off on the Device Info page of the virtual device May cause the light to go on/off yet not correctly show the state because the feedback portion of the highway is orphaned.
