Is a working, reliable ZWave network possible?

Add-ons Bindings
,
1

Basically I would like to know if anyone has a working, reliable network with many (20+) ZWave devices running? I have spent days trying to get my Aeotec(Aeon) Multisensors to work. I have many years technical experience. I have an Aeotec Z Stick. I have stable openHAB 2.1 installed on NUC with Ubuntu. Have Symlink configured for Z Stick.

Adding my first two Aeotec(Aeon) Multisensors(DSB05 and ZW074) worked after a couple of tries. But, trying to add more sensors I just get all possible errors, I/O exceptions and what not reported via openHAB log file. After many, many tries(adding and removing node), I managed to get it to add a third node. After a couple of days, I upgraded binding to latest Snapshot, but still so many errors. I am aware that battery powered zwave nodes require time(up to hour) for controller to send pending settings to nodes. But, it hardly ever works. And, I keep getting all these errors in log file, which seem to be from a very buggy zwave binding.

Is there something wrong with my setup?? I have tried Stable 2.1 and Snapshot 2.2 zwave binding. I can not imagine how any one can use the current binding for a reliable installation. Are there any success stories out there?

At this stage I am wondering if it might be better getting a zwave to MQTT bridge, and just using MQTT in openHAB. I have many very, very reliable MQTT devices running on my current openHAB installation. They run reliably for months, and never crash. Never get any log errors from MQTT binding.



Some of the errors and warnings I get:

=== Initializing does not complete ===
After adding new node(Aeontec DSB05 MultiSensor), I get it listed in Inbox. I then add it as a Thing. After doing some configuration for the newly added Thing(add Temperature and Motion Channel, reduce wakeup to 60 seconds), it shows “pending” in editor(HABmin), and shows “Node initialising: WAIT” in things(HABmin). But, after 14 hours it still shows same message, and never seems to finish initializing. After 14 hours I tried pressing button on sensor, and remove/replace batteries to try and wake it up, and get controller to finish initialization, but it does not work.

=== Deleted Thing keeps on re-appearing in Inbox ===
After 14 hours of my thing not initializing (status still shows “Node initialising: WAIT”, I deleted it. I remove batteries from device. It is not powered any more. But, it always appears again in the Inbox, or is found when I search for new things. I delete it multiple times using HABmin and PaperUI, but it keeps on appearing again. I also tried in HABmin “add to failed items list”, and “remove item from controller”. But, this also does not work, and actually brings up another error message “node not found”.

===== WARN: Restore from config: Error. Data invalid =====

2017-12-13 11:56:20.572 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 1: Restore from config: Error. Data invalid, ignoring config.

=== WARNING: Already processed this callback Id, ignoring ===

2017-12-13 09:36:28.703 [WARN ] [l.serialmessage.SendDataMessageClass] - NODE 7: Already processed another send data request for this callback Id, ignoring.

===== ERROR: Polling aborted due to exception =====

2017-12-13 08:53:50.133 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 0: Polling aborted due to exception
java.lang.NullPointerException
at org.openhab.binding.zwave.handler.ZWaveThingHandler$1.run(ZWaveThingHandler.java:365)[194:org.openhab.binding.zwave:2.2.0.201712110910]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_144]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)[:1.8.0_144]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)[:1.8.0_144]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)[:1.8.0_144]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_144]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_144]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_144]
2017-12-13 08:54:14.338 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.

===== ERROR: Unknown Device Error =====
About half the times I add one of my Aeotec Multisensors, it adds a “Unknown Device” to my Inbox. In log file I see:

2017-12-13 09:43:04.227 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 7: Device discovery could not resolve to a thingType! 7FFFFFFF:7FFFFFFF:7FFFFFFF::0.0

===== ERROR: FrameworkEvent ERROR - org.openhab.binding.zwave =====

12:21:50.853 [ERROR] [org.openhab.binding.zwave ] - FrameworkEvent ERROR - org.openhab.binding.zwave
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [196]
Another singleton bundle selected: osgi.identity; osgi.identity=“org.openhab.binding.zwave”; type=“osgi.bundle”; version:Version=“2.2.0.201712110910”; singleton:="true"
at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1562)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]

===== ERROR: Exception occurred while disposing handler of thing =====
This error happened when deleting a zwave Thing in openHAB.

2017-12-13 10:24:22.275 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occurred while disposing handler of thing ‘zwave:device:614ae48a:node4’: java.lang.NullPointerException
java.util.concurrent.ExecutionException: java.lang.NullPointerException
at java.util.concurrent.FutureTask.report(FutureTask.java:122)[:1.8.0_144]
at java.util.concurrent.FutureTask.get(FutureTask.java:206)[:1.8.0_144]
at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous(SafeMethodCaller.java:194)
… many more lines …
at java.lang.Thread.run(Thread.java:748)[:1.8.0_144] Caused by: java.lang.NullPointerException
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeSerializer.SerializeNode(ZWaveNodeSerializer.java:97)[194:org.openhab.binding.zwave:2.2.0.201712110910]
at org.openhab.binding.zwave.handler.ZWaveThingHandler.dispose(ZWaveThingHandler.java:480)[194:org.openhab.binding.zwave:2.2.0.201712110910]
… many more lines …
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_144]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_144]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_144]
… 1 more

