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

@Guessed

“when values change in Vera, they’ll be automatically reflected in openHAB”

Seems all OK now - it’s a question of what gets updated when and if it’s done automagically. So for example a change in the items file, describing an item, will update very quickly in the associated web page; ditto for the sitemap file. However the actual values can take a while to update. May be old ground but is there someway of manually forcing OH to update from Vera? So when you add in a new item you can get its status updated asap. I’m on 1.6, so this may have changed in recent time. Any advantage in 1.7 at the moment?

Another trap is the demo rules file, fills all the temperatures with random values for the demo - that had me going for a little while. :-\

Saw your mention of the Odroid boards. Was wondering why you chose the ODroid C1 over the ODroid U3 used by ap? It’s a moveable feast: Cubieboard3/Cubietruck looks like a goer and the upcoming Cubieboard4 also looks good. Suppose it’s a question of time & money.

Board comparisons

@Aaron
I thought the EVL3 might handle at least five connections. OK then - it’s either a proxy or use the OH DSC binding. Is it compatible with Guessed’s great Vera DSC plugin?

There are a couple of people on the forum currently using the proxy, therefore, yes. I added some info

http://forum.micasaverde.com/index.php/topic,29635.msg210698.html#msg210698

And… From the Eyez-on forum.
http://forum.eyez-on.com/FORUM/viewtopic.php?f=6&t=544&sid=fbc77c2dadd5960b05c87124aaebe84a

[quote=“a-lurker, post:292, topic:181558”]“when values change in Vera, they’ll be automatically reflected in openHAB”

Seems all OK now - it’s a question of what gets updated when and if it’s done automagically. So for example a change in the items file, describing an item, will update very quickly in the associated web page; ditto for the sitemap file. However the actual values can take a while to update. May be old ground but is there someway of manually forcing OH to update from Vera? So when you add in a new item you can get its status updated asap. I’m on 1.6, so this may have changed in recent time. Any advantage in 1.7 at the moment?[/quote]

So the 1.7 version of the MiOS Binding has the latest changes, particularly the stuff resulting from @lolodomo’s usage feedback here.

The main changes are:
a) More automated conversion of openHAB DateTime Items sourced from MiOS Epoch time strings.
b) Better handling of Item changes when MiOS Engine restarts (previously this would re-trigger rules)
c) Additions to the list of UPnP Service Aliases that can be used instead of having to use the fully spelled out versions.

More discussion on the details of these is contained in the above threads.

To upgrade to it, you only need to DELETE the existing [tt]org.openhab.binding.mios-1.6.0-SNAPSHOT.jar[/tt] from the OH/addons folder, and put in the newer [tt]org.openhab.binding.mios-1.7.0-SNAPSHOT.jar[/tt]. You can continue to run the reset of the 1.6.x openHAB, there’s no need to tweak that (I certainly don’t)
.
… and restart.

The one “main” update problem that’s left occurs when editing the item files. When this is done, openHAB is triggering a repository reload, which throws away the current value of each of the items and/or restores them from the Persistence layer (it’s been a while, I can’t remember which) but there’s obviously no value for “new” Items, and won’t be until they change.

This is noted above in @lolodomo’s comments. Once you get a stabilized Items file, you don’t see this anymore, but I know that takes a while to get there (you can also generate it using AP’s Lua utility)

Saw your mention of the Odroid boards. Was wondering why you chose the ODroid C1 over the ODroid U3 used by ap? It's a moveable feast: Cubieboard3/Cubietruck looks like a goer and the upcoming Cubieboard4 also looks good. Suppose it's a question of time & money.

Board comparisons

I like a challenge. I know I can buy a ($70) ODroid U3, and it’ll work just fine, but I also like to try new things, and the ($36) ODroid C1 is a good fit for that :wink: Worst case, if it doesn’t pan-out, it’s not that much to buy the U3 (or an XU3 Lite) and reuse the C1 as a syslog server… It’s also handy that they ship locally from NoCal (ameridroid), so delivery is ~1day.

Realistically, like a RPi, both need a number of bits before they become really practical.

[quote=“guessed, post:294, topic:181558”]So the 1.7 version of the MiOS Binding has the latest changes, particularly the stuff resulting from @lolodomo’s usage feedback here.

