My big z-wave disappointment

For short reading, go directly to II.


I control ON/OFF a gazoil furnace, about 8 kW power, a little special while it is a ventilated “open fire”, with atmospheric pressure gazoil injection. This involves timing constraints.
I use OpenHAB-2 application on a Raspberry-pi to act as a programmable “time - temperature” clock, which sends setpoints to a Z-Wave “Secure/Horstmann” ambiance thermostat, which sends ON/OFF commands to a Z-Wave binary switch, which drives the furnace. All of that by Z-Wave.

Major constraint
Because of the technology of the furnace :
• Once I turn on the furnace, I don’t have the right to turn it off before 20 minutes.
• Once I turn off the furnace, I don’t have the right to turn it on before 20 minutes.

The OpenHAB application is :

  1. An user friendly interface allowing the configuration of 4 time ranges in a day, and the desired temperatures for each of them. It also provides selection between an automatic mode, an absence mode temperature setting, and the display of some feedback data.
  2. An automate which sends, through Z-Wave binding, the setpoints to an ambiance thermostat (Secure), according to the desired temperature settings, when the time range changes.

The Z-UNO application
Because of the unavailability of any ZW thermostat able to meet my furnace constraints, nor the unavailability of any ZW binary switch able to mask the receiving commands during a (programmable) long delay, I was constrained to realize a specific application, using a Z-Uno. (too bad).
Mainly this Z-Uno application acts as a Z-Wave binary switch, which inhibits/allows the received ON/OFF commands according to the 20 minutes delays mandatory by the furnace.
In addition, it also acts as a multi-channel Z-Wave sensor of binary and analog values, providing internal information to the OpenHAB controller.

What I want to do :
Because of a lot of Z-Wave problems with the Secure thermostat, and because I also need now an humidity sensor (just to display its value), I would like to replace the thermostat by a simple temperature sensor, which seems existing as Z-Wave “combo” device, including temperature and humidity sensor.
Given I necessarily already have a Z-UNO in the furnace, I will to realize the full predictive pseudo regulation in the Z-UNO device. Knowing precisely all the special constraints I have, I obviously will be more efficient than with a “standard” thermostat/regulation.
(despite it is surprisingly not so bad with the Secure now).


The “Secure/Horstmann” Thermostat

  1. Setpoint communication :
    The setpoints communication between OH2 and the Secure thermostat is catastrophic.
    At the beginning of my job, the data was “randomly” (or not) transmitting. Sometimes, the feedback value was coming with 2 or 3 values of delay. Collaborating with @chris Chris Jackson (from OH team), this one solved the problem (still thanks).
    But a big problem remains : The delay in which the Secure takes a setpoint change into account can be from 5 minutes, to …. 20 minutes !
    In addition, if one has the misfortune of touching the roller control knob on the thermostat, the set point communication can become totally erratic. Do not touch !

  2. Battery lifetime :
    If I would like a reasonable response time for giving setpoints, or for reading temperature values, my “sampling” interval is about 5 minutes ! More would be unacceptable.
    Despite of this very poor response time, the battery life is already less than 3 month.
    In addition, the thermostat seems no more able to feedback corectly the battery level value to the OH2. I receive it when I restart OH2, and then, no more.
    (some time ago, I think that it worked ; I don’t know what occured since)

The Price
No comment ; far too expensive !
It seems that Z-Wave is not able to do “very complicated things” such as transmitting a setpoint value in a reasonable time. At least it should be able to do simplest, such as driving a lamp with a button. In this case, it costs about 100$ by couple lamp-button. Nonsense !
So what can we do that makes sense with this network ???

The reliability
Most of devices are not able to deal with communication failures. In a networked environment,… that’s just unbelievable !
By example, I have a thermostat which is paired with a ON/OFF switch. For any reason, if the thermostat disappears (removing the battery, destroying the thermostat, any else ….), and by misfortune, the thermostat was in ON state… too bad for my 8 kW furnace, which will end by putting fire in house.
In fact, I even quasi never seen, in such kind of application, any one who recommended a hard security system (security thermostat). Even to drive big heaters.
Could DYI be becoming dangerous ?

