Thermostat External Sensor temp not being updated

[hart2hart]

@Goose66I've got 3 Colortouch thermostats and each of them has an external temp sensor.  The Great Thermostat has stopped updating the sensor value in PG3x but it is still correct on the thermostat.

The remote sensor is outside and its value is 40 F.  I've restarted and stopped etc NS  and the value appears to be fixed at 79 F in the NS.  I've downloaded the log package and just DM'ed it to you.

[hart2hart]

Its not finishing the upload of 2.4m log file here or in DM.  

Edited December 7, 2023 by hart2hart

[hart2hart]

@Goose66 Have you found anything or need anything from me?

[Goose66]

It appears that the names of the sensors from Venstar thermostats were changed after the Discovery process that found the thermostat(s) and created the nodes. For example, the sensor node for the Outdoor temp was initially created with the name "Outdoor Temp Sensor" but now appears to be called "Outdoor." Because the remote sensors are separate nodes, they have node addresses that are an extension of the thermostat node address, and the way the plugin links them back to the node is through the name, so the names have to match what the original node has. 

Two ways to fix this: 1) change the names of the remote sensors back to what they were (you can see these names in the Node listing in PG3 Dashboard) or 2) remove the node and rediscover the thermostats. If choosing #2, remember that the dynamic discovery no longer functions because of a change made in PG3/PG3x. I need to fix that, but in the meantime you can just list the hostnames/IP addresses of your thermostats in the "hostname" Custom Configuration Parameter (separated by semicolons) and then click "Discover" in the PG3 Dashboard to recreate all the nodes. The nodes should retain the same addresses, so your programs should all continue to work.

[hart2hart]

@Goose66 , thanks so much for figuring that out and sorry as it appears I caused the issue. I’ll simply rename it back to original name.

[hart2hart]

@Goose66 sorry but I’m lost again. All the names for the node in IOx AC and PG3x Nodes are showing as Outdoor Temp Sensor.

Where are you seeing Outdoor? In retrospect, I do recall trying to give it that name in AC and then going back to the original name in same session.

 

I see the following in the log but can't find a place to rename it.

2023-12-27 18:20:24,517 Thread-44  udi_interface      DEBUG    venstarapi:getThermostatState: in API getThermostatState()...
2023-12-27 18:20:24,518 Thread-44  udi_interface      DEBUG    venstarapi:_call_api: HTTP GET http://192.168.1.183/query/info data: None
2023-12-27 18:20:24,521 Thread-43  udi_interface      DEBUG    venstarapi:_call_api: HTTP response code: 200 data: {"sensors":[{"name":"Thermostat","temp":71.0,"hum":47},{"name":"Space Temp","temp":71.0},{"name":"Outdoor","temp":49.0}]}
2023-12-27 18:20:24,522 Thread-43  udi_interface      DEBUG    venstarapi:getRuntimes: in API getSensorState()...
2023-12-27 18:20:24,522 Thread-43  udi_interface      DEBUG    venstarapi:_call_api: HTTP GET http://192.168.1.183/query/runtimes data: None
2023-12-27 18:20:24,545 Thread-44  udi_interface      DEBUG    venstarapi:_call_api: HTTP response code: 200 data: {"name":"Great Room","mode":1,"state":0,"fan":0,"fanstate":1,"tempunits":0,"schedule":0,"schedulepart":255,"away":0,"spacetemp":71.0,"heattemp":71.0,"cooltemp":73.0,"cooltempmin":35.0,"cooltempmax":99.0,"heattempmin":35.0,"heattempmax":99.0,"activestage":0,"hum_active":1,"hum":47,"hum_setpoint":48,"dehum_setpoint":99,"setpointdelta":2.0,"availablemodes":0}
2023-12-27 18:20:24,546 Thread-43  udi_interface      DEBUG    venstarapi:_call_api: HTTP response code: 200 data: {"runtimes":[{"ts":1703203200,"heat1":351,"heat2":0,"cool1":0,"cool2":0,"aux1":0,"aux2":0,"fc":0},{"ts":1703289600,"heat1":300,"heat2":0,"cool1":0,"cool2":0,"aux1":0,"aux2":0,"fc":0},{"ts":1703376000,"heat1":162,"heat2":0,"cool1":0,"cool2":0,"aux1":0,"aux2":0,"fc":0},{"ts":1703462400,"heat1":68,"heat2":0,"cool1":70,"cool2":0,"aux1":0,"aux2":0,"fc":0},{"ts":1703548800,"heat1":9,"heat2":0,"cool1":0,"cool2":0,"aux1":0,"aux2":0,"fc":0},{"ts":1703635200,"heat1":191,"heat2":0,"cool1":0,"cool2":0,"aux1":0,"aux2":0,"fc":0},{"ts":1703701223,"heat1":361,"heat2":0,"cool1":0,"cool2":0,"aux1":0,"aux2":0,"fc":0}]}
2023-12-27 18:20:24,546 MQTT       udi_interface.interface INFO     interface:_message: Successfully set c0a801b7 :: GV11 to 0 UOM 25
2023-12-27 18:20:24,547 Thread-44  udi_interface.node DEBUG    node:setDriver: c0a801b7:Great Thermostat No change in GV0's value

 

 

Only thing I see in nodes is:

 

Node Name 3    Address    NodeDef    Primary Node    Hint    Enabled    Is Primary    Delete
Outdoor Temp Sensor    c0a801b7_s1    SENSOR    c0a801b7    16974592    true    false    
Name    Driver    UOM    Value    Variable
BATLVL    51    0    ${sys.node.n015_c0a801b7_s1.BATLVL}  
ST    17    79.0    ${sys.node.n015_c0a801b7_s1.ST}  

 

 

