VeraLite to Openhab conversion (using raspberry pi and razberry board)

[quote=“garrettwp, post:40, topic:181558”]Is not home and tried two include an appliance module and a dimmer module I had laying around. They included, but I can not get them to configure. They end up being reported as dead. Mind you, i’m using habmin to include the modules. I don’t have time to tinker (hopefully this weekend I will). The zwave chip is running the 3.5 firmware and not the older firmware. Does this make a difference?

  • Garrett[/quote]

I haven’t used the Habmin software yet. On my raspberry pi, I just used the z-way from zwave.me to configure all of my devices and then shut it down and started back up openhab. Some of my nodes get reported as dead when I startup openhab but it shortly heals them and everything is fine after that.

I was finally able to get the Vera z-wave chip to work with OpenHAB. The secret to getting things working properly is that the Vera z-wave chip must be using z-wave firmware 2.78 and not 3.20. I had to downgrade the firmware and once I did that, everything appears to be working. I compiled and loaded up openzwave control panel and included some test devices and ran a heal. Once I was done with that, I stopped the openzwave control panel and configured OpenHAB with the new zwave devices and fired it up. I now have communication with the zwave devices in OpenHAB. Not the most ideal solution but it all works.

  • Garrett

Thanks for the update, I am considering this solution when locks and thermostat control comes to openhab. Once it is there I have no need for the VeraLite unit so I might as well take advantage of the internal zwave chip. Is it working pretty good or are you noticing any issues?

Thinking about trying openHab too. Is it possible to import datamine data in openHab?
How does OH counterpart to data mine work?
Does it logs to mySQL?

The Persistence layer has adapters for rrd, Mongo, MySQL, etc.

It’s setup & exposed as outlined here:
Persistence · openhab/openhab1-addons Wiki · GitHub

Not sure how you’d migrate data from another store, but like most things ‘If you code it, they will come’ 8)

You can get dataMine CSV or JSON output using dmDBserver.

For sure you can convert dataMine data (which is basically CSV) and import it into mySQL which can then be used by openHAB. You’ll also find that the HABmin UI for openHAB looks pretty familiar to dataMine as I started with dataMine when I wrote HABmin (although the next version will look a bit different).

Chris

[quote=“Chris”]For sure you can convert dataMine data (which is basically CSV) and import it into mySQL which can then be used by openHAB. You’ll also find that the HABmin UI for openHAB looks pretty familiar to dataMine as I started with dataMine when I wrote HABmin (although the next version will look a bit different).

Chris[/quote]

Chris,

How far along are you with the remake of habmin? I’ve installed it from day one of getting openHAB running. Again great work and glad to see you still around contributing to the community. Are you able to share what your plans / features will be on the new remake?

  • Garrett

Interesting project… I checked out OpenHAB a bit today, and I fully agree with their vision statement and approach. This looks like a strong horse to bet on.

Is there a functional bridge, or are you still building one? A working bridge would offer a great “soft” migration path, basically keeping Vera to manage the Z-Wave stuff but handing off all automation tasks to OpenHAB. From what I have read, that is how they intended it anyway. It also means I won’t have to rebuild my network either, and I can keep using Vera for remote access. At some point I’ll probably just add an OpenHAB gateway type to HomeWave.

[quote=“intveltr, post:49, topic:181558”]Interesting project… I checked out OpenHAB a bit today, and I fully agree with their vision statement and approach. This looks like a strong horse to bet on.

Is there a functional bridge, or are you still building one? A working bridge would offer a great “soft” migration path, basically keeping Vera to manage the Z-Wave stuff but handing off all automation tasks to OpenHAB. From what I have read, that is how they intended it anyway. It also means I won’t have to rebuild my network either, and I can keep using Vera for remote access. At some point I’ll probably just add an OpenHAB gateway type to HomeWave.[/quote]

It’s a work in process. Guessed sent me some notes that I still need to respond to. Been pretty busy the last few days and just had some time to configure the IDE setup for openHAB. I will be responding to Guessed notes soon. But right now we are just laying out the basics like defining the binding representation. And how to support the upnp service variables. Guessed suggested that we start looking / hacking how the XBMC binding in openHAB as it does something similar to what we need. The challenging part right now is just learning how it all works and grasping all of it.

Just having vera do the z-wave duties would allow vera to be pretty stable. It’s when you add the additional plugings and start pushing the unit more that causes Vera to not play nice sometimes.

Once I can understand how to implement bindings in openHAB I also want to integrate the ISY Insteon controller as well.

  • Garrett

