Should I leave Vera and go to OpenHab2?

Tags: #<Tag:0x00007faed92b8510> #<Tag:0x00007faed92b83d0> #<Tag:0x00007faed92b8290>

I am very frustrated with the pace of development with Vera and feel that they might be on the way out. At least they are currently in the process of coming out with their first firmware upgrade in over a year.
I’m interested in moving all of my devices onto OpenHab by using my VeraPlus as a bridge for all of my Z-Wave Devices. I’m interested in also adding a MQTT server, adding Sonoff devices, raspberry pis and Arduino microcontroller for different relay and sensor products.
One of the primary reasons for leaving Vera is to improve the cohabitation between different protocols in HA.

Determining Questions:

  1. Is this a really good time to go for it?

  2. Am I better off using it on a low power Unix Server (self-built) or virtually in Windows using the same computer that I use for my Plex Server or should dedicate a Raspberry Pi to it?

  3. How well does OpenHAb2 work If I have a bathroom, that has a zigbee sensor for humidity and/or a Zigbee sensor for occupancy) to use for turning my bathroom fan on and off for humidity, while at the same time controlling ZWave Lights using the zigbee occupancy sensor. I will also have LED’s controlled via the app and by using a Go-Control switch remotely controlling a Leviton dimmer controlling the AC-DC converter LED Dimming functions?

  4. Can I have all this work in harmony just by using OpenHab, meaning that all devices connected through different means work together just by using the OPENHAB App or a voice assistant like Alexa or Google Home?

  5. I guess what I really need to know Is if I have zigbee bulbs attached to Philips Hue Bridge I can still have them work together with Z-wave devices from Vera through scenes or environments?

  6. I picked OpenHab2 because I have read that the programming is a bit easier and when there is a firmware upgrade it doesn’t require as much time to reconfigure compared to an opensource platform like Home Assistant. Am I right about this?

  1. I think nobody can tell if it is the right time for you.
  2. Personally I prefer running openHAB on a dedicated server (Intel NUC here), a Raspberry Pi 3 will suit your needs.
  3. You can create Rules and Scenes to have interaction between the different technologies.
  4. Definitely Yes.
  5. Yes
  6. Upgrading to newer releases should not cause much effort/trouble, but sometimes can do.
1 Like

I agree with your answer to question 1.

Creating rules and scenes between different technologies is exactly what I want.
I predominately want to use mostly Z-Wave since I’ve already invested so much into it and the fact they work well together and help build out a mesh network. Zigbee is becoming ever more present in the US. In order for it work with Vera we are at there mercy to write a driver for proprietary ZigBee Devices. Knowing that I can do so much more with OpenHab is really looking like I’m more convinced than ever to switch and just use my vera as a Z-Wave Bridge.

Keep in mind that you don’t have to commit to the switch. If you want to test openHAB, set it up on a Windows PC to mess around with and determine if you like it before installing on a Raspberry Pi and disabling your Vera rules.

Honestly, I don’t think you’ll go back. I have TP-Link switches/plugs, Belkin plugs/sensors, Logitech Harmony Hubs, and Google Homes & Chromecasts, all of which are wifi and all of which can be combined in rules to varying degrees. Last week I added a UPS that OH can monitor, and I’ve just ordered a Z-Wave dongle and multi-sensor, knowing that I’ll be able to use the sensor readings to trigger the wifi switches.

Also, with openHAB you don’t have to upgrade when a new version rolls out. And if you do, you can make a backup of your current installation.

1 Like

Thank you to all of you who have answered me so far. Rpwong…that sure is an assortment of devices that you have. I like the UPS add-on also. I love the in-wall customization I have seen so far with touchscreen units. I am a strong believer of building-out your Home Automation System by using patience and waiting for devices to go on sale. I never even considered TP-Link switches and plugs, but they are a much cheaper alternative for just on and off appliance switching.

While I make an attempt to get OpenHab started, I am in the planning phase of installing an irrigation/sprinkler controller using an arduino board and relays to control my 24V existing system. It looks like there is more flexibility and options available through OpenHab compared to Vera. I love the fact that there are bindings for WI-Fi Based systems, so I can get a rebate from MWD Water in SoCal for buying an accepted irrigation system. This would be faster and the device has a warranty.

