4 ms·

I am curious if they will include cameras (security / door), because the characteristics of the payload are quite orthogonal to the characteristics of the paylo

I am curious if they will include cameras (security / door), because the characteristics of the payload are quite orthogonal to the characteristics of the payload of other smart home devices.

ahyattdev 7y ago
Since Apple just added support to HomeKit for cameras I am sure this new standard they are making will support them too.
- mackey 7y ago
  Homekit has had support for cameras for a while. The recent support was for a cloud integration to store video securely.
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.
    - 7y ago
jon-wood 7y ago
There are two aspects to most security cameras. The one everyone thinks of is video streaming - there’s plenty of standards for that, most notably RTSP and recently WebRTC. That’s probably out of scope for smart home protocols. Totally in scope is provisioning, configuration, and notification of things it can detect such as motion. I’d anticipate those being managed as part of this new protocol, with streaming simply being to provide an endpoint address and maybe an authentication token to connect.
oflannabhra 7y ago
I doubt some of they PHYs have the bandwidth to support streaming video, but there have been some good efforts in the IETF to maximize streaming protocols over low-bandwidth connections. But the whole point of CHoIP is that PHY doesn't matter, so you can configure your camera using IP messages over BLE, and then the camera connects to services over WiFi to stream.

I am curious if they will include cameras (security / door), because the characteristics of the payload are quite orthogonal to the characteristics of the payload of other smart home devices.

ahyattdev 7y ago

Since Apple just added support to HomeKit for cameras I am sure this new standard they are making will support them too.

mackey 7y ago
Homekit has had support for cameras for a while. The recent support was for a cloud integration to store video securely.

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.
  - 7y ago

jon-wood 7y ago

There are two aspects to most security cameras. The one everyone thinks of is video streaming - there’s plenty of standards for that, most notably RTSP and recently WebRTC. That’s probably out of scope for smart home protocols. Totally in scope is provisioning, configuration, and notification of things it can detect such as motion. I’d anticipate those being managed as part of this new protocol, with streaming simply being to provide an endpoint address and maybe an authentication token to connect.

oflannabhra 7y ago

I doubt some of they PHYs have the bandwidth to support streaming video, but there have been some good efforts in the IETF to maximize streaming protocols over low-bandwidth connections. But the whole point of CHoIP is that PHY doesn't matter, so you can configure your camera using IP messages over BLE, and then the camera connects to services over WiFi to stream.