The main changes are:
a) More automated conversion of openHAB DateTime Items sourced from MiOS Epoch time strings.
b) Better handling of Item changes when MiOS Engine restarts (previously this would re-trigger rules)
c) Additions to the list of UPnP Service Aliases that can be used instead of having to use the fully spelled out versions.[/quote]

You forgot to mention
d) Fix for strings containing non ASCII characters
:wink:

Isn’t it possible that you simply apply the same treatment as when openHAB is starting, that is fetching all values from the Vera ?

I just discovered the voice control from HABdroid. Just do quick tests and the variacle VoiceCommand seems to be set correctly in my natural language 8)
So it remains to define my syntax and analyze the string in an openHAB rule.

I like the idea to not have a fixed syntax or something forced in english 8)

Any good (or bad) experience using voice control from openHAB ?

Hi all !

This is a very great job, and I really want to give it a try !

I just downloaded the lastest stable version of OpenHAB 1.6.1, and there is already a mios binding to the addon archive.

Must I use the one included into the addon archive or the one in this link ? : https://app.box.com/s/fbmp3b11sx3b9mtwxui5

Thanks for this work !

[quote=“macfly92, post:298, topic:181558”]Hi all !

This is a very great job, and I really want to give it a try !

I just downloaded the lastest stable version of OpenHAB 1.6.1, and there is already a mios binding to the addon archive.

Must I use the one included into the addon archive or the one in this link ? : https://app.box.com/s/fbmp3b11sx3b9mtwxui5

Thanks for this work ![/quote]

Hi @macfly

The version available @ https://app.box.com/s/fbmp3b11sx3b9mtwxui5 is a recent patched version produced by @guessed for me to test few fix/enhancements.
I think the right place to download the last official Mios binding version is in the openHAB nightly builds. @guessed provided the right link few messages before.
But I am still running the version downloaded from app.box.com !

Thanks you Lolodomo.

I saw Guessed talked about a documentation, but I wasn’t be able to find it.
I’m reviewing the 20 pages posts to find how to declare items :slight_smile:

[quote=“macfly92, post:300, topic:181558”]Thanks you Lolodomo.

I saw Guessed talked about a documentation, but I wasn’t be able to find it.
I’m reviewing the 20 pages posts to find how to declare items :)[/quote]

openHAB wiki page: Home · openhab/openhab1-addons Wiki · GitHub
MiOS binding wiki page: MiOS Binding · openhab/openhab1-addons Wiki · GitHub

