Today, Google announced the end of support for the Nest Smart Learning Thermostat for Gen1 and Gen2 models. With the discontinuing of support for these models, Google indicates they will no longer be supporting the products with Software Updates (Understandable, as many of them are a Decade or so old now). Google also announced that the Smart features which rely on Wi-Fi connectivity for the product will be discontinued. This includes functionality such as controlling the device via the Nest/Google Home App, using a Smart Speaker, having Home/Away presence based on the presence of a Smartphone, or in my case, a person who uses Home Assistant, no more Home Assistant Integration support! This is because the Thermostat lacks a local API, HomeKit connector, or MQTT Agent which allows the product to be controlled without going to the Cloud.
This sort of thing needs to stop.
In a few other blog posts, I’ve alluded to the fact that I am building integrations with an open source solution called Home Assistant. It’s a great platform which you should definitely check out if you are looking to build a Smart Home. It is maintained by the Open Home Foundation, who also supports the development of ESPHome, a great open source firmware for the inexpensive Espressif ESP8266 and ESP32 micro-controllers which power so many IoT devices like Smart Bulbs, Smart Plugs, and other Smart gadgets. Many ESP-powered devices that you can find on the Internet often run proprietary firmware, or use Tuya, which is equally as questionable as a Nest Thermostat in terms of longevity and not requiring the Cloud. Both Home Assistant and ESPHome can be hosted on your own hardware, which could be a Raspberry Pi, a NAS capable of running Docker containers, or any computer for that matter capable of running Linux. Because ESPHome and Home Assistant are open source, you can be sure that the software isn’t just going to shut down and break, because a company decides to discontinue support for the software.
I am the owner of a Nest Generation 2 Thermostat. So likewise, I have another device to add to the pile of Internet of eWaste. With that said, the product is still going to work as a Thermostat with all of the local functionality, assuming there isn’t some firmware level problem that breaks the Thermostat’s basic functionality in time. Currently, I have the device integrated in with Home Assistant, after paying Google’s $5 API fee to be able to control the Thermostat. Once again, the functionality still depends on the Cloud to work, and it isn’t a great API at that (low daily rate limits for polling temp/humidity/system status, and control, notably).
What Google, and other companies need to do in this situation (and honestly should be required under the law to do), is do at least one or two things. They need to either update the firmware to expose a fully local API for software developers to build upon, or they need to open up the Bootloader and provide documentation on the product, such as schematics and boot structures, to allow people willing to run custom firmware on their devices, the ability to do so.
The former should be an easy win for any product. Local APIs are already common with products that tout HomeKit Integration, MQTT Integrations, or which sport a Web Interface with a documented Control API (common with AV equipment). It’s not a difficult or new concept, and if a product is abandoned from software updates, then it is no longer the problem of a company if the device remains “Smart” without a cloud. It just becomes a local network device, and the responsibility of the end user to secure (like many printers). These devices with Local APIs should also have no requirements to use a smartphone app to complete the setup, since these will lose support over time for old products, or can suffer from abandonment themselves – especially where login is required to start managing products.
The latter can be much harder, because of existing laws via Copyright and Patents, as well as concerns about modifying products outside of their intended functionality. Abandoned software in terms of Copyright, realistically, should be treated as abandoned, and therefore public domain. Patents on board design are another thing, and abandoned products should expire the patents which are specific to that exact product (iterations can remain patented if they remain in active support). As for security or intended functionality changes, if a product is abandoned, it’s not getting security updates anyways, and the manufacturer sold a product as-is. Abandonment should absolve them of any responsibility for changes made by the owner of the product.
With that said, the abandonment of the Nest Gen1 and Gen2 products can also be problematic. In Google’s discontinued support announcement, they mention how the Thermostat will no longer be able to communicate with Nest Protect sensors. These sensors can work together with other Nest products to do things like, turn off the thermostat if a House Fire is detected by a Nest Smoke Alarm, or if CO levels rise while the heat is on, to avoid adding fuel to a brewing fire, or to avoid spreading Carbon Monoxide from a faulty heating system to the rest of the house through forced air. This is the Emergency Shutoff feature. I find it insane how an Emergency Shutoff feature requires the Cloud to work, and how it has no viable, local method to do this whenever such a path is possible. Because hey, what if the Internet is down/Google is down, but the local network is still up?
Of course, this also means a loss of a lot of quality of life and energy efficiency functionality. The ability to figure out if people are home via Smart Phone apps and Smart Product interaction also is reduced to nothing more than a proximity and motion sensor with the in-built sensors. For those with Home Automation tools such as Home Assistant, it is easy to do this all locally and to pick your data sources. For example, to control some smart outlets which power my indoor Holiday lights in December, I have a Home Assistant automation in place which turns the outlets on ONLY if certain devices are detected on the Wi-Fi, and have been on the Wi-Fi for X number of minutes. The outlets are off, otherwise, saving my electric bill from Holiday lights which are on while no one is home to enjoy them. This doesn’t require any apps on the cell phones, and is also privacy respecting of the person’s location outside of the home (if they’re not home, they’re not on the Wi-Fi. Simple). My Wi-Fi network has a locally hosted controller with a read-only account for Home Assistant to query for connected clients. Something like this requires a local API to be available on the Nest Thermostat once the servers are turned off to accomplish similar functionality.
The ability to adjust the thermostat in anticipation of bad weather or of impending power outages can also be a problem, and likewise the ability to adjust the thermostat based on peak usage billing is hampered. For example, right now I use data from my air quality monitors (AirGradient), both indoor and outdoor, to adjust my thermostat for comfort and health. If the air is smoggy outside (high PM2.5 or US AQI) then the Thermostat will run the fan constantly to ensure the air indoors remains filtered. I use MERV13 filtration, and it has helped to keep the air inside of my home fresh while outside is filled with wild fire smoke, and the AQI is over 130. If the weather forecast calls for hot weather, or if my air quality monitors report a rapid rise in temperature, then the thermostat is carefully adjusted to call for cooling before the house begins to soak in heat and humdiity (Which makes things very uncomfortable come bed time), and reduces my cooling costs. This performs the same job as a Nest Sensor, but on Steroids, as the data being analyzed is from a wider variety of data sources, including professional monitoring stations via the Internet. But, all of this works without Internet as well, which is important because sometimes my ISP, or Cloud Services, can be down for multiple hours at a time. If I had a Solar system to aid in electrical, then I could additionally tie in data from that via Home Assistant to control the Thermostat based on solar production (to save on grid power demand/maximize grid sell-back), as Nest has no such product natively to my knowledge.
Power companies who offered rebates or discounts for the installation of such products, might see that costs need to be passed back onto the consumer for using a product which cannot function as a full smart thermostat anymore. If it were possible to add the Nest device in with a local API, all of this information could be configured into schedules with Home Assistant, and I could have the choice of data provider for things like energy billing rates. Wouldn’t do much about automated rebates and grid-suggested adjustments, but I figured this might be worth pointing out should it happen.
So none the less, this is pretty bad news. As for what I’d replace my Nest Gen2 Thermostat with? Not another Nest, even though I’ve had about a decade of faithful service from the device with only one or two times that I can recall where it failed to work and needed a reboot. I’ve had a lot of people recommend Ecobee to me, since their Thermostats support HomeKit. I still have many concerns about whether that will remain a viable path for the indefinite future. From my basic understanding of their product, though, an Ecobee device can be set up via Matter, Wi-Fi, or Bluetooth, and displays pairing information right on the screen on how to get it set up, supposedly not requiring a mandatory smartphone app. I don’t know if the product will support being connected to a Wi-Fi network without Internet access (or heavily policed access), and whether HomeKit setup will complete under such a circumstance. So that is something I need to look into more. Others have recommend Honeywell Thermostats to me, but Honeywell at the moment makes me think of Chamberlain and their MyQ garbage. I need to see if Honeywell has a local API on their H-series thermostats, and if they do, then they may be viable. As long as they don’t have a dumb Smartphone app/cloud account requirement to get things working. So long story short, I’m trying to find something that works locally, and isn’t going to be at risk of becoming a glorified scheduling thermostat
Another example of Cloud-Connected Trash
Another example of some products which have led to my e-Waste trash pile getting a little more full are Smart Light Bulbs. One of my Housemates a few years ago, purchased WLED Light Bulbs from a company called Vont, which was prominently on Amazon for quite a while, selling Light Bulbs, Light Strips, Smart Outlets, and other gadgets. Their products are based on the Espressif ESP8266 and ESP32. They produce a pretty nice light, and overall have been dependable products.
A year or so ago, Vont went out of business. Their products, like many other consumer devices, require a Smartphone app to configure, and the product then ties into the Cloud for all interactions. The Cloud Integration is also used to handle the Google Assistant and Alexa Integration advertised by the product, since these Smart Speaker products typically require Cloud Brokering and connectivity. In some cases these Vont products may use Bluetooth or HomeKit for more local control, but in general in they require connectivity to the Cloud before they can even get that far, and use a proprietary app which can no longer be logged into. Factory resetting a bulb will require their app to communicate with, otherwise the bulb becomes a simple smart light bulb that is on or off.
Since the bulbs my housemate has are ESP32-based, one route Vont could have taken to keep their bulbs in service was to provide a path to flash them to ESPHome. Or to provide a local Web API. Both of which are something that will operate on an ESP8266 or ESP32. Bulb setup could be done by simply connecting to a Wi-Fi network produced by the bulb and accessing an HTTP Server. From there, HomeKit, Home Assistant, or any other assortment of automation and control tools could be stood up to keep the bulbs operating as Smart Bulbs.
For now, the fix for the Vont bulbs is to crack each one open, and obtain serial access to the ESP32 board. Once obtained, different firmware such as ESPHome can be flashed to the bulb. Still though, cracking open these bulbs requires cutting adhesive seals holding the bulb casing together, and getting into portions of the bulb which make contact with the mains power, so a little more dangerous than what most people would be willing to do. Or they can be bound to running as just basic on/off bulbs which take an extra second or two to power on (waiting for the ESP to boot) when the switch is flipped.
If I were to purchase any Smart Bulbs, I would go with something such as the KAUF Smart Bulbs. These ship with ESPHome firmware pre-loaded, and can be flashed to another open source firmware called Tasmota, which also has Home Assistant support! The Smart Outlets I mentioned earlier for my Holiday Lights, are KAUF PLF12 Plugs. They have worked exceptionally well, have very granular current monitoring for gauging power usage, and have virtually instantaneous response to on/off commands, due to not having any cloud tie-in. Connecting them to the Wi-Fi is as simple as using a Wi-Fi enabled device with a web browser to connect to a hotspot, visit a web page, and entering in the Wi-Fi credentials. Alternatively, I know Phillips HUE is a pretty proven and dependable lineup, plus products built off of Zigbee and Matter are a bit more unified in how they work, so leaving the direct-to-Wi-Fi ecosystem is also a possibility for long term support.
Yet another example – Except less Trash
Another example to provide is with the Wink Relay. A friend of mine installed one of these in their home when they initially began to use Smart Home Products. These are Android-powered Smart Switches, and for a while had a promise of acting as a Smart Home controller complete with Zigbee support. My friend had the product for several months before the device was seemingly abandoned. Abandoned in the sense that, the product stopped receiving software updates, stopped updating weather information (the telltale sign something happened to the product), and the underlying platform for it became useless. Following the abandonment, newer products were released which require a subscription in order to use the Smart Home functionality.
So OK. I get it. A subscription to keep cloud-based services working and to provide software updates long term. Doesn’t sit well with me, though, as this still means connected products can stop working at any time, and it also means price hikes.
As for the Wink Relay, there are jailbreaks and ways to root the device (one of many examples), as well as mechanisms for installing custom applications onto the factory image, bypassing all Cloud connectivity for the device. I would consider this to be a bit more open than the other examples provided above, as getting the product back into a usable state does not require completely disassembling the product and serial flashing (although you can do that if you really want to flash it to Stock Android).
Anyhow. This post has turned more into a rant about the abandonment of yet another Smart product. Hopefully it is useful in some way.
