4 ms·

>I don't want to buy into a single IoT thing which depends on a cloud-component in order to work. I agree but in some cases, you end up with such a restrictive

by jasode 9y ago

>I don't want to buy into a single IoT thing which depends on a cloud-component in order to work. I agree but in some cases, you end up with such a restrictive product because it's part of a system package. For example, I recently bought a new Trane air conditioner system and it comes with a fancy system controller.[1] It has wifi so Trane promotes the capability for you to control the temperature remotely from your smartphone. Well, the IoT rub is that it requires the cloud for that capability. When I first heard that explained to me by the installer, I had to have him repeat it twice because it didn't make any sense. "You mean my iPhone that's on wifi doesn't communicate with this thermostat that's on the same wifi -- directly? You mean the thermostat app on my iPhone has to send the "increase temperature" command out of the house to the mothership cloud, and then round trip back to my thermostat?!? Yes, that's how it works." That's crazy -- If the internet is down, my iPhone can't control the thermostat that's 10 feet away! Needless to say, I just forego the smartphone remote app and simply walk up to the thermostat and change the settings on the wall. [1] https://www.trane.com/residential/en/products/thermostats-and-controls/connected-controls/comfortlink_ii.html https://www.trane.com/residential/en/products/thermostats-an...

deleted 9y ago
[deleted]
Piskvorrr 9y ago
One explanation is "laziness." Local networking is surprisingly hard (physically adjacent devices are not always adjacent topologically, AP client isolation and tigers and bears, oh my!), just polling a server Out In The Cloud via HTTP is dead simple by comparison. In other words, "1. cut a few corners, 2. trash the device in a few quarters, 3. PROFIT!"
- jasode 9y ago
  Yes, your explanation is plausible. When I thought about it, the best theory I could come up was that they assumed the smartphone would usually be away from the home -- as in, you're sitting at your job and use the remote app to raise the temperature an hour before you commuted home. If that was the common use case, Trane needed a centralized cloud server (like Nexia[1]) to enable that since the wifi thermostat at home would likely be behind an ISP firewall. smartphone at the office --> cloud --> thermostat home The problem is that the engineers made the command flow with the cloud as the only method of communication instead of enabling a secondary communication that lets 2 wifi devices talk directly. Obviously, direct wifi communication is technically possible since people buy inkjet wifi printers and their wifi laptops print directly to them every day. People would be livid if they couldn't print their paper just because the internet down or the vendor's cloud server had an outage for "maintenance". The data sent from the computer to the printer does not roundtrip up to the cloud and back down to the printer. [1] http://www.nexiahome.com/ http://www.nexiahome.com/
  - Piskvorrr 9y ago
    Oh, it's theoretically possible all right. I'm not buying any wifi-direct printer ever again, though. (Because, as I said earlier, local networking is hard, and most attempts at it fail miserably - people are livid when their damn printer refuses to print, and they don't give a damn if it's a cloud issue or their computer refusing to play nice with their printer)
    - jasode 9y ago
      >their computer refusing to play nice with their printer Yes, you reminded me of a very good point about local wifi communications: If 2 devices are on wifi, it's easier if both are configured as clients that talk to a 3rd server (such as cloud). When both act as clients, they don't need to know each other's ip address to communicate. The other option of configuring one of the wifi devices as a server is more difficult especially for non-techies. Now, you have an extra complication of discovering the ip address of the printer/camera acting as a "server" to receive commands. This requires a weird dance where the server device has to "broadcast" itself and you have the client computers "find" it. For my Canon wifi printer, I had to press and hold down the power button a certain way so the computer could "discover" it. For my wifi camera, I had to go the DOS prompt and enter an obscure ARP command[1]. The difficulty is compounded when the "server" device has no builtin LCD display so you're basically "flying blind" as to what ip address it got from the wifi router's DHCP. However, the HVAC wall controller has a large LCD display and touchpad so configuring it as a server on local wifi shouldn't be that difficult. [1] https://www.axis.com/ro/en/support/faq/FAQ2551 https://www.axis.com/ro/en/support/faq/FAQ2551
      - Piskvorrr 9y ago
        Yeah, that's what I'm talking about two posts up: Shouldn't be a problem, but a large number of unknowns enter into the equation - such as the client AP isolation, where two WiFi client devices don't see each other: the AP just drops packets coming from one destined to the other. The user's network might have this on, and the user may not even be aware of it. Even if thus is OK, finding a server in the local network is not straightforward, even with Zeroconf/Avahi. And those are just a few out of many issues.