The Z-UNO problematic
Despite I found this product very, very interesting, I first discovered the difficulty to implement it in OH2. ZW seems to be so “dynamic” in its configuration, that I am disappointed to have to “specialize” a whole OH2 version, only to add a “static definition” of a generic product. But I did that.
OK, that’s rather an OH problem than specifically ZW .
In addition, which perhaps partially explains the above, is the fixed device identification by VendorID / DeviceID. I don’t know if it is a ZW or a OH design decision, but it is bad.

The Z-UNO reliability
Z-UNO problem or Z-Wave problem (probably Z-UNO) ?
Although my program is trivial, especially not using interrupts, the Z-UNO device crashes, after weeks or even months of good operation !
Nobody, especially not me, has a few chance to find a day the cause of that problem.

The performance
Five minutes, in the best cases, to transmit a value to a battery powered device !
The “sleeping” technique to preserve battery life is a little ridiculous. In my case, I need to transmit setpoints perhaps 5 times in a day from OH2 to the Secure, and I cannot be better than 5 minutes to expect a result.
During that time, the Secure transmits about continuously ON/OFF orders to my switch, which needs no more than 1 value each 20 minutes !

Replacing the “Secure” Thermostat by a simple temperature sensor
To do that, I absolutely need a device able to send the temperature values to the Z-Uno at least every minute (I expected 30 seconds, but … don’t dream).
I don’t find any sensor able to send me values in less than every 10 minutes !!!
I however could find any which are able to send values at every 0.1 degree changes, which could be OK for me, but nobody is able to say in which delay it will send it. I expect at least in less than 5 seconds, and at least deterministic, but ???
In that case, how will the battery behave ??? no answer neither.
A “mains powered” device could also be OK for me, but I don’t find any one.

I also was desapointed when I began searching another solution than ZW.
Why is there now about ten different systems avaiable ? (Zwave, ZigBee, WiSun, Thread and its derivates, M-Bus,…. That only for the Sub-1Ghz range)
My question 1 : Today, which wireless fieldbus is the most pertinent while starting a new project of
• a small house automation / supervision?
• A big building automation / supervision?
Obviously, which one which has the most promising future, and for which we can find the greatest number of different devices.
And obviously too, one which do not have the faults described below.

My question 2 : Does anybody have answers about my previous topic “Replacing the Thermostat by a simple temperature sensor” ?

Perhaps I misunderstood some basics of the ZW, perhaps I did not use correctly some functionnalities (error handling by example), or perhaps I am totally right in my appreciation.
I then would be happy to read your answers, comments or remarks.
Thank’s in advance,


This is definitely aberrant behavior. I’ve a number of Zwave devices and command are received in milliseconds of pressing the control on BasicUI. How dense is your mesh (i.e. how many other mains powered Zwave devices do you have and how are they distributed around your house)? Do you see errors in the logs from the Zwave binding?

To conserve power, battery powered zwave devices are not chatty. In some cases (e.g. I’ve some Zwave smoke alarms) they report back maybe once every other day. That’s how the protocol and devices are designed to work. So of course, it’s going to take quite some time of non-reporting before a battery powered device is detected as offline.

Furthermore, battery powered devices get to set their own schedule for communicating with the controller. As I understand it (and I’m often wrong with Zwave), battery devices wake up periodically to send data and ask for any queued up commands on it’s own schedule. It sounds like yours is only waking up about once per half hour which means it could take up to 30 minutes for it to respond to a command. Put another way, these battery powered devices are not in constant communication with the controller.

It’s not zwave that’s the problem, its that you are using battery powered devices that is the problem.

Given the timing and safety aspects with driving your thermostat, you really should be using mains powered devices, perhaps with a battery backup to fall back to. Battery powered devices, be they Zwave, Zigbee, or even WiFi will all work similarly to what I describe above. It’s the only way to get any sort of battery life time.

Because every company want’s their own standard. And each has certain things it’s better at than others.

There is no one answer. It depends on your specific requirements. Clearly using battery powered devices (of any kind) is not the right solution for your use case. But I would expect a zwave or zigbee deployment with a good mesh of mains powered devices would be more than adequate. There’s also lots of options that use WiFi like Shelly. Though personally for something safety focused like this I’d look for wired as opposed to wireless.

