openLuup & (not) vera

I can confirm, that since last week… I’m using my Vera only for zwave/zigbee devices. All plugins/logic/scenes are running on openLuup.

So, I really need to say thanks to @akbooer, @amg0 and @vosmont

You are having all of you, a really nice piece of the whole puzzle.

Next thing will be to wait an update for the ZWay plugin so I can move all my zwave device to zway :wink:

and wish there was a zigbee interface too… 8)

Don’t know if there’s an equivalent board/USB for Zigbee on RPi?

There is a combo USB stick:

Not sure what driver it runs.

When you start putting more device inputs into openLuup you might run into deadlock problems because of the single threaded nature of openLuup.

Just having a ZWave input on openLuup may not be the panacea you think!

Vera went through a tough cycle in UI4 with implementation changes that reduced the chance of deadlocks. Early versions of Vera were single threaded.

[quote=“RichardTSchaefer, post:25, topic:197445”]When you start putting more device inputs into openLuup you might run into deadlock problems because of the single threaded nature of openLuup.

Just having a ZWave input on openLuup may not be the panacea you think!

Vera went through a tough cycle in UI4 with implementation changes that reduced the chance of deadlocks. Early versions of Vera were single threaded.[/quote]

I actually thought that UI7 was single threaded. I am having Zigbee deadlock issues related to how busy the vera Luup engine appears to be. Openluup in spite of single threaded is offering a second much faster thread. Since I have unloaded the vera, even the remaining scenes on the vera run faster, the zwave commands also all run much faster. I will see how this goes but the main purpose of moving things to openluup for me was to circumvent the dreadful speed and crash happiness of the vera.

There are still things that are not designed properly for multi-thread operation.
This is typically plugins. But camera’s on Vera have the same problem.
There are no design guidelines for this.
But plugins that need to be aware of this … are plugins that:

  1. Have side effects that use network services (i.e. send messages to other device, i.e. Vera Alerts, Nest, IFTTT. …)
  2. Call luup.call_action, in particular on another device or plugin. (i.e. PLEG)
  3. Have any computation intensive code … or calls luup.delay

I have had to learn a lot about this because of (1) and (2), but as I said, things are not documented.
Vera’s solution is to use Jobs, and Jobs are on another thread and can run concurrently.
But this is still a limited number of threads (two per device/plugin).

Blocking IO, or an infinite computational loop could do this. I haven’t run across this as an issue in my system linked to 4 Veras and ZWay and MySensors…

I know of one huge system that we had to tweak because it was running many videos (something I wouldn’t recommend!)

Vera went through a tough cycle in UI4 with implementation changes that reduced the chance of deadlocks.

I’m suspecting that this is one reason why it uses SO much memory, another thing which it frequently runs out of.

…I do believe that there are many more ways to bring a Vera to its knees, than an openLuup system, which, by the way, doesn’t restart randomly. Most of mine have been up for over 100 days, and then only taken down for system updates.

AK,

I confirm too, using openLuup for everything and I never have a crash like with Vera! No reboot/no restart… nothing.

And my Veraplus is running more smootly too without all the plugin like Smartswitch that runs on openLuup since a week now!

Maybe that my crazy hardware setup help too as I’m running everything (openLuup / influx / grafana and node-sonos) in different Linux container under proxmox using a cluster with 2 nodes :wink:

I’m using a bunch of Raspberry PI 3 and also the new Zero W around the house that feed some data to openLuup or control some “monitor” around the house!

Maybe that my crazy hardware setup help too

Good Grief! I’d hate to think that people thought that hardware like that was necessary!

No, certainly not necessary… but nice!!

[quote=“akbooer, post:30, topic:197445”]

Maybe that my crazy hardware setup help too

Good Grief! I’d hate to think that people thought that hardware like that was necessary!

No, certainly not necessary… but nice!![/quote]

didn’t want to insult you AK… I’m just “think big” kind of guy! Sorry bro!

[quote=“RichardTSchaefer, post:27, topic:197445”]There are still things that are not designed properly for multi-thread operation.
This is typically plugins. But camera’s on Vera have the same problem.
There are no design guidelines for this.
But plugins that need to be aware of this … are plugins that:

  1. Have side effects that use network services (i.e. send messages to other device, i.e. Vera Alerts, Nest, IFTTT. …)
  2. Call luup.call_action, in particular on another device or plugin. (i.e. PLEG)
  3. Have any computation intensive code … or calls luup.delay

I have had to learn a lot about this because of (1) and (2), but as I said, things are not documented.
Vera’s solution is to use Jobs, and Jobs are on another thread and can run concurrently.
But this is still a limited number of threads (two per device/plugin).[/quote]

This explains a lot of things in my mind. Thank you!
There is some randomness factor in the vera which I believe are related to the concurrent jobs not completing at the same time every time so for me I have had random “error in lua scenes and startup lua” happen on the vera as my system and codes were growing. I suspected that the startup lua code did not finish before some of the plugins and scenes were loaded. It also contributes to the random Luup reloads on the vera.

@DesT, I am running Openluup along with 5 other various server/bridges on a VM on my NAS which has an i7 6700K with 2 threads (i.e 1 core) dedicated to it… It is incomparably faster than the vera. You are not crazy. :stuck_out_tongue:

rafale77,

Just for fun… that’s my other 3nodes clusters for having fun with stuff other than IoT/home automation!

Just discovered that the Countdown timer plugin actually does not quite work. My openluup cpu is too fast compared to the vera and is not able to sense when the timer ends before the “Event” variable switches back to 0. I had to modify the plugin so that at the end of the countdown, the event variable stays “1” for 1 second so I can use it as a watchable variable…

Just tried to do the same configuration on Ubuntu. I get “could not poll Vera” - will retry in 10s"
I can ping the IP that I used in the config but, for some reason, it doesn’t work. Any suggestions would be appreciated.

Couple of months later…

Anyone have some new experience about moving zwave to another hardware and keep running openLuup?

Having tried many, I have settled to stay with the vera for now. The new firmware and all my mods combined has enabled me to have a luup reload only every 10-16days is satisfying. I could have easily ported bridged hubitat with their API as well but opted not to proceed as I didn’t deem it necessary and would have involved another learning curve. I still wish openluup would embed openzwave somehow but I also realize that it is a lot of work.

Did you shared your mods somewhere on the forum? :wink:

Let’s see how long this one lasts.
:stuck_out_tongue_winking_eye::grin:

@rafale77 Just checking about this thread… the thing I don’t like with Vera, it’s here and there, some devices stop working properly.

Are you having the same kind of issue ?

Can you share all the mods you made with your Vera? :wink: