Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Class: Thermostat
#1
General Discussion

[INDENT]This thread is for discussion of the Thermostat device class. Device of this class obviously implement the standard functionality of a thermostat. Though thermostats can be quite fancy, this device class has to stick to the basics that can be expected to exist on almost any thermostat.[/INDENT]

Fields Provided
[INDENT]The fields provided by this device class have pre-determined names, and these MUST be implemented as indicated here. They are all prefixed by the device class prefix in one the forms:

THERM#fieldname
THERM#sub~fieldname

where THERM# indicates it is a field of this device class, and fieldname meets the general requirements of CQC field names. If the device provides more than one thermostat, then the sub~ part will be present and will indicate the specific thermostat instances, see the Multi-Unit Considerations section below.

The fields provided by each thermostat instance are:
  • CurrentTemp. Indicates the current temperature that the thermostat is sensing in the environment, i.e. the one it is displaying to the user on its own interface if it has one. This field MUST be marked with the CurTemp semantic field type and conform to the restrictions of that semantic type.
  • LowSetPnt. The low set point currently set, i.e. the point at which the thermostat will invoke the heating cycle. This field MUST be marked with the LowSetPnt semantic field type and conform to the restrictions of that semantic type, with the added requirement that it be readable and writeable.
  • HighSetPnt. The high set point currently set, i.e. the point at which the thermostat will invoke the cooling cycle. This field MUST be marked with the HighSetPnt semantic field type and conform to the restrictions of that semantic type, with the added requirement that it be readable and writeable.
  • CurMode. The currently 'set' mode of the thermostat, i.e. the mode you tell it to use. This MUST be a String field, with an enumerated limit that indicates the available modes. It must be readable and writable. If there is an 'Off' mode, it MUST be first in the list and named 'Off'.
  • OpMode. The current 'operating' mode of the thermostat, i.e. the mode it is in based on the set mode you told it to use and what it needs to do to honor that set mode. It MUST be a read only string field with an enumerated limit that indicates the possible operating modes.
  • FanMode. The currently 'set' fan mode of the thermostat. It MUST be a String field with an enumerated limit that indicates the available modes. It must be readable and writeable. If there is an Off mode, it MUST be first in the limit list and be named 'Off'. See below for comments on thermos that may not expose the fan mode.
  • FanOpMode. This is the current operating fan mode of the thermostat, i.e. the mode it is in based on the set fan mode you told it to use and what it needs to do to honor that set mode, i.e. if you set an Auto mode, the operating mode may be Off or On or some such, based on circumstances.
The driver MAY provide other functionality, but the above is all that is required to implement this device class. If it provides other temp and/or humidity sensors, it can implement separate device classes to expose those if applicable.

NOTE that temps are always Ints, as per the CurrentTemp semantic field type. If the device exposes fractional degrees that can be exposed via a separate, non-V2 compliant field for those who need it. The V2 field will be the floating point value rounded to the closest integral value.

Note that there are separate 'set' and 'operating' modes. This is because some thermos don't have a symmetrical set of modes that you can set vs. what the thermo can be in. I.e. it may have 'auto' modes you can set, which just tells it to automatically choose an operating mode, the latter of which must be a real mode, i.e. Heating, Cooling, etc... Where the thermo has symmetrical settable/current modes, the set and operating modes will be the same. But portable customization content should use the operating modes for display purposes or to determine current mode for logic reasons. The 'set' mode field will show the current set mode, which may be different.

DO NOT add any un-settable values to the set mode field limits, such as Unknown. These enumerated values will be presented to the user as the available settable modes, so it makes no sense to preset them with an Unknown value. If you cannot read back the currently set mode, initialize it based on what you see as the current operating mode.

If the thermostat doesn't expose the fan mode, the provide a single Auto mode for the FanMode field, and set that as its current value on start up. It will essentially then stay that value. For the operating mode, provide Off and On values and just set it to On when the thermostat is in a running operating mode, and Off otherwise.
[/INDENT]

Multi-Unit Considerations

[INDENT]It will be fairly common for devices to expose multiple thermostats via a single control interface. Typically they are actually separate thermostats, but are being controlled by an intermediate controller so CQC sees them all via the same driver. In such cases, the driver MUST use sub-unit naming conventions, to identify the fields for each thermostat.[/INDENT]

Backdoor Commands/Queries

[INDENT]None at this time[/INDENT]
Dean Roddey
Software Geek Extraordinaire
Reply
#2
(reserved for expansion)
Dean Roddey
Software Geek Extraordinaire
Reply
#3
(reserved for expansion 2)
Dean Roddey
Software Geek Extraordinaire
Reply
#4
OK, a first whack at a thermostat device class. Does this make sense? Anything else that could be added and have a chance at being very widely supported?
Dean Roddey
Software Geek Extraordinaire
Reply
#5
You have to add for consideration multi staged systems where current state might be more complex

-p
Reply
#6
Does that just mean it has more modes and fan modes? If so, this device class won't define what those modes have to be. That will be up to the driver. Any code like the auto-gen system will just have to grab the enumerated limits of such fields when providing mode selection interfaces and such.

It may define an 'Off' state for both, just so that it can tell the difference between off and not off, or just require that the first value in the enumerated limit represent the off mode.
Dean Roddey
Software Geek Extraordinaire
Reply
#7
Many thermostats that dont have the range ability only have a single target temperature that is used in both heat and cool modes. Not sure how many controllable thermostats fall into this category.
Reply
#8
I would presume that the answer there would be that both fields would just map to the same setting in such a case?
Dean Roddey
Software Geek Extraordinaire
Reply
#9
Dean Roddey Wrote:I would presume that the answer there would be that both fields would just map to the same setting in such a case?

I guess that can work. Some thermostats have both - a range and a single setpoint that are independent. The single setpoint is used in heat or cool mode and the range is used when in heat/cool mode.
Reply
#10
It looks like all the thermostats that CQC has official drivers for have separate heating and cooling setpoints. I would think having both options is pretty common on the smarter thermostats that can be controllable.
Brian

"Really dear, it was too good of a deal to pass up. Besides, look at what it does now...."
I think my wife is getting a little tired of hearing this :-)
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Class: SceneCtrl Dean Roddey 20 3,777 03-31-2015, 12:38 PM
Last Post: Dean Roddey
  Class: Irrigation Dean Roddey 8 1,970 01-28-2015, 12:09 PM
Last Post: Dean Roddey
  Class: NowPlaying Dean Roddey 8 2,085 09-23-2014, 02:01 PM
Last Post: Dean Roddey
  Class: Switcher Dean Roddey 9 2,164 08-20-2014, 08:17 AM
Last Post: Dean Roddey
  Class: Security Dean Roddey 33 5,940 08-13-2014, 03:02 PM
Last Post: Dean Roddey
  Class: Projector Dean Roddey 29 4,489 08-11-2014, 08:56 AM
Last Post: Dean Roddey
  Class: Lock Dean Roddey 5 1,628 07-31-2014, 01:24 PM
Last Post: Dean Roddey
  Class: ContactClosure Dean Roddey 7 1,746 07-31-2014, 10:14 AM
Last Post: Dean Roddey
  Class: DIO Dean Roddey 7 2,042 07-31-2014, 10:08 AM
Last Post: Dean Roddey
  Class: Relay Dean Roddey 4 1,517 07-31-2014, 09:56 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)