From AC:

 

Edited December 28, 2023 by hart2hart

[Goose66]

It needs to be renamed in the Venstar thermostat.

[Goose66]

Look at the third entry of the log entries you posted above. The Thermostat is reporting it as “Outdoor” instead of “Outdoor Temp Sensor”. So it can’t match it up.

Edited December 28, 2023 by Goose66

[hart2hart]

1 hour ago, Goose66 said:

Look at the third entry of the log entries you posted above. The Thermostat is reporting it as “Outdoor” instead of “Outdoor Temp Sensor”. So it can’t match it up.

You can't name it in the thermostat.  All you can do is pick a type:

o Outdoor

o Remote

o Supply

o Return

It's only been a little while since I made the change I mentioned so should have recalled it better.  Anyways, thinking it was originally set to Remote at the time of discovery and I "corrected it" and set it to Outdoor which is where the sensor was and is located.   I just reset it to sensor type of Remote and the NS appears to be getting the correct temp now -- I'll have to wait to see if it changes with as temp changes to be sure.  Is there any way to confirm it was originally Remote at time of discovery and that my changing it to Outdoors created this issue.   The thermostat shows the Outside Temp at a nearby weather reporting station unless the sensor is set to Outdoor.  When set to Outdoor, the thermostat displays the sensor reading as outside in climate displays which is why I adjusted it.  The point was so I could quickly see the outside reading on thermostat face very easy to confirm some programming actions based on outdoor temp. Additionally, and in some cases more important is that my true local temp is usally 2-4 degrees off from distant official weather stations like at the Nashville Airport.

I'm wondering if there is an issue when selecting the sensor type of Outside instead of Remote in that it does something different with the NS.  I renamed two other remote sensors on the other thermostats, and they continue to register correctly.  I just reviewed my topology listings that I save after all changes and the name always shows Outdoor Temp Sensor.  Again, I think, I changed the type and not the name.

Again, Thanks for looking at this and hoping it means new knowledge of the NS related to the wired sensor.  

[hart2hart]

Adding a bit more information... The log entry about "Outdoor" has now changed to "Remote" after I changed the Sensor Type.  It is updating the NS with the correct temperature.  Does the CoolTouch API designate the sensor by type -- appears so from log?  I'm a little surprised that they would do this as you can only have one wired sensor, but then I recall they added a WiFi sensor so maybe that's why the type is so important.  I've had a WiFi sensor still in its box for a few years.  If I can find it do, we want to experiment with adding it to thermostat and see what types it can be set to...

To me, clearly now me changing the Sensor Type from Remote to Outdoor was the root cause of my issue but its discovery will likely add to the cause.

2023-12-28 06:53:03,643 Thread-3455 udi_interface      DEBUG    venstarapi:_call_api: HTTP GET http://192.168.1.183/query/sensors data: None
2023-12-28 06:53:03,653 Thread-3455 udi_interface      DEBUG    venstarapi:_call_api: HTTP response code: 200 data: {"sensors":[{"name":"Thermostat","temp":72.0,"hum":40},{"name":"Space Temp","temp":72.0},{"name":"Remote","temp":33.0}]}
2023-12-28 06:53:03,653 Thread-3455 udi_interface.node DEBUG    node:setDriver: c0a801b7_s0:Thermostat No change in ST's value
2023-12-28 06:53:03,654 Thread-3455 udi_interface.node DEBUG    node:setDriver: c0a801b7_s0:Thermostat No change in BATLVL's value
2023-12-28 06:53:03,654 Thread-3455 udi_interface.node DEBUG    node:setDriver: c0a801b7_s1:Remote No change in ST's value
2023-12-28 06:53:03,654 Thread-3455 udi_interface.node DEBUG    node:setDriver: c0a801b7_s1:Remote No change in BATLVL's value

[Goose66]

I have to go back to the code again - thought I understood how it worked.

[Goose66]

Going through the code and the two log files you sent more thoroughly, it appears to work the way I understood it to work above. What you are saying is happening and what I see in your log files and in the code just don't comport.

It appears that the "name" of hardwired temperature sensors comes from the selected type, where wireless sensors have a separate, configurable name. It further appears that, after initial discovery, the names (not the addresses) of the nodes (both thermostat nodes and sensor nodes) were all changed in the Admin Console, and somehow these name changes propagated their way back into the PG3 database. I can see this in your log file(s) on the initial loads of the nodes on restart of the plugin. Now, this is not supposed to be possible, unless you modify the PG3 database directly. Another possibility is that an update to the Thermostat firmware changed the way the thermostat reports the sensor names through the API, but this doesn't seem likely given the specificity of some of the current node names.

Moreover, with the node names of the sensors like they currently are (i.e., 'Internal Temp sensor', 'Outdoor Temp Sensor', 'Attic Temp Sensor', and 'Media Temp Sensor') and the thermostats returning the names of the sensors as "Thermostat", "Outdoor", and "Remote", there should be no way that any of the sensor nodes are having the proper temperature reported.

I think the only way to make sure it is all correct is to delete all of your Thermostat and Sensor nodes from the plugin using PG3 Dashboard (allowing the change to propagate to IoX), restart the plugin, then perform the discovery again. All of the nodes when recreated should have all of the same node addresses so your programs should all work correctly.

I believe you should be able to change the names for thermostats and temperature sensors that appears in IoX through the Admin Console without changing the names from discovery in the PG3 database, but I am checking on that with some other folks.

[hart2hart]

@Goose66, thanks.  After changing sensor type setting on the physical thermostat from Outdoor to Remote and doing testing all is working well.

 

Edited January 3 by hart2hart