Jump to content

Venstar T-3950IAQ doesn't respond to heat/cool setpoint settings

Scott Korvek

By Scott Korvek
in VenstarCT

Recommended Posts

Scott Korvek Experienced

Scott Korvek

Posted
Posted

Hello,

Just getting started with changing over all my thermostats to Venstar to use this nodeserver.  I have both the colortouch T7900s and the Explorer T3950IAQs, both of which are noted as supported by the nodeserver. 

All are online and connected to the nodeserver (direct IP address in the nodeserver configuration) and status changes by the thermostats are picked up by the nodeserver and displayed in the IOX admin console.

If I press increase or decrease setpoint in IOX via the button or via a program action, or directly set a setpoint value via program, it works with the color touch thermostats. The same action does not work with the explorers.  If I directly program a setpoint value, it changes in the IOX UI but not the thermostat display. With the next poll, the IOX UI reverts to the thermostat setting. Same with increase/decrease setpoint button pushes.

The thermostats are all newly installed (this week), using http protocol not https, and are again, all online and connected to the nodeserver. They're all on the most recent firmware.

The other oddity I've noticed is schedule mode. I have all thermostats set to non-programmable and "program off" is shown on the thermostats. Via the API info the thermostat reports schedule 0 and schedulepart 0. Yet the IOX UI keeps showing an active schedule. If I press the schedule mode off button, it briefly reports "inactive" but then quickly reverts to a time of day such as "morning" - yet the API still reports 0/0. The nodes for the color touch thermostats correctly report inactive schedule mode.

Perhaps there is an issue with parsing the API response? The responses are not identical, however parameter names are consistent when included.

Color Touch: 

curl http://xxx.xxx.xxx.xxx/query/info

{ 
 "name":"Kitchen",
 "mode":1,
 "state":0,
 "fan":0,
 "fanstate":0,
 "tempunits":0,
 "schedule":0,
 "schedulepart":255,
 "away":0,
 "spacetemp":70.0,
 "heattemp":64.0,
 "cooltemp":80.0,
 "cooltempmin":72.0,
 "cooltempmax":99.0,
 "heattempmin":35.0,
 "heattempmax":78.0,
 "activestage":0,
 "hum_active":0,
 "hum":44,
 "hum_setpoint":0,
 "dehum_setpoint":75,
 "setpointdelta":2.0,
 "availablemodes":0
 }

 

Explorer 

curl http://xxx.xxx.xxx.xxx/query/info

{
 "name":"Bedroom",
 "mode":1,
 "state":1,
 "activestage":1,
 "fan":0,
 "fanstate":0,
 "tempunits":0,
 "schedule":0,
 "schedulepart":0,
 "away":0,
 "spacetemp":69.0,
 "heattemp":71.0,
 "cooltemp":78.0,
 "cooltempmin":72.0,
 "cooltempmax":72.0,
 "heattempmin":78.0,
 "heattempmax":78.0,
 "setpointdelta":2,
 "hum":40,
 "availablemodes":1}

 

 

Any help would be appreciated.

Scott Korvek Experienced

Scott Korvek

Posted
  • Author
Posted

Adding a bit more detail:

 

I can directly set heat/cool setpoints via a direct API call and they are instantly reflected in the TSTAT UI and API query. They appear in the IOX UI as well after the next short poll as well. 

curl http://10.10.60.105/query/info
{"name":"Bedroom","mode":1,"state":1,"activestage":1,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":69.0,"heattemp":71.0,"cooltemp":78.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":40,"availablemodes":1}


POST http://xxx.xxx.xxx.xxx/control HTTP/1.1
Content-Type: application/x-www-form-urlencoded

mode=1&fan=0&heattemp=64&cooltemp=82


curl http://10.10.60.105/query/info
{"name":"Bedroom","mode":1,"state":0,"activestage":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":69.0,"heattemp":69.0,"cooltemp":82.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":39,"availablemodes":1}

