While it's tiresome to read comments on HN like the GP's that seem to come from a "Look at me, I'm more Catholic than the Pope" mentality, the reality is that a good thermostat algorithm is a fair bit more complicated than that.

You need to take hysteresis into account, temperature overshoot/undershoot, your compressor's duty cycle and startup latency (especially as it impacts MTBF), emergency/backup furnace control, failsafes to make sure the house doesn't freeze or overheat if/when any of the above goes wrong... lots of stuff like that.

The spec for an HVAC control system isn't overwhelming but it does warrant some thought.

In the UK, many homes and older office buildings still have traditional bi-metal mechanical thermostats. For typical domestic applications they work just fine.

For finer control of room temps, people often use mechanical radiator thermostats. They work just fine too.

New electronic models are usually just a thermistor with some analogue hysteresis. They work fine as well.

I might expect something with the extras you're describing to appear in a new office building, but in the UK at least adding PID and/or some kind of learning system to a domestic thermostat is overkill.

Generally, simple solutions are less likely to go badly wrong.

That's the tragic irony of Nest. The design is great, but the added value offered by a buggy and overcomplex implementation is negative.

In home systems aren't most of those problems handled by the furnace/ac system itself? Thermostats are pretty dumb.

Depends on the hardware. An old-fashioned bimetallic strip/mercury switch thermostat has mechanical hysteresis built in. (Actually, they can have too much lag -- some of them include heating elements to 'accelerate' their response.) Old-school mechanical devices aren't always as dumb as they look.

As far as short-cycling the compressor goes, my current HVAC is smart enough to disallow that, but I've lived in older houses where that wasn't the case. You could potentially damage the compressor by wiggling the thermostat back and forth, forcing it to start up against back pressure.

Understanding the requirements is really job #1, and first on the list of reasons why HVAC control isn't just a simple "if too cold then turn on heat else turn on A/C" statement. That doesn't mean people shouldn't jump in and try it, of course. It's the best way to learn, if not always the cheapest.

Code review #1: You're going to want to add debounce logic, or you're going to be erratically turning on and off your heat and ac when the temperature is exactly equal to the ends of desired_range.

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

It sounds simple, but this algorithm will very quickly break both your ac and heating units.

You want a PID controller in there (in some cases you might get away with just PI, but that needs analysis of the specific case)

Ideally of course you'd want to model the exact energy loss curve of the specific building you're in but nobody really does that.

The best part is of course that a PID controller sounds complicated, but the simplest one is actually just around 15 lines of code.

Throw an anti-short-cycle delay in there. You've never programmed HVAC have you.

And also PID control... and defrost or heat exchanger cooldown intervals... and further checks to avoid overcycling and damaging anything with a compressor. And probably a dozen or a hundred other things I don't know about because I'm not a process controls engineer.

Pretty sure you just illustrated GP's point