Building my own HomeKit Thermostat
staycaffeinated.com
staycaffeinated.com
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.
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?
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.
while True:
if temperature < set_point:
heat for 15min
wait for 15min
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.
Seems like that would be really inefficient, but maybe that's common practice in embedded software stuff.
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.
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.
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.
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.
(I don't have AC.)
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.
I had a wifi honeywell for several years and eventually the wifi portion died. But the rest continued to function just fine.
If whatever you have does die in the dead of winter, you can always remove the thermostat and short the common and heat wires together.
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.
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.
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.
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.
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 just wish Hue would play better with HomeKit. Even my homebrewed HomeKit devices work more reliably in the Home app than Hue :/
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.
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).
My company was one of the first to have a HomeKit thermostat, and the biggest barrier was the hardware requirement.
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.
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.
As GP mentioned, HomeKit works when your internet is down. It only uses Apple’s servers for out-of-home control.
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)
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 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
https://vrfrejected.org/case-studies/
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.
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...
Nothing last forever.
[1] https://www.npmjs.com/package/homebridge-nest [2] https://github.com/homebridge/homebridge
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.
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.
The ratings for their own software on their own web site show all the problems.[0]
[0]https://www.amazon.com/Amazon-Digital-Services-LLC-Download/...
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.
https://iot.stackexchange.com/questions/2895/wi-fi-line-volt...
The question lists a number of commercial thermostats that may be of interest, as well as a nod to WebThings:
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.
I have an esp32 sensor system in my garage I’d like to add HomeKit functionality to.
[1] https://github.com/Brawrdon/esp-homekit-arduino-sdk?utm_sour...
[2] https://github.com/espressif/esp-homekit-sdk/tree/master/exa...
* 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.
However there is more than one solution for ecobee.
1. Replace the existing wiring! Probably not as hard as you think.
2. Use an external power supply - this is supported by ecobee.
3. There are 2 to 3 wire converters: https://support.ecobee.com/hc/en-us/articles/360008702251-FA...
Roll your own is fun, but these options are all going to be quicker and result in a better solution.
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.
https://www.connectedhomeip.com
https://github.com/project-chip/connectedhomeip#connected-ho...
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.