3 ms·

>because the characteristics of the payload are quite orthogonal to the characteristics of the payload of other smart home devices. how so?

by melq 7y ago

seedless-sensat 7y ago
Higher bandwidth. Not sure if that is 'orthogonal' though, seems like the requirement is on the same dimension, just bigger...
- obituary_latte 7y ago
  I think you’re right. Typical smart home coms being short little on/off or temperature up/down type commands vs. streaming/recording video and audio with some having two-way audio up to and including machine learning/AI for object detection which most likely is done remotely.
stetrain 7y ago
Lights and switches are generally basic async polling and commands versus live streaming video and constant video uploading to a cloud storage service.
LeifCarrotson 7y ago
A camera requires orders of magnitude more bandwidth and power than other devices that might be connected over a low-power, low-cost radio network. It needs to transmit that payload 24/7. Currently, home automation typically uses a variety of custom protocols built on IEEE 802.15.4 (not 802.11*). It's a simple protocol that can be implemented by a cheap 8-bit microcontroller from 2 decades ago. Devices from one manufacturer may or may not communicate with those from another, and the network architecture is typically a hub with spokes - there's limited or no support for multi-router, multi-access point, or mesh networked setups. This style of network honestly works pretty well for motion sensors, lights, outlets, temperature sensors, thermostats, etc. The master node might query a device every few seconds for a couple bytes of status, or might only send a short command when a user interacts with the device. Most smart home devices send a few bytes of data four times a day when you push "light on" and "light off" on the hub. This is great for operating for months or years on just a couple AA batteries. A camera sends a few bytes per pixel times (simplifying) 720 pixels down times 1280 pixels across times 30 frames per second times 86400 seconds per day, and can only run for an hour or two on a larger battery. That's almost 8 terabytes vs. 8 bytes. But to use 802.15.4 networks, you need a hub, which is a barrier to entry - instead of one $20 light, you need a $15 light and a $50 hub. You likely already have an 802.11 router that could be the hub if the devices were smart enough to talk to it. And (tinfoil hat on) I think these companies would rather have their servers be the hub, rather than a device in your home they can't monitor and profit off of.
- stefan_ 7y ago
  This is a very Hacker News answer, in that you wrote three dense paragraphs that are all technically correct, yet also completely divorced from our practical reality that has smart home cameras in it. What is the obvious implementation out there? They just have both. They have the cheap 8-bit microcontroller from 2 decades ago transmitting on the low-bandwidth home automation network, and when it is decided that the camera should stream, it wakes up the beefy Ambarella or Socionext SoC to send its video feed over classic WiFi to the vendor cloud, and whoever wants to receive it just gets a stream URL back.
  - outworlder 7y ago
    Yeah, there's no reason to saturate the control channel with high bandwidth data.

>because the characteristics of the payload are quite orthogonal to the characteristics of the payload of other smart home devices. how so?

by melq 7y ago

>because the characteristics of the payload are quite orthogonal to the characteristics of the payload of other smart home devices. how so?

seedless-sensat 7y ago

Higher bandwidth. Not sure if that is 'orthogonal' though, seems like the requirement is on the same dimension, just bigger...

obituary_latte 7y ago
I think you’re right. Typical smart home coms being short little on/off or temperature up/down type commands vs. streaming/recording video and audio with some having two-way audio up to and including machine learning/AI for object detection which most likely is done remotely.

stetrain 7y ago

Lights and switches are generally basic async polling and commands versus live streaming video and constant video uploading to a cloud storage service.

LeifCarrotson 7y ago

A camera requires orders of magnitude more bandwidth and power than other devices that might be connected over a low-power, low-cost radio network. It needs to transmit that payload 24/7. Currently, home automation typically uses a variety of custom protocols built on IEEE 802.15.4 (not 802.11*). It's a simple protocol that can be implemented by a cheap 8-bit microcontroller from 2 decades ago. Devices from one manufacturer may or may not communicate with those from another, and the network architecture is typically a hub with spokes - there's limited or no support for multi-router, multi-access point, or mesh networked setups. This style of network honestly works pretty well for motion sensors, lights, outlets, temperature sensors, thermostats, etc. The master node might query a device every few seconds for a couple bytes of status, or might only send a short command when a user interacts with the device. Most smart home devices send a few bytes of data four times a day when you push "light on" and "light off" on the hub. This is great for operating for months or years on just a couple AA batteries. A camera sends a few bytes per pixel times (simplifying) 720 pixels down times 1280 pixels across times 30 frames per second times 86400 seconds per day, and can only run for an hour or two on a larger battery. That's almost 8 terabytes vs. 8 bytes. But to use 802.15.4 networks, you need a hub, which is a barrier to entry - instead of one $20 light, you need a $15 light and a $50 hub. You likely already have an 802.11 router that could be the hub if the devices were smart enough to talk to it. And (tinfoil hat on) I think these companies would rather have their servers be the hub, rather than a device in your home they can't monitor and profit off of.

stefan_ 7y ago
This is a very Hacker News answer, in that you wrote three dense paragraphs that are all technically correct, yet also completely divorced from our practical reality that has smart home cameras in it. What is the obvious implementation out there? They just have both. They have the cheap 8-bit microcontroller from 2 decades ago transmitting on the low-bandwidth home automation network, and when it is decided that the camera should stream, it wakes up the beefy Ambarella or Socionext SoC to send its video feed over classic WiFi to the vendor cloud, and whoever wants to receive it just gets a stream URL back.
- outworlder 7y ago
  Yeah, there's no reason to saturate the control channel with high bandwidth data.