Nitpick: it's not "debounce logic" (that's for handling pushbuttons, because the contact physically bounce, meaning you get multiple on/off readings within a few milliseconds), the word you're looking for is "hysteresis".

Because there's a giant surge current when you start up a motor (like that in an A/C compressor), and it's just plain bad and even annoying to have your A/C cycle between on and off rapidly, a thermostat will intentionally overshoot the set point when cooling, and then undershoot that same set point when waiting for the house to heat up before it turns the A/C back on (or vice versa for heating).

Hysteresis is absolutely necessary to avoid both this problem, and also the problem where your temperature sensor isn't perfectly accurate and the readings from it will vary a bit from reading to reading.

Both are necessary.

You are absolutely right that you need to account for hysteresis.

Debounce is also necessary for sensors that have precision problems, where, in boundary conditions, they bounce back and forth between a measurement that would cause an "on" signal and a measurement that would cause an "off" signal. But, I think we're agreeing with each other :)

Yep, we're just disagreeing over minutiae :-)

For the sensors, it seems to me that a debounce routine wouldn't work, and (this is assuming the sensor is giving an analog reading, not an on-off binary reading) what you really want there is some kind of averaging routine. Usually, the way a debounce routine works is that you look for a state transition (off->on), and then wait 30ms (general rule of thumb for human-actuated switch) and look again to make sure that the state is still "on" and then you do your operation based on that. But for analog sensors, you probably want something that's more like a running average so the readings don't vary too much, and one erroneous or too-extreme reading doesn't affect things much.

I could be wrong though; this is probably highly application-dependent.

Or just put in a deadband, that's what most thermostats do.

Also, you should note that most of them also don't show the exact temperature in the room... it's an algorithm. Your furnace might heat to 68 on the display but the actual temp may be between 67 and 69, but if your display temp constantly bounced it would result in mass consumer disappointment.

You can use this logic if the range is wide enough and you don't check that often. Or better yet wait 5 min after changing state to check again. You often have at least high and low heat which adds complexity.

Also, overshooting you ideal temp is fairly easy to do as there can be a lot of hot air in the vents even after you turn down the heat. So a little predictive modeling can be useful.

Also you can decouple the handling of ac and heat, and check the current state to prevent a redundant transition into the current state.

  if (temp > max + error)
    if (off (ac))
      turn_on (ac);

  if (temp < max - error)
    if (on (ac))
      turn_off (ac);

  if (temp < min - error)
    if (off (heat))
      turn_on (heat);

  if (temp > min + error)
    if (on (heat))
      turn_off (heat);

If in between samples you go from above max to below min you'll have both heat and ac on.

The take-away is that like programming lift controllers[0] it's not quite as simple as it might first seem - many many edge cases.

[0] http://play.elevatorsaga.com/ (for example)

I think that's wrong, because all 4 if-statements are evaluated for each sample.

But yes agreed, in general there are lots of edge cases. I actually wrote a finite state machine specification for an elevator in a logic class once. Without having really thought about it much, it looks like the biggest problems with thermostats are dealing with scalars, sampling frequencies, and sampling error.

I'd prefer a nice fuzzy logic rule set with some variable speed on the heat/fans.

I know what debouncing is, but I don't really grok it. Is there a Khan Academy-style explaination somewhere?

If you hook up an oscilloscope to a physical button, you will see that there's not a nice clean on/off when you press it [1]. The signal bounces on and off for quite some time after. This is a problem in a lot of situations. If, for example, a momentary push button is used as a power button on a device, it might be connected to an interrupt on a microcontroller. Without debouncing the device will rapidly switch on and off dozens of times over a millisecond. While there are easy ways of debouncing in hardware, most don't bother, as it's very simple to do in software. The simplest is just to ignore or disable the interrupt for a short period (a few milliseconds, perhaps).

Here's an Arduino sketch showing a simple way of doing it. https://www.arduino.cc/en/Tutorial/Debounce

[1] http://www.labbookpages.co.uk/electronics/files/debounce/bou...

Many thanks