I originally used all Belkin Wemo stuff, but after years of frustration with crappy firmware and bad support, I moved to the cheaper and more reliable Kasas. The only Belkins I have left are a motion sensor and a Wemo Maker, which I use on my gas fireplace. Also, TP-Link stuff goes on sale frequently in Canada.

If I could afford it, I would have used Z-Wave or Zigbee switches/plugs, simply because these protocols don’t rely on wifi and consume less power.

As for the UPS, I recommend it for reducing the risk of corrupting the SD card in an RPi due to loss of power. I might write a tutorial about it if I can find the time in the near future (and before I forget how I did it).

Low power usage is a very important asset to Z-Wave’s usefulness. I also love the fact that it stays out of the 2.4 GHz spectrum. There is just too much going on in unlicensed WiFi RF Zone. I always use cabling whenever I can for all network connections for that very reason. I had to look up “…Kasas”. It’s the name of the App for TP-Link. I was looking it up thinking it was some new IOT HA device or family of devices I hadn’t heard about until you wrote it. Hehehe!

Oops, sorry. Thought I wrote “TP-Link Kasa switches” earlier.

When you look at the bindings and add ons available to OpenHab it looks like a Smorgasbord of Home Automation devices on a buffet platter that OpenHab will work with. It’s kind of like the first time all of us had our first experience at the Apple App store or the Google Play Store. I couldn’t wait to get all of those Apps installed. I I have to make sure I take a very tempered and patient approach to ensure I don’t get ahead of myself.

I am going to concentrate on command and control of all the newly connected devices and ensure they all work with Google Home and Amazon Alexa, before attempting to create scenes and different programming functions.

I’ll preface with the obvious. You are asking an openHAB forum whether you should move to openHAB. You are unlikely to get unbiased answers. Though we are a pretty open minded bunch and not so partisan to deliberately steer you wrong.

  1. I don’t know, is it?

  2. The best hardware to run OH on is what ever hardware you already own. But note, both Plex and OH will want to share the network discovery port (5000 I think) so you might encounter some issues there. Most users dedicate an RPi to OH.

  3. That’s almost the total raison d’etre for OH in the first place. Bindings expose devices as Things. Each sensor reading or control point on that device is represented as a Channel. Channels get linked to Items. Everything else in OH operates on Items. So your Rules, your UIs, your persistence have no idea what technology the Item is actually controlling/getting sensor readings from. That’s where the power comes from. For instance, I have two Zwave outlets with lamps plugged in, one zwave wall switch, one Shelly1 behind a wall switch, and three Sonoff Basics connected to lamps. As far as OH is concerned, these are Switches in my Lights Group and I can control them all the same, or have all the Sonoffs turn on when the Zwave switch turns ON.

  4. Probably. I’m not up to speed on how the Harmony binding works. But I’ve some advice below that is worth considering. Theoretically the answer is yes. OH doesn’t care where the commands come from or where they are going to so long as they are represented by Items.

  5. Yes, absolutely. That’s what OH does.

  6. I have no experience with Home Assistant so I can’t answer. The Rules DSL, the language of OH Rules, is a simplified language and it is pretty easy for non-programmers to pick up. There are tons of good examples on this forum and loads of people willing to help as well. But if you are a programmer already, you will probably find Rules DSL to be a nightmare. Luckily, there are several other options available to you including NodeRed, or JSR223 Rules which lets you write OH Rules using a “real” programming language like Jython, JavaScript or Groovy.

The longer you wait to upgrade between versions the more work it will be for you all at once. But usually, the upgrades between minor versions (e.g. 2.3 to 2.4) are relatively minor work for most users. But there are always breaking changes so upgrades almost always require a little bit of work. The known breaking changes are always listed in the update announcement. But you can do the upgrades on your own time. Major upgrades (e.g. between 1.8 and 2.0) require a significant amount of work but it is impossible to predict how much.

I’ll weight in as this is something that I tackled a couple years ago, and I’ve been running the OH / Vera combination since then. Here are my thoughts on some comparisons and how they play together…

Overall, I’ve been very happy with OH. I started with 1.8, migrated to 2.0 (big improvement) and have been upgrading steadily since. Upgrades have been pretty painless since the switch to 2.0. I upgraded from 2.3 to 2.5 snapshot last week with very little pain for instance.

