I've been running homemade HVAC control for 12 years now. A few points:
1. Have "can't fail" safeties. In my case, that's the existing thermostat in parallel with the relay (so that the house can't freeze up if my system fails) and a second extra thermostat in series with it (so that if it fails stuck on, things won't overheat too badly). The second safety thermostat can be out of the way, like in the basement.
2. Assuming you live in a northern area and have a furnace that's less than a decade old, it may well be a two-stage (i.e. high and low heat mode) one set up for autostaging (run on low for 5 minutes, then fire up full blast) because the installers were too lazy to fish the extra wire to run a proper 2-stage thermostat. My homemade system has a 0.3 degree Celsius difference between the low and high stage cut-in, plus some hysteresis to avoid short cycling, and it keeps the temperature wonderfully stable (within 0.2 degrees of the set point) with the furnace only ever switching to high if you turn up the temperature (on the very most brutally cold winter days it might run almost continuously on low). At least here in Canada, installers have to leave the technical manual with the furnace, so you know which DIP switch or jumper to change to disable autostaging.
3. Mechanical thermostats have something called an "anticipator" which slightly warms the sensing element as the furnace runs, so it tends to turn off below the set point. This is to avoid overshoot. Digital thermostats do it in software by pulse width modulating the furnace enable as the temperature nears the set point. In my case it's completely unnecessary to code this up - I guess the thermostat location is just perfect - but if you do get overshoot, just simulate it in software.
4. AC units can be damaged by short-cycling and sure enough an early version of my system had a bug that caused this. Luckily I noticed right away. Now it's full of safeties like minimum run and rest times and probably much more conservative than a real thermostat. Longer AC run times are better for dehumidification anyway. I also enforce minimum run times on the furnace.
Thought this was a really interesting comment. Looked at your profile, which led to your website, which had a page about your family, which said you had a brother named Matthias, which tickled something in my head. Clicked on the rather dated link and saw a familiar face. I don't really follow the woodgears website that much, but I've heard it mentioned here several times.
Anyway, I thought that was a neat connection to make.
What inspired you to build your own thermostat?
What sort of hardware is involved in that?
It's changed over the years. Currently it's an Arduino Mega2560 with custom stuff to talk to the 1-wire sensors (not just bit banged) and the ubiquitous 8 relay board for output. But the actual thermostat logic is on my main Linux server machine. Yes, if my server crashes my heat goes down, I'll fix that some day, but it never does crash so it's run like this for 12 years. The original setup used owfs for input and output, but it was never completely stable that way.
Why? Because my bog standard 7-day programmable thermostat did not have the "turn the heat up in two weeks just before I come back" functionality. Back in 2008, if internet programmable thermostats even existed, they had the same suckage - only works via proprietary cloud stuff. Yech. I just want "turn up the heat", and I want it my way. The web interface is a HTML form with a single input box that says "Temperature". Programmable thermostat stuff is crontab entries.
We had issues with uneven heating and large temperature swings, so I fixed it with simple (though case-specific) logic:
while True:
if temperature < set_point:
heat for 15min
wait for 15min
Works wonders, consistently, even with differing types of radiators and no need for fancy PID/control loops. Measured temperature is a 5-min median, otherwise nothing fancy, except a bit of safeties¹.
Didn't bother with accessible controls - temperature adjustment of cca 2-3K can be made by raising/lowering the temperature probe.
¹ Contains a secondary probe, in a different room for safety. Doesn't heat if any probe above it's maximum setpoint, 50% duty cycle is not too bad and there usually is someone present. Median is considered valid only if data is available for each minute.
Hydronic heating systems (i.e. hot water and radiators) are a whole different ballgame from warm air - much slower to respond. But the beauty of homemade is that you can just come up with an algorithm that works for your house, by trial and error!
I guess I was more wondering if running in a busy loop like that was a thing people did on embedded hardware since from my very minor experience with Arduino it is basically just a big while loop.
Again, you are assuming that the line that says 'wait' is a busy loop, but they are just saying that the program doesn't turn on the heat for 15 minutes after it has run for 15 minutes. That doesn't mean they are using a busy loop or not using one.
> you are assuming that the line that says 'wait' is a busy loop
I wasn't asking if the "wait" was a busy loop, I was asking if the "check whether the temperature dropped too far" was evaluated in a busy loop, and if not, how often that condition was checked.
It doesn't really matter, and I imagine I won't get a response at this point, but it was just something I was curious about since I had never considered writing your own home thermostat software.
I believe it uses sleep, and either threads or events / interrupts. I don't remember which. It's programmed in micropython.
It calculates medians for each minute, and from those a 5-minute median (which is only considered valid if a majority of values are present) to filter out things like opening doors and missing values. Temperature readings are transported wirelessly from a different room. It supports multiple temperature clients for multiple rooms, each with a preset minimum (heat cycle activating) temperature, and also a maximum (safety-shutoff => don't activate heating) temperature.
It could be done with interrupts. With something like a raspberry pi it could be done with thread sleeps that yield non trivial amounts of process time so that the CPU usage is low.
More safety: always have physical NC relay in series with SSR for any AC application.
SSRs are super fun and useful. They are quiet, can be switched 100 times a second if you want more than just on/off control for your heating element and they won't wear out.
But they also leak current keeping the equipment under AC voltage even if not powered and have nasty fault mode where they just fuse and conduct as a very efficient short.
The physical relay fixes both problems.
I typically have current sense on SSR output so that my controller can compare output from SSR with what was supposed to happen and signal fault if the SSR becomes a very good jumper. So the SSR is only ever connected when the controller decides it should.
This is one reason why I've never gotten anything more complex than a simple Honeywell programmable thermostat. I haven't felt a real need but I also just don't trust "smart" thermostats not to fail off in the winter which can be a really serious event if you're not around (and I normally travel a lot). There are other failure modes for heating of course but I absolutely don't want to introduce another one for no good reason.
The problem I have with Nest in particular is that the hardware design assumes Internet will always be available. Heat pump systems regularly have an external thermometer to ensure that the heat pump is only operated down into the low 40's (F). After that your auxiliary heat turns on.
For some reason Nest chose not to include the requisite hardware to run this feature directly, so it gets outdoor conditions from a weather feed. Of course if internet/wifi goes down, then it just has to assume what the outdoor temp is, which is going to be very suboptimal in either direction. When you're out in the boonies, Internet goes down from time to time and the Nest doesn't handle it well at all.
I still use it because I do like how it optimizes heating for occupancy (e.g. much lower setpoints when away/sleeping) and I can't bring myself to drop another $x00 on some alternative that will likely just get sucked into IoT hellscape. DIYing it seems much better. I'm actually starting to DIY a control for my wood stove to help optimize for longer burn times...should be interesting.
Yeah, I've done some locks and status IOT stuff around the house but I don't trust my rather expensive central air/furnace to nest or my own hacking. The 10 year old thermostat works quite well.
This is my bugbear. All my smart systems are 'who cares'. I really want security, heating, and cooking to be smart as I have specific use cases but I don't have the time to Engineer the systems how I want them. Its particularly annoying as I have all the skills!
You can get an old school mechanical thermostat as a backup. I've suffered a total frozen house disaster in a past place - most of the plumbing wrecked - because of a heat failure during the Christmas break (gas valve in that case though; a mechanical thermostat wouldn't have helped). That's what started the obsession with remote temperature monitoring - I was into DS18B20s before they were cool - and from there it was only a little bit more hacking to just take control as well (so I can control it over the internet the way I like it - ssh!)
I have a couple different temperature monitors. Of course, doesn't necessarily do a lot of good unless I can get someone to do something. And that may not be possible if they're not around or if there's not anything they reasonably can do. As in your example.
But I did get an alarm on a trip a couple years ago and texted a neighbor and she was able to tell me the power went out but it was going to be back soon. Of course, backup generator is an option but it's expensive to do right and unsupervised.
Yup - even if I still only had a simple mechanical thermostat I'd still have a second as a backup. The backup thermostat was easy to add - just wired it in parallel directly next to my furnace in the basement; all I had to do was run the second cable from the second thermostat into the furnace control board and double up the connections on the terminals that call for heat. Cheap insurance that took all of 10 minutes to install.
I've had half a mind to start shutting off my water and draining my pipes before leaving on trips in the winter. We've had frozen pipes several times before, but thankfully PEX doesn't seem to burst. Have been working on fixing the insulation issues that lead to the frozen pipes, which I suppose is probably the better solution. But draining the pipes would be a pretty low effort way to get a bit of added insurance.
Don't drain your p-traps - your house will fill with methane/sewer gas. Don't ignore your sewer pipes either; they can burst too. Instead if you really want to winterize, pour RV antifreeze down all your sinks, toilets, tubs, showers, etc.
RV Antifreeze is also great to pour down all your drains if you aren't going to be in your house for an extended period of time even when it's not freezing cold outside - it evaporates a LOT more slowly than water and thus your home will be far less likely to smell like a sewer when you return.
My dad used to have the operation done in the winter at his house in Maine and it wasn't trivial.
Of course, he just turned off the heat entirely as opposed to protecting against temporary heating loss. That said, I never investigated how easily one could just do such protection on one's own. I have improved insulation over the years but you're presumably still in a bad situation if you have a multi-day power outage in freezing temperatures or your furnace quits.
I know to winterize a camper you fill the water lines with antifreeze. I suppose to be really protected you'd need to go that route.
We live in a townhouse with a garage on the main level, so the water comes in on the main level, but basically all of our plumbing is on the upper levels. I've had several times when dealing with different plumbing issues where I turn off the main water valve, then open all the faucets and let the water drain out through our water heater.
I guess the weakness in that approach would be if there was a bend in the pipe somewhere to not let the water drain fully out, it would still freeze. I guess that's probably why people do the antifreeze method when actually winterizing water lines.
I am lucky enough to have a couple of mercury thermostats for this purpose but I don't think I can get any more of those at this point. New "mechanical" thermostats tend to be actually electronic, some with a embedded battery that will eventually go dead.
Try thrift stores / Craigslist / Kijiji / garage sales (after COVID anyway) and of course secondhand building supply stores like (here in Canada) Habitat for Humanity Re-stores. Those things are everywhere. Bonus points for finding a round Honeywell. Another trick that works (I used that to get a replacement panel for a no longer made garage door) is just call up the outfits that install them and offer them a reasonable sum for a "pull".
Great tips! I am already doing the parallel with current thermostat (I don't trust my system at all). I will look into the other things as well, maybe I'll add them in my v2.
Indeed, and it's worth noting that a solid state or mechanical relay can fail in either the On or Off position, so you have to consider both possibilities.
For anyone looking to tinker with automating their thermostat, I highly recommend looking at the OpenTherm Gateway[1] (OTGW). It uses the OpenTherm protocol which is supported by a lot of heating systems.
Though the protocol is backwards compatible with the old type of thermostat which would simply turn on and off for heating, OpenTherm works with modulation as well. Not simply turning the heating on at 100% capacity and turning it off again when the target temperature was reached, but taking a bit more of a gradual approach.
The OTGW fits in here beautifully. It sits in the middle between your heating system and your existing (OpenTherm-speaking) thermostat. Listening to all the messages being sent between your heating system and thermostat. And if the onboard firmware fails, it should even fall back to that behavior completely.
For me, it allows to get a ton of information from my thermostat and heater, and automate heating and cooling down my home. All in a much better way than a simple relay with an ESP8266/ESP32 could do. It also retains my (non-smart) home thermostat functionality, including the ability to change setpoints on it. Which is much appreciated by my partner.
Third party support for the OTGW is relatively good as well. Home Assistant and Domoticz both support the OTGW, and the serial protocol it speaks is quite simple as well. Best of all, its opensource and has no need for any cloud connection you don't want.
I just set up one with a Fujitsu heat pump. The idea I'm playing with is to control the outgoing water temperature based off the data from smart radiator thermostats.
I have to say that HomeKit really does a good job in unifying the Home IoT experience. I used to use Philips Hue exclusively, but the HomeKit app is just so much nicer. And since then I've branched out considerably, and the only unifying factor is HomeKit. It's great.
HomeKit is underrated. A really well designed protocol, with mandatory local control and good security. The biggest gripe was that it used to defacto require Apple DRM for anything serious. But they eliminated that requirement recently, and improved the Home app as well.
I just wish Hue would play better with HomeKit. Even my homebrewed HomeKit devices work more reliably in the Home app than Hue :/
I develop home automation devices for a living and I must say, Homekit is quite annoying to develop for. First, many things in the spec are clearly thrown in your way for Apple's convenience, and feel as totally arbitrary or almost counterintuitive.
Others are clearly nonsensical or unreasonably complex to do; for instance, until a few revisions ago, the spec specified an "outlet in use" characteristic for power outlets that literally meant "something is physically plugged in". This isn't something you can know without putting actual sensors on your outlet's shutters, in order to detect if a plug was inserted in, something that while very fancy, it increases sensibly the cost of what is basically a relay strapped to a power socket. Needless to say, Apple had to make it optional because lots of manufacturers were simply not certifying their lower end smart outlets for HomeKit.
Also, certification with Apple is a massive PITA, and they meddle with every single aspect of your device, and they ask for money on each step of the process.
Interesting to hear the other side. Are you an iphone/mac user? I know the Apple walled garden makes some people feel jittery, but I have to say when it comes to HomeKit I feel much better off overall from their playing hardball with device manufacturers when I look at how sketchy other home auto stuff is out there. I'm thinking the cheap Chinese stuff off Amazon that won't work without their "cloud".
No, I'm not an iPhone user, I just use Apple products only when I need to test if HomeKit is working OK, mostly.
For your second questions, HAP is clearly intended for single, stand alone expensive devices with strong WiFi access, totally disregarding the fact that certain constraints could directly hinder performance or reliability in certain circumstances. I think most users would rather prefer having HomeKit supports that works fine 99% of the time than having a certain insignificant or nonsensical feature implemented that butchers the overall performance and responsivity of the device.
They also clearly try to shift away the implementation burden from their own internal teams to you, the developer of a much less powerful device. They can afford to do this because they have the upper hand in their relation with the manufacturers (they want to interoperate with their stuff, after all) and it clearly saves them money on developers by simplifying a lot what the Home app/the phone has the do, but it leads to overcomplicated, bloated firmwares that then need to run on meagre specs and very limited platforms (thankfully, the ESP32 exists). This is perhaps the number one reason why HAP-compliant gadgets tend to be more expensive - people that buy iPhones clearly have money to spend, though, so this is less of an issue.
Another big thorn that exacerbates this is the closed nature of the protocol; given that you _must_ support Android, you are also forced to implement a second protocol and keep it and HAP always aligned when anything happens, with all the issues that come from that.
I think that Apple likes playing hardball a bit too much, especially since they really like to change specs arbitrarily when they see fit. Every time this happens, the whole certification process needs to start again, even for minuscule changes, forcing your company to pay hefty fees (yes, the Apple tax exists).
The overall process is also way too strict, and I know for sure that several companies have cheated in some way or another in order to get their products approved. For example, while studying one of our main competitors HAP-compliant devices already on the market, we noticed that it clearly does not respect some of the most cumbersome fine-print in the HAP specification; in their defence, it must be said that those aforementioned requirements they omitted are incredibly stupid, and clearly they've been devised by by some UX designer that knows nothing of how electronics or software works. Had they followed them it would have made zero difference on their users, because everything works perfectly and those devices have been out for years, while driving up the retail cost considerably.
Our theory is that (like others), they must have sent the Apple-designated lab either modified devices or firmware with hacks in in order to pretend to actually implement those nonsensical requirements and then sold different devices on the market. The third party labs Apple usually delegates the whole certification process to generally only care about squeezing as much money as they can from you, so they don't really check if the product on the shelves matches with the one you sent them.
I can understand how Apple's approach comes from their intransigent, "screw devs", "user first" culture, but it's clear to me that by being so intransigent they completely miss the point of these gadgets, hindering HomeKit adoption in the process.
For instance, the Alexa's certification process is much less strict than Apple's but as far as I've seen, Amazon-certified gadgets are not qualitatively inferior than MFi-certified ones (it's often the opposite, actually).
It would be nice if more hardware vendors got out of their own way and supported HomeKit. It’s not perfect, at all, but it is far ahead of the typical vendor provided software experience.
HomeAssistant or HomeBridge (?) work great for this. At least with HA, nearly every reasonably communicable smart device can be finagled into cooperation and HomeKit sees them all through a bridge. I even have a "legacy/real" home alarm system wired up with it along with smart switches with flashed firmware to avoid OEM app issues.
This is because your device is either required to have a MFI chip in it, or you have a common device already in the home with a MFI chip that it can communicate with.
My company was one of the first to have a HomeKit thermostat, and the biggest barrier was the hardware requirement.
One of the key things with HomeKit is that its on the local network.
For Google or Amazon home automation, it goes from device to AWS or GCP, to the vendor cloud portal, back to the home device or bridge to those devices.
In my eyes, that "out and back on a different channel" is the problem.
Home kit devices can be controlled without an internet connection (I've just tested this) though the voice control of them still does the speech recognition in the cloud.
So, the home kit (via HomePod) does device to cloud to device to home automation.
I would contend that this approach is more secure - the control of the home automation devices only comes from the HomeKit hub rather than the internet. How much more secure that is - one can debate.
One missing part is whether the devices will talk on the public internet anyway. Some of them will, but at least with HomeKit you can firewall their traffic, I guess. Most home routers wouldn’t be able to do that though.
Moreover, does any Apple server going down mean you can’t use your lights? Like what happened a few weeks ago with Google, someone I know had their entire house behaving like a poltergeist.
> Moreover, does any Apple server going down mean you can’t use your lights? Like what happened a few weeks ago with Google, someone I know had their entire house behaving like a poltergeist.
My setup is:
* HomePod as the HomeKit hub
* Hue bridge (no external connection)
I disconnected the network at the modem - the entire house was without an internet connection for the duration.
Neither HomePod Siri nor an iPad Siri was able to control the lights via voice. However the iPad and various Macs were able to control the lights.
The only thing that HomeKit uses the cloud for is the voice recognition of things spoken to Siri.
The default configuration has an integration for HomeKit such that it bridges devices that do not have dedicated support. For example, I can control my Google-only through my iPhone.
Highly recommended, especially the appliance vm image or docker (hassio)
I’ve been quite frustrated that both of the houses I’ve lived in in the past decade have used “communicating” systems, meaning that the products exploring this space are out of reach. HVAC professionals describe these systems “Ferraris” of thermostat control, but their remote features, API, etc are awful - I’m stuck with what I can only describe as a touch thermostat made by the lowest bidder.
Yeah; ours has a variable speed compressor and variable speed fan (it is also a heat pump). The wire protocol is a closely guarded trade secret from what I can tell.
The manufacturer sells a custom EcoBee to work with it, but their own custom EcoBee can only set a few fixed speeds instead of variable speed.
This market is ripe for disruption. Sell me something with a 30 year warranty, and
plans to wire it to a raspberry pi. I’ll pay twice as much for that as I would for anything with a sub 20 year warranty. Since California is close to banning new natural gas installations, focus on making a heat pump that’ll last forever. Military grade limited access compressors exist and aren’t expensive compared to having someone in Silicon Valley perform a house call. Also, old air conditioners regularly lasted 30+ years, so this is a solved problem, and the patents have probably expired.
I’ll probably buy your weird proprietary thermostat because I’m lazy, but if it sucks badly enough, I’ll know there are decent third party options.
My heat pump was sold as having “700 levels” (that’s 30-100% in 0.1% increments), but the Nexia software shows unit % and also Level 1 or Level 2. Who knows if it’s actually using the fine grain control I paid a lot of money for?
My first thermostat also died in the first year when the power went out. What happens in 10 years when it’s no longer made? I have to dump the whole system and start again?
Also whole features are poorly implemented - Quiet Mode limits speed at night, but not until after startup (or, I think when defrosting)
I’m a bit unhappy with Trane/Nexia at the moment and would absolutely not recommend
The availability of multi-speed or variable speed compressor (inverter drive) is extremely limited in the residential market space outside of anything proprietary because there isn't enough cost flexibility. It doesn't help that American manufacturers are at least 20 years behind the Japanese and Korean makers on developing these.
It generally doesn't make sense for the manufacturers that have the tech to make open hardware systems for this market segment when you're only talking about $1000/ton for residential hardware. The lock in is more valuable than the initial sale is my guess.
I think one could likely home brew an open-hardware variable speed system by retrofitting a standard three phase compressor and variable frequency drive (see Jeremy Fielding's youtube channel—linked below) to their residential unit but it is hard to find a small enough three phase compressor and wouldn't probably be mass marketable because even single stage units are often good enough for most residential applications.
Future building code adoption will probably have an influence on this particularly in the areas where ventilation requirements are tightened.
> Also, old air conditioners regularly lasted 30+ years, so this is a solved problem, and the patents have probably expired.
Survivorship bias argument.
Also, EPA has much stringent standard, my 50 years old AC using probably has a shitty 6 SEER (compared to 22 SEER for the best units these days), refrigerant has changed too, manufacturing tolerances are much tighter now, higher demand and lower prices has probably caused material quality to plummet as well...
I would pay good money to get access to the API my communicating thermostat uses - the Trane device is terrible in many ways that basic software updates could fix
Thanks for posting this! This looks like a fine product, and it led me to learn that Starling Home Hub is effectively "homebridge-nest[1] in a box", which is great news for Homebridge[2] users.
I ran Homebridge for a while but got tired of dealing with maintenance. The Starling box is set-it-and-forget-it. I don’t think I’ve had to access the control panel since installing it so it was well worth the $100 imo.
For sure, the reduced cognitive overhead is absolutely worth the price of admission.
I need to run Homebridge anyway for a bunch of devices that I want to be available via Alexa and HomeKit, so for me there was no incremental complexity. I'm running Homebridge via a Docker image[1] on my NAS (using QNAP Container Station), with Homebridge UI to manage.
It's a bit of a recurring pattern with Apple software. Good example is with tvOS, where streaming apps based on the template app that Apple provides are typically less frustrating and more functional than bespoke streaming apps.
Similarly, on iPadOS streaming services delivered through Apple TV+ channels often have better quality than those delivered via provider apps — this has been extremely visible going from watching Star Trek through the CBS TV+ channel w/4k video and 7.1 surround to The Expanse through the Prime Video app which delivers a "1080p" stream that often looks worse than Youtube 720p.
I think the root problem with all of these examples is companies treating software as a checkbox when it should be treated as core to the product.
I don't know what it is about Amazon software, but at least in the Apple ecosystem, it's terrible. I downloaded the macOS version of the Kindle reader because I was reading a programming-related book. A single page turn would take seconds to complete on a Mac Pro. I ended up profiling it with Instruments. It was a QT app that they had obviously ported from another platform and done no performance tuning on. It turned out it was redrawing the page 4 or 5 times, and allocating and freeing something like 40MB of memory on each redraw. It seemed like just having a statically allocated 40MB buffer would have solved the problem, but who knows? It was pretty appalling.
The ratings for their own software on their own web site show all the problems.[0]
I'd be interested in seeing if products can become HomeKit only. Unfortunately you still sort of need your own app for setup, etc. It's a decently sized barrier for manufacturers, and their app ends up shit anyway.
Most the HomeKit products I've tried don't need the native apps, just Homekit native on the phone.
Vocolinc and Wemo both are like this. In fact, the latest Vocolinc app has a "Homekit" mode, where it's basically just passthrough. Used for updating firmware only, pretty much.
I recently added a new Wemo smart-plug and used Homekit, not the app. The plug works fine in Homekit, doesn't even appear in the Wemo app. The only downside is no way to update firmware.
Biggest downside to Homekit only, is that you lose specific functionality a manufacturer might have. That said, I find Homekit to be better than the vendor stuff anyway, so stick with it.
You can actually set up some devices without downloading a manufacturer app. I did this for an iDevices thermostat I bought recently, although I downloaded their app later because the home app has no idea how to do "keep the temperature between this range during these hours". (The app is not half bad, FWIW.)
Complains about not having a common wire for an ecobee, cobbles together a separate box with a USB cable draping down around the door jamb - love it :)
As others pointed out, put a plain old bi-metallic thermostat in parallel with these confounded computerized thermostat as a fail safe. Frozen pipes are no joke! I have one in parallel with my Nest and would probably do it with a "normal" thermostat anyway as I've had those fail in weird ways in the past too. Redundancy on critical systems is never a bad thing.
You can hack it if you get access to an older furnace being junked. You need the 24VAC transformer and the main relay (the really old furnaces don't have one of course). Then the smart thermostat (which probably needs the parasitic power from this) can run off that, and your millivolt system can run off the relay contact closure. That said, as always, keep your existing thermostat paralleled to it, just in case.
Thermostats have been the subject of maker magazines since the beginning of DIY electronics, (personally) to the point it became boring to read another article about them. If only I could have guessed they had the potential to spawn a billion dollar industry. Anyway, just typing "DIY thermostat" into Google returns quite a lot of projects.
On the topic: I've had an ecobee 3 for the past few years, and I'm pretty happy with it - if you're in the market I'd highly recommend one. Killer features are mostly from the room sensors:
* Keep upstairs comfortable at night, main floor during the day
* Auto home/away mode (based on motion). This works so well, I only just changed the schedule to account for working from home about a month ago
I also like "Run fan for minimum of x minutes per hour" as it makes a noticeable difference on sunny days where the South side of the house is normally a lot warmer than the North.
Other than that, the app is decent and it's easy to connect to Home Assistant.
I have an older wifi thermostat controlling my fireplace, and a very useful automation I only just added turns on the furnace fan when the fireplace is "on" (temp set above 21) which helps keep the house balanced.
My only complaint about the ecobee is the Alexa integration will listen when I tell my Echo Dot to play music then I’ll end up with the Dot playing Apple Music and the Ecobee playing I Heart Radio or whatever because it doesn’t support Apple Music. So two songs playing and one on a garbage thermostat speaker. I wish it could just have Alexa support but only for thermostat stuff then ignore anything else.
Well the thermostat is in the living room and the echo is near the Alexa enabled microwave in the kitchen. So then we wouldn’t be able to adjust the thermostat from the living room without buying another Echo or Echo Dot.
I too am pretty happy overall with it. The web portal is pretty bad though. Its very finicky about logging in and maintaining its session. The app "Just Works" for the most part.
Didn't realize external power supply was available on ecobee, I contacted support (before purchasing) and they only gave me the neutral wire suggestion.
Yeah - I was also misinformed by support both before and after purchase.
They have a great resource library but their support staff don’t seem to get enough training.
Edit: I had to fish a new wire for one thermostat, and rewire the furnace for another. The results were well worth it though because of the wireless temperature and occupancy sensors.
Honestly, if HomeKit was something that we could use in an operating system that wasn't owned by Apple (~70% of devices on the planet ride Android, to be clear), the title here would feel a little bit more reasonable, but alas, Apple is the truest of true closed ecosystems. Open doesn't look like HomeKit and those boycotting walled gardens should know better than to find themselves trapped inside Apple.
You can install a homekit connector to home assistant, which has then great Android integration. No need to lock yourself to any garden. I use HASS with homekit, all kinds of zigbee devices and a german xml-rpc protocol for heating, all operated through HASS from one app.
Amazon, Apple, Google, and the Zigbee Alliance joined together to promote the formation of the Working Group. Zigbee Alliance board member companies IKEA, Legrand, NXP Semiconductors, Resideo, Samsung SmartThings, Schneider Electric, Signify (formerly Philips Lighting), Silicon Labs, Somfy, and Wulian are also on board to join the Working Group and contribute to the project.
Sure. I'll accept that I am just complaining that I can't get from one walled garden to the other. From my perspective, if they are all walled gardens, I might-aswell choose the best one.
That's totally fair. The title of this post is much more reasonable now. It avoids the argument that HomeKit is open and instead focuses on the cool engineering effort. :)
1. Have "can't fail" safeties. In my case, that's the existing thermostat in parallel with the relay (so that the house can't freeze up if my system fails) and a second extra thermostat in series with it (so that if it fails stuck on, things won't overheat too badly). The second safety thermostat can be out of the way, like in the basement.
2. Assuming you live in a northern area and have a furnace that's less than a decade old, it may well be a two-stage (i.e. high and low heat mode) one set up for autostaging (run on low for 5 minutes, then fire up full blast) because the installers were too lazy to fish the extra wire to run a proper 2-stage thermostat. My homemade system has a 0.3 degree Celsius difference between the low and high stage cut-in, plus some hysteresis to avoid short cycling, and it keeps the temperature wonderfully stable (within 0.2 degrees of the set point) with the furnace only ever switching to high if you turn up the temperature (on the very most brutally cold winter days it might run almost continuously on low). At least here in Canada, installers have to leave the technical manual with the furnace, so you know which DIP switch or jumper to change to disable autostaging.
3. Mechanical thermostats have something called an "anticipator" which slightly warms the sensing element as the furnace runs, so it tends to turn off below the set point. This is to avoid overshoot. Digital thermostats do it in software by pulse width modulating the furnace enable as the temperature nears the set point. In my case it's completely unnecessary to code this up - I guess the thermostat location is just perfect - but if you do get overshoot, just simulate it in software.
4. AC units can be damaged by short-cycling and sure enough an early version of my system had a bug that caused this. Luckily I noticed right away. Now it's full of safeties like minimum run and rest times and probably much more conservative than a real thermostat. Longer AC run times are better for dehumidification anyway. I also enforce minimum run times on the furnace.