openHAB2 and Z-Wave - Recommended combo?

Add-ons Bindings
1

I have been playing around with openHAB2 for a while now to get a feel for the state of the system. In general I think it looks very good, however, I have had limited success with Z-Wave so far. I started out thinking I would go all-in, meaning using only new stuff (openHAB2, zwave 2.0.0, HABmin2, etc.).

Things seems to work more or less (I have only tested line-powered devices so far, as battery powered devices are a little tricky in general), however, I found that devices that were already included in the network and configured stopped working or exhibited strange behavior after moving my zwave controller to the openHAB2 setup.

Anyway, searching and browsing the forum I get the feeling that there is some kind of subtext stating that the most stable setup pt. is openHAB2 core + 1.x bindings.

I therefore did a clean install of openHAB2, enabled the legacy 1.x binding support, and installed the zwave-1.9.x binding, hoping that this would make things better.

I am now stuck on something as basic as how to configure the devices? As far as I can see HABmin2 will not work since I am using the old binding, and I cannot see any way to install HABmin1.

Any pointers on how to proceed are appreciated.

I would also like general comments on what combination of openHAB2 and versions of bindings you find works best.

2

The REST API for OH 2 is different from OH 1 so I don’t know if this is possible. Assuming it is possible I would imagine you could use the OU 1.x compatibility layer and put the stuff that goes in webapps for OH 1.x into the html config folder. Though I’ve no idea if that would work properly or not. Just guessing.

I’m using and happy with the following. The only problems I’ve run into with any of these bindings were caused by limitations from running OH in a Docker container.

  • Astro 1.9
  • Exec 1.9 (installed but no longer using since moving to a Docker container
  • HTTP 1.9
  • MQTT 1.9
  • Nest 1.9
  • Network Binding 2.0 (not using because I can’t figure out how to give the Docker container the correct rights to the network without running as root)
  • NetworkHealth 1.9 (will be moving off of this soon now that I have dd-wrt and can move the detection to that)
  • NTP 0.9? (I don’t really use this and probably will eliminate it)
  • Zwave 2.0
  • Pretty much all of the UIs except CometVisu (I find CometVisu fancier but not necessarily more user friendly)
  • InfluxDB 1.9
  • MapDB 1.9
  • RRD4J 1.9 (I’ll likely drop RRD4J in the near future)
  • Mail Action 1.9 (I don’t use this and probably will eliminate it)
  • I’ve been using the old and manually installed NotifyMyAndroid Action with the 1.x compatibility layer but now that it is listed as official I need to move over to the Karaf managed install)
  • I used Pushover for awhile without realizing that they completely cut you off after 30 days without paying. :expressionless:
  • All the transforms except Exec, Scale, and XPath.
  • my.openhab 2.0

I’ve not had any different of an experience with the OH 2.0 Zwave binding than I did with the 1.x binding. I’m sorry to hear you are having problems.

1 Like
3

Thanks for a quick and extensive answer!

This is interesting. Naturally, I assume that your experience with openHAB1+1.x binding was a positive one, and that you see no “degradation” in this positive feeling towards an openHAB2+2.0 binding combo?

This leads me to want to give it another try - starting out with a fresh install. I was just getting a little worried that I was trying to setup something that really was not ready for general use. I think even Kai in some pretty recent post indicated that a combo of openHAB2 + 1.x bindings was the recommended way for a stable system (he was not specifically talking about the Z-Wave binding, of course).

Anyway, I’ll cross my fingers and give it another try, :slight_smile:

4

Mostly positive. Aeon Minimotes are still a pain. Everything else seemed to work just as easily as they did in the 1.x binding. I have a very simple zwave setup though, two outlets, two appliance modules, one switch, and three smoke/CO alarms (and the two troublesome remotes of course, though I don’t really use those right now).

I think what he meant on that thread was that if you are worried about the stability of the OH 2.0 bindings you have the option of sticking with the 1.x bindings. I don’t think he meant to imply that the 2.0 bindings are not stable. As with OH 1.x, some are more stable than others but I do not think, based on my own experience, that they are any less stable than the 1.x bindings. Though as you can see above, I’m not using many 2.0 bindings, though that is largely because there are not that many that I need.

