Vera Mods Summary

Community Playground Getting Started & Initial Setup
#1

I have initiated a couple of threads over the past year to discuss and share my attempts to make the vera more reliable and dependable while at the same time more secure. Over time some members have asked questions about them so figure I would post them here.
Please note first of all that none of these mods are supported by vera and you risk CS to not want to support you in case of issues.
I have also discussed these problems through a number of open tickets with CS and have not been able to get them fully resolved. They have however to their credit always attempted to help me and I am very grateful that this product is as open as it is in terms of allowing users to access it. It is just unfortunate that I have had to dig as deep into the firmware as I have in order to make it go from 90% reliable to 99% reliable. Yes there is still a 1% left. More on that later. I am not a coder and don’t even have much background in computer science. It took it as a hobby and have learned more than I wanted in the process.

First as background, the vera is based on a router hardware running on various versions of an opensource linux distribution for embedded devices: OpenWRT.
It’s firmware is very compact and space efficient with high compression in order to fit it on a device designed to be an appliance: ie. very little to no writing needed either logs or otherwise. And the onboard storage memory reflects this. It is designed to hold a firmware.
The firmware is broken down into three categories: Bootloader, Kernel and the root file system aka rootfs and each is stored in a different partition. the vera actually has 11 nested partitions.
In comparison to a PC, this would be roughly the equivalent of Bootloader=BIOS, Kernel=Low level operating system, rootfs=higher level operating system (user interface and programs) and files system/storage. More info about it here: [OpenWrt Wiki] The OpenWrt Flash Layout
As far as I know Vera never updates the Kernel or Bootloader and every firmware update has always been updates to the rootfs. The result is that the kernel used is very old and lacks a lot of improvements the openWRT OS has made over time in terms of stability and security.
Another problem is indeed that with this partitioning, if one wants to start installing a lot of plugins… you have very very very little left, to the point of being a bit ridiculous (a meager 10MB?) even with compression. To address this I used an external SSD drive and pivoted my Rootfs over to it as I posted here: http://forum.micasaverde.com/index.php/topic,103140.0.html
Unfortunately I believe this only works on the Vera Plus and Secure and not on the edge.

The second big issue I found was the constant communications and the unreliable mios servers causing my vera to occasionally randomly reboot. You can actually test this by unplugging your vera’s ethernet plug. Mine continuously restarted luup or simply rebooted. Isolating the vera from the internet was therefore not quite feasible. It is actually constantly phoning home and I decided to disable all of these connections except for one as discussed in details in this thread: http://forum.micasaverde.com/index.php/topic,83627.0.html
This of course disables all the mios server services like the mobile apps, the remote relay, the cloud backup storage, even the firmware upgrade servers and the app store which I disabled at the end but has completely eliminated the cmh reboot and greatly stabilized the controller.

The third problem was for some of us a memory shortage caused by what seemed to be a memory leak which eventually caused a reboot of the machine.
After 7.0.26 I had noticed a huge improvement in how fast the GUI was loading and I now know why from looking at how the machine works. The UI is actually run through a webserver distribution: lighttpd which is notorious in the older versions for memory leaks. On 7.0.26, it was finally updated to a newer version which to me has eliminated the memory leak.
I have since also updated a number of packages and libraries on openWRT which improves performance and security but have not been able to update the kernel.

Edit: 4th problem to address, well not so much of a problem but more of a default setting philosophy from mios which in my opinion is a contributor to instability to the zwave network is that polling is enabled by default for all devices. This makes the zwave network very chatty, adds latency to commands, can cause devices to crash etc… Unchecking the zwave polling in the zwave settings menu is unfortunately not doing anything because polling is actually a device specific setting. I recommend to do the opposite of what vera has done: disable polling by default for all devices and only enable polling for devices which require it. Discussion in this thread: http://forum.micasaverde.com/index.php/topic,121989.0.html

