[tgsovlerkhgsel]

> So stop building cloud-only device interaction then... Home Assistant users will take a LAN API over a cloud API any day.

Normal users don't want a LAN API though. They want an app that works. They want an app that works, and keeps working, even if their WiFi access point has client isolation, or their phone decides that it doesn't like the WiFi and switches to a cellular connection. They might even expect the app to work while they're not at home, and they certainly won't set up working NAT for it.

That means that the vendor has to implement a cloud API for the majority of users. At that point, it's probably cheaper to only have their app use that cloud API, even if the devices are on the same network and could see each other, simply due to the complexity of switching and maintaining the extra logic.

So the LAN API would be a completely separate feature that would have to be developed separately, and without extra effort, it would likely quickly go stale or break because there are no official use cases exercising it. That means a lot of spending for a small subset of users.

As much as I'd want a local API and would likely avoid most cloud-only devices that I can't somehow convert, I understand why vendors do it.

[rekoil]

> Normal users don't want a LAN API though. They want an app that works. They want an app that works, and keeps working, even if their WiFi access point has client isolation, or their phone decides that it doesn't like the WiFi and switches to a cellular connection. They might even expect the app to work while they're not at home, and they certainly won't set up working NAT for it.

This aligns with the companies interests too because after they've built that they'll have somewhere to upload telemetry to.

The presence of a cloud API doesn't rule out a LAN API. The control functions exist regardless, just expose them to both the cloud and on the LAN. You could even use the cloud integration to provision authentication for the LAN API (although I'd much prefer a fully local version personally, but I'll take that compromise).

> That means that the vendor has to implement a cloud API for the majority of users. At that point, it's probably cheaper to only have their app use that cloud API, even if the devices are on the same network and could see each other, simply due to the complexity of switching and maintaining the extra logic.

Yep, that makes sense, still doesn't make having a LAN API for users to play with themselves in any way a problem, the device functions still need code somewhere to run, and exposing that code in two APIs is only marginally more work than once, the bulk of the work is in the endpoints/functions themselves.

You could even simplify the process by only building a local HTTP API, and then contain the functionality that communicates with the cloud in a single binary that just makes local HTTP requests and relays the response to the cloud.

> As much as I'd want a local API and would likely avoid most cloud-only devices that I can't somehow convert, I understand why vendors do it.

I'm not gonna lie or pretend to be naive, I understand as well, it's just that as a developer myself I know how I'd do it to provide both with minimal effort, and when I read articles like these it makes me mad because the engineering effort to get them out of this situation is tiny in comparison to the shitstorm they create by making it a legal issue.

I honestly think there needs to be some piece of regulation written about selling devices that require an online backend, because we've seen time and again how devices become non-functional because the company goes bust. That regulation should stipulate that any cloud-based functionality must be replicatable by a device-owner via local control.