For short reading, go directly to II.
I : CONTEXT
Application
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 :
- 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.
- 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).
II THE BIG Z-WAVE DISAPPOINTMENT
The “Secure/Horstmann” Thermostat
-
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 ! -
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.
III ALTERNATIVE TO ZWAVE
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” ?
IV ANSWERS AND COMMENTS
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,
Regards,
Charly.