API access is being ended as well, so third-party apps and services will not work.
replies(1):
at least they dont seem to be planning a mass bricking.
Some earlier discussion: https://news.ycombinator.com/item?id=45033555
And when it was announced in April: https://news.ycombinator.com/item?id=43802574
But yes, this is why I'm staying away from Gemini. Seems like an amazing product! But no way am I putting my AI eggs in the Google basket.
I wish the internet of things was soo much better than it is. There was a dream once of a world that worked efficiently, and then profit models came in and destroyed it.
I guess it would be cute to get some analytics dashboard, but that’s about where my interest ends.
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.
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.
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.
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.
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
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.
Lyrion Music Server (formerly Logitech Media Server) is open-source server software for Squeezebox audio players, https://lyrion.org/
Tasmota is open-source firmware for ESP8266 and ESP32-based devices, https://templates.blakadder.com/preflashed-stand.html & https://github.com/tasmota
Some IP cameras have open firmware replacements.
Some Chromebooks are supported by mainline Linux.
Of course the app stops working, but that’s expected from a WiFi product.
Since it's Homekit compatible though, you can go that route. HA easily discovers anything HK compatible as soon as you connect it to your network. So you connect Ecobee to HA with the HomeKit protocol in lieu of connecting it with Apple's stuff.
[1] ...and anything's better than the asinine on-device UI that Ecobee "updated" to a couple years ago (ask yourself: what would a foolish inexperienced "uX dEsIgNeR" do to ruin a plain old thermostat UI? It's that.)
The day the kill that, is the day a new hell is trust upon you.
As it were, appreciate the life you have right now that AI doesn’t have ads, it’s coming.
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.
"Smart" home devices work as expected for about a year and then they fail in new and exciting ways, and then you replace them.
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. ;)
I am a HA guy and prior to my ecobee I ran an American Radio Thermostat with local HA support and you could control over curl. But the wifi module was so old that no modern device connected to it when I had to reset it up.
But I agree zwave plus HA are a great option too.
You’re still in the return window when you are presented with the service ToS.
Serious answer: I do not expect any specific lifetime at all (though legal return period is an obvious floor), but at a bare minimum I do expect (and think should absolutely be mandated by law) that power be intimately tied to responsibility. Ie., it's fine if a hardware vendor decides to retire their cloud services (or OS updates or the like) in 1 year or 10 years or 20 or 30, but IF they cease to support it, THEN they must also remove any technical obstacles to hardware owners pointing it at another service of any kind. So any signing keys required, code, docs/APIs etc. Decide that a given product no longer makes commercial sense for you to produce or support? Sure, fine, it happens. The problem is then ensuring the hardware/software dies with that.
The basic issue is that these places generally want to have their cake and eat it too. They want all the financial power of a monopoly tie-in and feudal rent extraction, but no responsibilities to go with it and the ability to force customers onto new stuff (or nothing). That should be illegal. Honestly, I think any tie-in should be illegal, fully accessible local APIs should be required and any 1st party subscription should earn its place on its merits.
But at a minimum, no one should be able to have it both ways. If they want power over their customers, they should have responsibility proportional to that. And conversely if they go full open source community friendly hackable from day 1 (and are fully upfront about that), I'm fine saying they have very minimal long term responsibility. There can and should be room for many different approaches to the market, but not extractive lock-in.
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.
Can a $20 Honeywell thermostat do that with wireless sensors? If it can, I will get one.
Not that straightforwardly in Nest's particular case to be fair, but a lead in to other products, and Nest was perhaps bought by Google before having to worry too much about profit margins(?).
> 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.
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.
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.
> "Smart Local Control" home devices work as expected until the electronics fail
ftfy.
It doesn't need to be cloud-connected to do so, but that's not a feature I'm aware a $20 Honeywell has.
Also, that posts says the thermostat will still work locally so the failure state of the "smart" device here is that it became a "dumb" device after a decade+.
[1] - https://en.wikipedia.org/wiki/Google_Nest#Nest_Learning_Ther...
Curious to hear what local polling or local push thermostat you settled on with HA support!
Release years aren’t purchase years.
Everyone didn’t have the same purchase year.
And, it’s just a thermostat. When they first came out it was a little novel. Not anymore.
Temperature is a solved problem and algorithm.
There’s no real reason to discontinue them - they do the same thing they always have, connected to the same shared infrastructure.
I highly doubt the cost of cloud, tech increased or decreased since then.
It feels like a form of forced planned obsolescence. Maybe some growth or product folks not hitting their bonus lol.
Gen 1 and Gen 2 were unique also don’t have microphones in them. I know Gen 2 handled microbursting well not sure about other gens.
The truth is the cloud is someone else’s computer and the cloud always costs someone else, if not the customer.
Maybe nests aren’t being replaced fast enough or new nest purchases aren’t growing like before due to other options.
I won’t trust or buy any more Nest devices again or trust the brand. I buy newer Nest devices and cycle them out.
Gen 1 and Gen 2 folks were early adopters and they can find more elsewhere.
There are lots of other better options.
It’s easy to go early adopt the next thing. Home automation has come a long way and those who are trying to earn in the past risk being left in the past.
The device will work locally but api is being removed so the mobile app won’t work and neither will any home automation integrations.
The least they could do is just let people control it directly. We’ll see if it gets unlocked now.
EDIT: That comment was heavily expanded after I replied. It was originally only about the distinction of purchase date. I won't debate the rest of the comment because as I said at the start, "While I agree with the message...". I just don't think this specific case is a particularly good example of what is being argued and therefore arguing it is probably counterproductive.
A shortcut however is checking out the homelab subreddit. People will post about the gear they are using in their stack.
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.
1. That you can buy a smart local control device.
2. That the electronics were designed with appropriate thermal management so they don't fry themselves quickly. Smart bulbs are the most notorious offenders here, but the problem is widespread.
I'm using reolink now for doorbell and will probably stick to them and other such brands going forward. poe of course too since all battery based cams suck in comparison (no live streaming capability or preroll recording before detection, needing regular charging). Wifi units are kind of crappy too compared to poe. Running cable is kind of satisfying in a strange way imo.
These mofos are too greedy to do this.
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/
The first thing I did when I bought my house was remove the Ring camera, but I left the keycode entry for the front door in place. Long story short, a few months later it locked me out of the house and shortly after I replaced it with a regular lock and key. Never again.
It will probably last over a century.
Yes it was an unfortunate autocorrect and it’s now too late to fix it!
At this point I’ve thrown out so much Google hardware that was end of life but still operating I’ve become just the opposite — I constantly suggest people don’t use their hardware.
* There are internet-connected controllers and local controllers so you'd also want a local controller. I've used an Aeotec Z-Stick for ZWave devices for around a decade, it plugs into USB, HomeAssistant accesses it directly, and the ZWave network itself is connections between the Z-Stick and the devices without the internet.
One device is a pain. When you have a smart fridge, dishwasher, sonos, doorbell, smart lock, etc: the mean time to corporate abandonment gets very short.
I have an Ecobee, and for sure I’m looking to get off of that ecosystem once I’m forced to.
It also feels like Ecobee is an abandoned project at this stage: I get a 500 error trying to get a dev token, and portions of the app have been broken the entire time I’ve had one (9 years, 2 devices).
Thermostats generally last a lot longer than that.
Most of these Nest units continue to work perfectly well and could continue operating with a simple cloud service for many years.
Recently one of my Zigbee-controlled thermostats started pumping cold air constantly. To fix it, all I had to do was open and examine the board; one of the varistors got some battery acid on it when I had an alkaline battery burst in the unit. Because it was a no-name with an actual PCB, I was able to solder a new varistor in place, and it works good as new.
So I would say that "Smart Local Control" isn't the problem, but rather the ability to repair the thing. Also, the thermostat was $45 when I purchased it 5 years ago, so it was a good investment IMO. I think that's why everyone is upset about the Nest gen 1 and 2 sunsetting; there should be no reason that these devices should be breaking now (no failing electronics) but they die anyway because the company is too cheap to keep an extra endpoint running.
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.
Source: I own one. :)
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’s no excuse for Google arbitrarily disabling functionality.
Imagine if a company disabled your freezer after 10 years and told you “hey a refrigerator and freezer that reverts to a refrigerator after 10 years is better than a refrigerator!”
Of course, new devices might use some incompatible Bluetooth standard in the future.
The last dev who understands the code and the build tooling left years ago.
That’s just today’s nonsense tacked on to tomorrow’s tool.
I’m talking about Apple and OpenAI having all your context and an ads-baked-in system where you work out hard on Thursday and on Friday as you are passing by a advertising-buyer ice cream shop that your phone tells you that you earned whatever flavor it knows you like.
Worse are all these home-automation IoT devices etc. that "need" to re-route and ping servers outside even to get commands sent from devices on the same subnet! How absurd is this design ?
This ads-ification and "productization" of the user is the bane of tech industry. Such a scummy practice...
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.
Not really. The BOM of a smart thermostat is nearly equal to a dumb one right now. What adds cost is reliability. Hardware reliability costs engineering time and expensive component choices. Software reliability requires engineering resources and a mindset beyond optimizing quarterly returns.
There is no legitimate reason a fancy thermostat should be e-waste after ten years.
I worked for a company that converted a legacy wire protocol with no QoS guarantees to be used over a proprietary modification of Zigbee. One of the managers complained that their volume control would randomly climb to the max loudness. The protocol used press/release packets for button presses and if the volume-up release packet was lost due to interference, you got a runaway increase in volume from the system assuming it was still held down. This usually happened when the channel assignment was in a band used for active wifi.
That said, investing in devices that are local first is certainly good advice, provided the APIs are open and well supported.
Engineers don’t make business decisions on when to end support, that’s a management decision; engineers ideally ought to be consulted on what it would take to continue support, but even that isn’t guaranteed. If planned obsolescence has been a business strategy, literally having an obsolescence switch and pulling the trigger on it has to be tempting to certain decision-makers even when support would be practical.
Future generations deserve better.
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 it because they continue to offer valued other services?
Is it because the affected people of any untrustworthy move are acceptable casualties?
Is it because they've been cashing in goodwill created by earlier generations of leadership?
Something else?
I’ve seen house thermostats that were so old they were starting to embrittle from ozone and UV damage. That’s more like 40+ years.
Also as someone else pointed out, the Nests are typically at least 2-3 times the cost of a normal thermostat. True, they eventually pay for themselves, but that money still went to Nest instead of PG&E.
And before you accuse me of being “way off base” lemme ask you: why doesn’t Gmail support push for iOS Mail anymore?
And is actively trying to prevent hackers from running stuff locally.
Send me an email if you’re interested in more info.
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.
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...
Making a reasonably-designed API available, only if connected to an inaccessible network, doesn't sound dangerous, but the goodwill gained might be hard to weigh against a miniscule chance of malware, which would revise everyone's opinion of the degree of negligence or recklessness.
> Even keeping the Linux kernel up to date with the latest version is a major undertaking.
> investing in devices that are local first is certainly good advice, provided the APIs are open and well supported.
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.
Let me turn it around. Imagine that you are a Google engineer who worked on Search, YouTube, or Nest. How would you feel reading your own post? You would probably vehemently disagree! I'm not sure your sentiment is relative in 2025. Everyone on HN knows that any "web scale" public product (with billions of users) 100s of engineers behind it. And, it takes very good ones to keep them running and continuously improve them.
Thus, in response to:
> It might be unfair
> The last dev who understands the code and the build tooling left years ago.
> LAN-only access
Even more pertinent, when it gets time to go through the promo process and when I need to prove “impact” and make sure what I’m doing is aligned with the department wide OKRs, why would I want to be on a project supporting old legacy tech that I can’t spin to show how it helped the company’s revenue?
I’ve never worked for Google. But incentives based on the promo culture is endemic to all of BigTech.
And even worse, every company is focused on “AI” these days. If you aren’t part of an initiative that can be said to be AI adjacent, if you care about your career and comp, you shouldn’t touch it with a 10 foot pole.
https://www.warp.dev/blog/problems-with-promotion-oriented-c...
Sounds like Nest/Google didn’t think about that when they priced their products. That’s not the consumer’s fault. I’ve been de-Google-ing myself over the past couple of years and this is the final nail in the coffin. They could have given a partial refund, instead they insult customers with a “discount”.
Empathy and being a good human being in relation to society. Making devices that look good at first and cause pain later, when it's too late to do anything about it... is bad.
> I need to prove “impact” and make sure what I’m doing is aligned with the department wide OKRs
Fair, and that's a reason to _not_ put in the effort to make longer lasting devices.
> But incentives based on the promo culture is endemic to all of BigTech
And we should be calling them out for it. It's bad in the same way that forced ranking systems are bad; they promote the wrong things.
- 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.
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.
And no one works for a privacy invading ad tech company because they want to make the world a better place. It’s purely about making a shit ton of money.
> And we should be calling them out for it. It's bad in the same way that forced ranking systems are bad; they promote the wrong things.
Despite the newest LP about being the best employer, Amazon has been the shittiest of the BigTech employer as long as I can remember. Their reputation hasn’t changed anything about their profitability or stock price.
Before you ask if I knew that, why did I work there. I was 46 at the time, it was my 8th job out of 10 and it was purely remote and a “field by design role” that was remote until a year after I left. It was purely a money and resume play.
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.
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.
Already replaced the doorbell with a Eufy, but I'll ride the thermostat into the ground, which might be around 6 years at this rate.
Another hurdle is that the Nest thermostat is tied into the local electricity co-op's peak-time usage reduction rebate program. They currently only support by Google (Nest), ecobee, Amazon, and Honeywell.
For a thermostat, with presumably an attack surface that could be made arbitrarily small (albeit by removing non essential features) -why?
Surely this means all embedded devices are a serious liability?
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.
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?
Convenience and comfort are nice.
We do the same thing with the air conditioning, but the AC cools the house a lot faster than the radiators heat it. But it's still nice that the house automatically transitions to away and turns off the air conditioning during the day when nobody's home.
While I was at Google I complained bitterly about the repeated killing Nest products. But there was no way I had the bandwidth (or the permission) to serve as the sole lifesaver for any of them.
https://www.reddit.com/r/hacking/comments/1k97rv0/hack_a_nes...
They are pretty niche, so much so that it took me maybe a year of half-hearted searching before I found a smart thermostat that wasn't dependent on an internet connection. And of course there is a home assist integration/etc https://www.home-assistant.io/integrations/venstar/
Read some reviews before you buy them, or you might be surprised by the resistive touch on some models (which works fine with the UI), audible click when the relays go on/off (this is actually a big advantage in failure modes), and other features some people might not like.
Then they couldn't resist fiddling with the UI. Every new update changed the UI such that I had to relearn how to operate it.
That was the last straw, so I disconnected it from my wifi and just used it as a standalone thermostat.
Google does quite literally owe their shareholders ROI, by law.
Why would one expect them to do anything other than the minimum support period and expense that they can get away with that won’t trigger a class action?
There are no surprises or bait and switch here. Nobody was promised eternal support or updates.
It’s a business, not a charity.
How much do you think a server for config files costs? The true cost is very little here. You can make a server host a million thermostat connections for less than a thousand dollars per year. But let's 10x that to be safe, and have a sysadmin dedicate an overkill 1 day per week to keeping the servers happy. And we'll say the sysadmin makes well over median salary and costs $200k to employ.
For 2 million devices, that's $20k a year in server costs and $40k a year in sysadmin. For 50 years, that's 3 million dollars. So it would take a whole... dollar and a half per purchase to fund 50 years of servers.
Making this subscription-based would be fine, as long as I have my choice of providers. Because then I can run it myself on a raspberry pi or pay a big host a few dollars a year to handle my entire household of devices.
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?
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.
If the medium was ATM or hard wired ethernet then sure why not send button presses. Those are reliable media.
The obvious fix would be transmit "vol+1/Pressed" on button press and "vol+1/Release" on button release. On receipt of v+1 do just that and no more. Note a /Release to colour a widget correctly, perhaps. Holding down V+ would transmit multiple v+1 or use a wheel as an old school Walkman did to send actual values.
Nothing new is old or something 8)