I do know that chris has focused almost all of his recent efforts into the 2.0 zwave binding so while the 1.x binding may remain reasonably stable, it is unlikely to receive any new features and minimal updates. Eventually a move will be all but required.

What specifically were your problems? Did you follow the migration tutorial?

5

I run about 25+ devices with zwave 2.0 binding.
All of them work pretty good.

So no real issue with the binding.

I have
DLINK Z110 DoorWindow
Devolo DoorWindow
Devolo Plug
Hauppauge Plug
Fibaro Plug
Fibaro Flood
Fibaro Smoke 2
Philio 4in1
Philio Flood
Aeon Multisensor 6
Fibaro RGBW
Nodon 3100 Remote

6

So, I have now made a clean install of openHAB2, and added the zwave 2.0 binding. The devices in my network (already included and available in the Z-Wave controller) are recognized and available in HABmin, but things are not working quite as well as it used to be.

One example is my Fibaro Wall Plugs (I have 5 of these; 3 x FGWPF-101 and 2 x FGWPF-102):

I can toggle the switch (relay) from openHAB, and open is also (more or less) immediately notified if I toggle the physical switch. However, power reports are really not working. I simply cannot get the device to report changes in power. If I use the “refresh items” option in HABmin, however, the correct power measurement is reported.

Using the same Z-Wave controller and Fibaro device (that has just been carried over to openHAB2) in openHAB1 worked flawlessly; whenever the power draw of the attached device changed I got a report into openHAB.

Are your wall plugs sending power report as the should? If so, did you have to do some kind of configuration differently than with openHAB1?

7

Sadly, none of my outlets report power usage at all. They don’t implement that command class. But this difference in behavior sounds like a good candidate for an Issue on github. I’m sure @chris would love to have logs from both OH 1 and OH 2. It really does sound like a problem.

8

they work great 


Pasted image1204×211 43.2 KB

9

Thanks for posting the log @shorty707!

This lead me to take another look at my items file, and I discovered that my “power items” were mapped to the channel named “meter_watts”. When I changed this to the channel named “sensor_power” it works as expected, :slight_smile:

I wonder why the “meter_watts” channel does not work the same as the “sensor_power” channel, though? It is also worth noting that as far as I can see, the “meter_kwh” channel works as expected. Hm


10

they are identical actually. and both have values for me

11

Hi!

I have 7x fgwp 102. They work quite reliably. In order to get the reports working you need to set the association group for controller updates.
The power reports will be for the sensor_power channel and when the device is polled the power channel, so make sure you are using the sensor power.

12

Did that

Yes, the sensor_power channel seems to work as expected. I still cannot get the meter_watts channel to work, however. This is no biggie but I would like to understand the difference between these channels, especially since @shorty707 reports that both channels work (in a similar way).

13

For me, at least, the meter_watts is updated on every poll. Try setting the polling interval to something short, like every 30 seconds or every minute (Just to test it out), and see if you get updates on it.

Regards, S

14

Only @chris can shed some light here i think

15

Without looking at the database etc, the difference is likely the command class used. The sensor_xxx channels normally use the SENSOR_BINARY, or SENSOR_MULTILEVEL command class, where the meter_xxx channels use the METER command class. If one doesn’t work, then it could be the device configuration or database configuration
 For example, some devices can be configured to provide the same data using different command classes


More than this I’d probably need to see logs to see what is going on with one channel not working


16

Openhab2, Z-Wave2 is using Aeon Labs Aeotec Z-Wave Z-Stick, Gen5 (ZW090), on CentOs7.

Only issue with installation was the attempt of the software to put lock on the device under /var/lock/LCK
ttyACM0 - if you run it under ‘openhab’ user you have a problem with access as all locks are under /run that is re-spawned and owned by root after each restart - bottom line it was easier to run whole thing as root, after that all worked fine.

Devices in the mesh: WS15Z-1, WD500Z-1, WO15Z-1, ZOOZ ZSE40 sensors, DSC27103 dimmers, DSC26103 switches.
Total of about 24 devices on the z-wave, out of whole mesh 3 give intermittent messages like ‘NODE 6: Got an error while sending data. Resending message’ in the log, I think it is location specific as all works fine and all is responsive.