When looking at capabilities of the systems, there’s really no comparing OH & Vera. While the vera is pretty limited in it’s rules capability (and they create a lot of reliability issues due to the resources they consume), OH is pretty much wide open. The rules engine is pretty good, and I’ve never needed to add scripting, etc. on top of it for even more HP, but it’s there if you ever need it. I run my OH in a virtual machine on an ESXi server, but you can get by with much less computer than that. Pis are popular, but I wanted something with more computing power and more storage for persistence.

Visually, the Vera is pretty limited comparatively as well. In my experience, you’re stuck with 3rd party solutions (I used ImperiHome back in the day). I’m a very big fan of Habpanel. Very flexible and has been able to do everything I’ve wanted. If you like Imperihome or similar apps, most will work with OH too.

Persistence is another big difference. While Vera uses a flash drive for limited storage, OH actually uses real databases (with multiple options depending on need). I use MapDB for everything (records last state) and InfluxDB for the things I want historical data on or charts of (using Grafana).

Regarding the OH / Vera combination, they work pretty well together. The Vera binding is still a 1.x binding, but it works fine with 2.x - you just configure with a file instead of graphically the IP address, etc. of the Vera, nothing hard. There’s a couple sh files that allow you to port over all devices into items easily, so you can have the combination running very quickly. I have seen the Vera and OH stop talking briefly every once in a while, but as best I’ve been able to tell, the issue is with the Vera, not OH. It hasn’t really impacted anything, but it’s worth noting.

Since I’ve made the switch, all I use the Veras for is as a ZWave adapter - I do everything else in OH. Last week, I’ve had one of my two Veras die (3rd one I’ve had die over the years), and I’m not replacing it. The OH ZWave binding now supports security protocol, so I have no need for the Veras any longer. I’m switching to a PI with a Zstick as a remote adapter for OH, similar to the way I was using the Vera. In my testing over the past few days, it seems to work well.

I hope my ramblings helped…

Danny

I have a similar set up to you (use Vera to bridge to Zwave security devices, before security was supported in the current Zwave binding), etc.

I will give you my thoughts:

  1. Openhab is very, very hard to learn. I know, it doesn’t look it, but I’m an engineer that has been using OH1/OH2 for 3 years or more, and it still confuses the hell out of me.
  2. OH is very unforgiving. any minor error will break your entire system. A missing ) and your entire system comes down. Trying to find the missing ) can take hours because
  3. The debugging tools are poor, and error messages are obscure.
  4. The programming language is a sort of not-java that no-one knows, so you will have to learn it, and the documentation is non-existent. You have to find out how it works from experts on the forums, and previous examples (which are a godsend).
  5. Documentation is not OH’s strong point, so there are lots of old documents out there about OH, most of which are out of date, hence wrong, and so don’t work.
  6. The development of OH is active, which can be a good thing, but also means that the volunteers are busy ripping out things that work, and adding new things (that may not). This can be a bit of a surprise when something that used to work for years now no longer does. Complaints about these events are not well received.
  7. OH recently lost it’s leaders, and is now casting around for a direction. One of the proposed plans is to remove support for OH1 bindings (this is a large amount of the interoperability you were looking for). The reply to people who question the plan to remove 50% of OH2 functionality has been “you could run two copies of OH, old and new”.

So why use OH if it’s such a pain? because it’s the only thing out there that does what it does, and can do it well. So you have to learn the weird not-java, put up with difficult debugging, expect your system to go down with every release, unless you run snapshot releases (in which case you find out about the breaking changes as they happen), and deal with the European centric attitude (“the fix is not a priority that breaking change only affects North America” - from the last release).

Is this a good time to move to OH? I would say no, as the current plans are to do away with most of the functionality in the next release, and OH is currently leaderless.

I am waiting for the next release, If OH1 binding are gone, then I will have to rethink my whole HA strategy, as a lot of my automation is based on Insteon, which is an OH1 binding, and no-one is going to re-write all those working OH1 bindings.

If you look through the list of bindings, and find that you can get away without OH1 bindings, you may as well go for it (but the Vera interface is an OH1 binding, so you would have to move all your ZWave devices to OH - not easy), but be prepared for major changes that come with leadership vacuums.