So at least confirming it's not a network/Venstar API/Thermostat error.

Goose66 Advanced

Goose66

Posted
Posted

Addressing the two problems separately:

1. Schedule mode reporting: the API documentation says the schedpart will be 255 when schedule mode is inactive, and that's what the ColorTouch reports. The ColorTouch was the thermostat I had at hand when coding this node server, so I just used schedpart to determine the schedule setting - kind of a shortcut. Obviously, the Explorer does not report the same way, so I need to go back and look at the schedule state and the schedpart to report the schedule status values to IoX - should be an easy fix. 

2. Temp setpoints: The API documentation sort of alludes to a requirement that you have to send all four settings in the settings POST (like you do in your curl test), but the ColorTouch didn't enforce any such requirement. Accordingly, the node server only sends the settings that are changing (after testing modes and setpoint deltas). That may be why the Explorer is not accepting the setpoint changes from the node server. The REST API will report success but put an error message in the return data if the POST command is not successful. Look in the node server log and do a search for "Error message returned from control API" (or some part thereof) and see if you see any messages. Or better yet, send a copy of the logs and I can take a look. If that turns out to be the problem, that would be an easy fix too.

Goose66 Advanced

Goose66

Posted
Posted (edited)

Actually, you said the setpoints update temporarily in the Admin Console, but then go back on the next poll, so I assume you won't find the "Error message returned from control API" messages in your logs.

Also, I notice that the setpoints in the second query after the POST in your curl test don't match the setpoint values actually set in the POST. Are you sure you are POSTing to the same thermostat that you are querying and not the ColorTouch thermostat (stupid question but I had to ask)? Is it possible that the Explorer has screen lock set requiring a PIN to change the settings?

 

Edited by Goose66
Scott Korvek Experienced

Scott Korvek

Posted
  • Author
Posted

Schedule mode: Agreed- should be an easy fix- the API documentation lists both schedulepart and scheduledetail but doesn't detail which thermostats report what. All of the possible responses are detailed but it's not very clear on which are actually used. On the Explorers you can set the thermostat to programmable 7 day, learning, or nonprogrammable.  On the ColorTouches you cannot set it to nonprogrammable, but you can disable each timeslot of the program as well as set it the program active/inactive.

Temp setpoints: I initially tried just changing one parameter on the Colortouch via the API (mode) and it didn't work- wherein I discovered in the API docs that is appears to indicate you have to send both heat and cool setpoints together as one command. While odd I figure it's standardized in case auto mode is specified.

That is the behavior on the currently released firmware for my ColorTouch but NOT the Explorers. 

I just did some more rigorous testing because I'm confusing myself here:

ColorTouch (Firmware version VH6.93)

Unless I send both heattemp and cooltemp setpoints together in one call I get an error that "Both Setpoints are required". So perhaps they've changed the API. I cannot tell as it's not versioned with a changelog.  I can send the fan setting individually and I get success responses and the expected behavior. If I try to change the mode individually, I get an error back "Missing Setpoints when changing mode".  So it appears on the ColorTouch now that fan is ok individually, mode requires both setpoints, and any setpoint change requires both setpoints.

Explorer (FW 5.28)

I can send any of the 4 parameters- mode, fan, heattemp or cooltemp individually via the API and I get a success:true message and the expected behavior.  (???) Tested with multiple thermostats- all same FW (latest)- I have 2 ColorTouch and 5 Explorers at the moment.

I can send both setpoints at the same time heattemp=68&cooltemp=75 and I also get a success message and the thermostat responds. I can send a mode setting along with both setpoints and I also get a success message and the thermostat responds appropriately.

 

However:

I can send increase/decrease setpoint commands to the ColorTouches via the IOX buttons. The UI changes instantly, then after a short lag the thermostat responds. Same with schedule mode.

With the Explorers, I cannot. The UI changes then flips back at the next shortpoll.

