Why does Vera not offer an option to get decent hardware

Right now I’m very frustrated because I have hit the limit on my Vera Lite and I can’t anymore content and I’m having major issues even saving changes because the Vera memory has run out.

I opened a ticket with support on Friday and it is now Wednesday and I haven’t heard anything which forced me to try to find a fix my self. The only option I had was to restore from a backup and start removing plugins and apps to free up memory space.

I currently have this configured on my box.
-55 Scenes
-70 plugins\devices

My current average memory usage is around 158MB.

That is where the problem occurs. The Vera Lite only has 64MB of memory so the device is way over utilized right now but I personally don’t think I have much on the box. I understand at this point I should have purchased a Vera 3 with 128MB of RAM but honestly that still won’t resolve my issue, considering my average memory usage. And plans to add a lot more to my z-wave network and apps.

My question to the Vera developers is why don’t you offer an option that can actually scale. I would like an option to buy an out of the box appliance that can handle more or maybe integrate the Vera into a software solution that can be installed on hardware of my choosing. I completely understand offering an option that is low on energy draw, but that’s no reason not to offer an option that allows power users to actually use the device. After all most of the power users are the people who are going to contribute back to the project.

Seeing that the Raspberry Pi platform costs $35 and comes with 512MB of RAM and a faster everything else. I really don’t understand why we are stuck with this JUNK hardware!!! GRRRRRRRRRR

Please fix this immediately so I can actually use my Vera.

It might help if you list all of your plugins. There could be a plugin that might be causing a serious memory leak. The lite is just that a box that is used for not heavy use. The vera 3 is more of a pro model. MCV is coming out with a new Vera that will have 1GB of memory. Not all plugins are created equal and it would be best to figure out what is consuming memory. Also understand that Vera is a niche device and development cost to a smaller scale of customers will cause for higher prices to make up that cost. Raspberry pi has sold far more devices than what Vera has sold. So that is one reason why they can also sell at a lower cost.

  • Garrett

I’m pretty sure you can scale by adding additional Vera controllers.


This does bring up an interesting idea to expand the Vera’s functionality to a cloud platform. Most of the computing could be done remotely through an IP connection.

Thank you for the response but as I had said even going to the Vera 3, that will not solve my problems, my relatively small network is still too much for the Vera 3.

Here is a list of plugins that I currently have installed:
ERGY Plugin
Wunderground Weather
garage door
Combination switch (I have about 4 of these)
Virtual on\off switches (I have about 12 of these)
Program logic timer switch ( I have about 5 of these)
Push notification
Countdown timer( about 3 of these)
Vera alerts
Google Calendar Switch
Ping Sensor
Day or Night
Program Logic Core
Program Logic Event Generator


Sorry but adding additional controllers doesn’t scale well at all. Adding more controllers merely just segments functions to specific controllers and can not do a full sync between the controllers. If you did do a full import to all controllers then you are limited by your smallest Vera Controller. I will probably end up adding another controller until Vera pro comes out, but that is a really crappy way to scale the network.
Thanks for the response though.

[quote=“MackBlanch, post:3, topic:174147”]I’m pretty sure you can scale by adding additional Vera controllers.


This does bring up an interesting idea to expand the Vera’s functionality to a cloud platform. Most of the computing could be done remotely through an IP connection.[/quote]

When you do find out which of these plugins is chewing up your memory (it could be mine, you’ve got two that I wrote), please do tell us. Remembering that fourteen of the fifteen plugins you list are written by volunteers who have donated their code and time to the community.

It sure would be nice to get a memory dump after each device init …
Would be helpful to understand this.

I have written 6 of the plugins … some with multiple device instances.

Personally I have more devices and all my plugins with more instances than listed here … and I am @ 76% mem for a Vera3

Thank you very much Futzle and Richard for your interest and input! In my original estimate of plugins I underestimated how many combinantion switches I had. Instead of 4 I have 10, and some of the switches have up to 5-6 devices. I’m thinking that each of these combo switches is taking around 5-6MB in memory so that could be 50-60MB of memory right there.

I’m going to try getting rid of some of them and see what happens to my memory. I will follow up and let you guys know.

The Combination Switch is one of mine. I can think of a couple of reasons why it is so memory-hungry. If you can SSH into your Vera I can think of some tests you can do for me.

I would also remove one at a time and see how the memory usage turns out. Again the best solution is to track which plugin(s) are causing the memory issues as it not only helps you but it helps others and the developer to rectify the problem.

  • Garrett