====== ERROR: Concurrent Exception (Not sure if this is Zwave related) ========

at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)[:1.8.0_144]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)[:1.8.0_144]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)[:1.8.0_144]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_144]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_144]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_144]
2017-12-13 08:44:14.338 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.

2

I have 15 Z-Wave devices from all kind of brands (Fibaro, Qubino, Devolo, Aeon) and haven’t had issues that were described by you. Most of them are smoke detectors and switches/relays.

I am running Razberry on Raspi3 with Openhab 2.1 stable. So unfortunatley no experience with the ZWave Stick.But I would think that there might be something wrong with your setup in general.

3

Thanks for quick reply, and positive report! Can you tell me if your installation runs stable for months without issues? I need a very reliable installation, that will require minimum maintenance once set up.

4

Yes, you definitely can have a reliable zwave network.

I have around 35 zwave devices including lights, outlets, energy monitors and door locks. They are rock solid. I just recently tried a 4 in 1 motion sensor and have not been super impressed but it does work… sorta.

My network runs for months without me touching it. I use a vera edge for my controller though. I didn’t want to use the usb sticks.

5

I have 64 nodes in my network. It’s a combination of mains devices and battery-powered devices. While it took some time to get it set up, it runs very reliably.

Don’t get discouraged. A smooth-running network is possible!

Here’s a list of the nodes in my network. As you can see, it’s a pretty diverse collection of devices.

// NODE 1 Controller
// NODE 2 Everspring ST814 Temperature and Humidity Sensor
// NODE 3 Everspring ST812 Water Sensor
// NODE 4 Everspring SM103 Door/Window Sensor
// NODE 5 Everspring ST814 Temperature and Humidity Sensor
// NODE 6 Everspring ST814 Temperature and Humidity Sensor
// NODE 7 Everspring ST814 Temperature and Humidity Sensor
// NODE 12 Fibaro FGK-101 Door/Window Sensor
// NODE 15 Leviton VRS05
// NODE 16 Leviton VRP03
// NODE 17 Leviton VRPD3
// NODE 18 Leviton RZP03
// NODE 19 Aeon Labs Minimote
// NODE 20 Leviton RZP03
// NODE 21 Leviton RZP03
// NODE 24 Ecolink Garage Door Tilt Sensor
// NODE 25 Leviton RZP03
// NODE 26 FGMS001 Motion Sensor
// NODE 29 Aeon Labs Minimote
// NODE 30 Aeon ZW096 Smart Switch
// NODE 31 Aeon ZW096 Smart Switch
// NODE 32 Aeon ZW096 Smart Switch
// NODE 33 Aeon ZW096 Smart Switch
// NODE 35 Fibaro FGFS101 Flood Sensor
// NODE 37 Fibaro FGMS001 Motion Sensor
// NODE 38 Aeon ZW100
// NODE 39 Fibaro FGPB101 Button
// NODE 40: Leviton VRMX1 Dimmer
// NODE 41: Everspring ST814 Temperature and Humidity Sensor
// NODE 42 Everspring ST814 Temperature and Humidity Sensor
// NODE 43 Everspring ST814 Temperature and Humidity Sensor
// NODE 45: Leviton VRMX1 Dimmer
// NODE 46: Leviton VRMX1 Dimmer
// NODE 47: Leviton VRMX1 Dimmer
// NODE 48: Leviton VRMX1 Dimmer
// NODE 50: Leviton VRMX1 Dimmer
// NODE 51: Leviton VRMX1 Dimmer
// NODE 52: Leviton VRMX1 Dimmer
// NODE 53: Leviton VRMX1 Dimmer
// NODE 54: Leviton VRMX1 Dimmer
// NODE 55: Leviton VRMX1 Dimmer
// NODE 56 Leviton VRMX1 Dimmer
// NODE 57 Leviton VRMX1 Dimmer
// NODE 58 Leviton VRMX1 Dimmer
// NODE 59 Leviton VRMX1 Dimmer
// NODE 60 Leviton VRMX1 Dimmer
// NODE 61: Leviton VRMX1 Dimmer
// NODE 62: Leviton VRMX1 Dimmer
// NODE 63: Leviton DZ1KD Dimmer
// NODE 64: Leviton DZ1KD Dimmer
// NODE 65 Leviton VRMX1 Dimmer
// NODE 66: Leviton VRMX1 Dimmer
// NODE 67: Aeon Energy Meter Gen 1
// NODE 68: Aeon Energy Meter Gen 2
// NODE 69 AEON ZW097 Dry Contact Sensor
// NODE 70 AEON ZW130 Wallmote Quad
// NODE 71 AEON ZW097 Dry Contact Sensor
// NODE 72 AEON ZW130 Wallmote
// NODE 73 Leviton VRMX1 Dimmer
// NODE 74 Leviton DZ15S Switch
// NODE 75 Leviton DZ15S Switch
// NODE 76 Fibaro FGMS001 Motion Sensor
// NODE 77 Jasco Outdoor Switch
// NODE 78: Leviton VRMX1 Dimmer
// NODE 79 Leviton VRI06 Switch
// NODE 80 Jasco Outdoor Switch
6