Here's the nodeserver log when I send an "increase setpoint" command by pressing the button in IOX for an Explorer thermostat: 

2023-11-06 12:44:22,862 MQTT       udi_interface.interface DEBUG    interface:_message: QUEUING incoming message command
2023-11-06 12:44:22,862 MQTT       udi_interface.interface DEBUG    interface:_message: QUEUING incoming message command
2023-11-06 12:44:22,864 Command    udi_interface.interface DEBUG    interface:_parseInput: DEQUEING command
2023-11-06 12:44:22,865 Command    udi_interface      INFO     nodes:cmd_inc_dec: Increase or decrease temperature of OFFICE in command handler: {'address': 'xa0a3c68', 'cmd': 'BRT', 'query': {}}.
2023-11-06 12:44:22,866 Command    udi_interface      DEBUG    venstarapi:getThermostatState: in API getThermostatState()...
2023-11-06 12:44:22,864 Command    udi_interface.interface DEBUG    interface:_parseInput: DEQUEING command
2023-11-06 12:44:22,865 Command    udi_interface      INFO     nodes:cmd_inc_dec: Increase or decrease temperature of OFFICE in command handler: {'address': 'xa0a3c68', 'cmd': 'BRT', 'query': {}}.
2023-11-06 12:44:22,866 Command    udi_interface      DEBUG    venstarapi:getThermostatState: in API getThermostatState()...
2023-11-06 12:44:22,867 Command    udi_interface      DEBUG    venstarapi:_call_api: HTTP GET http://10.10.60.104/query/info data: None
2023-11-06 12:44:22,867 Command    udi_interface      DEBUG    venstarapi:_call_api: HTTP GET http://10.10.60.104/query/info data: None
2023-11-06 12:44:22,971 Command    udi_interface      DEBUG    venstarapi:_call_api: HTTP response code: 200 data: {"name":"OFFICE","mode":1,"state":0,"activestage":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":70.0,"heattemp":70.0,"cooltemp":78.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":35,"availablemodes":0}
2023-11-06 12:44:22,971 Command    udi_interface      DEBUG    venstarapi:_call_api: HTTP response code: 200 data: {"name":"OFFICE","mode":1,"state":0,"activestage":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":70.0,"heattemp":70.0,"cooltemp":78.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":35,"availablemodes":0}
2023-11-06 12:44:22,973 Command    udi_interface      DEBUG    venstarapi:setThermostatControls: in API setThermostatControls()...
2023-11-06 12:44:22,973 Command    udi_interface      DEBUG    venstarapi:setThermostatControls: in API setThermostatControls()...
2023-11-06 12:44:22,974 Command    udi_interface      DEBUG    venstarapi:_call_api: HTTP POST http://10.10.60.104/control data: {'heattemp': 71.0, 'cooltemp': 78.0}
2023-11-06 12:44:22,974 Command    udi_interface      DEBUG    venstarapi:_call_api: HTTP POST http://10.10.60.104/control data: {'heattemp': 71.0, 'cooltemp': 78.0}
2023-11-06 12:44:23,828 Command    udi_interface      DEBUG    venstarapi:_call_api: HTTP response code: 200 data: {"success": true}
2023-11-06 12:44:23,828 Command    udi_interface      DEBUG    venstarapi:_call_api: HTTP response code: 200 data: {"success": true}
2023-11-06 12:44:23,830 Command    udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE Reporting set CLISPH to 71.0 to Polyglot
2023-11-06 12:44:23,830 Command    udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE Reporting set CLISPH to 71.0 to Polyglot
2023-11-06 12:44:23,831 Command    udi_interface.node DEBUG    node:reportDriver: Updating value to 71.0
2023-11-06 12:44:23,832 Command    udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in CLISPC's value
2023-11-06 12:44:23,831 Command    udi_interface.node DEBUG    node:reportDriver: Updating value to 71.0
2023-11-06 12:44:23,832 Command    udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in CLISPC's value
2023-11-06 12:44:23,850 Thread-1   udi_interface.interface DEBUG    interface:_send: PUBLISHING {'set': [{'address': 'xa0a3c68', 'driver': 'CLISPH', 'value': '71.0', 'uom': 17, 'text': None}]}
2023-11-06 12:44:23,850 Thread-1   udi_interface.interface DEBUG    interface:_send: PUBLISHING {'set': [{'address': 'xa0a3c68', 'driver': 'CLISPH', 'value': '71.0', 'uom': 17, 'text': None}]}
2023-11-06 12:44:23,966 MQTT       udi_interface.interface INFO     interface:_message: Successfully set xa0a3c68 :: CLISPH to 71.0 UOM 17
2023-11-06 12:44:23,966 MQTT       udi_interface.interface INFO     interface:_message: Successfully set xa0a3c68 :: CLISPH to 71.0 UOM 17

