Workaround for RCS setpoint bug in HS2 (using HS3 connector)

[cbryan]

Since the HS3 RCS serial plugin is essentially non-functional and no longer supported (especially in multiple thermostat and zone controller environments) I am forced to control the older RCS stats and ZCV4 zone controllers by running HS2 and controlling the stats through the Jon00 connector.

There is a long documented bug in the HS2 RCS plugin that affects setpoints on RCS stats that have dual setpoints for heating and cooling:

http://board.homeseer.com/showthread.php?t=134464

The HS2 RCS plugin erroneously alters the cooling setpoint anytime the heat setpoint is set from the plugin or an event. This can cause the cooling system to cycle on for the minimum run time (MRT) unintentionally. For years I have put up with this since the bug was never corrected, probably to maintain backwards compatibility with the earlier single setpont RCS stats.

This behavior can be avoided by setting the system mode to "off" prior to changing the heat and cool setpoints then resetting the system mode to "auto" or "cool" or "heat" after changing any setpoint (either through an event or script). It is still critical to change the heat setpoint first then the cool setpoint since it is the heat setpoint that contains the bug that also sets the cool setpoint and setting the cool setpoint after the heat setpoint corrects the cool setpoint error (see discussion in above thread regarding SPH/SPC and SP).

By taking the system offline (setting the system mode to "off") during the time the setpoint change data is being written to the stats you can avoid the unintentional compressor cycling every time a heat setpoint is changed. Just remember to have the event or script re-enable the system mode after the changes are made.

[Uncle Michael]

I've been using the RCS serial thermostats for years in HS2 and have never encountered the bug you describe because I always change both heat and cool set points in the same script. What do you see as the advantage of the method you describe?

As an aside, I am also running HS2 now only to support my thermostats until I get around to replacing them. I've found that Rover for HS2 is an efficient way to allow HS3 to control an HS2 plug-in and JSON messaging is also an efficient way for HS2 to modify devices or trigger events in HS3.

[cbryan]

Thanks for the suggestions on Rover and JSON messaging.

First, let me preface all of this by saying I am running RCS plugin version 2.4.0.7 as I believe this was the final version that RJ posted that correctly supported the ZCV4 zone controller (with 4 wall display units) plus two single TR40 stats. Several of us tested RJ's stat addressing scheme in the plugin until it worked successfully with both stand alone stats and the RCS ZCVx zone controllers.

My system uses dual setpoint stats and has always exhibited the bug. I primarily use RCS events to change setpoints (both setpoints changed within a single event, heat first then cool - to accommodate this bug). Because we are located in a climate that may call for heat at night and AC during the day the stats stay in the "auto" mode.

As the above thread describes, when you change a heat setpoint the RCS plugin sends both the SPH and SP commands to the stat(s). This effectively sets the heat setpoint at the desired value but also sets the cool setpoint at the heat setpoint plus the SPH/SPC temperature offset (delta factor) programmed into the stat (mine is 4 degrees). So, for example, when I change the heat setpoint to 64 and the cool setpoint to 74 from a single event, the stat actually is first set to 64 (heat) and 68 (cool) for a brief interval until the stat receives and writes the cool setpoint from the same event at which point the stat is correctly set to 64 (heat) and 74 (cool). During this brief interval when the cool setpoint is incorrectly set at the heat setpoint plus the delta (4 degrees) the stat calls for cooling from the system if the incorrect temporary cool setpoint is below the ambient room temperature. This causes the compressor to run for the minimum run time (MRT) programmed into the stat to protect the compressor. This has driven me crazy for years as the compressor would nearly always startup and run for the MRT during the winter months at very low outside temps.

Although the bug is discussed in detail in the above referenced thread, I proved out the issue in my system by leaving the system mode in "auto" and creating an event that just sent only a heat setpoint (64) to the stat. In this instance I found that the heat setpoint is set to 64 but the cool setpoint also changes (un-commanded) to 68 (the heat setpoint plus the delta programmed into the stat). If the event were to have a second component that sets the cool setpoint right after the heat setpoint the cool setpoint from the event would overwrite the un-commanded setpoint that was associated with the heat setpoint bug. Unless you break the event down you will not see the bug since the cool setpoint clears out the issue when run from the same event, albeit too late in the eyes of the stat as it has already called for cooling in the short time the un-commanded cool setpoint was effective.

By disabling the system (set system mode to "off") prior to sending ANY setpoint change then re-enabling whatever system mode you prefer (in my case "auto") after all the setpoints have been written to the correct values (overwriting any un-commanded cool setpoint value), this prevents the stat from calling for the compressor to start while the un-commanded cool setpoint is present.

Hope this makes sense!

[Mountainman]

First, let me preface all of this by saying I am running RCS plugin version 2.4.0.7 as I believe this was the final version that RJ posted that correctly supported the ZCV4 zone controller (with 4 wall display units) plus two single TR40 stats.

You might try the beta version 2.4.0.14 I got from Rich and posted in this thread:

http://board.homeseer.com/showthread.php?t=156922

[Uncle Michael]

Because we are located in a climate that may call for heat at night and AC during the day the stats stay in the "auto" mode.

Hope this makes sense!

Perfect sense. The Auto mode was the piece I missed. We never use it, preferring not to delegate that function to the thermostat. (We only need AC during limited periods in the summer, and nearly always both night and day when we do.) That would explain why I've never seen the behavior you describe.

Thanks for the clarification.

[cbryan]

You might try the beta version 2.4.0.14 I got from Rich and posted in this thread:

http://board.homeseer.com/showthread.php?t=156922

Are you using any zone controllers? There was a serious addressing issue for zoned systems and I am wondering if this version carried forward the resolution RJ implemented regarding the set up for zones and the associated wall display units in 2.4.0.7.

[cbryan]

Had a chance to test plugin 2.0.4.14 this weekend. That solved the issue and it does work with the ZCV4 zone controller.

Now to undo all of the workaround events.

Thanks Mountainman, sorry I missed that post at the time.

[Mountainman]

Had a chance to test plugin 2.0.4.14 this weekend. That solved the issue and it does work with the ZCV4 zone controller.

Now to undo all of the workaround events.

Thanks Mountainman, sorry I missed that post at the time.

Glad to hear it works for you! I do not have any zone controllers so I didn't know how well that part worked. It has been working fine with 3 TR40's for a couple of years so I trust it. It's a shame this version never made it to the updater.

I did not pursue trying to get the double triggering problem fixed as there is a way around that.