Regarding plugins and automation/scenes and integration, I moved everything to openLuup on a virtual machine on my NAS since I have assessed the Vera Plus to be too slow running on a 880MHz single core 32bit mips CPU and have blocked the vera from accessing the internet through a firewall block.

Hope this helps.

openLuup & (not) vera
#2

Thanks for this write up. Really useful

the ‘constant communications and phoning home’ Is it just that MiOS can’t deliver reliable servers at their end? I guess it must be given the current standard of home boradband (well at least mine) but that’s a trifle worrying. Nothing else we can do apart from pulling the plug as it were?

Cheers

C

#3

If you look at the taking off the grid thread, (sorry I am on my phone right now so I can?t find which post it is), I listed somewhere the various services and connections served by mios. The server reliability to be honest has been ok, though not without outage. My problem has been that it is taking away cpu clock cycles on an already constrained piece of hardware. It looks to me like an assemblage of services accumulating over time because of the number of different servers and the communication protocol used. There are also some very buggy implementations (like the time management). The remote access server (RA) is probably the most communication intensive as it constantly is reading the status of all devices and syncing them. There are services also which updates files on your vera without user knowledge or intervention… meaning you could come back one day and find something no longer workin and not know what happened.

#4

Could come back and find something not working? :smiley:

Thanks, again.

C

#5

I’m not sure if this is the correct venue for suggestions on strategic improvements, but I’d like to make a suggestion.
This is from my personal comparison of some of the leading contenders for consumer facing Home Automation controllers in North America.
I have tried out the following: SmartThings, Hubitat, Fibaro, HomeSeer, Vera Plus, Home Assistant, OpenHab, Zipato. (I’ve got a big cupboard full of controllers!)
I have noticed that a key ingredient of the SmartThings/Hubitat success story (I believe that they have the biggest market share), is the fact that the overwhelming majority of Home Automations can be done very easily (and quickly) by filling in a form (called Smart Lighting in SmartThings). For other, more complex automations they have a more sophisticated tool (webcore/rule machine which is roughly equivalent to PLEG). This easy to use, easy to understand tool is not found in any of their competitors products. Could it be a competitive advantage which has contributed greatly to their success?
I am by no means whitewashing or excusing any of the issues which have constantly plagued the SmartThings platform.
Nonetheless, if someone out there is re-imagining the Vera platform, I believe that this is a suggestion that should be considered.

#6

For the ease of use, Sorry I must be a little less focus on it at this point though I understand the requirement for new users. Vera is definitely not it. You can see that it is trying very hard to make itself user friendly with UI7 but it is failing mostly because of its bugs and platform limitations. The UI has its quirks in terms of location and availability of things but it isn’t too bad. The problem is that it just doesn’t work very well.

Luup reloads are completely abused. There are also a number of non-sensical behaviors like having to wake up and reconfigure a device when changing its polling rate (polling frequency is only a controller parameter), the insane flagging of devices not detected when the device functions perfectly and waking up per schedule which I am suspecting is due to reading of the z-wave chip which keeps a dead device list and I am forgetting many more.

When I look through the code, my reactions swing between “wow pretty smart!” to “what were they thinking?”. I am about done peeling the onion on the device. The vera basically functions on 3 languages.

  1. The LuaUPnP program written in C and assembled in uclib (a c language library) on the Mips platform and therefore only compatible with OpenWRT 15.05 (Chaos Calmer dated from March 2015) since openWRT has changed their C library to Musl after this version. The newest Vera units run on 14.07 (Barrier Breaker dated from 2014)
  2. Lua. The plugin and automation scripting uses the lua 5.1 library
  3. Bash Scripts… Almost all the OS level commands are using bash scripts. Startup, time syncing, file saving, backups, ethernet comm, Server connections, firmware upgrades, Webserver which serves the UI etc…

Because the luup engine is compiled, we can obviously not see the code and I really wish I could get the source code to fix a few bugs.

#7

Edited the 1st post to add the device polling resolution which also helps stabilize the zwave network.