I have not seen any good documentation on bridging systems … I thought I would start a thread where people that have successfully done so can document their successful practices as well as the things that caused them problems.
There is no documentation, that I have seen that tells a plugin developer what they have to do to be a good citizen in this environment. Any Ideas there would be great as well.
My main message would be as described here:
Here is a start:
New: http://wiki.micasaverde.com/index.php/Bridged_Mios_Engines
Old: http://docs2.mios.com/doc.php?page=multiple_mios
The bridging can be one way (all devices show up on one central Vera or two way (all devices show up on both Vera’s). Two way is just 2 x one way trusts.
Master Vera (has devices of master and slave):
** Z-Wave Lock 1
** Plugin Device 1
** Z-Wave Device 2 (bridged Vera)
** Plugin Device 2 (bridged Vera)
Slave Vera (bridged to master):
** Z-Wave Device 2
** Plugin Device 2
Overall, commands “pushed” from Master to Slave are fast and trigger immediately. Status updates “pulled” from Slave to Master (i.e. a Z-Wave Switch on Slave Vera will take 3-6 seconds to change from on/off on the Master unit it’s bridged too). This means there is a delay of 6 seconds can react to a manual command. My home is fully automated so manual control is rare (you need to press a button for bedtime, or to disable the 15 minute no motion timer in the living or bed rooms.
Personally, I use limited plugins on the Slave Vera’s as they always need to be duplicated (apps will auto-download if in the app store if dont’ exist on the master already). PLEG (for items which can’t wait for status update delay to master), InfoViewer, virtual switch for debugging. Both these Slave plugins bridge over to the Master Vera.
Note - Don’t edit mirrored devices. You must go to the Vera the device is native too and edit the device settings there (not the master).
I think you asking for more bridging development best practices I’m afraid. I wish there was more information I could share.
So far i’ve had reasonably good success with bridged Veras. I have a Vera 3 as Primary and a Vera Lite as Secondary.
Right now there are NO Zwave devices installed on the Secondary, only a limited set of APPs. ALL ZWave devices are on the Primary along with some APPs
I will second @AgileHumor’s comment about editing/changing ONLY ON THE VERA WHERE THE DEVICE/APP is installed.
Some specific APPs and my current experience:
EventWatcher **
Works fine on both systems. There does not appear to be any interaction other than replicating the Secondary APP appearance on the Primary. Events and Reports reflect the respective systems. A report run using the Secondary image on the Primary will report on the Primary so you must use the correct system.
Vera Alerts
Works on both systems with a few caveats. The Secondary Vera will send alerts as intended to the Users defined ONLY on the Secondary. With the exception of the principal administrative user, Bridging does NOT transfer/replicate users from the Primary ) >:( ) so you must re-create them or create new ones. (and MCV Tech Support claims they can’t help.)
Everything must be done ONLY on the Vera where the APP is installed. The “appearance” of the Secondary APP on the Primary will show the Profiles and Settings of the Secondary but the “Notification Configuration” will reflect that of the Primary NOT the Secondary.
There does not appear to be a way to manage Secondary alerts from the Primary anyway so if you need SysLog or something for Secondary events (other than those reported by EventViewer) you will have to install Alerts on the Secondary.
MySensors
This works fine on the Secondary and immediately posts results to the Primary. You can in fact run the Inclusion from the Primary but in keeping with the general rule I suggest you only do it from the Vera on which it is physically installed
Day/Night
My results with this were questionable. I moved it to the Secondary and reassigned some Triggers/Properties in a Primary PLEG to use the relocated PlugIn (actually what you use is the “Secondary Image” on the Primary.) I had problems with the PLEG not executing for several days until I relocated the PlugIn back to the Primary so for now I think that Day/Night needs to be installed on the Vera where it is going to be used.
GCal Sensor (NOT the new version, not tested)
This appears to work fine installed on the Secondary and accessed on the Primary. Calendar events detected on the Secondary appear to trigger actions on the Primary without a problem
iPhone Locator
This appears to work fine installed on the Secondary and accessed on the Primary. I have this set up to be used by a Primary PLEG and right now simply update a Primary Virtual Switch with the Present/Away status. (The other three family members have Android devices and are managed by Vera Proximity.)
PingSensor
This appears to work fine installed on the Secondary. The state is reflected on the Primary and you can Arm/Disarm the Secondary from the Primary if you wish. Right now I have several installed monitoring local systems (Blue Iris, SysLog, NetStore, etc) Up/Down reports to SysLog and my phone are handled by the Vera Alert on the Secondary.
[Update **]
I inadvertently wrote EventViewer when I intended EventWatcher.
@Clipper, can you confirm that ping sensor does not mirror over to the other Vera? I’ve run into a few plugins that didn’t mirror…but couldn’t remember which ones.
The Ping Sensor most definitely mirrors over from the Secondary to the Primary but not other way.
There is, of course, nothing to stop you bridging multiple Veras in both directions, resulting in a symmetrical (if confusing) device configuration. Of course, scenes are not so replicated, and remain local to each machine, even though they may act on bridged devices.
There is, of course, nothing to stop you bridging multiple Veras in both directions, resulting in a symmetrical (if confusing) device configuration. Of course, scenes are not so replicated, and remain local to each machine, even though they may act on bridged devices.[/quote]
Its confusing enough with unidirectional bridging, I can imagine what it would be like with 3+ Veras with bidirectional bridging running — “rubber room” time 
How does a user distinguish a local vs bridged device ?
A local device is controlled by Zwave, whereas a remote one has the appropriate MiOS virtual device as parent.
Thanks for starting this thread! Very useful! As I plan to go down this road as well…
@clippermiami interesting setup, have you seen significant memory savings when just moving a limited set of Apps to the secondary (and no Z-Wave devices)? Overall is it worthwhile?
I’m asking because I prefer to do a similar setup, I definitely don’t want to go thru the hassle of excluding many Z-Wave devices, adding them to a secondary Vera, and fixing all the affected automation scenes. I probably have around 50+ Z-Wave devices…
I can’t say that I’ve noticed a measurable improvement. I’m still trying to sort things out and the memory usage is higher than i’d like but better than it was when I first made the move.
Last night I had a glitch that will slow me down. Just after midnight, when no one could have been fiddling with the Primary Vera it went into a RESTART loop, about every 30 seconds it would RESTART, thus getting nothing else done. The SysLog was just one RESTART after another, no other activity. I could barely get in to the system so i ended up doing a restore from a backup of 18 May. After that it settled down and has been fine since. It took a while to “put it back together” and recreate/recover the changes I made since that backup. (I know I had a backup of 20 May but it was nowhere to be found … odd behavior. BTW, the Secondary continued running fine.
The current state of things is transitional, my intent was to move most of the apps to the secondary over time.
I don’t currently have any plans to move ZWave devices to the Secondary but who knows how that will shake out. I have most of the active ZWave devices installed, only one or two light switches remain. Right now most of my home automation expansion plans are centered on Arduino Sensors and that APP is already installed on the Secondary. I MIGHT reinstall the DVR to interface my Blue Iris system but I’m having a hard time seeing what that actually accomplishes.
I wouldn’t expect a lot of memory savings as all the apps on the slave vera…as all the devices need to replicate (in part) to the master vera.
That is why i suggest the master vera hold all the apps/logic, and minimal or no Z-Wave devices.
Just my preference.
[quote=“AgileHumor, post:13, topic:181231”]I wouldn’t expect a lot of memory savings as all the apps on the slave vera…as all the devices need to replicate (in part) to the master vera.
That is why i suggest the master vera hold all the apps/logic, and minimal or no Z-Wave devices.
Just my preference.[/quote]
I can see the logic. It’s just the way I started. I could obviously go back, break the bridge and recreate it with the Vera Lite as the master. I may still do that.
In my setup, the slave is also an alarm system for my window/door sensors…along with the siren. It’s in a much more secure location than the master unit.
This means that if the master goes down (which handles a lot of my TTS notifications and alerts on my Media Center) and the alarm/siren will still function on the slave (using Simple Alarm plugin). A user PIN entered on the Z-Wave locks will disarm the alarm.
Total plugins on Slave are:
[quote=“AgileHumor, post:15, topic:181231”]In my setup, the slave is also an alarm system for my window/door sensors…along with the siren. It’s in a much more secure location than the master unit.
This means that if the master goes down (which handles a lot of my TTS notifications and alerts on my Media Center) and the alarm/siren will still function on the slave (using Simple Alarm plugin). A user PIN entered on the Z-Wave locks will disarm the alarm.
Total plugins on Slave are:
Interesting approach. One thing I have planned to do but not accomplished yet is to run the DSC Alarm interface on the secondary rather than the primary.
I’ve just noticed a problem with using AutoVera in the bridged environment.
I had been using AutoVera on the Primary and was fooling around with status update to my Android phone. It recognizes that there are two Veras and can in fact talk to both of them and update the respective device list for each. However any attempt to toggle status notification from the Secondary Vera results in an error message that it is unable to locate the AutoVera PlugIn on the Secondary Vera.
Surmising that this made sense I installed the Plug in on the Secondary and this of course resulted in an image popping up on the Primary. To avoid confusion I named the image “AutoVera - Vera2”. and placed it in a “Room” I created on the Primary to hold Secondary Images, i.e. devices that one should not actually manipulate on the Primary.
I then refeshed the AutoVera device listings for both Veras on my Android. For the Primary Vera it shows TWO AutoVeras, “AutoVera” and “AutoVera - Vera2” which makes sense. However when it updates for the Secondary Vera it shows ONLY “AutoVera - Vera2” the name assigned on the Primary; on the Secondary the name is simply “AutoVera” and this does NOT appear after the refresh. And attempts to toggle status updates for devices on the Secondary still result in “Unable to locate the AutoVera Plug In on your Vera. Install and refresh your device.” At which point it attempts to refresh the device list and never completes — requires a manual STOP of the application to clear.
Needless to say this is confusing. I’m trying ot manipulate only the Secondary because the Ping Sensors are installed on the Secondary. While they appear as images on the Primary any use of them results in a rapid “DOWN/UP” status report for ALL the Ping Sensors any time there is a change in contact between the two Veras. This makes sense as the Secondary immediately updates the Primary when they are back in contact but makes for a lot of false notifications.
So bottom line is there appears to be a problem with operating AutoVera in a bridged environment and especially so if it exists on more than one Vera.
Frustrating
This morning I awoke to find yet another change in my bridged Vera environment. Yesterday the UI for the Primary Vera reflected the UI for the Secondary i.e. all of the icons that were on the Secondary were replicated on the Primary. This morning half of them are replaced by the generic image, the little blue “gear-like” thing and none of the controls ont he block are present.
For example, the Secondary has a iPhone Locator App which was mirrored on the Primary (it had originally been installed on the Primary so all the code for it was still present.) This morning it is still on the Secondary as it should be but the replica on the Primary consists only of the blue gear, no other information. Similarly the GCal Sensor, Vera Alerts and MySensors (Arduino) Plug in and Node information are missing from the Primary. I reloaded the MySensor files as i have those separately and it made no difference, the Plug In and node do no reappear.
Both Veras have been reloaded several times to no avail.
It may be that in reality its a good thing that the Primary Replicas are replaced by simple placeholders but it is frustrating when SOMETHING has happened and there is NO APPARENT REASON for it to have happened. With the exception of the automatic update of Vera Alerts to version 5.7 over night, none of the items in question have been updated or changed in any way.
And it hard to see why the auto update of one app would have impacted several completely different apps. And why the update of Vera Alerts to the same version on both systems would result in the Primary Replica being missing when clearly all the code for the updated app is present on both systems.
And why reloading the code for the UNCHANGED MySensors items failed to reinstate the replica when re-uploading the same code last week DID reinstate the replica data
This bridged environment is difficult to keep track of.
The icon issues are normally a browser thing. Try deleting your browser cache.
Well, thanks, that got it. Odd since I had the impression that the Vera UI was more of an interactive device with the Vera and loaded essentially from scratch each time — hence the Vera Two Step every time you change something. But its never a bad day if you learn something … even if it is stupidly simple
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules