Migrating from Veraplus to Openluup questions-- some theoretical questions

Plugins & Plugin Development openLuup
1

So, due to scenes and logs overloading my Veraplus, I have decomissioned it to be device only interface, and do all the heavy lifting on a VM running openluup. A also have a VM running openhab for my alarm interface (omnilink).

So, I think I will be moving the virtual switches that I created from Vera to openluup for the alarm circuit.

Currently, they are virtual switches. I did not configure them in Vera as contacts, but was wondering if it really matters and what the schema for contacts/motion sensors when set up in openluup offer any special functionality in regards to priority, etc. (or for the Vera for that matter)?

Do I create custom switches, or change them to contacts, then on the openluup install, or maintain them on the vera and ‘bridge’ them thru openluup? Are there any advantages or disadvantages (theorectical or otherwise) to doing this? (there is one motion detector sensor)…

Also, is there a global index/master list of devices that can be used in openluup that enumerates the driver/function that are available for openluup, or just aggragate them from some of the stickied posts???

Thanks in advance –

drex

2

Welcome to the club…

I would move everything I can off of the Vera. It is overloaded and unreliable. I myself have also setup virtual switches to control a few Home assistant switches…

3

An incomplete list of known working plugins:

http://forum.micasaverde.com/index.php/topic,36939.0.html

The “openLuup Bridge” is a great help during the move process. And if a plugin doesn’t work someone can probably fix it for you. Note that PLEG is not available on openLuup and any plugin that does calls to the OS may not function, depending on what the commands are.

openLuup combined with lightly loaded Vera(s) works extremely well.

4

Thanks guys. Familiar with those.

Anyone familiar with Alarm structures/nuances in vera – ie contacts/motion sensors?? how do they impact or priortize things??

5

Can you be a bit more specific about your concerns here?

Assuming you’re talking about Zwave devices? These are treated just the same as everything else. Response time in terms of triggering something on openLuup might be a bit slower due to some latency of the bridge.

The bridge can also help with your transfer of automation to the openLuup environment. As well a providing links which can trigger remote Vera scenes, it also allows the possibility to import and ‘translate’ scenes automatically so that they act on the local openLuup devices, in the same way that they did when on the Vera. As with all scenes on openLuup, UPnP event-style triggers are not supported, but instead you can use the much more flexible AltUI device variable watches.

6

akbooer-

just trying to figure out if there is a vera-specific alarm condition that may not be supported on openluup/altui… specifically with security based features… or not… thinking about using openhab alarm integration directly on openluup instead of thru the vera… would that cause latency?

would use home modes on the openluup to control activation and deativation of same… would there be anything that would hamper or not be ‘a good idea’ to use that?

-d

7

I don’t know anything specifically about any newer ‘security-based’ features, but as long as the basic need of HTTP access to /port_3480, and running of Lua code is enabled in the actual Vera itself, then anything else device-related should work. VeraBridge makes complete clones of Vera devices and follows their state changes with a small latency. Control from openLuup to Vera is very responsive indeed.

House modes are supported and you can choose one of several ways of working

[ul][li]0 : no mirroring,[/li]
[li]1 : local mirrors remote,[/li]
[li]2 : remote mirrors local.[/li][/ul]

Scenes on openLuup can be set to run only in certain modes, but I have not implemented any further time-based of activation, aside from normal scene timers.

openLuup does not spontaneously restart, like Vera does so often, so that states and scenes and timers, etc., behave as you would want. I’ve had my openLuup systems up and running for stretches of over 100 days at a time, only taken down for updates (or, before UPS, power outages.) Your only point of failure is Vera itself… if it’s not there to respond to a command, then the command can’t happen.

In transitioning logic from Vera to openLuup, as well as linking to scenes and having local versions of remote scenes, then openLuup can also mirror local device variables back to other devices on Vera, allowing openLuup logic to interact with Vera scenes. Your goal though, as stated by others here, should be to end up with Vera just being a Zwave bridge, as far as possible, to maximize reliability.

I don’t want to say it’s the solution to all your problems, that’s up to you to find out, but it is a very secure basis on which to proceed, and there are others here who can help.