4 ms·

Why should the garage door manufacturer take a cut if a third-party wants to use/access my garage door (which sells for real money and isn't advertised as a ren

Why should the garage door manufacturer take a cut if a third-party wants to use/access my garage door (which sells for real money and isn't advertised as a rental). If a homeowner wants to let Amazon, Walmart, etc to open their garage door, it should be up to him to provide them with an access token/secret/etc to enter, just like you can put a door keycode in the order notes. The interaction should be purely between him and the retailer and there is absolutely no need for some rent-seeking scum to be involved. The disgusting business model you seem to be justifying is akin to house builders/contractors being perpetually owed a cut every time you invite over a guest into your house or they switch on the lights.

amluto 3y ago
I don't actually find this model so disgusting as long as it's implemented in a non-restrictive way. If a garage door manufacturer offers me a (free, local) API to fully control my door and allows me to check a box to let Amazon in, what, exactly, is the problem? Sure, I could also allow Amazon in without checking the box (assuming Amazon offers the appropriate integration and I'm willing to deal with maintaining my side of it), but it also seems okay for Amazon to pay the garage door opener company for the first-party version. Everybody wins. Forcing the actual device owner to use a crappy cloud service is an entirely different story, but it's not required for the Amazon business model. Similarly, many video recording devices support ONVIF and have an optional paid first-party video storage. (And I imagine that quite a few commercial users demand the former -- no one who operates a concierge/security desk or a serious office building or a warehouse or an industrial site has the slightest interest in using four different first-party cloud offerings from four different vendors of their various gizmos that contain cameras. They are going to run one NVR, possibly with off-site backup, with one integrated system for viewing and analyzing the feeds. And they will pay handsomely for that, and they're paying that money to one of several established companies in the space, all of whom require at least token ONVIF or RTSP compliance, and they aren't about to kick any of that money over to the camera makers, because there is no shortage of competing camera makers.)
- efitz 3y ago
  They are not giving me a free, local API. They are doing everything possible to make the API unusable except by their application, and they are throwing ads all over their app and using dark patterns to hid the open/close buttons until you scroll past the ads.
seanalltogether 3y ago
1. Company wants to sell an iot product. 2. Through research they find user wants to interact with their smart device while outside of range of wifi/bluetooth. 3. Company builds device firmware and cloud infrastructure to support this goal. 4. Company wants to simplify business logic and doesn't provide local (wifi/bluetooth/zigbee) support. Online only can service both on-premise and off-premise. 5. Company needs to reduce costs and justify ongoing operational costs of supporting this cloud + device service. 6. We arrive at the current solution.
- jasonjayr 3y ago
  7. insecure, opaque devices that have always-on internet connections, that owners cannot upgrade/fix/defend against and require external actors to protect (ISP's blackholing bad traffic) Remember, the S in IoT is for Security. They could simplify their business logic by making sure local first is reliable, and internet access can be turned off, and supporting vendors making (user-controlled, upgradeable, etc) gateways that handle the cloud/internet/local handoff
  - seanalltogether 3y ago
    I don't disagree with you, since the company I work for supports both local network access to their devices as well as cloud access for when you are outside the home. But supporting both does not simplify business logic, it increases complexity. It introduces more states and failure points that your firmware devs and app devs need to account for.
    - Nextgrid 3y ago
      A solution to that is to make the cloud-based service as dumb as possible, only operating as a NAT traversal helper and/or TURN relay, over which the local-only protocol is tunnelled.
    - jasonjayr 3y ago
      I appreciate your response, and don't want to go too far off the thread here, but as a software developer/architect myself, how can that possibly be true? The state of the environment that the IoT device is sensing or controlling, has to match local reality. Therefore, the state that's actually on the IoT's MCU is the true state that matters. (Any state stored cloud-side could be stale if the MCU is disconnected, or misses updates) Ergo, if the cloud service is showing or manipulating the state of the IoT device, it has to read or command the IoT in near realtime, implying some kind of constant/realtime connection. This would be the same mechanism a local-first connection would use, right? What am I missing here?
rasz 3y ago
Because as they clearly demonstrated its not your garage door.

amluto 3y ago

I don't actually find this model so disgusting as long as it's implemented in a non-restrictive way. If a garage door manufacturer offers me a (free, local) API to fully control my door and allows me to check a box to let Amazon in, what, exactly, is the problem? Sure, I could also allow Amazon in without checking the box (assuming Amazon offers the appropriate integration and I'm willing to deal with maintaining my side of it), but it also seems okay for Amazon to pay the garage door opener company for the first-party version. Everybody wins. Forcing the actual device owner to use a crappy cloud service is an entirely different story, but it's not required for the Amazon business model. Similarly, many video recording devices support ONVIF and have an optional paid first-party video storage. (And I imagine that quite a few commercial users demand the former -- no one who operates a concierge/security desk or a serious office building or a warehouse or an industrial site has the slightest interest in using four different first-party cloud offerings from four different vendors of their various gizmos that contain cameras. They are going to run one NVR, possibly with off-site backup, with one integrated system for viewing and analyzing the feeds. And they will pay handsomely for that, and they're paying that money to one of several established companies in the space, all of whom require at least token ONVIF or RTSP compliance, and they aren't about to kick any of that money over to the camera makers, because there is no shortage of competing camera makers.)

efitz 3y ago
They are not giving me a free, local API. They are doing everything possible to make the API unusable except by their application, and they are throwing ads all over their app and using dark patterns to hid the open/close buttons until you scroll past the ads.

seanalltogether 3y ago

1. Company wants to sell an iot product. 2. Through research they find user wants to interact with their smart device while outside of range of wifi/bluetooth. 3. Company builds device firmware and cloud infrastructure to support this goal. 4. Company wants to simplify business logic and doesn't provide local (wifi/bluetooth/zigbee) support. Online only can service both on-premise and off-premise. 5. Company needs to reduce costs and justify ongoing operational costs of supporting this cloud + device service. 6. We arrive at the current solution.

jasonjayr 3y ago
7. insecure, opaque devices that have always-on internet connections, that owners cannot upgrade/fix/defend against and require external actors to protect (ISP's blackholing bad traffic) Remember, the S in IoT is for Security. They could simplify their business logic by making sure local first is reliable, and internet access can be turned off, and supporting vendors making (user-controlled, upgradeable, etc) gateways that handle the cloud/internet/local handoff
- seanalltogether 3y ago
  I don't disagree with you, since the company I work for supports both local network access to their devices as well as cloud access for when you are outside the home. But supporting both does not simplify business logic, it increases complexity. It introduces more states and failure points that your firmware devs and app devs need to account for.
  - Nextgrid 3y ago
    A solution to that is to make the cloud-based service as dumb as possible, only operating as a NAT traversal helper and/or TURN relay, over which the local-only protocol is tunnelled.
  - jasonjayr 3y ago
    I appreciate your response, and don't want to go too far off the thread here, but as a software developer/architect myself, how can that possibly be true? The state of the environment that the IoT device is sensing or controlling, has to match local reality. Therefore, the state that's actually on the IoT's MCU is the true state that matters. (Any state stored cloud-side could be stale if the MCU is disconnected, or misses updates) Ergo, if the cloud service is showing or manipulating the state of the IoT device, it has to read or command the IoT in near realtime, implying some kind of constant/realtime connection. This would be the same mechanism a local-first connection would use, right? What am I missing here?

rasz 3y ago

Because as they clearly demonstrated its not your garage door.