Tech Info
This page is OBSOLETE
Vera is built on OpenWRT, adds the DCE messaging protocol libraries from LinuxMCE, and the rest is our own in-house software as well as commercially licensed 3rd party. The architecture is extensible, and we document the protocols for controlling Vera from another application, and provide access to a build server for developers who want to write their own modules to run inside Vera. Vera has a consumer-friendly front-end and self-configuring network setup, a socket-based messaging architecture for devices similar to and binary-compatible with LinuxMCE, an easy-to-use HTTP server for interrogating and controlling devices, and a secure online remote access / remote control gateway.
We've also put a Vera system online, at testvera.micasaverde.com, complete with a camera, Z-Wave accessories, and the secure remote access activated, so developers can play around with it and test having their own applications talk to it. (Learn more here.) Also see upcoming features in the Roadmap.
Contents |
For OpenWRT users
To make Vera appealing to a mainstream audience we added a self-configuring networking module that automatically determines whether you have another DHCP server on the network and if Vera can get an internal (192.168., 10., 172.) or routable IP address, then automatically configures the firewall, DHCP server, and other network settings. To make Wi-Fi setup easy for a novice, each Vera comes pre-configured with Wi-Fi enabled with WPA2 encryption and a unique, strong password printed on the bottom of each unit, along with a unique SSID. We pre-configure the wireless accessories on our web shop to each particular customer's SSID and password. However, under the 'Net & Wi-Fi' tab, when you click 'Advanced Configuration' it bypasses our simplified network setup and takes you directly into to the OpenWRT (Kamikaze) site. So you don't lose any of the advanced functionality in OpenWRT; we just add an extra layer on top to make it more consumer friendly.
For LinuxMCE users
Vera does not use any of LinuxMCE's code except for the open source DCE/util libraries. However, Vera's architecture will look quite familiar since the messaging layer is the same DCE protocol. Vera includes a message router that is compatible with LinuxMCE's DCERouter, although Vera's was re-written to use JSON files for storing device information, rather than a MySQL database, since Vera can't run MySQL. The device numbers, categories, etc., are the same, and your existing LinuxMCE devices can connect to Vera's message router and send/receive commands the same. If you have developed your own DCE Devices, they should work fine with Vera, although if you made devices that use the MySQL database, that database will need to be hosted on a PC, not on Vera.
A bridge between Vera and LinuxMCE could make LinuxMCE more usable too. Vera has plenty of power to handle message routing. So, a Vera unit could be left on all the time to handle home control, security and remote access, using only 6 watts of electricity (or zero net additional watts if you wanted an access point anyway), and then the LinuxMCE core/media directors would only be running when you need media. Vera is also designed to be far simpler, with a higher WAF, than LinuxMCE. We're also developing a lightweight media plugin + media catalog + rip/identify software suite that runs inside a low-cost NAS device, and a front-end that runs on the Sigma 8634-based DMA's (same chip that's in Blu-Ray drives). They both use Vera as the Core. When this is done, you'll have a comparable media solution to LinuxMCE, but at a fraction of the cost with a tiny amount of energy consumption; the NAS/DMA units go into standby mode when you're not watching media, so you've only got Vera running at 6 watts most of the time. A normal PC running LinuxMCE uses up to $92/month in electricity vs $1.50 for Vera. (See: Energy Savings) This new media catalog will also compliment MythTV users well, since, like a LinuxMCE Core, our NAS device stores all your MythTV recordings, and you can watch them not only on a MythTV PC, but also on the DMA's. The NAS unit also has simplified ripping; attach a USB CD/DVD drive, and anytime you insert a disc it's automatically id'd, ripped and ejected, so it's really easy for everyone in the family to use.
We also built our own data provider plugin for retrieving data. It is a lot more flexible than the DataGrid system in LinuxMCE, and returns data in XML and JSON format. We also built a request server that listens on port 3451 to accept messages and data requests as simple html requests. This makes it a lot easier to integrate Vera with other devices. more on the Data Provider Catalog Plugin We also have secure, remote access with SSL encryption.
We are also working on Vera's own version of "Generic Serial Device". But instead of Ruby we're developing a Lua version, because Lua is more lightweight and can run on Vera, and for GSD devices, people didn't really need the full power that Ruby offered anyway.
For Mr. House users
We have not tried integrating Vera with Mr. House. However, there have been attempts at integrating Mr. House with LinuxMCE, and as mentioned above, any LinuxMCE->Mr. House bridge devices should work fine with Vera. There are a few benefits that Mr. House users would find to having a Vera->Mr. House bridge: First, leaving a PC running 24/7 uses a lot of electricity. (See: Energy Savings); having a way for Vera to provide the basic home control while the PC is off would save quite a bit. Second, Vera should do well with the WAF. There's an iPhone and Java (Blackberry/Nokia) front-end and it's easy to configure. So a bridge would allow a simple, stable front end for the non-technical user, while the geeky Mr. House stuff runs elsewhere. Also, there's automatic secure, remote access with SSL encryption.
Build environment
One of the issues with building custom modules for an OpenWRT platform is that it's not as easy to compile C/C++ code as for an x86 because you need to set up the correct kernel header, tool chain, etc. To make it easier for developers, we've established a dedicated build server with virtual machines. So, when a developer wants to do some custom stuff, we'll provide a VM on our build server which is pre-configured with everything needed. Just run one script to build a new firmware image with your custom changes. And, we've forked our svn so the developers and FOSS community have their own branch where they can add the "geeky" stuff, and we periodically merge in the fixes/changes from our consumer branch. The source code is here: Source Code