Odd- reports success. But the value did not change in the UI, nor the TSTAT. And the next poll puts it right back to the prior value:

  

2023-11-06 12:44:36,268 Thread-15645 udi_interface      DEBUG    venstarapi:getThermostatState: in API getThermostatState()...
2023-11-06 12:44:36,269 Thread-15645 udi_interface      DEBUG    venstarapi:_call_api: HTTP GET http://10.10.60.104/query/info data: None
2023-11-06 12:44:36,417 Thread-15645 udi_interface      DEBUG    venstarapi:_call_api: HTTP response code: 200 data: {"name":"OFFICE","mode":1,"state":0,"activestage":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":70.0,"heattemp":70.0,"cooltemp":78.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":35,"availablemodes":0}
2023-11-06 12:44:36,417 Thread-15645 udi_interface      DEBUG    venstarapi:_call_api: HTTP response code: 200 data: {"name":"OFFICE","mode":1,"state":0,"activestage":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":70.0,"heattemp":70.0,"cooltemp":78.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":35,"availablemodes":0}
2023-11-06 12:44:36,419 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in GV0's value
2023-11-06 12:44:36,419 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in GV0's value
2023-11-06 12:44:36,420 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in ST's value
2023-11-06 12:44:36,421 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE Reporting set CLISPH to 70.0 to Polyglot
2023-11-06 12:44:36,422 Thread-15645 udi_interface.node DEBUG    node:reportDriver: Updating value to 70.0
2023-11-06 12:44:36,423 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in CLISPC's value
2023-11-06 12:44:36,420 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in ST's value
2023-11-06 12:44:36,421 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE Reporting set CLISPH to 70.0 to Polyglot
2023-11-06 12:44:36,422 Thread-15645 udi_interface.node DEBUG    node:reportDriver: Updating value to 70.0
2023-11-06 12:44:36,423 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in CLISPC's value
2023-11-06 12:44:36,424 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in CLIMD's value
2023-11-06 12:44:36,425 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in CLIFS's value
2023-11-06 12:44:36,426 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in CLIHCS's value
2023-11-06 12:44:36,424 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in CLIMD's value
2023-11-06 12:44:36,425 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in CLIFS's value
2023-11-06 12:44:36,426 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in CLIHCS's value
2023-11-06 12:44:36,427 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in CLIFRS's value
2023-11-06 12:44:36,428 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in CLISMD's value
2023-11-06 12:44:36,429 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in CLIHUM's value
2023-11-06 12:44:36,430 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in GV1's value
2023-11-06 12:44:36,431 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in GV2's value
2023-11-06 12:44:36,427 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in CLIFRS's value
2023-11-06 12:44:36,428 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in CLISMD's value
2023-11-06 12:44:36,429 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in CLIHUM's value
2023-11-06 12:44:36,430 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in GV1's value
2023-11-06 12:44:36,431 Thread-15645 udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE No change in GV2's value

