3 ms·

It's ridiculous. I don't understand why so many of these things need to connect to cloud services just to work. I mean, surely computing power is cheap enough

It's ridiculous. I don't understand why so many of these things need to connect to cloud services just to work. I mean, surely computing power is cheap enough these days that you can build all the intelligence you need into the device for day to day operation and simply use internet connectivity to get updates, such as security patches, and the like? Maybe the compute side of things could be a pluggable module that could be upgraded independent of the rest of the device if you ever do need more processing power. This would work particularly well for larger devices such as robot vacuum cleaners. I find it indefensible that some data centre going down in Australia (or wherever) could render something as basic as a doorbell, or even a vacuum cleaner, inoperative.

_alex_ 6y ago
My theory is that consumers already have wifi networks and know how to enter a wifi password (or push a wps button). They don’t need to buy some new base station and then worry about if it speaks the right protocol as all their other devices. Historically there wasn’t a ubiquitous, push button, cross-vendor wireless protocol that fit the bill. I’m really hoping that everything actually moves to local comms over zigbee.
nullc 6y ago
People don't refuse to buy them for doing it, ... in part because there is seldom any disclosure of it.
finnthehuman 6y ago
>I mean, surely computing power is cheap enough these days that you can build all the intelligence you need into the device for day to day operation and simply use internet connectivity to get updates, such as security patches, and the like? I work on embedded systems that can not fail when the internet connection fails, and it's bonkers just how much you can accomplish with a <$5 microcontroller or even a <$10 chip running linux. But the tide of the industry is pulling toward remotely hosting as much as possible. Even if it doesn't strictly need networking, the desire for a companion app, firmware upgrade workflow and/or business desire for surveillance often justify it. Once you have network connectivity for any reason, well, then you're not not going to be phoning home to a surveillance system running in AWS anyway. If you have a companion app, making sure you can get a connection between the phone and device is going to have a fall-back path that runs through your servers because even self-styled techy people don't always understand networking. Now that your networked device is already sending all the data home anyway, why not do more work serverside? Add in the prevalence of developers that can't be arsed to learn to develop for a microcontroller. Or those that can only get by in the very-handheld embedded environments. Now your design is starting to take shape, and you need to do some more number crunching. Do you invest in learning to leverage esoteric features of your microcontroller? Add a DSP to the BOM? Or just say it's easier to do on the serverside with comparatively infinite processing resources and the ability to rush development because features and bugfixes only require updating servers rather than pushing firmware to the fleet?

_alex_ 6y ago

My theory is that consumers already have wifi networks and know how to enter a wifi password (or push a wps button). They don’t need to buy some new base station and then worry about if it speaks the right protocol as all their other devices. Historically there wasn’t a ubiquitous, push button, cross-vendor wireless protocol that fit the bill. I’m really hoping that everything actually moves to local comms over zigbee.

nullc 6y ago

People don't refuse to buy them for doing it, ... in part because there is seldom any disclosure of it.

finnthehuman 6y ago

>I mean, surely computing power is cheap enough these days that you can build all the intelligence you need into the device for day to day operation and simply use internet connectivity to get updates, such as security patches, and the like? I work on embedded systems that can not fail when the internet connection fails, and it's bonkers just how much you can accomplish with a <$5 microcontroller or even a <$10 chip running linux. But the tide of the industry is pulling toward remotely hosting as much as possible. Even if it doesn't strictly need networking, the desire for a companion app, firmware upgrade workflow and/or business desire for surveillance often justify it. Once you have network connectivity for any reason, well, then you're not not going to be phoning home to a surveillance system running in AWS anyway. If you have a companion app, making sure you can get a connection between the phone and device is going to have a fall-back path that runs through your servers because even self-styled techy people don't always understand networking. Now that your networked device is already sending all the data home anyway, why not do more work serverside? Add in the prevalence of developers that can't be arsed to learn to develop for a microcontroller. Or those that can only get by in the very-handheld embedded environments. Now your design is starting to take shape, and you need to do some more number crunching. Do you invest in learning to leverage esoteric features of your microcontroller? Add a DSP to the BOM? Or just say it's easier to do on the serverside with comparatively infinite processing resources and the ability to rush development because features and bugfixes only require updating servers rather than pushing firmware to the fleet?