I’m a reasonable way along, but it’s far from ‘there’ yet. I’ve been focussing on trying to find a new framework to move away from ExtJS and also Highcharts (they have commercial licenses). So, I’ve been boilerplating a lot of the code to make sure that the framework can support what I currently am doing in HABmin, and a few more bits and bobs.

So, I’m converting the framework over to use Dojo which is a bit of a learning curve and not quite as refined as Ext, however with that comes a bit more flexibility. In general, I’m planning on supporting the same functions as currently in HABmin, but the plan is to make it a little more glossier, and also to work in with openHAB v2 which will have better support for an admin console. This will allow admin notifications for example, so that I can have a notification when including new devices, and also allow me to get advised when data changes rather than having to poll… (at least, that’s my hope - I’m not 100% sure what Kai and the guys are planning - they are a little resistant to some of my ideas :().

The dojo charting engine isn’t as good as Highcharts, but it’s actually still quite nice (it surprised me!). It supports quite a lot of configuration and I’ve got it presenting charts pretty nicely. It took a bunch of additional code, but again, it does have an advantage that it’s possible to code things a bit more flexibly. One thing I’m missing though is zoom/pan with the mouse so it’s something I need to look at.

I’m also trying to consolidate the rule editor. I’ve got the block editor running quite well, but I’ve also been discussing with the ESH guys the idea of supporting Javascript as a rule language. The current rules are a bit difficult to use (very picky on syntax and strongly typed) - the block editor removes a lot of this from the user perspective, but it’s a bit of a pain to code and the strong typing might make it a bit error prone. Within the editor I want to be able to ‘link’ the block rule designer and the code editor so that an advanced user could design a rule and convert it to source for advanced modification).

ZWave configuration will get an overhaul - instead of using a generic configuration list as I do now, I’m planning on allowing advanced editors within the GUI that have some knowledge of the data they are displaying - this allows them to present the generic config information in a more specific way.

I’m definitely open to ideas though. To me, having spent a couple of years with the Vera and got next to no response from MCV when there were problems, I’m really keen on the open source.

Cheers
Chris

It’s a work in process. Guessed sent me some notes that I still need to respond to. Been pretty busy the last few days and just had some time to configure the IDE setup for openHAB. I will be responding to Guessed notes soon. But right now we are just laying out the basics like defining the binding representation. And how to support the upnp service variables. Guessed suggested that we start looking / hacking how the XBMC binding in openHAB as it does something similar to what we need. The challenging part right now is just learning how it all works and grasping all of it.[/quote]At this point it’s rough.

I have the following:

[ul][li]a) The proposal/outline for what the bindings would look like.[/li]
[li]b) A codebase derived from XBMC, which gave me all the OSGi setup, build configs, config parsing and a rudimentary callout mechanism.[/li]
[li]c) openhab.cfg (config file) support for multiple Vera units.[/li]
[li]d) Periodic calling out to one or more Vera units, per config file and binding entries.[/li]
[li]e) Parsing of the above into JSON, but only printing out totals of #devices, #scenes (Etc) - not yet being pushed/advertised to the Bus itself.[/li]
[li]f) A Running OpenHAB Build, with the above bits inside it.[/li][/ul]

The initial version is focused on getting data from Vera into OpenHAB (inbound binding), to prove it out. Once that’s functional, we’d move onto making callouts from OpenHAB back to Vera, along with any complexities of binding non String/Number Item types (Switches, Dimmers, etc) to Vera devices (SwitchButton1, Dimming1, etc)

Once there’s something meaningful/useful, I’ll push it over into my Github account so others can contribute to it. Right now it’s more in the “how does this framework work?” stage), so progress has been slower than I’d hoped.

Let me know when you are ready for people to contribute @guessed. I have been messing with the rest API and adapting iViri to using openhab. Geofencing worked great and it is really easy to add virtual switches in openhab and build rules around those switches.

@jpete7683,
I’ll definitely keep you in the loop with updates. I just need to get it to a meaningful state, with maybe a demo, so I don’t waste people’s time 8)

Ok, so I finally got the code “crawling” and I can bind openHAB items to just about any property in Vera.

At the moment it’s for “read-only” purposes, but you can bind to the following types of things in a MiOS system:

[ul][li]a) Device State Variables (like the CurrentTemperature of a device)[/li]
[li]b) Device Attributes (like the IP address of a device)[/li]
[li]c) Scene State (am I running, etc)[/li]
[li]d) System attributes (like the ZWaveStatus of a given MiOS system)[/li][/ul]

