Setpoint problems on thermostat HRT4-ZW (SRT 321)


I am using the thermostat ZWAVE HRT4-ZW Battery Powered Wall Thermostat.
I configured the WakeUp time to 300 seconds. OK!

The “Setpoint” is “zwave:device:ccdcc7d8:node3:thermostat_setpoint_heating”,
so binded :

Number  chThermo_Temp_SetPoint "chThermo_SetPoint [%.1f °C]" {channel="zwave:device:ccdcc7d8:node3:thermostat_setpoint_heating"}

I can do

chThermo_Temp_SetPoint.sendCommand(Indoor_Temp_Nuit.state as Number)
-- or -- 

Both are OK!

However, this setpoint is a “bidirectional” value i.e : the setpoint can also be adjusted on the device, by a wheel.

I then can do

rule "Thermo Indoor Update" when Item chThermo_SetPoint	changed  then ...... end
-- or --
when ... received update ... 
 when ... received command ...

In all cases, OK, I receive an event when changing by the device.

As soon the setpoint is modified by/on the device, the setpoints I send / post by my application behaves erratically.
It seems they are “queued” somewhere, but never transmitted to the device.
However, when I switch ON/OFF, on the device, the switch allowing configuration, (that probably forces a wakeup), I receive on the device my “queued” values, one after another, each time I switch ON/OFF this device’s switch.


  • How can I clearly bind one variable for “TX” value, and another one variable for “RX” value ?
  • Or, how can I deal safely with only one variable, the postUpdate / sendCommand and the trigger change / on update / on command ?

I all tried, without success.

Subsidiary Question
How can I access all the command classes supported by a zwave device ?
by example :

Thanks in advance for your answers.

1 Like

If there is only one channel you cannot do this.

postUpdate only changes the internal OH state of the Item. sendCommand will forward the new state to the actual device. But in this case, I think that will not address your problem. I think the root of your problem is that when you use the Slider or SetPoint on your sitemap/HABPanel a whole series of commands get sent. Then a whole bunch of response commands are received as the thermostat reports the new temp it was just set to.

So I think you need to use a Design Pattern: Proxy Item to represent the Thermostat.

Put the proxy Item on your Sitemap and then use a pair of rules to synchronize the Proxy with the “real” item. In one of the rules we will use a timer to avoid sending the command on to the thermostat until it has remained unchanged for a certain amount of time, half a second should about do it but you will have to experiment.

var timer = null

rule "Proxy Item changed"
    Item chThermo_Temp_SetPoint_Proxy received command
    if(timer == null) {
        timer = createTimer(now.plusMilliseconds(500), [ |
            timer = null
    else {

rule "Real Item Updated"
    Item chThermo_Temp_SetPoint received update

This will eliminate any feedback loops and reduce the number of commands sent to the device drastically which hopefully will clear up your problem.

You can only access those command classes that the Zwave binding implements. It does not yet support this command class. If you don’t see channels representing a given command class, that version of the Zwave binding does not support it.

1 Like

Thank you Rich for your answer.

About sending values, it is already my case :
I don’t have any binded variable directly used in my sitemap.
I always have an “intermediate” variable, on which I trig / I work , and finally the real output is done through a “cron” in which only value(s) really changed are effectively sent/posted.

However, saying that reminds me something afraid :

Inputs are triggered “by zwave”.
Some variables are triggered by sitemap.
Output and some other variables are handled by cron.

Are all these operations running in the same thread context !!! ???
( asking is answering ) :slight_smile:

While minding, my problem typically looks like a multitasking side effect problem.
So, I want assume that my 3 cases above are running in different threads, and I want immediately mind about and try to protect what is needed to be protected.

The problem is for testing.
Bull shit of “battery device” which cause to wait about 5 minutes to see a result! :rage:

I keep you informed !

They are.

Good luck!

I reorganized (simplified) my code so clean as possible, excluding eventual side effects, excluding eventual “circular re-trig”, … (I even not need usage of “lock” mechanism) …
I avoid so far as possible usage of trigger on values. Most is done in a “cyclic cron”,… I begin to be absolutely sure of my code (it’s not often) :slight_smile:

Luckily, after posting my problem on a topic related to bindings, somebody experiments also the same problem.
The problem should be probably in the zwave binding and/or in the SRT itself.

Still Thanks for your help.