In the Micasaverde wiki, there is a page ( http://wiki.micasaverde.com/index.php/OpenHAB ) with a lua script allowing to build initial files from the Vera setup. That could be a good start point.

Then openHAB 1.x requires time to understand and adjust config files for personal UI and rules. The openHAB wiki can help a lot for that. For rules, that is not always easy to know what can be done and what cannot be done, or what syntax to use.

PS: discussion in french still possible in the “other” forum :slight_smile:

Yeah I have already a OpenHab setup that handle my Philips HUE lights. It is a bit tricky :slight_smile: It is for testing purpose ATM.

Thanks you for infos Lolodomo, this is a good start !

Isn’t it possible that you simply apply the same treatment as when openHAB is starting, that is fetching all values from the Vera ?[/quote]

Yes, and no. I use RRD for persistence, and it looks like some things (dates?) aren’t persisted correctly. If I rerun the entire sequence then those will get reloaded, which might trigger their Rules…

Still thinking about the right way to do this. I may do it that way, but to avoid the RRD persistence bug I’d prefer something with a more localized impact.

In my case, I don’t apply persistence on most of my items, I only use persistence (rrd) for few items like temperatures & humidities for which I want to display charts.

[quote=“lolodomo, post:299, topic:181558”]Hi @macfly

The version available @ https://app.box.com/s/fbmp3b11sx3b9mtwxui5 is a recent patched version produced by @guessed for me to test few fix/enhancements.
I think the right place to download the last official Mios binding version is in the openHAB nightly builds. @guessed provided the right link few messages before.
But I am still running the version downloaded from app.box.com ![/quote]

If you’re using the cloudbees version, sometimes you’ll have to navigate the current builds in order to get to the 1.7.0 version (vs the 1.6.1 version). There are “Build History” links on the left that can be used to page through the latest build sets:

https://openhab.ci.cloudbees.com/job/openHAB/

The Box.net version doesn’t have some of the latest changes, mostly minor stuff, but it’s missing things like the new ServiceId aliases (openHAB PR #1909)

It appear that modifying item’s file while OpenHAB is running load the new items but destroy all the Vera status until the state of each item changed.

Maybe try to restart OpenHAB after editing the items file, because the Vera’s states are correctly loaded at startup.

guessed,

Thanks for the information on the Odroid C1. I have been eyeing it for some time. Right now I have been running my OpenHAB test instance on a VM which is working well. I may move it over to something more dedicated. My OpenHAB instance is no where near production ready. I still have a lot to learn and am currently working on writing getting my ISY controller integrated.

For the ISY integration, I am not writing a direct plugin for OpenHAB. Since OpenHAB2 changes how the plugins work and I do not have time to figure out how the plugins work in OpenHAB1, I will be writing separate code to tie it in. The code will be written in node.js and communicate via mqtt. I have a proof of concept running and listening for events on the ISY and passing them along to mqtt which is running on the same instance as OpenHAB. I then have OpenHAB listen to messages via mqtt. So far it looks very promising. I now have some code that will take commands from OpenHAB and pass them to the ISY via mqtt and the ISY rest api. Right now I am struggling with mappings in OpenHAB and trying to figure out the best way to handle some of the controls. As soon as I have something decent I will be posting the code for others to use.

Hopefully I can get the rest of my OpenHAB instance running with rules etc and just have my vera act as a zwave gateway and all other functions via OpenHAB. I may be picking your brain a little on thoughts / opinions for my ISY tie in and the inner workings of OpenHAB.

  • Garrett

Aha, gotcha. Is it possible this could also further enhance the viability of a dimmer switch having an on/off/dim level setting? I know we would likely still need a mapping for the dimmer, but it makes me think I could add 2 buttons to a single line or choose a percent item, allowing me to turn on/off and set a dim level with a single item? In this case allowing something other than just a Dim level being called to a dimmer? I really wish OH would plumb in this capability to simply map 2 devices to a single item, or a single sitemap item at least for dimmers rather than 2 switches. Same boat with the arm/disarm trip/untrip of motion sensors, contact sensors, etc.

I guess these are complaints of a strictly ZWave compliant HA setup vs the vast majority of integrations for bindings others are using. :wink:

[quote=“shmixx, post:308, topic:181558”]Aha, gotcha. Is it possible this could also further enhance the viability of a dimmer switch having an on/off/dim level setting? I know we would likely still need a mapping for the dimmer, but it makes me think I could add 2 buttons to a single line or choose a percent item, allowing me to turn on/off and set a dim level with a single item? In this case allowing something other than just a Dim level being called to a dimmer? I really wish OH would plumb in this capability to simply map 2 devices to a single item, or a single sitemap item at least for dimmers rather than 2 switches. Same boat with the arm/disarm trip/untrip of motion sensors, contact sensors, etc.

I guess these are complaints of a strictly ZWave compliant HA setup vs the vast majority of integrations for bindings others are using. ;)[/quote]

The openHAB SiteMap UI will still restrict you to one-item-per-line, and that Item can only have a single-value at any time (well, except Color, where it has RGB).

This is more about needing to call things, like Say, via a script where the “binding” can’t [natively] handle that it has more than one parameter that might need to be bound to the arguments (or that it would be convoluted if it did)

I am proud to announce that I have been running stable for a little over 4 months using this binding. I originally used the razberry board but realized that the Vera Unit has a much better z-wave chip in it. This binding has allowed me to take a once crashing VeraLite with all of the automation loaded on it, split the automation onto an ubuntu system and just keep z-wave components on the VeraLite. I am now 4 months and running without a single crash on the Veralite and without any issues to speak of with the vera openhab binding. Amazing work @Guessed!

Folks,
We now have a dedicated openHAB MiOS Binding sub-forum for this discussion, so I’m going to lock this thread while I (mostly) pull it apart into the relevant sub-threads.

Please feel free to post new threads in the [above] openHAB MiOS Binding sub-forum, or to contribute to the ones already there.