OH3 may emerge triumphant or commit suicide, the jury is still out at the moment.

  1. This is why we strongly recommend using VSCode with the openHAB extension. It will tell you about the missing ) as you type. And to be fair, there isn’t any language I know of that is able to give meaningful errors for missmatched parens or brackets.

  2. Error messages and checking is improving but still a problem for sure.

  3. Or skip it and use JSR223 rules and code in Python, JavaScript, or Groovy. If you have even the slightest programming experience, I strongly recommend going this route.

  4. If you point to any page in the official docs that is out of date, someone will fix it immediately. If you are referring to the form postings, well a forum is not documentation and one should not expect old forum postings to be updated. They are correct at the timer they are written. Beyond that, caveat emptor. If you are referring to tutorials written by third parties, we have no control over those so it is unreasonable to expect us to keep those up to date.

  5. OH definitely has a problem with understanding the full implications of some changes. But all known breaking changes are published as part of the release notes. Pointing out where there is an unintended consequence is usually well received. However, when we see the 15th or 20th passing saying the same thing and berating the developers and helpers on the forum we can indeed get a little miffed. Also, realize that this is a community effort. No one person speaks for OH. Everyone is a contributor and can speak from their own opinion and experience and no more.

7.? This statement is not factually correct. All the main “leaders” are still leading OH development, as far as any open source project is lead. But indeed, the people who are maintaining the code no longer want to maintain that compatibility layer. This is an open source project 100% supported with volunteer labor. No one can force anyone to work on something they don’t want to work on. Slavery has long since been outlawed. If anyone wants to preserve the compatibility layer, step up and become a contributor it find someone to become a contributor to maintain the compatibility layer. Otherwise, yes, the compromise is to run two OH instances and federate them, which frankly little different from what people who run zigbee2mqtt are doing. And it’s will worth noting that the decision to remove the compatibility layer hasn’t even been made. It’s just a proposal. We can continue to relitigate this ad nausium but the fact remains, someone must volunteer their labor to do the work. No volunteers, no compatibility layer.

See above, and it’s also worth noting that the Rules DSL is likely going to become deprecated in OH 3 in favor of the JSR223 languages. Deprecated doesn’t mean support is going to be dropped, but it will no longer be the default. If you are just getting started and have even the smallest bit of programming experience, I strongly suggest not using Rules DSL. If you do not have such experience, getting started with Rules DSL would still be my recommendation, at least until some PRs get merged to make using JSR223 a little easier.

The milestone releases are a good compromise. Usually those come out once a month and are free from known problems.

Perhaps that would change of there were any North American contributors to the code. To my knowledge, there is Dan who runs the web sites including myopenhab.org and myself who limits himself to contribution on the forum.

OH is not leaderless, the leader has decided he doesn’t want to donate his time single handedly maintaining the compatibility layer. Anyone can step in and take over and all will be well.

And the next release is well over a year away.

And all that has happened this far is conversation about removal of the compatibility layer. No decision had been made. But if no one steps up to maintain it, that in itself will become a decision.

You can have all the leadership in the world, butt in as project like this the only way anything gets done is if someone volunteers their labor to do the work. And that is what we are really talking about here.

And yet I’m aware of at least one effort to in fact write a 2.x Insteon binding.

I’m not really expecting anyone to do anything, just giving my perspective as a long term user of Openhab - and it’s not all hearts and flowers - but then what is?

I’m interested in the Insteon 2.x binding though, that could solve a lot of my problems, I have been working on an Insteon to mqtt project (python based) with some other users as an interim workaround, but a native binding might be better. Do you have a link to it? I have been looking for such a thing, but haven’t found it.

Nick.

Unfortunately it started to gain stream in a thread that was initially focused on another subject. I did find these threads:

but none of these are the thread that I remember reading where some real collaboration is taking place. Perhaps the link to the github repo in the second link will lead you to them.

I’m been on openhab2 for 2 weeks. I’ve encountered all tIypes of stumbling blocks. My goals are to eventually create all types of scenes and advanced configurations, but in order to get to that point my desire is to strictly address controls of all of my primary devices, especially my Z-Wave Devices.

