Thermostat Widget Only Sends Celsius

[Cash at Folsom]

I am using a CT100 thermostat with r522, with the generic thermostat widget.  My locale settings are set for Fahrenheit, as is the thermostat itself.  The issue is that the widget is not able to update the heating and cooling setpoints, and appears to be sending Celsius values regardless of locale settings.  Therefore the widget displays my chosen setpoint, but the thermostat does not honor the command.

Using the following from a browser is able to change the setpoints on the thermometer immediately:

http://<HG address>/api/HomeAutomation.ZWave/<Node>/Thermostat.SetPointSet/Cooling/80

Code: [Select]

2016-06-18 07:57:17.0552 Info WebServiceGateway 192.168.0.1 HTTP GET 200 /api/HomeAutomation.ZWave/10/Thermostat.SetPointSet/Cooling/80 [OPEN]
2016-06-18 07:57:17.0552 Debug ZWaveMessage (RawData=01-0C-00-13-0A-05-43-01-02-09-50-05-3B-C8)
2016-06-18 07:57:17.0552 Debug ZWaveMessage (Direction=Outbound, Header=SOF, NodeId=10, Type=Request, Function=SendData, CommandClass=ThermostatSetPoint, CallbackId=59, CallbackStatus=NotSet)
2016-06-18 07:57:17.0552 Info HomeAutomation.ZWave 10 ZWave Node Thermostat.SetPoint.Cooling 80
2016-06-18 07:57:17.0552 Info WebServiceGateway 192.168.0.1 HTTP GET 200 /api/HomeAutomation.ZWave/10/Thermostat.SetPointSet/Cooling/80 [CLOSED AFTER 0.004 seconds]
2016-06-18 07:57:17.2992 Trace [[[ BEGIN REQUEST ]]]
2016-06-18 07:57:17.2992 Trace WaitAck
2016-06-18 07:57:17.2992 Trace Sending Message (Node=10, CallbackId=3B, Function=SendData, CommandClass=ThermostatSetPoint)
2016-06-18 07:57:17.2992 Debug 01-0C-00-13-0A-05-43-01-02-09-50-05-3B-C8
2016-06-18 07:57:17.3212 Debug 06-01-04-01-13-01-E8
2016-06-18 07:57:17.3212 Debug ZWaveMessage (RawData=01-04-01-13-01-E8)
2016-06-18 07:57:17.3212 Debug ZWaveMessage (Direction=Inbound, Header=SOF, NodeId=0, Type=Response, Function=SendData, CommandClass=NotSet)
2016-06-18 07:57:17.3212 Debug 06
2016-06-18 07:57:17.3212 Trace SendDataReady
2016-06-18 07:57:18.3773 Info WebServiceGateway 192.168.0.1 HTTP GET 200 /api/HomeAutomation.HomeGenie/Config/Interfaces.List/ [OPEN]
2016-06-18 07:57:18.3773 Info WebServiceGateway 192.168.0.1 HTTP GET 200 /api/HomeAutomation.HomeGenie/Config/Interfaces.List/ [CLOSED AFTER 0 seconds]
2016-06-18 07:57:18.5213 Debug 01-05-00-13-3B-00-D2
2016-06-18 07:57:18.5213 Debug ZWaveMessage (RawData=01-05-00-13-3B-00-D2)
2016-06-18 07:57:18.5213 Debug ZWaveMessage (Direction=Inbound, Header=SOF, NodeId=0, Type=Request, Function=SendData, CommandClass=NotSet)
2016-06-18 07:57:18.5213 Debug 06
2016-06-18 07:57:18.5213 Trace Complete
2016-06-18 07:57:18.5213 Trace [[[ END REQUEST ]]] took 1223 ms
But adjusting the setpoint to 80 via the widget dial produces:

Code: [Select]

2016-06-18 07:57:35.8993 Info WebServiceGateway 192.168.0.1 HTTP GET 200 /api/HomeAutomation.ZWave/10/Thermostat.SetPointSet/Cooling/26.666666666666664/ [OPEN]
2016-06-18 07:57:35.8993 Debug ZWaveMessage (RawData=01-0C-00-13-0A-05-43-01-02-09-1A-05-3D-84)
2016-06-18 07:57:35.8993 Debug ZWaveMessage (Direction=Outbound, Header=SOF, NodeId=10, Type=Request, Function=SendData, CommandClass=ThermostatSetPoint, CallbackId=61, CallbackStatus=NotSet)
2016-06-18 07:57:35.8993 Info HomeAutomation.ZWave 10 ZWave Node Thermostat.SetPoint.Cooling 26.6666666666667
2016-06-18 07:57:35.8993 Info WebServiceGateway 192.168.0.1 HTTP GET 200 /api/HomeAutomation.ZWave/10/Thermostat.SetPointSet/Cooling/26.666666666666664/ [CLOSED AFTER 0.004 seconds]
2016-06-18 07:57:35.9233 Trace [[[ BEGIN REQUEST ]]]
2016-06-18 07:57:35.9233 Trace WaitAck
2016-06-18 07:57:35.9233 Trace Sending Message (Node=10, CallbackId=3D, Function=SendData, CommandClass=ThermostatSetPoint)
2016-06-18 07:57:35.9233 Debug 01-0C-00-13-0A-05-43-01-02-09-1A-05-3D-84
2016-06-18 07:57:36.0243 Debug 06-01-04-01-13-01-E8
2016-06-18 07:57:36.0243 Debug ZWaveMessage (RawData=01-04-01-13-01-E8)
2016-06-18 07:57:36.0243 Debug ZWaveMessage (Direction=Inbound, Header=SOF, NodeId=0, Type=Response, Function=SendData, CommandClass=NotSet)
2016-06-18 07:57:36.0243 Debug 06
2016-06-18 07:57:36.0243 Trace SendDataReady
2016-06-18 07:57:37.1243 Debug 01-05-00-13-3D-00-D4
2016-06-18 07:57:37.1243 Debug ZWaveMessage (RawData=01-05-00-13-3D-00-D4)
2016-06-18 07:57:37.1243 Debug ZWaveMessage (Direction=Inbound, Header=SOF, NodeId=0, Type=Request, Function=SendData, CommandClass=NotSet)
2016-06-18 07:57:37.1243 Debug 06
2016-06-18 07:57:37.1243 Trace Complete
2016-06-18 07:57:37.1243 Trace [[[ END REQUEST ]]] took 1201 ms
In the meantime I can adjust setpoints via the browser, but it would be nice to get the widget working.