- sitkack 9y ago
  If twitter wasn't retarded, they absolutely could have hosted small scraps of key value data for exactly this scenario. No extra cloud provider needed.
  - Piskvorrr 9y ago
    ...except Twitter. That's just passing the buck.
dreamcompiler 9y ago
That's pretty much how all modern IoT crapware works now. It has to build a tunnel through my NAT to the cloud so I can control it with my phone, which I never need to do unless I'm standing in my living room, and they have the nerve to tell me this is a feature rather than a bug. All so they can better monetize me by charging me a monthly fee, arbitrarily alter the functionality of my device through unwanted software upgrades, and spy on me and sell my data to advertisers. No thanks, assholes. If your device doesn't work without knowing my router's access code, sayonara.
- Piskvorrr 9y ago
  Of course it's a feature. It's called a "cash cow". Oh, you meant a feature for you?
ryandrake 9y ago
Same thing with Nest and Dropcam and pretty much all of the IoT trash. It's sitting there in my house, within WiFi range of any device that would be controlling it, yet it has to route all commands (and maddeningly, video, in the case of Dropcam) out through the Internet connection and back into my house through the same Internet connection. Total bonkers. Silicon Valley only knows how to make web services apparently.
- Aloha 9y ago
  and with Bonjour/Avahi zeroconf, this should be a totally workable thing - but there are security issues with this approach, and in general its more complex to implement right and have it "just work" - so they choose the easy route and use the cloud.
dmix 9y ago
This really highlights the need for always-on internet and fallbacks to a cell network if the IoT-connect fantasy world they keep selling is ever going to be a reality. If your IoT device depends on the internet for functionality it really should be able to connect to cell networks, not just wifi. The only problem is the security risks with that, but it doesn't expand the attack surface that much more than having a cloud-connected device as it is. Some proposals for future 'smart cities' is having CAT-6 LTE (which can be as fast as most home broadband connections) broadcasting everywhere and having all the devices connected to that, so you don't have to depend on your home wifi staying on or being in range.

by jasode 9y ago

deleted 9y ago

[deleted]

Piskvorrr 9y ago

One explanation is "laziness." Local networking is surprisingly hard (physically adjacent devices are not always adjacent topologically, AP client isolation and tigers and bears, oh my!), just polling a server Out In The Cloud via HTTP is dead simple by comparison. In other words, "1. cut a few corners, 2. trash the device in a few quarters, 3. PROFIT!"