I want to get that set-up and then address the HabPanel for my tablets and phones and really want to get the system integrated with Amazon Echo and Google Home. I’m coming from Vera, so all of this coding and textual interfaces are kind of overwhelming, but I know if I keep working at it the learning curve will be more tolerable.

I created a premliminary Zwave.items file and it is not showing up in Paper UI. I did compile some Astro binding things and that is working so far.

Can anybody tell me what I should configure first?. It seems that Things, Items and Sitemap all work in harmony and needed to be configured as you go in parallel.

Is there a way to observe the configuration files for the demo openhab just so I can see how my stuff correlates with it?

I’m mostly using openhabian through putty to configure my files. I’ve also already experimented with Visual Source Code with the Openhab plug-in, but I’m unable to save the files to my raspberry pi. What is cool is that I have the folders within the configuration folder present on the Visual source program, but that doesn’t help because I still can’t write to it.

Indeed. This is discussed in the Concepts section of the docs but at a high level:

  • Things represent devices and are the interface between the rest of OH and OH 2 bindings (from the user’s perspective). Each piece of data (sensor reading) and each thing you can control (actuator) on a given device is given a separate Channel.

  • Items are where you model your home automation. It’s where you give devices a meaningful name and describe how to interact with that device. For example, I have a Thing zwave:device:dongle:node4 with a switch_binary Channel. I will Link this Channel to a Switch Item named FamilyRoomLamp. By using a Switch Item I’m indicating that this device can be switched on or off but it’s not a Dimmer where I can control the brightness. The name is self evident; the Switch controls the lamp in the family room. Items are the coin of the realm. Pretty much everything else that you do within OH from a user’s perspective is going to be done using Items.

  • Sitemaps are one way to build a user interface for your bespoke home automation. Sitemaps can only be created using Items. This is opposed to PaperUI which is a configuration and administration UI.

All of the above applies to OH 2. However, there are a number of OH 1.x version bindings still in use. The concept of Things was created in OH 2 so OH 1.x bindings work differently. There are not Things or Channels. Instead there is a binding config that you apply to each Item instead of a Link to a Channel. There is pretty much nothing that you can do with OH 1.x bindings in PaperUI.

So the order that you integrate a new technology like Zwave which has a 2.x version binding is as follows:

  1. Install the binding

  2. Read the binding’s docs for details about how the binding works

  3. If necessary, manually create the Bridge Thing. A Bridge Thing is a special type of Thing that represents the connection that the binding goes through to reach the devices. In the Zwave case, you need to manually create a Serial Zwave Thing and configure it to use the serial device of that represents your Zwave dongle (e.g. /dev/ttyUSB0). For MQTT2 you would manually create an MQTT Broker Thing with the connection information. Not all technologies have or require a bridge, see the individual binding’s readme.

  4. Once you have the Bridge Thing, usually the rest of your Things can be automatically created. Open the Inbox in PaperUI and if it isn’t already discovering new devices you can click the scan icon and force a scan. In the case of Zwave, all the devices that have been paired with the controller will appear. Accept the Things from the Inbox and they will become part of your configuration.

  5. Each Things has one or more Channels. For those Channels that you want to use an Item needs to be created (of the correct type, the Channel entry in PaperUI will tell you what type of Item you need) and that Item Linked to that Channel.

  6. Once you have the Item Linked to the Channel, you can use the Item to build sitemaps, save the data to persistence, or write Rules.

A note about PaperUI. PaperUI is only for configuration and administration. The Control tab in PaperUI will only show Channels from Things that have been Linked to an Item. Items created that are not linked to anything will not appear. Group Items will not appear. Items bound to OH 1.x Items will not appear.

To the extent that there are files you can look at and easily understand from the Demo config, they will be in /etc/openhab2. However, stuff that is created through PaperUI get stored in a database. It’s a text based database you can look at in /var/lib/openhab2/jsondb, but it’s a bunch of JSON which isn’t all that human friendly.

There might be something off with the Samba config that shares the files.

Quick History since my last post. I’m somewhat addicted to Openhab. My only programming background was in C. I do realize that this code isn’t as stringent, but was shocked to find my items file was getting denied because I left out one space inside of a parenthesis. The line identifiers in the log helped me identify it.
I’ve broken-down and built up my files until I was able to do everything using the items file.

I’ve been using the Visual Studio Code Editor to create many of my files.

