Bridged Mios Engines

HOWTO Create and use a combination of 2 or more (bridged) Vera systems.

Introduction

You can have one MiOS systems import, or aggregate, the devices of one or more other MiOS systems, so that all the devices appear to be on one system. You can create scenes and events which include devices from different systems.

One of the most common uses for this is a home that is too large or spread-out for one Z-Wave network. For example, there may be a main house and a guest house with a big distance in between with no Z-Wave nodes to act as repeaters. So you can put a MiOS system in the guest house, and another MiOS system in the main house. They both have separate Z-Wave networks. But, assuming they are on the same home LAN, the main system can import the devices of the guest system, so that the whole home appears to be one big system. Z-Wave scene controllers in the guest house can run scenes in the main house, and scenes can span both systems.

To do this, choose Add Device and Add control over another UPnP device, such as another MiOS.
If the option for UPNP Scanning is not checked, you must check it first, then save your settings, and wait a few minutes before adding the other device.
Whichever system you are using to select the Add Device will be the 'master', and whichever system you add to it is the slave.

Technical specs

For those interested, the way it works is this:

1. Upon adding the device the master performs an "ImportDevice" which adds the slave system as a device.
2. Upon reload, the master system calls <data_request?id=master_registering> on all the slaves. It will keep retrying this until it gets an OK from the slave. It will call this every time the master reloads. The slave will store a list of all masters in the "foreign_master" tag in it's user_data. The master stores the list of all slaves as normal devices in it's user_data.
3. . Upon receiving the master_registering, the slave will then call a <data_request?id=slave_data_changed> on the master immediately, and again every time any data changes on the slave or the slave reloads.
4. Whenever the master receives the id=slave_data_changed call, it will do a id=status on the slave, and if the loadtime has changed, meaning the user_data is different, it will first do an <id=sud> (short user data) first.