paulbates Posted August 22, 2016 Posted August 22, 2016 io_guy I know we've been waiting for an update to the colortouch FW to fix "the humidity readout issue". Its been over a year, and I recently asked tech support some very direct questions about it and the next FW update, which went unanswered after they requested and I provided clarification (below). I was wondering if you could make the same fix you made to venlink? The tag says this: It should be But it currently returns: "hum":0, Current Sensor hum_active "hum_setpoint":52, Humidification Set point hum "dehum_setpoint":10, Dehumidification set point hum_setpoint "hum_active":99 Calling for humidification dehum_setpoint Also, if you could pass the "hum_active" through as read only variable? It indicates when the Thermostat is calling for humidity and is useful for logging/reporting Paul
io_guy Posted August 23, 2016 Posted August 23, 2016 Paul, This is what I use (with latest firmware): Value NodeLink VenLink Humidity sensor(0).hum sensor(0).hum Hum Setpoint hum_setpoint not read - only calculated if you use autohumidity option Dehum Setpoint dehum_setpoint NOT SET Active NOT SET NOT SET The NodeLink humidity setpoint returning hum is the firmware bug (at least on mine). Not completely following how you want this changed, especially the dehum setpoint off of hum_active?
paulbates Posted August 23, 2016 Author Posted August 23, 2016 Rick I get nothing back for Humidity setpoint in the ISY, its been blank for me for both thermostats. When I read the http://x.x.x.x/query/info response from the thermostat, I used the values I could see on the Thermostat display and compared against what the response said. its formatted wrong. {"name":"Family%20Room","mode":2,"state":2,"fan":1,"fanstate":1,"tempunits":0,"schedule":0,"schedulepart":255,"away":0,"spacetemp":76.0,"heattemp":66.0,"cooltemp":74.0,"cooltempmin":35.0,"cooltempmax":99.0,"heattempmin":35.00,"heattempmax":99.0,"hum":0,"hum_setpoint":52,"dehum_setpoint":10,"hum_active":99,"setpointdelta":2.0,"availablemodes":0} The values are there, they can be found in the correct spot in the thermostat, they are reported back via /query/info.... however, they are being returned to the incorrect labels. My table above is the "decoder ring" for consuming the return correctly. I should start with me not seeing a value for Humidity setpoint in the ISY; should I be seeing that? It is reported in the query/info above, but as dehum_setpoint. This is kind of a kooky fw error, hopefully this makes sense. Paul
io_guy Posted August 23, 2016 Posted August 23, 2016 Can you return was you get from http://x.x.x.x and http://x.x.x.x/query/sensors I want to verify your firmware version. And if you want to confirm what is being written to the ISY just enable the main NodeLink ISY verbose log as well.
paulbates Posted August 23, 2016 Author Posted August 23, 2016 Its http://... {"api_ver":5,"type":"residential"} http://.../query/sensors {"sensors":[{"name":"Thermostat","temp":74.0,"hum":52},{"name":"Outdoor","temp":0.0}]} http://.../query/info {"name":"Family%20Room","mode":0,"state":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":255,"away":0,"spacetemp":74.0,"heattemp":66.0,"cooltemp":72.0,"cooltempmin":35.0,"cooltempmax":99.0,"heattempmin":35.00,"heattempmax":99.0,"hum":0,"hum_setpoint":52,"dehum_setpoint":10,"hum_active":63,"setpointdelta":2.0,"availablemodes":0} The "My Thermostat" panel says VH 4.08-1A Paul
io_guy Posted August 23, 2016 Posted August 23, 2016 I get humidity from the sensors(0).hum data. The regular hum being 0 is a Venstar Bug, as is the hum_setpoint being the actual hum. I believe I see a bug in NodeLink where humidity setpoint won't be sent to the ISY if you're not using the autohumidity and also don't have the ISY climate module. That being said once fixed it will either be what is set by autohumidity or wrong due to the bug above. Not sure what you meant by the dehum setpoint being hum setpoint - you're humidity setpoint is 10%? Still struggling to correlate everything. Unfortunately I don't know the extent of the Venstar bug with dehum and the active variable is not documented.
paulbates Posted August 23, 2016 Author Posted August 23, 2016 I do have humidity setpoint is set to 10 and autohumidity is off, for the summer. I set humidity higher and autohumidity on in the winter. I do have the climate module. I was guessing the 'active' would be the thermostat reporting out when it was actively calling for humidity. Unfortunately the current ambient humidity is too high to simulate that right now in mid summer. One way to see it is to set all of the humidity items to discrete, unique values in your thermostat, do a query info and see that it doesn't line up to their own labels. EDIT, I did turn autohumidity back on, and the setpoint does populate... but in the ISY its also identical to the current humidity from the sensor, this is incorrect. What should be populated here is the value "dehum setpoint"... that is the bug, the lables are mixed up. Run a query/info and compare values to your thermostat. {"name":"Family%20Room","mode":0,"state":0,"fan":0,"fanstate":0,"tempunits":0,"schedule":0,"schedulepart":255,"away":0,"spacetemp":73.0,"heattemp":66.0,"cooltemp":72.0,"cooltempmin":35.0,"cooltempmax":99.0,"heattempmin":35.00,"heattempmax":99.0,"hum":0,"hum_setpoint":54,"dehum_setpoint":34,"hum_active":99,"setpointdelta":2.0,"availablemodes":0} hum_setpoint:54 is actually returning the thermostat local sensor value "dehum_setpoint":34 is actually returning the humidity setpoint The blue and red labels are actually reversed in query info, that is how the bug expresses itself. If the Nodelink and the ISY used query/info value "dehum_setpoint", for humidity setpoint, that would address it it. Paul
io_guy Posted August 23, 2016 Posted August 23, 2016 That's my issue, mine isn't behaving the same as yours. hum_setpoint returns actual hum (not dehum) and my dehum_setpoint doesn't return the true humidity setpoint. Mine aren't swapped setpoints. Also you mentioned you have your setpoint at 10%, yet your dehum_setpoint shows 34%?
paulbates Posted August 23, 2016 Author Posted August 23, 2016 RIck, my bad I was double checking my results from a few weeks ago with another test, and changed it to be sure the value was going where I thought it was. Let's leave this as is I will keep pestering Venstar. Paul
Recommended Posts
Archived
This topic is now archived and is closed to further replies.