Thermostat programming help.

Using C-Bus Toolkit:

On the Unit Identification tab, you should make sure the Application is set the same as that used to switch your A/C plant. This is probably HVAC Actuator 1, but your mileage here may vary.

Next, on the Temperature Control tab, click "Remote Setback Control", and in here set the remote setback control source as "Control from Enable application". [I don't know why HVAC Actuator Control is even in there, I don't think it should be... thats for controlling relays that switch the HVAC plant, not for feeding a control signal into a thermostat!].

Anyhow, after setting "Control from Enable application", put in an Enable Group and a Disable Group. These CAN NOT both be the same, so you might need to use the "+" button to make new Enable Groups. You can, if you wish, create levels - this may make the next step in the CTC easier.

Having done this and saved to database and network, fire up PICED and edit your CTC project.

Make 2 buttons: make one of them an Enable Control button which transmits an ON message (OR a Enable <group = the Setback Enable Group you made in Toolkit> <level = 255 / 100%>) - this is the one that enables setback. Do the same with another ON message (OR a Enable <group = the Setback Disable Group you made in Toolkit> <level = 255 / 100%>) - this is the one that disables setback.

Save all this to your CTC, and try the buttons. This should be all you need.

(I don't have a CTC or thermostat here to actually try this out, I'm writing this from memory.)

 

I'm not sure...

It might be a defect, or it might be that this was a deliberate design decision.

Something to try: on the thermostat GUI in TK, go to the C-Bus tab, and in there check the box "Enables sending of Thermostat C-Bus messages".

This turns on the feature where thermostats can talk to each other, for example in master/slave arrangements. It may be that this needs to be enabled for remote setback to work.

The other possibility is that of the deliberate design decision, being that Program Mode is supposed to be all about running as a mostly-completey-automatic-thingy, and so (the logic goes) remote commands to fiddle setback would be inappropriate. I don't think this is necessarily a very good argument, but it might be the case.

I did once know all these details.... but its been a long time now so I'm a bit hazy on some of the decisions down in the fine-grain behaviour.

 

Ah -you probably want to change the Guard temperatures then.

Guard is a constant monitor, even when off, the system will turn on and heat if the temperature falls below the guard min.

Similarly there is a guard max - where the system will turn on and cool if the temp gets above guard max.

Normally the setup is something like this:


Guard max
.
.
Setback max
.
.
Setpoint max
Setpoint
Setpoint min
.
.
Setback min
.
.
Guard min

In other words your setpoint is what you want controlled as when you are present, say 21 degrees. Next, some hyteresis (sloppiness) is applied to prevent limit cycling - so the temperature is actually maintained as Setpoint+/-hysteresis, or inside the limits Setpoint min.. setpoint max.

Next, if setback is enabled, the hysteresis is made much wider... set the temperature is maintained in the range setback min..setback max. (Where this range is Setpoint+/-setback range... for example, setback range might be 5 degrees, so if setpoint was 21, then the temp is OK [and so nothing gets done] if temp is in the range +16..+26].

Guard is different - its a big override, so for example in a cold climate it will do a little heating to (help) prevent pipes freezing.

You probably want to set Guard to something like 5 .. 8 degrees C. Which is pretty cold, but it means you will keep your house at that (or above) during winter if you are away for some period of time.

Try fiddling the guard setting.