I am using two Vera 3 units in Bridged mode and I’m trying to figure out just what the real benefits are.
When running in Bridged mode, the Primary Vera creates a “mirror” of the function or device of the Secondary. Apparently the Secondary Vera directly manages the device or application but sends data to the Primary to update the status on the Primary.
So if the Primary has a copy of the application display functions and receives the data from the Secondary what real benefit is there to doing this as opposed to keeping everything on the Primary? There is clearly some CPU loading on the Primary for supporting communications with the secondary PLUS the load of replicating the Secondary’s data on the Primary.
I raise this for discussion because I have about 50 physical Z-Wave devices on my Primary, 9 PLEGs, my DSC interface, and some number of Virtual Switches etc. On the Secondary I currently have NO Z-Wave devices and a few applications such as the Blue Iris Interface, iPhone Locator, etc. My Primary Vera never drops below 40% CPU and is usually above 70%, often above 100%. My sensor driven functions have become very sluggish often taking 10-20 seconds for a light to go on driven by a motion sensor.
[ul][li]“Extending” Z-Wave coverage with a second(or more) Z-Wave network.[/li]
[li]Support more Z-Wave devices by splitting them into multiple networks.[/li]
[li]Reduce overhead on a Vera by distributing the load. One manages devices and possibly apps, another acts as a central controller and handles remote access. The amount of overhead is going to depend on what types of apps and how they are arranged.[/li][/ul]
Your 10-20 delay doesn’t sound like a CPU utilization issue. It sounds more like a routing issue.
My original plan was to move most if not all the applications to what is currently the Secondary leaving only ZWave devices on the current Primary. But having seen how it handles apps by replicating them on the current Primary anyway I’m not sure that it actually would accomplish anything.
Right now I’m at about 50 devices and the system is breathing hard as it is (the upside is that there are not a lot of additional ZWave functions that I can add so I may not apply much additional stress at this point.)
The CPU usage is of concern because it spends a great deal of time over 100+ percent which of course means something (what things I don’t yet know) are being delayed. As to the delay in ZWave device response I have run manual heals on the network a half dozen times and there is no improvement. From a signal strength standpoint a manual “device-by device” heal achieves 4-5 stars on every device whereas a manual “all device” heal results in over half of the devices in the 2 star range. And since it runs an internal heal every morning by itself it could easily be undoing any good the manual heals are accomplishing — if any.
As I said my original plan was to separate most of the applications from the ZWave devices. But that raises latency and other questions. For example should the PLEGs be with the ZWave devices or the applications? Whats the impact in time of separating them across Veras. What about the DSC interface? If there is a relationship between PLEGs and the DSC should they be together or is the latency low enough that it doesn’t matter? Adding anything on the Secondary replicates itself on the Primary so where is the gain, the “device” exists in both places anyway? for example, right now I have the Blue Iris interface on the Secondary but the cameras appear in both Veras so what benefits is there? At one point i tried putting the DSC interface on the Secondary which of course resulted in it replicating itself and all the zones in the Primary … the only difference is the replicated images got generic names rather than the names assigned in the Secondary so that had to be manually corrected, etc., etc., etc.
Right now I have the Blue Iris interface supporting three cameras on the Secondary. But of course they are replicated on the Primary so what have I gained over putting the interface on the Primary in the first place?
LOGS: Working through the logs seems to be virtually impossible, there is so much data that correlating events with devices and each other seems to be a monumental task. For example, any one of the more complex PLEGs produces hundreds of events every few minutes and there are nine PLEGs.*** A device event in the log may be separated by a hundred other events from PLEGs, other devices, etc. How do you correlate them?
(In an effort at “simplicity” – the alternative is one or two PLEGs with possibly fifty or more conditions covering a dozen different devices in different rooms. A larger number of PLEGs allows each to be less complex and configured to a set of functions in one “room”. But i’m not clear on the impact on the system from more PLEGs with fewer functions vs fewer PLEGs with more functions )
I can’t help you much on the bridged devices. I don’t use any bridged systems, myself. I would think that if the goal was resource conservation, then putting devices on the secondary and plugins on the primary would be the better way to go. As you said, plugins are replicated from secondary to primary, so you won’t save much putting them on the secondary, though some circumstances may dictate it.
I know that the logs can be difficult, but it’s really the only way to figure out exactly what is going on. In the case of a delay with a particular sensor, I usually search/filter on the device string:
grep 'Node="8"' /tmp/log/cmh/LuaUPnP.log
or
grep 'Device="32"' /tmp/log/cmh/LuaUPnP.log
and then start correlating timestamps. Outputing to a text file and the putting it through an editor with colorization or highlighting is helpful too.
The “easy” way is to contact support and make them do the log work for you. I wonder what they use. That job, trolling logs all day long, must suck.
The “easy” way is to contact support and make them do the log work for you. I wonder what they use. That job, trolling logs all day long, must suck.[/quote]
Truer words never spoken
Best Home Automation shopping experience. Shop at Ezlo!
)