GC-TBZ48 refusing setpoints

I have installed six of these, and some of them are refusing to accept a setpoint. I’ve tried my best to make all of the installs the same, and cannot find any differences between the working tstats and the problem ones. Here is a simple log of a thermostat reverting back to an original value. I am modifying the value through PaperUI’s control tab.

2019-06-22 19:14:05.152 [ome.event.ItemCommandEvent] - Item 'tstat_hallbar_setpoint_cool' received command 80
2019-06-22 19:14:05.174 [nt.ItemStatePredictedEvent] - tstat_hallbar_setpoint_cool predicted to become 80
2019-06-22 19:14:05.180 [vent.ItemStateChangedEvent] - tstat_hallbar_setpoint_cool changed from 79 to 80
2019-06-22 19:14:24.710 [vent.ItemStateChangedEvent] - tstat_hallbar_setpoint_cool changed from 80 to 79

I have a rule that triggers, and it is showing a double trigger:

2019-06-22 19:47:29.389 [ome.event.ItemCommandEvent] - Item 'tstat_hallbar_setpoint_cool' received command 80
2019-06-22 19:47:29.414 [nt.ItemStatePredictedEvent] - tstat_hallbar_setpoint_cool predicted to become 80
2019-06-22 19:47:29.467 [vent.ItemStateChangedEvent] - tstat_hallbar_setpoint_cool changed from 79 to 80
2019-06-22 19:47:29.547 [vent.ItemStateChangedEvent] - tstat_hallbar_setpoint_cool changed from 80 to 79
==> /var/log/openhab2/openhab.log <==
2019-06-22 19:47:30.954 [INFO ] [l.script.Thermostat Was Changed Rule] - tstat_hallbar_setpoint_cool (Type=NumberItem, State=79, Label=Cool Set, Category=thermostat, Groups=[gSet])
2019-06-22 19:47:30.957 [INFO ] [l.script.Thermostat Was Changed Rule] - tstat_hallbar_setpoint_cool (Type=NumberItem, State=79, Label=Cool Set, Category=thermostat, Groups=[gSet])

And here is a thermostat that is working properly:

==> /var/log/openhab2/events.log <==
2019-06-22 19:47:51.209 [ome.event.ItemCommandEvent] - Item 'tstat_choir_setpoint_cool' received command 80
2019-06-22 19:47:51.229 [nt.ItemStatePredictedEvent] - tstat_choir_setpoint_cool predicted to become 80
2019-06-22 19:47:51.264 [vent.ItemStateChangedEvent] - tstat_choir_setpoint_cool changed from 81 to 80
==> /var/log/openhab2/openhab.log <==
2019-06-22 19:47:51.263 [INFO ] [l.script.Thermostat Was Changed Rule] - tstat_choir_setpoint_cool (Type=NumberItem, State=80, Label=Cool Set, Category=thermostat, Groups=[gSet])

my rule:

rule "Thermostat was changed"
when 
    Member of gSet changed
then
    logInfo("Thermostat Was Changed Rule", triggeringItem.toString.toString)
end

It’s not a group problem, because when I remove it from a group, it shows the same behavior. I don’t think it’s a trigger problem. I think I set the value, then something is reverting the value, causing another trigger. I’ve tried removing the Thing. Should I do a hard reset and erase all cache data?

Try


or autoupdate=false in your items definition

Zwave can be rather frustrating.
I am using six identical thermostats.
Some work fine, others do not.
Even on the same thermostat, I can change the fan mode, and it updates, as well as other fields, so I know the tstat updated its state and sent the information over Zwave to OH. But then on the same device, when I update the cooling setpoint, it reverts back to the original value.

autoupdate=on does the reverting thing
autoupdate=off seems to disable actions from the change. For example, my rules do not get triggered. I’m doing this from remote, and can’t actually see the thermostat screen.
command poll doesn’t seem to make any difference.

It needs to be true or false, not on or off.

Okay, I finally tracked down the cause of this behavior.
In my Item file I had:

Number:Temperature TstatStageSouth_setpointheat “Stage South Heat Set [%.1f F]” (gHall, gHSet) {channel=“zwave:device:e8358de4:node6:thermostat_setpoint_heating”}

Apparently the [%.1f F] was throwing off the PaperUI control panel. I removed the formatting portion, and it works as expected.

Number:Temperature TstatStageSouth_setpointheat “Stage South Heat Set” (gHall, gHSet) {channel=“zwave:device:e8358de4:node6:thermostat_setpoint_heating”}

I suspect that the web page (in the browser) was faulting on the rendering, then returning an UNDEF or NULL back to OH. So, this could be browser dependent, and it probably is not a problem when a browser is does not have an open tab to that view.

No, this has to do with Units of Measurements:

Okay, there’s a lot of information in a small page. It says:

If the parsing failed the locale based default conversion takes place.

Just thinking here. If I had used °F, it should have worked, but if the format was wrong, it should have done the default conversion.
I think this is in need of some more testing now that I can repeat the issue. For me, the questions to answer are:

  1. with the refusing behavior, does the behavior continue with a web page open to the command tab
  2. what default conversions work, and when are they not used.
    Since this is not checked for syntax, a failure of conversion should be logged. Perhaps it is, and my log level is not turned up enough.