This is one of the reasons I am working on an enclosure-compatible open-source version of the 2nd gen Nest thermostat. It reuses the enclosure, encoder ring, display, and mounts of the Nest but replaces the "thinking" part with an open-source PCB that can interact with Home Assistant.
Nest has been pretty-badly supported in Home Assistant for over a year anyway, missing important connected features.
I've got the faceplate PCB done and working; the rotary encoder and ring working; and the display working but with terrible code with a low refresh rate.
I need to ship at the end of October to beat the retirement date. Plans to get some regular development report-outs and pre-orders are coming quite soon.
It's open source, and uses ESP32-C6 so it can be Wifi, BLE, or Zigbee, whatever software you intend to load onto it.
There is so much fun to be had with a rotary encoder and some sensors. What are your plans for extensibility? I think this would be an awesome hacker device — everyone needs a thermostat anyways, and an easy way to build new screens (volume control, door buzzer, whatever) and deploy to the device would be so cool.
I expect you’ll need to be heads down on the hardware and basic software problems to hit your dates. But I also think it’d be worthwhile to figure out the baseline for extensibility early. Maybe this is just a call-home mechanism so you can advertise updates, so you can do something more in the future.
I also wonder if you could somehow take advantage of ESPHome here, for very basic HA etc integrations (of other functions, to be clear).
Also, what are your thermostat algorithm plans? Are you intending to consume HA thermometers / sensors? Or perhaps expose programmability hooks directly on the device?
What language are you writing in? I recently did some rotary encoder work for a round display on an ESP32, and found the dev kit micro python stuff to be terribly slow. I’ve had good luck with LVGL in C++, and my “ick” feelings about c++ are pretty much totally resolved by a healthy dose of AI chat bots.
Send me an email if you’re interested in more info.
Oh, good to know. I have been using Toit for all the business logic, but the display can have special handling for performance if necessary. Toit can also adapt into custom C++ code if needed. https://docs.toit.io/language/sdk/display
Very close to having one! I've been working on getting a blog published and a store to pre-order the finished product. I'll reply back here with the link when it's ready.
Not at the moment, as the physical layout and components are different. In theory, all the research we put into making boards and software for the 2nd gen should have some applicability to making equivalent models for the 1st gen as well.
I replaced all my thermostats for both of my homes with Sinopé products. Smart, allows integration with locally hosted home automation, and compatible with ZigBee networks. Purchased my first batch in late 2021 and haven't had any issues. Physical temperature controls if the LAN goes offline. Highly recommend.
Here's the hardware installed for on-prem home automation using the open-source Home Assistant software:
* Raspberry Pi[1] CPU, heatsink, A/C adapter, and case
* ConBee II Zigbee USB gateway[2]
* USB ADATA Micro SD card reader and USB cable
* Micro SD card (for operating system and Home Assistant)
Same for myself. Sinooé devices are extremely solid (at least the Zigbee ones I've used) and work perfectly with Home Assistant. Would highly recommend.
Anything that requires a cloud account and does not offer a self hosted option, even a limited one, should be considered throw away. Would be nice if google released a self hosted server for these as a nod and thanks to the early customers.
Connected thermostats are great in theory! But they should not have to rely on a cloud connection. A local network with the option of internet connectivity would be awesome; but, it seems, no company is going to become uber successful if there isn't the option of forced upgrades and cloud subscriptions. Look at Ring...
Honeywell's z-wave thermostat basically does all of the shiny shit you'd want out of a connected thermostat while making basically impossible to lock the user out because Honeywell decided it didn't like the product anymore. Why people have to keep relearning this with IoT devices baffles me, and that Z-wave or maybe Zigbee isn't what's insisted upon.
If you're VC-funded then the valuation is the most important thing. The only way to juice your valuation is to get recurring revenue, because it comes with an 8x to 10x multiple. So you don't want to be in the hardware game, you want to use hardware to get a foothold in someone's home and then get them to pay you a subscription to maintain that hardware.
I think the valuation thing is what drives 90% of this stuff. Whereas an established company like Honeywell is more interested in building products and selling a lot of them, so they're going to charge you 5-10x of the cost of a Nest for the same feature set but with a local-first implementation instead of a cloud-first implementation.
I don't think I would ever buy a hardware product from a company billing themselves as a VC-backed startup.
Also, FWIW the Nest is a perfectly functional thermostat even if you never hook it up to their app. We found the scheduling and learning features to be really annoying so we turned them all off and never connected ours to the cloud.
I agree almost entirely, but I gotta quibble a point:
> so [companies like Honeywell] are going to charge you 5-10x of the cost of a Nest for the same feature set but with a local-first implementation
"Established" companies also see the long-term value of subscriptions and are also hopping on that bandwagon.
Additionally, customers are extremely sensitive to up-front price, so a product that's more expensive up-front but with no subscription fee and longer-term value will have trouble finding a foothold in the market compared to cheaper but subscription-based alternatives. Especially if the alternatives are "1 year free!" as they usually are.
I bought a $20 Zigbee thermostat from AliExpress and it has been fantastic. It turns on when it's cold, and off when it's hot. Anything else, I can do with software, because it's just Zigbee.
I go for Zwave by choice but Zigbee comes a close second. It does share 2.4GHz with wifi but its many tiny bands fit within the "edges" of the wifi bands. If you stick to 1,6,11 for wifi, Zigbee will co-exist very happily. Even if you don't, it will still work fine - the messages are tiny.
Both Zwave and Zigbee build mesh networks with multiple routes. Wifi devices ... don't. Wifi is fine for IoT but it isn't optimised for it. My fridge/freezer uses wifi as does my oven and microwave. It doesn't matter if they lose comms sometimes and there is no choice anyway.
My light switches are Zwave. Thanks to way modern UK wiring is done, most of my switches end up with an extra conductor and so are permanently powered and act as hubs for the battery powered window sensors and the like.
My cameras are all PoE ethernet, including the door bell. All Reolink.
I have two UPSs with at least 30 mins run time. I could easily put in a genny or a battery or even use my car (EV) but its not important enough (yet). So far everything will work without the internet.
I have deployed two VLANS for IoT - THINGS, and SEWER for the really worrying gear on it!
My Insteon thermostat is a great dumb thermostat that I can also send commands to over a serial connection to a powerline/RF modem. (Very similar to Z-Wave's RF, though proprietary.)
The key is do not buy smart devices with Wi-Fi. There are better products for serious people. Everyone here with a Zigbee or Z-Wave product probably learned that the hard way first. ;)
Plenty of companies are successfull and don't rely on forced cloud. Reolink for example. Plenty of others.
The real difference is that these are not american sv vc backed companies like nest or ring. they are chinese companies set on disrupting those vc backed companies using this local first mindset as the differentiator.
I have a Honeywell t6 that I got when they installed a new unit - Honeywell INSISTS that you create an account and download the app to connect it to your home network
Thankfully this is bullshit and you can connect it directly from the thermostat to HomeKit - you will not find a single piece of documentation on this though and will be told it’s not possible
The real kicker is that there is a notification to register your device that you can’t get rid of unless you register your device
You can only snooze it for a couple weeks at a time
How I’d love to have one on one conversations with the evil people who approve this type of crap
I got burned recently by Ecobee in the same way. The problem with 'smart' interfaces for traditionally mechanical devices is that the useable lifetime (support period) of low-end microprocessors and software, especially online APIs, is often far shorter than the mechanical device it's attached to.
Similar to how people that keep cars around for 10+ years are stuck with dated and worthless 'infotainment' systems, Google and Ecobee can't even honor their product for long enough to outlast the HVAC units.
What burns me is that it wouldn't be much of an ask for them to push one final (optional) update that would open LAN-only access to core functionality. I and many others in the HA/ESPHome community have written hardware integrations to devices over RS485/UART with unpublished/black-box protocols, so a simple HTTP API would have an integration within days.
It would maybe cost an engineer at Nest/Ecobee a day or two of work, and the goodwill would make me far more likely to purchase a newer model. As it is, I've committed to avoiding (where possible) devices that aren't local-first.
As an early Nest employee who worked on the first-gen thermostat I can tell you definitively that you're way off base here. That doesn't mean that Google shouldn't have done more to keep these units alive (and indeed that's one of the reasons I left Google). But these devices were designed in 2010-11. Even keeping the Linux kernel up to date with the latest version is a major undertaking. Adding major functionality like Matter compatibility, or even a simple (but secure!) local API, would take a seasoned engineering team a considerable amount of time.
That said, investing in devices that are local first is certainly good advice, provided the APIs are open and well supported.
Recent extreme frustration with Google products in mind, I'm tempted to read the crux of this post as, "Google engineers/designers are incompetent." It might be unfair, but on a day when Google Search, Youtube History Search, and (whaddya know) my Nest Thermostat have all failed me, the temptation is strong.
Security is always the excuse, but it's a local device connected to Wifi. Add a setting to the existing menus that is opt in to turn on the new API.
Beyond that, there's what, like 4 or 5 parameters that are useful to set, and a few that can be read. It wouldn't be necessary to over engineer the API, even a few simple, fixed TCP packets to query state and set the basic parameters like mode, fan, room and set temp would be all that is needed. It can be ugly and basic, just release the info and other devs would run with it.
For example, the older TPLink Kasa line of smart devices have a simple TCP packet protocol for local control. The 'security' was easily reverse engineered (simple key autokey cipher), but there wasn't any outrage. Their simple scheme that wasn't meant to be widely known meant it was possible for others to build the integrations.
"Even keeping the Linux kernel up to date with the latest version is a major undertaking."
To me this sounds always backward. We make a choice of tools, and now we can't support you longer, and blame it on the tools. It's like "I need a car because I've moved out of the city center." Yes, of course you need a car, but because of your choices and actions.
If you prioritize easier development over long term support when choosing tools, then this is what you get.
Of course it's ok and valid to make that tradeoff, but then don't blame it on the tools, but on your choices.
A bit of an unusual idea, but: if the users of such a thing are folks who're already playing with HA and are tech savvy, why not just expose the API and tell users that they're "only allowed to use the "hacker's update in good faith" if they put the devices on a separate network without internet access?
Your team doesn't need to spend a ton of time on making it super secure, and DIYers can continue to use the hardware for as long as it physically works, me thinks
Absolutely nothing is stopping Google from keeping all the integrations working until the thermostats physically break. No one asked for a new kernel and whatnot.
Is keeping alive the infrastructure that servers the 1st and 2nd generation devices online and just proxy the communication between the old features and new features available in HomeKit and other smart home hub apps such as big undertaking that Google balked at it?
Okay, but isn’t this really about, why should Google spend money making things work better for iPhone users? It doesn’t like doing that. That’s what Matter support is really about. It’s always been about Apple Home.
And before you accuse me of being “way off base” lemme ask you: why doesn’t Gmail support push for iOS Mail anymore?
> What burns me is that it wouldn't be much of an ask for them to push one final (optional) update that would open LAN-only access to core functionality.
The last dev who understands the code and the build tooling left years ago.
At least HVAC systems have a mostly standard control system and thermostats are easy to swap out. If a thermostat goes out of support and looses functionality, you do not need to replace the entire HVAC system; only the relatively cheap thermostat.
I'm contrast, while it is often possible to replace an infotainment system, the replacement needs to have been designed for a fairly specific set of cars, and actually installing it requires paying a mechanic for most people.
If your car is old enough to have a standard DIN radio, you can easily replace it with a modern CarPlay/Android Auto unit. And cars that are new enough to have CarPlay/Android Auto built in seem to be generally holding up. It’s really just cars from a specific window (after they started putting nav systems and screens, before adopting CarPlay) that age really badly.
In the early 2000s, even cars with oddball radios (like a CD slot adjacent to climate controls for example) could have an aftermarket head unit installed because dash trim kits were available to replace the proprietary layout with a DIN slot. Is this not the case for the era you mentioned?
> Similar to how people that keep cars around for 10+ years are stuck with dated and worthless 'infotainment' systems, Google and Ecobee can't even honor their product for long enough to outlast the HVAC units
I would never buy a car that doesn’t support CarPlay. The four protocols that Apple created to interface with non Apple devices - the original iPod protocol, AirPrint, AirPlay and CarPlay haven’t had any breaking changes. As of at least three years ago, I could use an old first gen iPad from 2010 (the first to support AirPlay/Airprint) and use it with modern Roku TVs with AirPlay support and modern printers.
My old 2011 Sonic that I had with a USB port that supported the iPod protocol for displaying titles for audio and controlling iPods still worked with every iPhone I had.
But I would never trust Google not to kill a device.
I got lucky with my 2011 Toyota because the inputs are standard Bluetooth, an aux port, and iPod-style USB. The display is also a VFD pixel display and not some crappy LCD with a resistive touchscreen.
Of course, new devices might use some incompatible Bluetooth standard in the future.
I don’t get who uses Nest or other non-first party thermostats anymore:
All modern furnaces/ACs/heat pumps require their own smart thermostat to work optimally. So if you install Bryant furnace, you end up with Bryant smart thermostat, and so on. In fact, when choosing new furnace/AC choose brand with good software in thermostat first and foremost - units themselves are pretty identical otherwise.
That really isn’t true. I have a split level heat pump with no thermostat, well, there is one in the remote control that sets a mini thermostat on each internal unit. Basically, we don’t have a central thermostat but that isn’t weird for Seattle.
Incidentally, I would love for a better remote control that was easier to use, we might use our heat pump more than a couple of weeks a year in that case.
Serious question: What does this mean? I'm such a dumbo about networking. Is it simple for an app to distinguish between "LAN" and "WAN" network requests?
To each their own, but the idea of an internet connected thermostat (at great expense!) never made sense to me. A $20 Honeywell lets you program 4 regions per day (waking, day, evening, night) and will be fine almost every day of the year. Has a battery backup and never failed me.
I guess it would be cute to get some analytics dashboard, but that’s about where my interest ends.
I really appreciate mine. My big use case is that we go away for a week or two over winter sometimes and turn the house down to 55F. The radiators take quite a while to heat the house back up from that temperature, so I turn the temperature back up remotely the morning before we fly back.
That said, I'm quite annoyed that Google is nuking my perfectly functional thermostat, and I will be buying an Ecobee to replace it, and integrating it with home assistant.
Well beyond a basic dumb thermostat I like that my EcoBee can use several wireless temperature sensors. During the day I have it set to only use the downstairs sensors and at night it only uses the upstairs sensors.
Can a $20 Honeywell thermostat do that with wireless sensors? If it can, I will get one.
The issue that the Nest solved for me was figuring out how long it took for the hot water to get to the radiators, and what the bounce looked like after it got there. It'll stop calling for heat before it reaches the final temp because it will still keep going up.
It doesn't need to be cloud-connected to do so, but that's not a feature I'm aware a $20 Honeywell has.
Everyone always says this stuff, but man these things are such garbage to use: terrible user interface, LCD screen with random blinking elements to tell you that's being edited, response rate slower than a ping to Mars. Modern app-connected thermostats are so much better.
I have the same thing and to be honest, if I had to replace a $200 thermostat every 2 years I would gladly do it. In fact, this whole thing has made me go and research which thermostat will fit where I live.
It's starting to look like when you buy any kind of electronics gizmo with a UI, your choices are limited to:
1. A non-smart device that will work forever but looks and feels like it's still in the 90s
2. A device with a nice, responsive UI, but destined for the landfill because it's chained to a cloud service.
Why are these things mutually exclusive? Across so many product categories, there's seemingly few or no options for a nice UI but without dependence on an Internet service that will inevitably shut down.
I used to have a Honeywell wi-fi thermostat. It looked like any other thermostat you've ever seen, except you could connect it to a home hub. It was nice because you could exactly what you're describing, but you could also do it in the app.
What made it worth it was being able to turn off the air or heat when you weren't home automatically. Now all or the "AI training" garbage? Yeah, forget that. I used to work in an office with a nest and it was torture if you showed up too early if stayed a little too late.
Luckily, this can all be achieved using a Wi-Fi or (even better) a Z-Wave thermostat that is 100% locally-controlled using something like Home Assistant or any number of other solutions.
The shameful part is that the only thing that even remotely (no pun intended) needs a server to even be online, is the out-of-home control, just for NAT traversal. It should be free to Google for these to have at least in-home smart functionality forever.
Well, that, and the moving target of updating an "app" every year for all the breaking changes Google and (especially) Apple do to the mobile OS. Although honestly I'd rather have a QR code that links you to a PWA hosted on the thermostat itself.
I’m affected by this, and as pissed at Google about it as anyone, but the headline is overblown. The old Nest devices continue to function as thermostats, and the on-device features like scheduling still work. But I need the cloud-based features (particularly remote control via the app), so I went ahead and paid the upgrade tax.
This should be pretty much true for every "connected" device out there. They should all have a mode that works by directly connecting over the local LAN. Why do device manufacturers refuse to support this configuration?
If I want to change the volume of my "smart speaker" from my phone that's also on my LAN, it shouldn't require a round trip to a server on the Internet, or an account with credentials, or any of that nutty stuff.
> Why do device manufacturers refuse to support this configuration?
My theory is that it checks boxes for "sEcUrItY."
There aren't enough enthusiasts who know the first thing about computers or security to be a market for any mass-market hardware, so they're designed for the proverbial "grandma" to be able to plausibly use. Therefore, you can't ask them to establish, remember, and maintain the secrecy of any credentials.
Therefore, they either need to make the devices permissively trusting on the LAN (which IoT devices got a lot of criticism for a few years ago) or they need these fluffy login methods that introduce dependencies: Usually they require email for forgotten-password recovery, SMS for a "sEcOnD fAcToR", and of course, because it would confuse people if the control only worked on the LAN without integrating into a home hub, they need every device to connect directly to the cloud and therefore for the app control to go through the WAN. Or at minimum, the LAN<->LAN communication is only permitted by possession of a JWT or similar that's been recently authorized by the cloud server.
I was hoping that at least my Home Assistant integration would keep working. That sucks terribly. Lesson of the day: Avoid any IoT device that you can't use without an external service.
FWIW, I replaced my Nests with Centralite Pearls a few years ago, and have been extremely happy with them WRT Home Assistant. The Pearl doesn't seem to be widely available anymore, but any Zwave or Zigbee thermostat + a local hub gets you a thermostat that should work with Home Assistant and will be immune to being sunsetted like this.
Readit News
I've got the faceplate PCB done and working; the rotary encoder and ring working; and the display working but with terrible code with a low refresh rate.
I need to ship at the end of October to beat the retirement date. Plans to get some regular development report-outs and pre-orders are coming quite soon.
It's open source, and uses ESP32-C6 so it can be Wifi, BLE, or Zigbee, whatever software you intend to load onto it.
I expect you’ll need to be heads down on the hardware and basic software problems to hit your dates. But I also think it’d be worthwhile to figure out the baseline for extensibility early. Maybe this is just a call-home mechanism so you can advertise updates, so you can do something more in the future.
I also wonder if you could somehow take advantage of ESPHome here, for very basic HA etc integrations (of other functions, to be clear).
Also, what are your thermostat algorithm plans? Are you intending to consume HA thermometers / sensors? Or perhaps expose programmability hooks directly on the device?
Send me an email if you’re interested in more info.
I replaced all my thermostats for both of my homes with Sinopé products. Smart, allows integration with locally hosted home automation, and compatible with ZigBee networks. Purchased my first batch in late 2021 and haven't had any issues. Physical temperature controls if the LAN goes offline. Highly recommend.
Here's the hardware installed for on-prem home automation using the open-source Home Assistant software:
* Raspberry Pi[1] CPU, heatsink, A/C adapter, and case
* ConBee II Zigbee USB gateway[2]
* USB ADATA Micro SD card reader and USB cable
* Micro SD card (for operating system and Home Assistant)
* Ethernet cable (optional if using onboard WiFi)
There's a tutorial walking through the setup:
https://www.youtube.com/watch?v=GJEwrSSFe9s
It takes a little more labour to make it remotely accessible via smart phone, but once you have it locally hosted, that world is your oyster.
[1]: https://www.raspberrypi.com/products/raspberry-pi-4-model-b/
[2]: https://phoscon.de/en/conbee2
These mofos are too greedy to do this.
I think the valuation thing is what drives 90% of this stuff. Whereas an established company like Honeywell is more interested in building products and selling a lot of them, so they're going to charge you 5-10x of the cost of a Nest for the same feature set but with a local-first implementation instead of a cloud-first implementation.
I don't think I would ever buy a hardware product from a company billing themselves as a VC-backed startup.
Also, FWIW the Nest is a perfectly functional thermostat even if you never hook it up to their app. We found the scheduling and learning features to be really annoying so we turned them all off and never connected ours to the cloud.
A Nest is ~$150, so I'm curious where these $750-1500 thermostats are...
Seems like you get a Honeywell thermostat for almost exactly the same price, if you don't care about cloud connectivity.
> so [companies like Honeywell] are going to charge you 5-10x of the cost of a Nest for the same feature set but with a local-first implementation
"Established" companies also see the long-term value of subscriptions and are also hopping on that bandwagon.
Additionally, customers are extremely sensitive to up-front price, so a product that's more expensive up-front but with no subscription fee and longer-term value will have trouble finding a foothold in the market compared to cheaper but subscription-based alternatives. Especially if the alternatives are "1 year free!" as they usually are.
Nests performed well in unique spaces with different heating and cooling profiles, not to mention different kinds of shoulder seasons.
Both Zwave and Zigbee build mesh networks with multiple routes. Wifi devices ... don't. Wifi is fine for IoT but it isn't optimised for it. My fridge/freezer uses wifi as does my oven and microwave. It doesn't matter if they lose comms sometimes and there is no choice anyway.
My light switches are Zwave. Thanks to way modern UK wiring is done, most of my switches end up with an extra conductor and so are permanently powered and act as hubs for the battery powered window sensors and the like.
My cameras are all PoE ethernet, including the door bell. All Reolink.
I have two UPSs with at least 30 mins run time. I could easily put in a genny or a battery or even use my car (EV) but its not important enough (yet). So far everything will work without the internet.
I have deployed two VLANS for IoT - THINGS, and SEWER for the really worrying gear on it!
Home Assistant runs the show.
The key is do not buy smart devices with Wi-Fi. There are better products for serious people. Everyone here with a Zigbee or Z-Wave product probably learned that the hard way first. ;)
The real difference is that these are not american sv vc backed companies like nest or ring. they are chinese companies set on disrupting those vc backed companies using this local first mindset as the differentiator.
I have a Honeywell t6 that I got when they installed a new unit - Honeywell INSISTS that you create an account and download the app to connect it to your home network
Thankfully this is bullshit and you can connect it directly from the thermostat to HomeKit - you will not find a single piece of documentation on this though and will be told it’s not possible
The real kicker is that there is a notification to register your device that you can’t get rid of unless you register your device
You can only snooze it for a couple weeks at a time
How I’d love to have one on one conversations with the evil people who approve this type of crap
If you have the latest models you’re not dependent on the cloud, and it’s unfortunate Google didn’t add this functionality to these retired models.
Similar to how people that keep cars around for 10+ years are stuck with dated and worthless 'infotainment' systems, Google and Ecobee can't even honor their product for long enough to outlast the HVAC units.
What burns me is that it wouldn't be much of an ask for them to push one final (optional) update that would open LAN-only access to core functionality. I and many others in the HA/ESPHome community have written hardware integrations to devices over RS485/UART with unpublished/black-box protocols, so a simple HTTP API would have an integration within days.
It would maybe cost an engineer at Nest/Ecobee a day or two of work, and the goodwill would make me far more likely to purchase a newer model. As it is, I've committed to avoiding (where possible) devices that aren't local-first.
That said, investing in devices that are local first is certainly good advice, provided the APIs are open and well supported.
Beyond that, there's what, like 4 or 5 parameters that are useful to set, and a few that can be read. It wouldn't be necessary to over engineer the API, even a few simple, fixed TCP packets to query state and set the basic parameters like mode, fan, room and set temp would be all that is needed. It can be ugly and basic, just release the info and other devs would run with it.
For example, the older TPLink Kasa line of smart devices have a simple TCP packet protocol for local control. The 'security' was easily reverse engineered (simple key autokey cipher), but there wasn't any outrage. Their simple scheme that wasn't meant to be widely known meant it was possible for others to build the integrations.
https://www.softscheck.com/en/blog/tp-link-reverse-engineeri...
To me this sounds always backward. We make a choice of tools, and now we can't support you longer, and blame it on the tools. It's like "I need a car because I've moved out of the city center." Yes, of course you need a car, but because of your choices and actions.
If you prioritize easier development over long term support when choosing tools, then this is what you get.
Of course it's ok and valid to make that tradeoff, but then don't blame it on the tools, but on your choices.
A bit of an unusual idea, but: if the users of such a thing are folks who're already playing with HA and are tech savvy, why not just expose the API and tell users that they're "only allowed to use the "hacker's update in good faith" if they put the devices on a separate network without internet access?
Your team doesn't need to spend a ton of time on making it super secure, and DIYers can continue to use the hardware for as long as it physically works, me thinks
Is keeping alive the infrastructure that servers the 1st and 2nd generation devices online and just proxy the communication between the old features and new features available in HomeKit and other smart home hub apps such as big undertaking that Google balked at it?
Deleted Comment
And before you accuse me of being “way off base” lemme ask you: why doesn’t Gmail support push for iOS Mail anymore?
The last dev who understands the code and the build tooling left years ago.
I'm contrast, while it is often possible to replace an infotainment system, the replacement needs to have been designed for a fairly specific set of cars, and actually installing it requires paying a mechanic for most people.
I would never buy a car that doesn’t support CarPlay. The four protocols that Apple created to interface with non Apple devices - the original iPod protocol, AirPrint, AirPlay and CarPlay haven’t had any breaking changes. As of at least three years ago, I could use an old first gen iPad from 2010 (the first to support AirPlay/Airprint) and use it with modern Roku TVs with AirPlay support and modern printers.
My old 2011 Sonic that I had with a USB port that supported the iPod protocol for displaying titles for audio and controlling iPods still worked with every iPhone I had.
But I would never trust Google not to kill a device.
Of course, new devices might use some incompatible Bluetooth standard in the future.
All modern furnaces/ACs/heat pumps require their own smart thermostat to work optimally. So if you install Bryant furnace, you end up with Bryant smart thermostat, and so on. In fact, when choosing new furnace/AC choose brand with good software in thermostat first and foremost - units themselves are pretty identical otherwise.
Incidentally, I would love for a better remote control that was easier to use, we might use our heat pump more than a couple of weeks a year in that case.
Deleted Comment
- You connect directly to the device to tell it what to do
vs
- You connect to some service at google/whatever that then tells your device what to do.
The former still works after google/whatever decide not to support/host the service that handles that.
I think you misspelled a _year_ or two of work. Especially with the scrutiny that comes with software written at a major corp like Google.
I guess it would be cute to get some analytics dashboard, but that’s about where my interest ends.
That said, I'm quite annoyed that Google is nuking my perfectly functional thermostat, and I will be buying an Ecobee to replace it, and integrating it with home assistant.
Can a $20 Honeywell thermostat do that with wireless sensors? If it can, I will get one.
It doesn't need to be cloud-connected to do so, but that's not a feature I'm aware a $20 Honeywell has.
I have the same thing and to be honest, if I had to replace a $200 thermostat every 2 years I would gladly do it. In fact, this whole thing has made me go and research which thermostat will fit where I live.
1. A non-smart device that will work forever but looks and feels like it's still in the 90s
2. A device with a nice, responsive UI, but destined for the landfill because it's chained to a cloud service.
Why are these things mutually exclusive? Across so many product categories, there's seemingly few or no options for a nice UI but without dependence on an Internet service that will inevitably shut down.
What made it worth it was being able to turn off the air or heat when you weren't home automatically. Now all or the "AI training" garbage? Yeah, forget that. I used to work in an office with a nest and it was torture if you showed up too early if stayed a little too late.
Being able to use the temp reading in a specific room is choice.
Deleted Comment
Adjusting the thermostat (which is downstairs) from bed.
At the airport - oh shit did I turn off the AC for the two weeks we'll be away? Ok I just did.
Well, that, and the moving target of updating an "app" every year for all the breaking changes Google and (especially) Apple do to the mobile OS. Although honestly I'd rather have a QR code that links you to a PWA hosted on the thermostat itself.
If I want to change the volume of my "smart speaker" from my phone that's also on my LAN, it shouldn't require a round trip to a server on the Internet, or an account with credentials, or any of that nutty stuff.
My theory is that it checks boxes for "sEcUrItY."
There aren't enough enthusiasts who know the first thing about computers or security to be a market for any mass-market hardware, so they're designed for the proverbial "grandma" to be able to plausibly use. Therefore, you can't ask them to establish, remember, and maintain the secrecy of any credentials.
Therefore, they either need to make the devices permissively trusting on the LAN (which IoT devices got a lot of criticism for a few years ago) or they need these fluffy login methods that introduce dependencies: Usually they require email for forgotten-password recovery, SMS for a "sEcOnD fAcToR", and of course, because it would confuse people if the control only worked on the LAN without integrating into a home hub, they need every device to connect directly to the cloud and therefore for the app control to go through the WAN. Or at minimum, the LAN<->LAN communication is only permitted by possession of a JWT or similar that's been recently authorized by the cloud server.
* technically still does, but they tried to switch before they backpedaled