I encountered an interesting situation during my recent work with thermostats.
The mode the thermostat is in (heat, cool, auto) really isn't a cmd or a sp.
What do you all think we should do?
I considered modeling it as: zone air mode cmd
-Adam
Maurice duteauThu 28 May 2020
I am still learning about Haystack but I do know thermostats pretty well. The heat and cool settings can lock out heating or cooling as the user decides and in auto mode the thermostat can decide itself. In Bacnet we store it as an MSV ...in Haystack I would guess a cmd but I am just a fly on the wall here for now.
Jay HerronThu 28 May 2020
Hey Adam, yeah we've found the same thing and model our thermostat heating modes as cmd points. As you suggest, this is in contrast with the current vavMode point, which uses sp.
Paul QuinnThu 28 May 2020
If the point isn't commanding the system to do something but rather is telling you what the system is currently doing, I model the point as a sensor.
zone hvac run sensor
If it was commanding it would be:
zone hvac run cmd
Set point doesn't make sense to me. I think of set points as numeric values to control to (as in a PID loop).
Paul BergquistThu 28 May 2020
As Paul Q mentioned you often have both what the system command cmd is and what the system is currently doing sp. For example, the system cmd is auto but it is internally calculating that heat is required. Another good example is occupancy objects where a system schedule is commanded unoccupied but the system is overridden occupied by an occ sensor or manual push button on the wall and the calculated mode output sp would become occupied.
Remember that sp is not only just setpoint. sp classifies a point as a setpoint, soft point, internal control variable, or schedule. In this case, the mode out is not a hard sensor point but calculated internal soft point, so sp is used as in vavMode sp point
So depending on the specific device, protocol, and the network control properties/objects available you will often have both cmd and sp objects that both command the device and output what it is currently doing.
Brian FrankThu 28 May 2020
To further what Paul said, the design philosophy is that "modes" should always be a sp. They control an internal variable in software to make used to drive algorithms. They do not directly command equipment (only indirectly). The cmd tag is designed to be used for things that are physically wired to actuators, valves, etc which are a traditional AO and BO in control systems. In this example mode would be the sp (software point) and the point that actually turned on the furnace would the cmd.
That said, it might be good to have a thermostatMode tag that mimics the vavMode tag.
Adam Wallen Wed 27 May 2020
Hi Everyone,
I encountered an interesting situation during my recent work with thermostats.
The mode the thermostat is in (heat, cool, auto) really isn't a
cmd
or asp
.What do you all think we should do?
I considered modeling it as:
zone air mode cmd
-Adam
Maurice duteau Thu 28 May 2020
I am still learning about Haystack but I do know thermostats pretty well. The heat and cool settings can lock out heating or cooling as the user decides and in auto mode the thermostat can decide itself. In Bacnet we store it as an MSV ...in Haystack I would guess a cmd but I am just a fly on the wall here for now.
Jay Herron Thu 28 May 2020
Hey Adam, yeah we've found the same thing and model our thermostat heating modes as
cmd
points. As you suggest, this is in contrast with the current vavMode point, which usessp
.Paul Quinn Thu 28 May 2020
If the point isn't commanding the system to do something but rather is telling you what the system is currently doing, I model the point as a sensor.
If it was commanding it would be:
Set point doesn't make sense to me. I think of set points as numeric values to control to (as in a PID loop).
Paul Bergquist Thu 28 May 2020
As Paul Q mentioned you often have both what the system command
cmd
is and what the system is currently doingsp
. For example, the systemcmd
is auto but it is internally calculating that heat is required. Another good example is occupancy objects where a system schedule is commanded unoccupied but the system is overridden occupied by an occ sensor or manual push button on the wall and the calculated mode outputsp
would become occupied.Remember that
sp
is not only just setpoint.sp
classifies a point as a setpoint, soft point, internal control variable, or schedule. In this case, the mode out is not a hard sensor point but calculated internal soft point, sosp
is used as in vavMode sp pointSo depending on the specific device, protocol, and the network control properties/objects available you will often have both
cmd
andsp
objects that both command the device and output what it is currently doing.Brian Frank Thu 28 May 2020
To further what Paul said, the design philosophy is that "modes" should always be a
sp
. They control an internal variable in software to make used to drive algorithms. They do not directly command equipment (only indirectly). Thecmd
tag is designed to be used for things that are physically wired to actuators, valves, etc which are a traditional AO and BO in control systems. In this example mode would be thesp
(software point) and the point that actually turned on the furnace would thecmd
.That said, it might be good to have a
thermostatMode
tag that mimics the vavMode tag.