[Cash at Folsom]

This is incredibly strange.  Last night, the behavior reversed itself: Fahrenheit setpoints could be changed from the widget, but calling the api from a browser using Fahrenheit values resulted in them being interpreted as Celsius [and therefore ignored for being out of range].  And now this morning, back to the previous behavior.  It seems to change on a whim.

[Zen]

I have a different thermostat and my observations may not be applicable to you. In my case, I send Fahrenheit setpoints and thermostat replies back with Celsius values. If I don't get Celsius reply I know the thermostat didn't get a command and I wrote a program to retransmit setpoint value again. I have never saw the Homegenie intercepting browser direct API commands or changing values.

While the debug saying the direction is outbound, may be you are seeing thermostat replies in Celsius?

Note: my Thermostats ignore setpoint commands if the value doesn't change and won't reply back Celsius values in this case  (example, you try to send 75 setpoint value but it already was set at 75 before).

Btw, you can look at thermostat widget script and comment out part where it chooses Fahrenheit or Celsius to make Fahrenheit the only choice irrelevant of anything else.

[Cash at Folsom]

Thanks, I will play around with these ideas.

Unfortunately I don't immediately see anything in the logs that show the thermostat sending values back autonomously, only responding.  But it does respond when the system is working properly.

And the examples given were indeed temperature changes, and not duplicating the setpoint already entered.

Doesn't seem to be the same situation, but again, thanks for the food for thought.

[Cash at Folsom]

I used the recent beta update as an excuse to start fresh last night.  I removed and then re-included the thermostat in the fresh install, and could initially change the setpoints correctly via the widget--entering Fahrenheit values changed the thermostat to the appropriate Fahrenheit values.

When I woke this morning, the functionality was broken again.  The thermostat widget was reporting incorrect setpoint values: 167 degrees when the thermostat is set for--and operating correctly at--75.  This tells me the widget is running the setpoint value from the thermostat through C>F conversion, even though it is already in F.  I can still use API commands via HTTP to read and change the thermostat's current setpoint values in the widget correctly, but reading and changing the setpoint from the widget remains broken since last night.  The current temperature display seems unaffected.

So sometime during the night it appears HG decided to stop sending and reading F values for setpoints, and start interpreting them as C, even though they're not.  Not sure what this means.  I poked around in the widget code, but it's not really my forte, and I can't immediately determine where things may be going wrong.

[Gene]

the issue is originated here:

https://github.com/genielabs/zwave-lib-dotnet/blob/master/ZWaveLib/CommandClasses/ThermostatSetPoint.cs#L58

this is where scale type sent by the device when reporting temperature is stored and used later for sending setpoint requests.

[Cash at Folsom]

the issue is originated here:

https://github.com/genielabs/zwave-lib-dotnet/blob/master/ZWaveLib/CommandClasses/ThermostatSetPoint.cs#L58

this is where scale type sent by the device when reporting temperature is stored and used later for sending setpoint requests.

Thank you, Gene.  How can I use this knowledge to check on the error?  Is the device sending the wrong scale type perhaps [unlikely since API calls over HTTP using the Fahrenheit scale still work properly]?  Or is this variable somehow getting cleared or changed on HG's end over time?

[Gene]

by design hg api should always internally use Celsius, then make the appropriate conversion to Fahrenheit when needed. If the UI is configured for Fahrenheit it will convert from C to F. if the device is speaking Fahrenheit it will also convert the internal value always stored as C to F. the problem is the ZWaveLib that instead of querying the dev for supported scale unit, it makes a guess based on the scale received from the device when reporting temperature. The fix could be implementing the missing piece of code of the zwave protocol that is meant to query the device in order to acknowledge the correct unit the device is expecting to receive.
The reason why is working when you enter Fahrenheit in the api call is because zwavelib is actually guessing your device is speaking Celsius, so it makes no conversion and sends the value as is ( I suppose).
Last and quick dirty solution could be going to the widget editor and tweak the javascript code in order to send Farheneight.

[Zen]

I had the same issue when Thermostat widget sometimes shows 100+ temperature value. Normally thermostat operates at room temperature which is less then 40C and more then 40F, so I added similar to the following "if" statement in the Thermostat widget before C to F conversions:

if (temperature < 40) {
              temperature = (Math.round((temperature * 1. * 10) /10) + 32;
              }

Gene,

Is it possible to specify in my programs the direction of traffic, inbound or outbound? It would be very helpful to me to use for verification purpose. Also, it could be used in a case like this, when incoming data is in C and outgoing commands are in F.