As you stated, I do not find those error messages in the logs. While repeatedly testing right now while watching the logs on a different computer, sometimes I see the value temporarily change in the UI then revert, sometimes I don't see it change- given the frequency of shortpolling I think it depends on when the command comes in in relation to the polls.

Similarly any changes to schedulemode in IOX for an Explorer reverts back at the next shortpoll.

Also note you ARE sending both heattemp and cooltemp at the same time. If I send a mode command, you are sending mode + both setpoints.

In programs, I can properly control the ColorTouches mode and setpoints, but not the Explorers. 

(I created a test program with only an action statement to change the mode) 

2023-11-06 14:07:12,022 Command    udi_interface      DEBUG    venstarapi:_call_api: HTTP GET http://10.10.60.104/query/info data: None
2023-11-06 14:07:13,221 Command    udi_interface      DEBUG    venstarapi:_call_api: HTTP response code: 200 data: {"name":"OFFICE","mode":1,"state":0,"activestage":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":70.0,"heattemp":68.0,"cooltemp":75.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":35,"availablemodes":0}
2023-11-06 14:07:13,221 Command    udi_interface      DEBUG    venstarapi:_call_api: HTTP response code: 200 data: {"name":"OFFICE","mode":1,"state":0,"activestage":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":70.0,"heattemp":68.0,"cooltemp":75.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":35,"availablemodes":0}
2023-11-06 14:07:13,222 Command    udi_interface      DEBUG    venstarapi:setThermostatControls: in API setThermostatControls()...
2023-11-06 14:07:13,222 Command    udi_interface      DEBUG    venstarapi:setThermostatControls: in API setThermostatControls()...
2023-11-06 14:07:13,223 Command    udi_interface      DEBUG    venstarapi:_call_api: HTTP POST http://10.10.60.104/control data: {'mode': 2, 'heattemp': 68.0, 'cooltemp': 75.0}
2023-11-06 14:07:13,223 Command    udi_interface      DEBUG    venstarapi:_call_api: HTTP POST http://10.10.60.104/control data: {'mode': 2, 'heattemp': 68.0, 'cooltemp': 75.0}
2023-11-06 14:07:14,407 Command    udi_interface      DEBUG    venstarapi:_call_api: HTTP response code: 200 data: {"success": true}
2023-11-06 14:07:14,407 Command    udi_interface      DEBUG    venstarapi:_call_api: HTTP response code: 200 data: {"success": true}
2023-11-06 14:07:14,408 Command    udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE Reporting set CLIMD to 2 to Polyglot
2023-11-06 14:07:14,408 Command    udi_interface.node DEBUG    node:setDriver: xa0a3c68:OFFICE Reporting set CLIMD to 2 to Polyglot
2023-11-06 14:07:14,409 Command    udi_interface.node DEBUG    node:reportDriver: Updating value to 2
2023-11-06 14:07:14,409 Command    udi_interface.node DEBUG    node:reportDriver: Updating value to 2
2023-11-06 14:07:14,416 Thread-1   udi_interface.interface DEBUG    interface:_send: PUBLISHING {'set': [{'address': 'xa0a3c68', 'driver': 'CLIMD', 'value': '2', 'uom': 67, 'text': None}]}
2023-11-06 14:07:14,416 Thread-1   udi_interface.interface DEBUG    interface:_send: PUBLISHING {'set': [{'address': 'xa0a3c68', 'driver': 'CLIMD', 'value': '2', 'uom': 67, 'text': None}]}
2023-11-06 14:07:14,542 MQTT       udi_interface.interface INFO     interface:_message: Successfully set xa0a3c68 :: CLIMD to 2 UOM 67
2023-11-06 14:07:14,542 MQTT       udi_interface.interface INFO     interface:_message: Successfully set xa0a3c68 :: CLIMD to 2 UOM 67

Nothing happens at the Thermostat.

If I post the same command manually: 

POST http://10.10.60.104/control HTTP/1.1 Content-Type:application/x-www-form-urlencoded mode=2&heattemp=68&cooltemp=75

