Multiple openLuup setup...

[DesT]

Hey guys...

Anyone is having more than one openLuup to offload some stuff ?

Right now, I'm having my veraplus ONLY for zwave devices.  No plugins at all.

All the other stuff like DSC, Sonos, and a couple of plugins like smartswitch, RulesEngine run on the openLuup box.

Most of the time, it's working fine but if I have one devices like sonos that stop responding for an update, it freeze the entire openLuup instance.

So, I'm thinking, if possible, to have another openLuup instance that will handle all the "IP" stuff while having the main openLuup for all my scenes and rules...

[akbooer]

Yes, I do.

My 'production' setup is:

• 'master' openLuup system running on a BeagleBone Black
• 'secondary' openLuup running on Raspberry Pi
• 2 VeraLite systems with separate ZWave netwrosk
• 1 VeraEdge

The master system is bridged to all three Veras and also runs a Philips Hue plugin to Zigbee devices and a Netatmo weather station.  It is running openLuup's Data Historian archiving data from everywhere.  It also hosts an InfluxDB instance.

The secondary system has a Razberry board and with its own Zwave network and also a MySensors gateway linking to some homemade sensors.  This system gets experimented on quite a lot so failures here have no impact on the main system.

The Veras are just gateways to the respective ZWave networks, and the Vera Edge is mostly a machine for testing.


Having said all that, we really should try and address why your Sonos hangs things - are you running the UPnP proxy?

[rafale77]

Wow... That's called sharing the load!

I was going to say the same thing as AK... might want to figure out why it is freezing first.
What sonos plugin are you using?

[DesT]

I'm using the sonos plugin available on the veraplus app store.  (urn:schemas-micasaverde-com:device:Sonos:1)

And I'm not using the uPnP proxy.

My IoT "network" is not the same as I used Sonos itself.

I know that my issue right now, it's sometime the Sonos in the garage is having a hard time reaching wifi properly if it attached to not the closest AP. (having 4 AP here)

In general, all my issue are coming from plugin that need to access the network.  I mean plugin that can hang 'cause a device is not responding fast enough.  One of them it's the chamberlain plugin that i removed last month 'cause it give me too much trouble of stability.

Right now I think my stability issue come from sonos and netmon plugin.

If I can have a second instance of openLuup that will handle all the "networking" stuff and be able from the main instance to use them in scene and rules engine it can be a nice solution until openLuup can handle multi thread

[akbooer]

If I can have a second instance of openLuup that will handle all the "networking" stuff and be able from the main instance to use them in scene and rules engine it can be a nice solution until openLuup can handle multi thread

The multi-threading would only be possible if I changed to Lua 5.3, so breaking compatibility with Vera.  At the moment, in 5.1, coroutines can't work across library calls which access C-code, so you can't do I/O with sockets between threads.   Actually, coroutines aren't used at all by the scheduler in openLuup, but it's the only way (shy of actually running separate Lua instances) that you could transparently suspend plugin code without having to rewrite it.

How were you thinking of connecting the two openLuup instances?  I've never actually tried to use VeraBridge to do that, not having any need to unify my two systems in that way.  AltUI, of course, is easily able to integrate multiple controllers at the UI level.

[DesT]

That's the next question AK

How to integrate multiple openLuup instance to share all devices on the same ALTUI interface 

Or I will need to have another VERA just to handle some plugin like Sonos.

I have a VeraEdge that I can use for that... but will prefer to have another VM running openLuup!

[akbooer]

AltUI has variable called ExtraController where you can put another IP address, I believe.

This is all you need unless you actually want the two separate controllers to see each other's devices.

[DesT]

I think the best solution will be that the "main" openLuup will see all devices from any other openLuup instance... and at this point, I think it's not possible 'cause openLuup is not build for that ?

I think we will need a kind of plugin like verabridge but openLuupbridge

[akbooer]

VeraBridge will need a small adjustment to make this possible, since it has to access Vera on port :80/port_3480 whereas openLuup's server runs directly on port :3480

Otherwise, I see no reason why this should not work, openLuup being a pretty faithful emulation of Vera as far as HTTP requests go.

[akbooer]

VeraBridge will need a small adjustment to make this possible, since it has to access Vera on port :80/port_3480 whereas openLuup's server runs directly on port :3480

OK, that's done.  Development branch v19.1.26 has the change.

VeraBridge now has a device variable RemotePort with the default value of "/port_3480" for Vera systems.  To access a remote openLuup system use ":3480".

[DesT]

awesome

But with this new change... how will react/respond the main openLuup instance IF the additional instance hangs will doing some check ?  Does the main instance will continue like nothing happen ?

[akbooer]

Good question! 

IIRC, there is a timeout, but there's also a change coming along (slowly) which makes the VeraBridge communication asynchronous, so, in the end, it should work.

Give it go!

[rafale77]

Though I may not need this, it deserves a +1! This was a quick turnaround!

[DesT]

Will for sure, this weekend.   Have a bunch of idea with this new mod    Will probably have a couple of rPI transform into a "slave" openLuup

Good question! 

IIRC, there is a timeout, but there's also a change coming along (slowly) which makes the VeraBridge communication asynchronous, so, in the end, it should work.

Give it go!