I also have a z-wave network with up to 50 devices. Most of them battery powered. Most of them door/window sensors.

What is hard for me to find out is, are all of my devices really working or just are gone. The binding says no problem but the devices are not really reporting anymore.
They do no longer report open door, breaking glas or temeprature. But I do not know this.

To detect this I implemented a monitoring by checking battery level updates. I configured all devices to send it every 6h. If a device does not report this for more then one day then I know that there is something wrong.

To fix this I have to do on of this, depends on the device and situation, every tiem I have to test, which one helps:

  • redetect thing by deleting and new adding into the binding (not into the stick)
  • manually waking up the device
  • reinclude the device into the stick

And sometimes it looks that if I relocate a z-wave devices, the network gets confused. For example if I add a new power driven device to the network I do this nearly the stick. If I move this to the final location, I got very often that some devices are no longer reporting to the binding. I know, that these power driven devices act as an relay or hub for battery powered devices. I think the network does not detect very fast that this relay was relocated and the communciation should take another way to the stick.

Has anyone else the same problems? And a solution which is working well.

7

I only have about 10 devices, but had the same issues with Z-Wave - after long trial and error, i bought a RaZberry, since then the network runs smoothly (including Meshing, Routing, etc).

8

20 nodes, no problems as long as you know what you are doing and read the official docs how to do the setup.
There are users here with about 100 devices with no problems.

But keep in mind that you are using a free software provided “as is”. Although it is pretty reliable you could also consider to buy off the shelf software, but i doubt it is any better. A lot of users come to openHAB because they have problems with these software and don’t like the limitations, where as in openHAB your possibilities are almost “endless”. But you have to tinker a bit around to get it going :grinning:

9

Reliable and without pain? probably not…

I have a reasonable investment in zWave devices (~25 devices plus 2x controllers) and I would have to count them as among the most frustrating technology I have ever bought.

I have yet to find a stable zWave device driver for either the Aeotec or the RaZBerry controller.
I have yet to find a stable & useful user interface that doesn’t require me to tinker with it for hours a day or become an expert in it to just get it running.

It won’t stop me trying… And yeah, I’m technical too… I’ve been doing Unix & Linux for 30 years now. Some of the software out there is bad enough to make me want to cry. I have to keep biting my lip to stop me expressing my deep and bitter resentment at some of the authors… But remember most of them are doing this for free because they want it to run for them… My requirements, yours and theirs are all different.

10

Hello David

I’ve used a zWave network with OH 1.x in my old flat (125qm, about 20 nodes) without any Problem for 2 years.
Since April I run a new zWave installation with OH 2.1 and 115 nodes in my house. Without any issues. It’s rock solid and very reliable. (Pokini F as server, AON Stick Gen5 as Controller, Ubuntu 16.04 LTS).
Most of my devices are from fibaro (multisensor, dimmers, switches), some devices from everspring, sensative strips and MCO are also included.

It’s very important, that you read the Manual first (especially for battery powered devices), and add them direct at the Controller (physically), and wait for the complete discovery before you place them at thier final position.

What I heard, is that the AON Multisensors are very batteryhungry and not the most reliable devices. Maybe you try others than them.

11

Yes, my devices are running smooth since August this year (that was when I started with openHab).
Adding battery powered devices talkes some time in the beginning, but if you follow the docs and really make sure that you include them close to the controller, everything is working fine.

12

Depends on your system. I’ve got almost 40 z-wave devices spread across two buildings at home, on two controllers. They’re 100% reliable, and have been since day 1 using Vera and Homeseer. I definitely think there’s some stability issues with the OH binding, however. 1/3 of my devices are secure ones, and Vera, Homeseer (with their hardware) and Z-Way (with a Razberry) have no issues with including them in the network, but OH with the Razberry or the Homeseer USB stick hasn’t successfully done so at any point. (OH with the Z-way binding works fine, but for a bunch of devices, I don’t get all the channels that should be there, so it doesn’t work in different ways.) I see all the same issues, lots of stacktraces that may or may not be related. Stability issues when needing to add/remove devices from OH. It also doesn’t seem to do network inclusion the same way as the other three systems – devices farther out on the tree add reliably to the other three, but never see the inclusion request in OH. And inclusions sometimes take a few attempts with battery devices because the back-and-forth runs more slowly. My Kwikset locks, for example, do the full negotiation, inclusion and retrieval of configuration and stuff in a few seconds with Z-way, but the process drags out over minutes in OH… which I suspect is why the secure binding fails. In fact, I’m starting to think the time it takes to include a device may be the core issue with the Z-wave problems I’ve seen.