instantly the Explorer thermostat responds.

The tempunits is set to 0- everything is in Fahrenheit. The delta is appropriate. If I send the same command as above with the tenth degree decimal place specified (78.0) it still responds properly.

I have no setting lock on any thermostat.

Re: command inconsistency in my report: Might have copied the wrong line back in as an example as I sent commands well before I started drafting the report. Apologies for the confusion. Given the behavior I'm seeing, I'm thoroughly confused.  But I am sure I'm testing the correct thermostats by IP address and the names programmed into the thermostats match the IOX UI, as do their settings when queried. Their IP addresses match my DHCP reservations. I can send an API command and then watch the IOX report change to match at the next poll as well as do this while standing right in front of the thermostat I'm controlling.

Since the first post I set up SkyPort and enrolled the thermostats- I can control them at will via their service. I'm on version 3.0.11 of your nodeserver.

Scott Korvek Experienced

Scott Korvek

Posted
  • Author
Posted

Could this have anything to do with it?  (TL;DR No it doesn't)

  

# Venstar ColorTouch Local REST API v4 spec.
_API_HTTP_HEADERS = {}
        try:
            response = self._session.request(
                method,
                url,
                params = params, 
                headers = _API_HTTP_HEADERS, # same every call     
                timeout= _HTTP_POST_TIMEOUT if method == "POST" else _HTTP_GET_TIMEOUT

 

When sending a POST request via the API the documentation states 

POST /control HTTP/1.1
Content-Type: application/x-www-form-urlencoded
mode=0&fan=0&heattemp=70&cooltemp=75

 

Is the "Content-Type" header missing or am I missing something in the code (not a python developer)

When I POST that via VS Code REST extension 

POST http://10.10.60.104/control HTTP/1.1
Content-Type: application/x-www-form-urlencoded

mode=1&heattemp=69.0&cooltemp=75.0

It works. 

When I omit that header It still works on both CT and Explorer. 

Well it was a thought at least.

Scott Korvek Experienced

Scott Korvek

Posted
  • Author
Posted

In absence of working control of Explorers I've created some network resources and 4 additional variables per Tstat to essentially mimic the nodeserver. The nodeserver is still used for polling, but multiple programs exist (previously planned) to compare desired to actual state. If there is a difference, the new integer variables are set (mode,fan,heattemp,cooltemp) and then passed to a network resource for the tstat to set the desired parameters. There's a wait in there to allow another poll prior to setting/calling to prevent a race condition among programs. I use a separate resource for each thermostat instead of passing the (fixed) IP as a URL parameter as often multiple need to be set at the same event (away setback for example) and each zone can be in different states (heating vs idle or with different setpoints) so it seemed best not to re-use the variables across the home, but that means 40 variables and 10 network resources.  For consistency and simplicity amongst programs and variables and overall approach I'm going to replace the direct settings of the colortouch thermostats with the same setup as well. That actually allows for easier control as all 4 can be specified in one API call rather than setting a heat setpoint, adding in a poll wait, then setting a cool setpoint which leads to logic loops. Alternative is separate programs for each of mode, fan, heat and cool setpoints for each TSTAT and each state (sleep, occupied, vacant, away, vacation)- a lot of additional programming.

 

Goose66 Advanced

Goose66

Posted
Posted

Here's something to try: using curl try posting to each thermostat with temperature values in floating point format, i.e. instead of "71", try "71.0". I am wondering if that works for ColorTouch but not Explorer.

Scott Korvek Experienced

Scott Korvek

Posted
  • Author
Posted

Yes, I tried that as noted above (lots of detail, I know- thinking my way through it).

 

Integer "heattemp=68&cooltemp=75" or floating point/decimal "heattemp=68.0&cooltemp=75.0" makes no difference- both are supported on both models of thermostats. 

Currently with the network resource approach I'm directly using an integer variable without any issue.

Direct curl commands 

curl -X POST -d 'heattemp=71&cooltemp=78' http://10.10.60.104/control
{"success": true}%
curl http://10.10.60.104/query/info

{"name":"OFFICE","mode":1,"state":1,"activestage":1,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":70.0,"heattemp":71.0,"cooltemp":78.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":36,"availablemodes":0}%
curl -X POST -d 'heattemp=70.0&cooltemp=76.0' http://10.10.60.104/control
{"success": true}%
curl http://10.10.60.104/query/info
{"name":"OFFICE","mode":1,"state":0,"activestage":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":70.0,"heattemp":70.0,"cooltemp":76.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":36,"availablemodes":0}%

 

I'm still wondering if the POST format header matters. Without specifying a content-type directly, curl sends the data using the application/x-www-form-urlencoded Content-Type.  I don't know what the default type is for the REST extension I was using in VS Code but omitting the header also worked, so I'm assuming it's the same. I'm explicitly using that header in the network resources.   In your nodeserver, no headers are defined. Do you know what the default format is for the library you use?

 

Although with testing I'm not sure as I get an error response with the POST to the Explorers using multipart form data content type which I would expect to see in the nodeserver logs, but I do not.  On the other hand, the ColorTouch reports success with multipart form data - but does not change the setpoints.

  

curl -X POST -F 'heattemp=62.0' -F 'cooltemp=76.0' http://10.10.60.104/control
{"error":true, "reason": "'--------------------------2ee368cbd9439dfe
Content-Disposition: form-data; name' Datapoint does not exist"}%
 
curl http://10.10.60.104/query/info
{"name":"OFFICE","mode":1,"state":0,"activestage":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":70.0,"heattemp":70.0,"cooltemp":76.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":36,"availablemodes":0}%
 
curl -X POST -F 'heattemp=62.0' -F 'cooltemp=76.0' http://10.10.60.103/control
{"success":true}%
 
curl http://10.10.60.103/query/info
{"name":"Master Bedroom","mode":1,"state":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":255,"away":0,"spacetemp":68.0,"heattemp":69.0,"cooltemp":75.0,"cooltempmin":72.0,"cooltempmax":99.0,"heattempmin":35.0,"heattempmax":78.0,"activestage":0,"hum_active":0,"hum":47,"hum_setpoint":0,"dehum_setpoint":80,"setpointdelta":2.0,"availablemodes":0}%

10.10.60.104 is an Explorer

10.10.60.103 is  ColorTouch

 

Similarly if I explicitly set the content type to JSON I get an error on the Explorer and nothing is changed but I get a success on the ColorTouch yet settings are not changed. 

curl -X POST -H "Content-Type: application/json" -d '{"heattemp":63,"cooltemp":79}' http://10.10.60.104/control
{"error":true, "reason":"Incorrectly formated request"}%

curl http://10.10.60.104/query/info
{"name":"OFFICE","mode":1,"state":1,"activestage":1,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":0,"away":0,"spacetemp":69.0,"heattemp":70.0,"cooltemp":76.0,"cooltempmin":72.0,"cooltempmax":72.0,"heattempmin":78.0,"heattempmax":78.0,"setpointdelta":2,"hum":36,"availablemodes":0}%

curl -X POST -H "Content-Type: application/json" -d '{"heattemp":63,"cooltemp":79}' http://10.10.60.103/control
{"success":true}%

curl http://10.10.60.103/query/info
{"name":"Master Bedroom","mode":1,"state":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":255,"away":0,"spacetemp":69.0,"heattemp":69.0,"cooltemp":75.0,"cooltempmin":72.0,"cooltempmax":99.0,"heattempmin":35.0,"heattempmax":78.0,"activestage":0,"hum_active":0,"hum":46,"hum_setpoint":0,"dehum_setpoint":80,"setpointdelta":2.0,"availablemodes":0}%

 

 

 

 

 

Guest
This topic is now closed to further replies.
Go to topic listing
×
×
  • Create New...