[rekoil]

> But their reason (cost and traffic) is the biggest reason we don't like it either.

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

A LAN API should satisfy everyone really, no unnecessarily large bills for the manufacturer, and Home Assistant users can get better/faster integrations with shorter update intervals.

[randomfrogs]

But if it's a LAN API, how exactly will the manufacturer harvest your usage information to sell to third parties? How will they get that sweet, sweet, post-sale monetization?

[rekoil]

I know this is a joke, but to just entertain it for a second, if they truly must have telemetry, then why not just have the device submit it anyway?

Local API for control, then submit telemetry via the cloud-version of the API they use for the app.

The obvious answer why not is: it enables people like me to just block the telemetry uploads.

But they can't have it both ways then, they can't make inefficient cloud-based control mechanisms, and then complain when people (ab)use them, because the truth is that that will not stop no matter how many cease and desists they send.

[supergeek133]

Or the fact that many of the major "security bad press" or "S in IoT stands for security" stories are because such interfaces were made but not properly secured. (see bosch story)

[rekoil]

Authentication is something that does need to be solved, that's true, but the device is authenticating to the cloud already, I can promise you any bad implementations that would have happened in a local API is currently in the authentication against the cloud-based management solution instead, it's just less obvious.

Security by obscurity is another phrase for it.

[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.

[plagiarist]

I still cannot believe HA users will accept a cloud API at all. I thought HA was about centralizing control of devices on one's own hardware. If you're using a cloud API the control is neither centralized nor on your hardware.

[paradox460]

Its a choice between a few competing "ideals"

Get everything into HomeAssistant, build dashboards, have cool stats and automations tying stuff together. Increases the family-acceptance-factor as well, as its a hell of a lot easier to say "Everything is in this app on your phone" rather than "ok well the washer is in the Miele app and the lights are in the Lutron app and the sprinklers are the…" If something is cloud based, so what, you can still get it into HomeAssistant. Sure, local is better, but thats a secondary concern over just having it there to begin with.

Additionally, one might observe that you can make a "cloud-only" smart device local control with varying levels of intrusiveness from custom hardware devices. You can stick an ESP32 with a current loop around the power leads on a washing machine, for example, to track when the machine stops running. You could use a light sensor taped over the "DONE" light to do the same. But these are passive, observation only controls. What if you wanted to start the machine too? Or observe where in its cycle it is. An ESP based controller gets a hell of a lot more invasive, and your wife/partner might not be too happy that you just took apart the $2000 washing machine to stick a $2.50 "computer chip board" inside it.

Ideally, we'd all have everything 100% local. I'll even go out of my way to buy things that not only have local control over things that have cloud control, but within limits. Its a checkbox on a comparison sheet, not a be-all-end-all. I'll even favor things that use HTTP based configuration/APIs over apps and stuff (see the UnfoldedCircle remote, which is 100% browser configured) becuase its one less thing to have to worry about

[rekoil]

I can think of several reasons:

    - Reading information from utility providers which few people are able to measure locally
    - You want to integrate with some system which is physically outside your home, like I don't know a smart mailbox if those exist (and god damnit now I want that...)
    - You are forced to because the product you have can't be controlled any other way and it's not feasible to replace it
    - A locally controllable version of X exists, but it's three times the price of one from vendor Y which requires a cloud integration

[paradox460]

RE: Smart Mailbox

I've seen a few people DIY them. You can put a reed switch or similar on the door, and watch for state changes, to trigger a "PostBox opened last at" style sensor, or use a light sensor in the box to do the same.

If you want to seriously over-engineer, you could put the box on a load cell, and measure the weight of the post.

Use an ESP32 for your control board, and its pretty much just basic ESPHome plumbing

[rekoil]

Unfortunately I can't do any of those things because I live in an apartment and we have mailboxes like these: https://kopbrevlada.se/pub/media/webp_image/catalog/product/...

But I appreciate the suggestions!

[drra]

Surely low power PIR sensor would work. Something like this maybe? https://www.youtube.com/watch?v=HGZFg4SVySM

[paradox460]

A light sensor on an ESP taped to the inside of the mailbox would probably work, and a note to the postal carrier informing them of its function, but I suspect you'd have issues with the range of the device.

[rekoil]

Yeah, I live 3 floors up and on the other side of the building from the mailboxes.

[supergeek133]

Understood, and I've advocated for this at my company, but I like to talk about things I have sphere of influence over.