I’m running my Veras in bridged mode with the intent of having actions on one exposed and controlled from the other. Right now the Primary Vera (Master in the relationship) has the DSC Alarm Plug in and some other functions and the Secondary (Slave in the relationship) has all the ZWave devices, lights, sensor, locks, etc.
Unfortunately I find this Bridged Veras configuration is largely useless. Status changes for only about 50% of Secondary-connected ZWave devices are reflected on the Primary and even then are usually delayed by a minute or in some cases up to a half hour. Attempts by the Primary to change the state of a Secondary connected device such as a light are only effecting in about half the attempts. All in all I find the Bridged Vera environment to be pretty much a waste of time thus far.
Which brings me to the reason for this post. Because my locks are on the Secondary Vera and the Alarm System is on the Primary Vera having an action such as disarming the alarm by lock pin code is impractical … the alarm will have gone off by the time the message gets across the interface. So, is it permissible, or is there a way, to have the same DSC Alarm Plug in installed on both Veras talking to the same Envisilink ontroller?
Expanded version…
The TPI interface on the Envisalink modules only allows on “thing” to be connected to it at any time (and a TPI consumer maintains a persistent connection)
Expanded version…
The TPI interface on the Envisalink modules only allows on “thing” to be connected to it at any time (and a TPI consumer maintains a persistent connection)[/quote]
Short Reply: Thanks
Expanded Version: Appreciate the explanation. This would not be a problem if the stupid bridge worked properly
There may be a workaround. If you have an Android computer that is always on, and always connected to your home network, look into the DSC Alarm app. His paid version, I think it’s $8 or so if I recall, acts as an “Envisalink server”. It gets around the single TPI client login of the Envisalink by -being- that login. Then you point all other TPI clients from other devices and software to the Android. There may be some consequences to this, such as erratic behaviour in a Vera for example, but I don’t know. Might be worth a try. He partly designed the app specifically to address the issue.
Good luck!
Edit: It’s been awhile, but I believe there’s a windows based version of this TPI server too, made by the same guy. Again, never tried it, but if my memory serves me correctly, it ought to do the trick.
[quote=“Pestus, post:4, topic:184942”]There may be a workaround. If you have an Android computer that is always on, and always connected to your home network, look into the DSC Alarm app. His paid version, I think it’s $8 or so if I recall, acts as an “Envisalink server”. It gets around the single TPI client login of the Envisalink by -being- that login. Then you point all other TPI clients from other devices and software to the Android. There may be some consequences to this, such as erratic behaviour in a Vera for example, but I don’t know. Might be worth a try. He partly designed the app specifically to address the issue.
Good luck!
Edit: It’s been awhile, but I believe there’s a windows based version of this TPI server too, made by the same guy. Again, never tried it, but if my memory serves me correctly, it ought to do the trick.[/quote]
;D :o 8) :