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: https://openwrt.org/docs/techref/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.