And one of the main purposes of OH is that you don’t have to choose just one technology. You can and should choose the best technology for what you need to accomplish.

Zwave and Zigbee are particularly well suited for large building automation because of the mesh network. Not all the devices need to be in range of the controller. They just need to be in range of another mains powered device that can relay the messages for it. But in both cases, battery powered devices do not participate in relaying messages so they do nothing to build your mesh.

If you didn’t get any replies than probably not.



into consideration, I would never trust a wireless driven system with this task. It is literally “playing with fire” here. I would expect some kind of controlling device as part of the furnace that enforces the 20 minutes block time before the next switch operation is allowed, but that does not seem to be the case.

This seems to be an older device. I had some thermostats showing exactly the same issues (Eurotronic CometZ). The newer incarnation from the same vendor (Spirit Z-Wave Plus) has a much better battery life, despite a nearly immediate reaction to commands. The “Plus” in the name indicates the usage of newer Z-Wave electronics, supporting the FLiRS (Frequently Listening Receiver Slave) technology. Instead of a few weeks of battery live I only have to exchange batteries once a year or so. I recommend to look for battery driven devices that use this technology if mains powered devices are not available/cannot be used for whatever reason.

1 Like

Hi Charly

I made myself some thoughts of your situation and as already mentioned by @rlkoshak and @stefan.oh I would never trust to a battery driven device.

Other things to consider:
Running OH on an RPI might work good enough, but there are several stories about SD cards that stopped working after a while. Better use a bit more expensive hardware and make it power outage failure safe. (My OH setup isn’t that critical but runs on a full stuffed older Mac Mini attached to APC device.)
If the operating system and OH is stable enough also Zwave is. This at least is my experience over 4 years now.
Another point is the accuracy of the temp/humid sensor itself I also recently leraned that there is huge bandwith between devices, some with already a huge gap ± and others even more worse and temperature depending.

I’ve had a quick read ad Z-uno. It might work no doubt. But I wouldn’t risk it.

You can switch your furnace max 3 times per hour. I’m not sure if this indeed is needed to be so.
The trigger for the switch should be a rule based command from OH via ZWave controller.

As you would extend it with a termostate or control it thermostate driven I would think about a qubino with a thermostate sensor attached immediately.
Despite the fact that those ones I use are without the thermo sensor I would give it a try.

So after all I wouldn’t say it is a z-wave based issue that results in your disappointment. More the question what you would like to achieve and what the budget is you plan for the realization.

You don’t link the product that you use, but it sounds identical to what I use: is it this?

I have this connected to a Vera Lite controller, and have been using it since January 2014. The delay is because the thermostat itself is battery powered, as everyone else has said. The thermostat only comes ‘online’ every couple of minutes or so to check if it has been remotely command. Through my Vera Lite (openHAB -> Vera Lite -> Thermostat), communication delays are no longer than 2 minutes - basically, until the next time the thermostat wakes up.

However, I also use the mains powered relay, and actually associate the two devices directly. If the thermostat setpoint is changed at the thermostat itself, it communicates immediately with the relay.

I use rechargeable AAA batteries (Amazon Basics brand), and get around 6 months use before I have to recharge them.

Out of all the different home automation technologies I have at home (admittedly, quite a lot of it DIY), this Z-Wave thermostat and boiler have been absolutely rock-solid - the most reliable!

Just another POV.

EDIT: Probably should note: I’m not using the Z-Wave binding - I’m commanding/getting via the Vera Lite upnp api over HTTP from within Jython rules.

If not just a 2 minute delay as above due to battery and it really is erratic Have you tried healing / reinitialising the problematic Zwave devices? I had a similar problem with huge delays when upgrading from 2.4 to 2.5 and this solved it. Mine have also got into this erratic state since if I’ve been doing a lot of tinkering changing parameters

If doing a lot of inclusion and exclusion the. Zombie nodes can exist messing up the routing and causing delays. They need to be deleted from the controller.

Yeah mine are fine, a quick heal/reinit sorts it. Was just an observation that could be worth trying. (Found it especially true if a node goes offline too such as power removed, as you say, routing gets messed up)