5 ms·

That's what I don't get, why they didn't just start with pure math/data when reaching out to the developer. The only thing I can think of is someone outside of

That's what I don't get, why they didn't just start with pure math/data when reaching out to the developer. The only thing I can think of is someone outside of the "knowledge chain" caught wind of it and just fired of the legal threat. For instance, if I told some people inside my company how much traffic HA uses in terms of how many users are on it they'd probably freak out like this too. But their reason (cost and traffic) is the biggest reason we don't like it either.

rekoil 3y ago
> 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 3y ago
  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?
  - supergeek133 3y ago
    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 3y ago
      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.
  - rekoil 3y ago
    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 3y ago
  Understood, and I've advocated for this at my company, but I like to talk about things I have sphere of influence over.
- plagiarist 3y ago
  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.
  - rekoil 3y ago
    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 3y ago
      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 3y ago
        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/cache/9ee025d4de222759f4b25feadcc9b7f2/f/a/fastighetsbox-renz-budget-789d.webp https://kopbrevlada.se/pub/media/webp_image/catalog/product/... But I appreciate the suggestions!
        drra 3y ago
        Surely low power PIR sensor would work. Something like this maybe? https://www.youtube.com/watch?v=HGZFg4SVySM https://www.youtube.com/watch?v=HGZFg4SVySM
- tgsovlerkhgsel 3y ago
  > 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 3y ago
    > 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.

rekoil 3y ago

> 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 3y ago
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?
- supergeek133 3y ago
  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 3y ago
    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.
- rekoil 3y ago
  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 3y ago
Understood, and I've advocated for this at my company, but I like to talk about things I have sphere of influence over.
plagiarist 3y ago
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.
- rekoil 3y ago
  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 3y ago
    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 3y ago
      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/cache/9ee025d4de222759f4b25feadcc9b7f2/f/a/fastighetsbox-renz-budget-789d.webp https://kopbrevlada.se/pub/media/webp_image/catalog/product/... But I appreciate the suggestions!
      - drra 3y ago
        Surely low power PIR sensor would work. Something like this maybe? https://www.youtube.com/watch?v=HGZFg4SVySM https://www.youtube.com/watch?v=HGZFg4SVySM
tgsovlerkhgsel 3y ago
> 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 3y ago
  > 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.