Do I declare group ownership in the items files, like I’ve been doing, or do you declare it inside of your sitemapping file?

Also,do I need to declare my groups on the same line. I was thinking that the compiler would not be able to identify the group name within the title of a item’s name.
This is how I’m going. My Sensor isn’t working, but at least it is compiling.

/* Lights */         
Dimmer   Sink_Light_Brightness_FF_Kitchen       "Brightness"            <slider>    (FF_Kitchen)    {channel="hue:0220:ecb5fa0450f0:1:brightness"}
Dimmer   SinkLightColorTemperature_FF_Kitchen   "Color temperature"     <slider>    (FF_Kitchen)    {channel="hue:0220:ecb5fa0450f0:1:color_temperature"}
String   SinkLightAlert_FF_Kitchen              "Alert"                 <slider>    (FF_Kitchen)    {channel="hue:0220:ecb5fa0450f0:1:alert"}
Switch   SinkLightEffect_FF_Kitchen             "Color loop"            <slider>    (FF_Kitchen)    {channel="hue:0220:ecb5fa0450f0:1:effect"}
Dimmer   DeskLampBrightness_FF_MilasDesk        "Brightness"            <slider>    (FF_MilasDesk)  {channel="hue:0100:ecb5fa0450f0:2:brightness"}
String   DeskLampAlert_FF_MilasDesk             "Alert"                 <text>      (FF_MilasDesk)  {channel="hue:0100:ecb5fa0450f0:2:alert"}
Dimmer   ShowerLightSwitchDimmer_BD_Toilet      "Dimmer"                <slider>    (BD_Toilet)     {channel="zwave:device:faea2ff6:node4:switch_dimmer"}                                                 
Dimmer   DiningLightSwitchDimmer_FF_Dining      "Dimmer"                <slider>    (FF_Dining)     {channel="zwave:device:faea2ff6:node8:switch_dimmer"}
Number   DiningLightSceneNumber_FF_Dining       "Scene number"                      (FF_Dining)     {channel="zwave:device:faea2ff6:node8:scene_number"}
Dimmer   FamilyRoomLightSwitchDimmer_FF_Family  "Dimmer"                <slider>    (FF_Family)     {channel="zwave:device:faea2ff6:node7:switch_dimmer"}
Number   FamilyRoomLightSceneNumber_FF_Family   "Scene number"          <slider>    (FF_Family)     {channel="zwave:device:faea2ff6:node7:scene_number"}
/* Sockets */


/* Sensors */
Number          Temp_BD_Toilet          "Temperature: [%.1f °C]"        <temperature>   (BD_Toilet)        {channel="zwave:device:faea2ff6:node3:sensor_temperature"}
Number          UV_BD_Toilet            "Luminance: [UV index %d]"      <light>         (BD_Toilet)        {channel="zwave:device:faea2ff6:node3:sensor_ultraviolet"}
Number          Lumin_BD_Toilet         "Luminance: [%.0f Lux]"         <light>         (BD_Toilet)        {channel="zwave:device:faea2ff6:node3:sensor_luminance"}
Number          Humid_BD_Toilet         "Humidity: [%.0f %%]"           <humidity>      (BD_Toilet)        {channel="zwave:device:faea2ff6:node3:sensor_relhumidity"}
Switch          AlarmMotion_BD_Toilet   "Motion alarm"                  <motion>        (BD_Toilet)        {channel="zwave:device:faea2ff6:node3:alarm_motion"}
Number          Alarm_BD_Toilet         "Alarm: [%s]"                   <alarm>         (BD_Toilet)        {channel="zwave:device:faea2ff6:node3:alarm_tamper"}
Number          Battery_BD_Toilet       "Battery: [%d %%]"              <batterylevel>  (BD_Toilet)        {channel="zwave:device:faea2ff6:node3:battery-level"}


In the .items file. The Group element on sitemaps is a way to put all the members of a Group on the sitemap using the default settings. I don’t recommend it’s use because you have no control over how the Items are displayed.

Each Group needs to be declared one it’s own line. A Group is just a special type of Item so it must follow all the same syntax rules as Items. See https://www.openhab.org/docs/configuration/items.html#groups

You must declare a Group before you can add an Item as a member of the Group.

2 Likes