ACCVWF1 reports wrong state on local API
Closed this issue · 4 comments
I've got a ACCVWF1 connected to a Voyager 3800. Yes - it's not a ColorTouch, but this Python library works great! Except for one bug in the Venstar ACCVWF1 firmware:
The ACCVWF1 wifi module reports the wrong 'state' - it reports state 2 when it is heating, and state 1 when it is cooling. The thermostat screen indicates heating, the system is providing warm air. But the API response definitions in the documentation are the other way around. (Meanwhile - my ColorTouch reports correctly on the system it's using). Even the Skyport Portal shows heating, while the local API reports state 2 (cooling).
I've asked VenStar if there is a firmware update available; no response. Meanwhile, figured I would report it as a possible issue to be coded around here (because I wouldn't be surprised if they coded around it in the Skyport portal code!)
The response to http:/// is:
{
"api_ver": 7,
"type": "residential",
"model": "VYG-3800",
"firmware": "2.22.19"
}
The response to the /INFO when the system is heating is this, which shows State 2, but the value for state when heating should be 1:
{
"name": "UPSTAIRS",
"mode": 3,
"state": 2,
"fan": 0,
"fanstate": 1,
"tempunits": 0,
"schedule": 1,
"schedulepart": 0,
"away": 0,
"spacetemp": 66,
"heattemp": 68,
"cooltemp": 73,
"cooltempmin": 70,
"cooltempmax": 99,
"heattempmin": 36,
"heattempmax": 74,
"setpointdelta": 2,
"activestage": 2,
"hum_active": 1,
"hum": 0,
"hum_setpoint": 0,
"dehum_setpoint": 99,
"availablemodes": 0
}
Can you try playing with this and let me know if it works or fix it if it doesn't? I haven't tested it or even tried running it.
https://github.com/hpeyerl/venstar_colortouch/tree/46_ACCVWF1_vyg-3800_wrong_state
Thanks @hpeyerl
I gave that a try, and it's still reporting state as '2' for COOLING. I thought your workaround fix for the issue would work, but it isn't, and I'm scratching my head.
For testing, I added print("Current state is {s}".format(s=ct.get_info("state"))) to the main.py. The output I got (edited for brevity) is:
python venstarcolortouch 192.168.33.11
Testing with IP: 192.168.33.11
logging in...
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): 192.168.33.11:80
DEBUG:urllib3.connectionpool:http://192.168.33.11:80 "GET / HTTP/1.1" 200 74
DEBUG:root:api_ver: 7
Login successful. API: 7 Type: residential
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): 192.168.33.11:80
DEBUG:urllib3.connectionpool:http://192.168.33.11:80 "GET /query/info HTTP/1.1" 200 336
WARNING:root:Unknown thermostat model VYG-3800, inferring API tempunits of Fahrenheit
Was able to get info:{'name': 'UPSTAIRS', 'mode': 3, 'state': 2, 'fan': 0, 'fanstate': 1, 'tempunits': 0, 'schedule': 1, 'schedulepart': 0, 'away': 0, 'spacetemp': 69, 'heattemp': 70, 'cooltemp': 79, 'cooltempmin': 70, 'cooltempmax': 99, 'heattempmin': 36, 'heattempmax': 74, 'setpointdelta': 2, 'activestage': 2, 'hum_active': 1, 'hum': 0, 'hum_setpoint': 0, 'dehum_setpoint': 99, 'availablemodes': 0}
Name is UPSTAIRS
Fan is 0
Heat setpoint is 70
Cool setpoint is 79
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): 192.168.33.11:80
DEBUG:urllib3.connectionpool:http://192.168.33.11:80 "GET /query/runtimes HTTP/1.1" 200 129
Runtimes: [{'ts': 1676201163, 'cool1': 0, 'cool2': 0, 'heat1': 57, 'heat2': 38, 'aux1': 0, 'aux2': 0, 'fc': 0, 'dualfuel': 0, 'uv': 0, 'hum': 0}]
API Version is 7
Thermostat Type is residential
Current state is 2
So it's reporting heating runtimes (only heating today) under heating, which is great. But the state is still wrong.
To fully address it in code would also require updating the set_mode routine too, and that's really getting into a lot of workaround for what is a bug in the Venstar Wi-Fi module firmware.
I reported it to Venstar tech support. They have benched it on their side and supposedly it works fine. They confirmed the firmware version (2.22) is the latest for the wi-fi module, and confirmed we should be seeing 'state': 1 A reset of my thermostat and wifi module to defaults didn't resolve it.
I appreciate you taking a look at this. Since I've got Venstar support looking at it, let's see if we can get them to fix their bug (or my particular issue since they can't replicate it) instead of making a bunch of workaround changes to accommodate this.
I will update this issue once I get farther with their support.
Venstar support said they have replicated the issue, and are working on a firmware fix. The firmware fix is pushed automatically to the Wi-Fi module if the system is connected to the Skyport portal.
I'll close this as an open issue, and will comment again when I hear that the firmware gets pushed.
Checked with new firmware 2.23.19 on the Voyager 3800, and it still reports the wrong state. I've emailed Venstar tech support to let them know they still have an issue with their thermostat.