An absolute best device so far is the DSC27103 dimmer. It is a pain to make it fit into the wall behind the existing switch but it allows very easy install to control your existing 3way light switches. I had big hopes for DSC26103 switch as i do not need dimmers everywhere but unfortunately it is a bad device, its triggering scheme is too sensitive and if you use it on long wires in 3way setup the interference from AC wires is enough to mess up trigger so it works sporadically and sometimes jitters with very loud clicks, So DSC27103 is the only device that you can put into your existing 3way setup with keeping old mechanical switches and it only needs 1 DSC27103 to make it work. Downside - it does not like dimmers, at least i could not make it work with an old dimmer for a trigger.

ZSE 40 sensors are finicky a bit - a trick to make it work well is NOT to activate it until you decide where it has to live. Move it to the spot, then put in battery, link with the stick and leave it be. Then it will be responsive. If meddled with or moved around it may stop communicating and with one it was so bad i had to unlink, reset and re-link it back to make it work again. Other than that - excellent sensor, motion detection works in nearly pitch black, response time is about 3 sec or so - fast enough to put on porch light when i step out. It is not waterproofed, so you need to mount it where it will not get soaked.

What really surprised me - i did not find any device on the market that would have combined motion sensor with a dimmer switch to be installed in the wall instead of the old dimmer. There is a ton of non-smart non-Z-wave switches and dimmers with motion detection but i found none that would have z-wave and sensor and dimmer in the same shell and it is very odd as that is all i needed, really, in the house - for the light switch to sense if anybody walks by. So for now i had to put several ZSE40 around - it works, but it is battery dependent.

17

I suspect this is because with Z-Wave it’s easy to link a dimmer and sensor and by using separate devices, I would suggest that you can optimise the coverage of sensors. Sensors and light switches probably aren’t best located at the same place in most/many cases. Of course this is more expensive to have separate devices, but that’s a different discussion :).

18

I also have several TP-Link switches and they are also good.
An item for it looks like this:

Switch Michael “Michaels Light” (SF_Bed, SF_Lights, SF_Lights1, SF_Lights2, Lights) [ “Switchable” ] { exec=">[ON:/opt/openhab2/conf/scripts/hs200.
sh@@192.168.10.46@@9999@@on] >[OFF:/opt/openhab2/conf/scripts/hs200.sh@@192.168.10.46@@9999@@off] <[/opt/openhab2/conf/scripts/hs200.sh@@192.168.10.46@@9999@@check:1000:RE
GEX((.*?))]" }

hs200.sh script can be googled up. “Switchable” tag exposes this device to Alexa via hue emulation.

Exec binding works very well, i actually like TPLink switches better than GoControl WS15Z-1 as those devices for some reason run warm on touch and i have no clue why. Other people in reviews also confirmed that those switches are warm after installed in the wall, so, i guess it is not a bug but a feature but i do not like it at all and eventually i will put them all out.Dimmers from same company run cold as any regular switch would be, so it is only a WS15Z issue.

19

I suspect this is because with Z-Wave it’s easy to link a dimmer and sensor and by using separate devices

Well, the problem is with aesthetics as my wife does not approve any odd things to be put there. I still think it is a major issue and has absolutely no excuse. There are z-wave sensors that may be put into the wall instead of the switch but they will occupy the whole spot and it is just plain stupid. Still, with ZSE40 it is resolvable as sensor is small enough to be placed above the door or window so it does not protrude or exposed to the view. Bit it would be much simpler to have sensors combined with the switch - like this one:
http://www.bulbsdepot.com/mscl-op153m-wh.html?gclid=CjwKEAiA6rrBBRDsrLGM4uTPkWASJADnWZQ4pdvDZL8RAh38sIQD9zh_Si39kwba11uIPlmeMIykRBoCluLw_wcB

I have to add - it is understood that this whole thing is a bleeding edge, etc, and it has nothing to do with openhab per se, but to search for devices and figure out what works and what does not is a major PITA. I really wanted to go with Lutron for aesthetics but got completely confused on what works with what and what does not. They have multiple lines of devices and it is extremely difficult to find any compatibility references
 So i ended up with the list i posted above.

20

@Paul_Atkin
The Fibaro Motion detector http://www.fibaro.com/en/the-fibaro-system/motion-sensor
Is quite subtle. You can configure it to not flash when detecting a motion as well (Although I have not tried that).