jasode 9y ago
Yes, your explanation is plausible. When I thought about it, the best theory I could come up was that they assumed the smartphone would usually be away from the home -- as in, you're sitting at your job and use the remote app to raise the temperature an hour before you commuted home. If that was the common use case, Trane needed a centralized cloud server (like Nexia[1]) to enable that since the wifi thermostat at home would likely be behind an ISP firewall. smartphone at the office --> cloud --> thermostat home The problem is that the engineers made the command flow with the cloud as the only method of communication instead of enabling a secondary communication that lets 2 wifi devices talk directly. Obviously, direct wifi communication is technically possible since people buy inkjet wifi printers and their wifi laptops print directly to them every day. People would be livid if they couldn't print their paper just because the internet down or the vendor's cloud server had an outage for "maintenance". The data sent from the computer to the printer does not roundtrip up to the cloud and back down to the printer. [1] http://www.nexiahome.com/ http://www.nexiahome.com/
- Piskvorrr 9y ago
  Oh, it's theoretically possible all right. I'm not buying any wifi-direct printer ever again, though. (Because, as I said earlier, local networking is hard, and most attempts at it fail miserably - people are livid when their damn printer refuses to print, and they don't give a damn if it's a cloud issue or their computer refusing to play nice with their printer)
  - jasode 9y ago
    >their computer refusing to play nice with their printer Yes, you reminded me of a very good point about local wifi communications: If 2 devices are on wifi, it's easier if both are configured as clients that talk to a 3rd server (such as cloud). When both act as clients, they don't need to know each other's ip address to communicate. The other option of configuring one of the wifi devices as a server is more difficult especially for non-techies. Now, you have an extra complication of discovering the ip address of the printer/camera acting as a "server" to receive commands. This requires a weird dance where the server device has to "broadcast" itself and you have the client computers "find" it. For my Canon wifi printer, I had to press and hold down the power button a certain way so the computer could "discover" it. For my wifi camera, I had to go the DOS prompt and enter an obscure ARP command[1]. The difficulty is compounded when the "server" device has no builtin LCD display so you're basically "flying blind" as to what ip address it got from the wifi router's DHCP. However, the HVAC wall controller has a large LCD display and touchpad so configuring it as a server on local wifi shouldn't be that difficult. [1] https://www.axis.com/ro/en/support/faq/FAQ2551 https://www.axis.com/ro/en/support/faq/FAQ2551
    - Piskvorrr 9y ago
      Yeah, that's what I'm talking about two posts up: Shouldn't be a problem, but a large number of unknowns enter into the equation - such as the client AP isolation, where two WiFi client devices don't see each other: the AP just drops packets coming from one destined to the other. The user's network might have this on, and the user may not even be aware of it. Even if thus is OK, finding a server in the local network is not straightforward, even with Zeroconf/Avahi. And those are just a few out of many issues.
sitkack 9y ago
If twitter wasn't retarded, they absolutely could have hosted small scraps of key value data for exactly this scenario. No extra cloud provider needed.
- Piskvorrr 9y ago
  ...except Twitter. That's just passing the buck.

dreamcompiler 9y ago

That's pretty much how all modern IoT crapware works now. It has to build a tunnel through my NAT to the cloud so I can control it with my phone, which I never need to do unless I'm standing in my living room, and they have the nerve to tell me this is a feature rather than a bug. All so they can better monetize me by charging me a monthly fee, arbitrarily alter the functionality of my device through unwanted software upgrades, and spy on me and sell my data to advertisers. No thanks, assholes. If your device doesn't work without knowing my router's access code, sayonara.

Piskvorrr 9y ago
Of course it's a feature. It's called a "cash cow". Oh, you meant a feature for you?

ryandrake 9y ago

Same thing with Nest and Dropcam and pretty much all of the IoT trash. It's sitting there in my house, within WiFi range of any device that would be controlling it, yet it has to route all commands (and maddeningly, video, in the case of Dropcam) out through the Internet connection and back into my house through the same Internet connection. Total bonkers. Silicon Valley only knows how to make web services apparently.

Aloha 9y ago
and with Bonjour/Avahi zeroconf, this should be a totally workable thing - but there are security issues with this approach, and in general its more complex to implement right and have it "just work" - so they choose the easy route and use the cloud.

dmix 9y ago

This really highlights the need for always-on internet and fallbacks to a cell network if the IoT-connect fantasy world they keep selling is ever going to be a reality. If your IoT device depends on the internet for functionality it really should be able to connect to cell networks, not just wifi. The only problem is the security risks with that, but it doesn't expand the attack surface that much more than having a cloud-connected device as it is. Some proposals for future 'smart cities' is having CAT-6 LTE (which can be as fast as most home broadband connections) broadcasting everywhere and having all the devices connected to that, so you don't have to depend on your home wifi staying on or being in range.