openHAB2 and Z-Wave - Recommended combo?

Tags: #<Tag:0x00007f616b2b42c8>

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?

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

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?

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.

they work great …

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…

they are identical actually. and both have values for me


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.

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).

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

Only @chris can shed some light here i think

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…

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.

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 :).

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@@] >[OFF:/opt/openhab2/conf/scripts/] <[/opt/openhab2/conf/scripts/
GEX((.*?))]" } 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.

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:

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.

The Fibaro Motion detector
Is quite subtle. You can configure it to not flash when detecting a motion as well (Although I have not tried that).

Have you looked at the Aeon multisensor 6? This can be recessed into the ceiling (and it’s damn small anyway).

Aeon multisensor 6

Yes, i did get one and i returned it. First thing - i cannot justify cutting a hole in the wall for this thing that needs to be extracted out. Plus it is huge compared to ZSE40 and according to people who had both - it works much worse in pitch black conditions. ZSE40 is a the smallest one on the market, just about an inch thick - so if placed above door frame you almost don’t see it. Until Lutron will make something good with an integrated sensor i will keep those battery non-sense things around.

I am really puzzled who runs marketing for those devices and how they decide what to put in those. It would make much more sense to combine motion detection with smoke detection and CO rather than have hygrometer and temperature. But, it is what it is.

Hmmm - the ZW100 is only 1.5 inches square - the ZSE40 is 2.25 square (according to the web search anyway). I guess the ZW100 is a little deeper - about 1.25 inches versus 1 inch for the ZSE40 - not exactly ‘huge’ in comparison, but I agree, it’s slightly deeper… I wonder if you were thinking of the multisensor 5 which was indeed pretty large?

I agree, but I think the issue is the sensors tend to be quite a bit bigger (at the moment), so if you want something really small, I don’t think it’s compatible.