Jump to content

- - - - -

Aprilaire driver bug?

  • Please log in to reply
No replies to this topic

#1 123



  • Registered
  • PipPipPipPip
  • 2170 posts
  • Location:Montreal, QC
  • Experience:average
  • Software:Premise
  • Hardware:Elk M1

Posted 06 March 2008 - 09:24 AM

I have noticed that when using the aprilaire driver, with the aprilaire 8870 tstat set to Auto and setpoints set to say heat = 65 and cool = 80, that when the "currentsetpoint" is set to say 68, the tstat comes on in heat mode but the driver reports the Heating Status Property as "Cool".

This causes the Currentsetpoint property to be set at the "Cool" setpoint of 80 and not the correct setpoint which should be 68.

Anyone encounter this? This is a two-stage heatpump system.

After some testing, i believe I found the bug.

The driver seems to be incorrectly processing the data sent from the thermostat to premise.

Ex: the thermostat reports the relay states as
SN7 HVAC=G+Y1+W1-Y2-W2-B+O-

this means that the Fan (G+) is on, the Mode is operating as heat (B+O-), the first stage compressor is on (Y1+).

Premise thinks that when the compressor is on (Y1) that the mode is cool. Premise needs to look at the B and O status before determining that the mode is Cool. If B+O-, the the tstat is in heat mode. If B-O+, then the tstat is in Cool mode. Only if O+, then Premise should show the heating status as "Cool"

Does anyone have the Aprilaire native source to be able to fix this?

Hate to have to write another serial driver for the aprilaire..

In glancing at the driver code, this appears to be an issue with the two stage functionality. Is it two stage in heating and cooling, or just heating? There are only two places in the driver where the cooling status is set. One on direct read from the device report, and one when the CurrentSetPoint is updated or calculated. Turn on the Transaction Viewer on the Statnet device object to see if the mode is getting set twice perhaps - once correctly from the device and once incorrectly by driver code...

Damon, Many thanks for your response.

This is a two stage heating and two stage cooling. Actually 3 stage heating, but the airhandler will kick on with gas heat if not satisfied within 10 minutes.

Anyway, does the code look at the status of the B and O (blue and Orange) messages coming from the tstat? When the Tstat wants to heat, then O will be - and B will be +. and vice versa when it wants to cool. This should be independent of the whether its one or two stage. In heat or cool mode, Y1 will come on first, then after 4 minutes, Y2 will come on for second stage compressor. The B and O status would indicate whether its in heating mode or cooling mode.

W1 will come on if the tstat gets set to Emergency heat. In that case, Y1 is -, Y2 is - and only G and W1 are +.

Can you check to see if the driver is looking at B and O?

In the transaction viewer, with the Stat set to auto and Set points at 65 and 80, current temp is 70 and I raise the Currentsetpoint to 72.
The following occurred:

Property Value
Currentsetpoint 72
HeatingSetPoint 72
_HeatingSetpoint 72 (I assume this came back from the tstat)
RelayFanState True
FirstStageCool True (I assume because the driver saw a Y1+
come back)
FanStatus ON
CurrentSetPoint 80 (Ooops. This should go to 72)
HeatingStatus Cool (This should read "Heat")

I hope this helps.
Thanks very much for looking into this.

I do not have a compiler environment. If all else fails, I would write a vbscript serial xdo for the tstat...


If you have the chance, would you please look at the humidity response handling in the driver..

The Tstat is configured with a remote Humidity sensor (I think its part # 8061?).

Anyway, the driver does a SN7 OH? and the response is (the 7 is a fictitious address):

SN7 OH=56%

Except that the humidity % property is never updated.

There is another humidity command , SN7 HUM?, that cause the thermostat to report back SN7 HUM=--%. However, with the remote humidity sensor, that response is always nothing.

Can the driver be made to extract humidity from the SN OH command?

Thanks again.
The OH response refers to the remote or outside humidity sensor and is sent to the atatnet's remote humidity child. The HUM response refers to (at least in theory of the protocol) the thermostat being configured as an indoor humidity controller, and is sent to the thermostat driver object. Based on the protocol, this is correct behavior... In most applications it's rarely this way. We usually just hook up the remote humidity object's humidity property to the humidity property on the statnet itself. You can do this with either a script or logic diagram.

Edited by 123, 19 March 2008 - 12:09 PM.

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users