> Why does any of it operate on remote cloud API calls when it could operate locally?
Vendor lock-in, and gives them the ability in the future to hold your devices hostage by requiring you to pay a subscription fee.
Various IoT platforms, eg Tyua (which gets rebranded a lot), sell a complete package that is totally cloud oriented. Configure the product behavior online, click order, purchase 10000 controller chips preflashed with firmware implementing said behavior, integrate with devices, slap logo on it, sell.
Also, maybe the developers of these products only know how to write cloud enabled software? (slightly joking)
Because adding brains and storage to hardware is expensive. And putting simple things on customer prem means less things can go horribly wrong.
And people actually like controlling their hardware from out-of-the-home, which makes doing everything locally even more complicated.
When you start trying to present end-users with a graph of whatever metric you want, you run into issues with storage, response time, CPU usage, storage, the web front-end, storage, etc. Then you have issues updating all that.
And if you want to do something like, say, comparing and benchmarking against other users you can't.
Really, only technical people care about this kind of stuff, and they can go ahead and write their own or use HA.
> Because adding brains and storage to hardware is expensive.
I disagree with this; it's expensive if you need the device to support Python or C# or similar. A $5 esp32 chip has enough storage and RAM to both act as a controller for hundreds of devices, AND run a minimal webserver to provide an interface for the user to automate those devices.
> And people actually like controlling their hardware from out-of-the-home, which makes doing everything locally even more complicated.
I second this: people who want home automation also want the ability to control it from their cellphone anywhere in the world. Unless they are technically proficient enough to setup their own public-facing server that is on 24x7, the customer is almost always going to prefer the device that is connected to a proprietary vendor's cloud.
Apart from the not-at-all-paranoid answer of "money", it's probably just easier for them to program - if you're going to have (honestly, required for 99% of users) integrations with cloud services like alexa, google, homekit, HA etc. where you need to provide an end-point, it's just easier to make your own app talk to the same end-point. Which is money too, I suppose.
Cloud based smart home offerings must be avoided at all cost. A home shouldn't be dependent on the Internet working, or a subscription fee being paid to whoever provides the service. There's zero reason for introducing that dependency, except as a business strategy to extract as much money as possible.
Integration with GoogleHome/Alexa/etc doesn't require cloud, they're running inside your home and can easily hit the device directly (wifi devices) or via the controller (which can "forward" the commands to the devices on the local network or the zigbee/zwave net).
Why does any of it operate on remote cloud API calls when it could operate locally?