Performance Intensive Devices and Scenes on Vera Controllers

Does anyone here know what types of devices use the most resources on a Vera Controller? Also, do certain types of Scenes cause a performance degradation? Like others, there are frequent times when Zwave operations will take a little time to execute and I’m trying to figure out why.

Does anyone have any ideas on how to increase performance on the controller itself?

Thanks in advance.

Remove cameras from the Vera and scenes. This helped my lock scene speed up considerably.

More plugins and those using WiFi might also eat up memory and you should evaluate what you need versus want.

The topic of zwave command queueing is ongoing with rafael77. It is the subject of slower response and trigger of excessive luup engine reloads. Rafael77 has posted many guides on other mechanisms you can do to help your system too.

For now, I have increased timings in my global poll settings so I could maintain having polling enabled but with less frequency as it seems my mixture of devices wasn’t working so well. I’m at 2 days of no luup reload starting my test versus half a day.

Probably so much more to list that I can’t think of.

I have indeed taken upon myself to troubleshoot the reliability and lagginess of the vera. Though there are many things you can do to improve as @tomtcom mentioned, I think I will create a post with a list of suggestions… not to the users but to eZLO.

The fundamentals you need to know are:

  1. The CPU is underutilized and under powered with you have a large setup. The vera UI does not use thread making multicore processor a moot upgrade. (the vera secure is not faster than the vera plus which is only a little than the vera edge due to cpu frequency). Reducing the load on the CPU is key. Plugins, cameras
  2. There is a fundamental design flaw in the lack of zwave queue in the vera engine which does not conform to zwave host controller design requirements. It results in having the zwave chip doing the command queuing which it is not designed to do and it is not doing it well seemingly creating significant lag and command retries by the vera due to dropped commands and responses and eventually luup crash and reloads. Eliminating unnecessary zwave traffic helps. (i.e polling, regular unwanted scheduled network healing). For example a home energy monitor can generate a lot of traffic. More generally devices reporting energy status at a high frequency as well.

I have been testing running the vera engine on an emulator based on an x64 CPU and though the interface is drastically faster with the faster CPU. The zwave commands still have intermittent lags.

2 posts were split to a new topic: TempLogFileSystemFailure messages periodically in log