Since there are a few plugin devs on this thread my question to you guys would be what is the best way to debug a specific plugin? Are there any tips / tricks you use from the console to single out individuals? I believe it all gets run in the main Lua loop - but I don’t have much experience debugging Lua…

Thanks! Great thread. I see memory issues looming as well - would be nice if there were other options to write code. While Lua isn’t a bad option, I would think an engine based on Node (Javascript) would be much more effective long term since:

[ol][li]It’s well supported - and v8 is maintained by Google.[/li]
[li]It’s darn fast and small.[/li]
[li]You can write CoffeeScript or any other abstracted language to make it that much easier.[/li]
[li]It’s asynchronous - the biggest win for home automation. Have no issues on blocking or particular loops waiting on events.[/li][/ol]

I think that’s just a small list of why SmartThings chose to go that way… I know that’s a huge shift - but it’d be cool to iterate in a more positive direction. I’m not sure, long-term, that Lua is the right choice. But, just my $0.02. :slight_smile: FWIW.


FWIW, perhaps start with the Ergy Plugin. I ran into severe stability issues, which seem to have disappeared after uninstalling the Ergy plug-in (even though things seem to have run fine for a while, with it installed). (Note: I have not investigated this / tried to reproduce this.)

Thank you oTi@, but I actually tried removing the ERGY plugin last night and it only saved me about 8-10MB of memory in the lua utilization. So I ended up putting it back in.

Make a backup.
Then zap one whole class of plugin devices at a time.
From a memory perspective it probably does not matter if things do not work properly because of missing triggers …
Reload Vera … Record Size … And Loop to next class of plugins.

When done ... restore backup ... Nothing lost ... and you will have a lot more insight to share with us.

Great idea Richard!

I have done exactly that… Please take a look at my attachments for the full report with screenshots.

My general findings are that each instance averages about 2MB per instance with the exception of some plugins.

ERGY was the highest with 8MB, then Vera Alerts at 4MB then everything was 3MB or lower per instance.

But my bottom line conclusion is that the Vera lite is way under powered at 64MB and should have had a lot more memory put into it. I also feel that Vera3 is way under powered with only 128MB.

After removing all of my plugins I was left with only the raw devices and 62 scenes and my Vera lite is still running at 75% memory? That’s horrible:
1. 4 Door locks
2. 4 motions sensors
3. 2 dimable lights
4. 6 switches (Lights or switch modules)

Take a look at my attachment and let me know what you think!

If you do not need a User Interface switch for things like the CountDown Timers and the Combination Switches i.e. you really only need the Logic and the Timers … than you can place some … maybe all of these in a single PLEG instance … with different condition names for different events. That could save a lot of memory. I think it’s a fluke that the PLEG came in so low.
This is a memory - speed trade-off. More conditions in a specific PLEG device means more evaluation when any event happens.

Also if the Scenes are only activated from the logic and not typically by you the user you can also place them as Actions in the PLEG and/or PLTS instance. That might save even more memory.
I am in the middle of some changes for Vera Alerts. I can save some memory by not loading packages needed for mail if you do not send mail from Vera Alerts.

IIRC there are a number of bugs in OpenWRT that make the line-item results in top inaccurate as a means for measuring memory utilization. In some cases, I think it comes down to re-counting [shared] library memory when multiple threads are going on (but it’s been a while since I’ve read up on this)

Vera starts a few threads for each [Luup] Device, so if there are OpenWRT bugs in the shared memory calculations, then that will multiply this problem on a per-[Luup]Device basis. Each of these threads will have it’s own set of base memory consumption (for stack etc)

Probably better to look at the top-line stats, showing overall system memory allocation. When reading these, bear in mind that Linux itself puts “whatever’s left” (fast/loose interpretation) into Cache (etc) which, luckily, is also shown. Linux can steal from these areas when there’s a real need.

Looking at your system, from a top-line stats basis, it appears you still have quite a bit of headroom (mostly in Cache)

Historically, things like ERGY were the “great destabilizer” in systems, and people removed it to improve overall system stability, although reportedly they spent some time to address that[sup]1[/sup].

There was also a time when the Ping plugin could restart your system[sup]2[/sup] if it took too long to actually perform the Ping operation. This was very early in UI5, and resulted in Aaron adding 2 (?) threads-per-Device, instead of a system-wide pool of 2, as well as extending the timeout from 30->60 seconds… both of which stabilized the situation (since no single plugin could stop Vera from functioning)

[sup]1[/sup] A search on ERGY on Vera will net those discussions, including how much of your PII they’re actually sending over…
[sup]2[/sup] A search will show these also, with people “early on” (mostly Beta folks) removing Ping until MiOS was fixed up.