I’ve gotten pretty frustrated. Homeseer is a rock stable platform with a horrible mobile story and a worse development environment. Vera, if you can get past having to use LUA, works well enough but its mobile apps can’t interact with custom plugins at all. OH inherits some weird (and not ideal) architectural limitations from ESH, but is an otherwise solid platform to build off of. Its just not for the faint of heart right now.

13

hi, we have over 160 zwave devices running on OH2 daily snapshots, no problems

14

I have running something like 35 Z-Wave Nodes here and overall things behave well… now.

Nevertheless I have had my learning as well - and a very simple actually: For the Aeotec Z Stick that I am using as well there is some backup software being offered - and my experience is to better use that.

No idea but out of a sudden when trying to team another node (other make than what I usually take) it started to blink red - and there was no way of getting it out of that state - except resetting to factory defaults.

That means all node information had been lost and devices had to be teamed again. I am using lots of modules placed behind wall mounted switches - so that was a hell of a work.

Taking backups of the Z Stick is since then something I do every time before and after I add additional nodes…

But yes… things are running pretty smoothly now…

15

The only time I’ve seen this error is when two versions of a binding are installed. Run bundle:list |grep -i zwave from the Karaf console. This could cause some major issues.

I have 110 devices and half of the devices are battery powered, using 2.2 snapshot build 1140 and the development zwave binding. There are bugs… but I’m using the development binding, so expected. I will restart every time there is a new version of the binding available, so long term stability is hard for me to judge. When there’s instability, I find it is usually a low/bad battery, or something else going on in the zwave network that is causing it, not the binding.

16

I am running a Z-Wave network with >30 Nodes, but it is far from reliable. A lot of errors especially with battery powered devices. The status of my three Qubino ZMNHOD Flush Shutter DC are not reported, the NQ-9021 NorthQ Electrical Meter only shows “Node is not communicating with controller” and when configuring the Z-Wave Me ZME Remote Control /Scene Controller ZME_RC2 only NullPointerExceptions are thrown (as with all battery-operated devices). Even my Fibaro FGS223 Double Switch 2, which was the reason to switch from OH1 to OH2, doesn’t report his status. Charts generates typically IO-Exceptions and no hour without a “Request node info not placed on stack due to error.” message.
With OH1 everthing was running extremly stable and reliable, but OH2 is pretty fragile.

17

I have about 60-70 devices, and while it works most of the time, after upgrading, there’s always one or two devices that does not make it, and some times there are long delays (like 10-30 seconds) switching things on/off. Mostly battery devices are worse, and I try to replace them with powered devices when I get a chance.
I think my set-up is partly troubled by the radio coverage of my house.
I get different errors in my log, especially at start up, but “Request node info not placed on stack due to error.” comes and goes in my logs.

18

I am running Z-wave with 12 nodes on a Raspberry Pi 2B with a Razberry GPIO-board. In the beginning I had similiar problems with lost connections. After replacing the build-in antenna from the Razberry with an external antenna (AliExpress) it’s much better. Sometimes a door contact loses connection for a while.
Several experiments with the antenna learned me that the place and position of the antenna can influence the range of the signal.

I expect the Z-Wave network will be more stable when I increase the amount of nodes in the near future.

19

I also have some ZWave devices and also have some minor problems. I have couple of dimmers, valve controllers and PIR sensors. I have problems with PIR sensors (NEO coolcam), they sometimes does not report that there is no motion anymore (after they report motion) and sometimes they report motion with a large lag (they are resending motion report every 8 seconds, so it may be that the first report didn’t reached the gateway). And they are located just 3-4 meteres from the gateway … So this could not be the bad reception problem. Is it the problem with this particular PIR sensor or is it the problem with the gateway ? I have aeotez z-stick gen 5. What can I do to sort out the problem ? From the general point of view, is it even possible for the zwave battery powered device not report its state to the gateway ? I guess that the device should know if the gateway received the message and retry if it received. If so, then obviusly the problem is either in the z-stick or in the OH side.

20

Yes - this is possible. It could either not be configured correctly, and thus not report, or the message could not get delivered.

Yes, there are retries, but if there is noise (or some other problems) within the network, then trying 3 times over something like 7 second doesn’t guarantee that the message gets delivered. IF the link is broken, retries will not somehow fix that.