It has a fairly standard poll-loop, so you’ll see value changes appear within openHAB within 10’s of ms. It’s basically acting as a Phone/Tablet MiOS client would, except that I only talk to “local” (on LAN) Vera units.

It’s [just] been floated to @garrettwp and @jpete7683 to try out and get some early feedback. It has no documentation just yet, so it’s not ready for broader try-out’s. I need to add support for “calling” a MiOS system, from within their Rule engine, as well as bi-directional bindings (so we can put Sliders atop Lights in Vera (etc)

Anyhow, just for grins, the attached image shows openHAB’s browser-client, running on my iPhone. It has data coming from the Weather Plugin and from @Chris’s original SysMon plugin.

@Chris, @guessed and all. Thank you for your work on this. One of my HP N40L microservers is used as a FreeBSD ZFS NAS and should have more than enough spare capacity to run as an OpenHab server. Although my Vera 3 is relatively stable, with the current flux in the HA playing field I am wanting a plan B in case Vera becomes a no longer viable option.

I have started testing and implementing the binding that @guessed is working on. I am very impressed so far, I am a Vera Lite user that moved everything over to a RPI with a z-wave chip, but what I am finding out about the child board is it isn’t as stable as the Vera Lite was when it came to just plan jane z-wave. I plan to move my z-wave network completely back to the Vera Unit and not install any plugins which will give me a stable Vera Unit again, and use the openHAB project to implement the binding and then it will bridge to any other system that is supported on the openHAB, plus I can achieve everything that the plugins gave me on the Vera side with rules in openHAB so I can keep that memory intensive stuff off of the Vera Unit and somewhat centralize on the RPI. I think you will be impressed with how nicely it integrates once @guessed adds the command and control functionality. I am personally impressed with just the reaction time to reading variables and the changes that occur.

I follow this topic too.

This solution requires, I imagine, to have a request sent to the Vera every xx seconds to have refreshed data.
What would be the standard refresh rate ? This will add a certain delay compared to the native Vera UI ?
Will it not overload the Vera (responding to these frequent requests) ?

It implements what is called a long poll it will open a connection with vera and wait until data has changed. Vera will return that data and the plugin will reestablish a new connection and wait for updated data. This is the same of what my app does as well as many others. Depending on the minimum delay set, the response can be instant or a few seconds.

  • Garrett

At the moment, I don’t use the minimum-delay feature, so it returns with data very quickly. In some cases, what would likely be a single “set” of changes from a Plugin will come back over the course of a few of these HTTP long-poll responses.

I can parameterize the minimum-delay, so folks can use it, but I haven’t seen the need yet. CPU load seems reasonable, and my graphs of memory usage don’t appear to show anything different.

Overall I’m not worried. I’ll use the transition as a mechanism to lighten Vera’s load overall, by removing the Automation elements (scene scripting) from it and, over time, Plugins.

My initial JSON response is about 700K, but the incremental ones are a lot smaller. I need to put some logging into the code to see how long it takes to load the initial, but the incremental loads are low-ms levels (according to openHAB debug logs)

Think of it as a Server-side implementation of this:
http://wiki.micasaverde.com/index.php/UI_Simple

The only downside I’ve seen to this is that the routine will return every second (on my machine) due to bugs in Vera’s JSON/status2 handler. Specifically, it’ll return that content has “changed”, even when it hasn’t, for some of my devices (appears to be isolated to Leviton Scene controllers).

I have 3x of them, and every second this call will return, showing me that the “status” has changed, as the [device] id will come back in any response:

07:27:18.524 DEBUG o.o.b.m.internal.MiosBinding[:573] - internalPublish: {mios="unit:house,device:145/id"}, value=145, bound 0 time(s) 07:27:18.524 DEBUG o.o.b.m.internal.MiosBinding[:573] - internalPublish: {mios="unit:house,device:145/status"}, value=-1, bound 0 time(s) 07:27:18.524 DEBUG o.o.b.m.internal.MiosBinding[:573] - internalPublish: {mios="unit:house,device:146/id"}, value=146, bound 0 time(s) 07:27:18.524 DEBUG o.o.b.m.internal.MiosBinding[:573] - internalPublish: {mios="unit:house,device:146/status"}, value=-1, bound 0 time(s) 07:27:18.524 DEBUG o.o.b.m.internal.MiosBinding[:573] - internalPublish: {mios="unit:house,device:144/id"}, value=144, bound 0 time(s) 07:27:18.524 DEBUG o.o.b.m.internal.MiosBinding[:573] - internalPublish: {mios="unit:house,device:144/status"}, value=-1, bound 0 time(s)