4 ms·

> Bluetooth Low Energy for provisioning via a QR code, while it relies on Wi-Fi for high-data rate connectivity and Thread for low-data-rate communications. Th

by bisby 4y ago

> Bluetooth Low Energy for provisioning via a QR code, while it relies on Wi-Fi for high-data rate connectivity and Thread for low-data-rate communications. They will only use "thread" for low data rate communications. They will all have Wi-Fi. thus the ipv6/cloud/tcp/udp talk. I want _just_ thread out of these things. I want my devices to talk to my zwave/zigbee/thread network and to not talk to the cloud without my permission.

bryanlarsen 4y ago
> They will all have Wi-Fi. AFAICT, devices that don't need high-data rate connectivity aren't required to have WiFi. IOW a thread camera will have WiFi but a thread light switch doesn't have to.
- clairity 4y ago
  yup, i should have noted that wrinkle in my original comment. some devices will have wifi connectivity built in because they need the bandwidth (and maybe the wider access too), but many won't, because they don't need the bandwidth nor the higher power consumption that comes with it. zigbee/thread-only devices can't route to the wider internet directly because of protocol differences, which is why it needs the border router, but obviously wifi connected devices can. what matter does is standardizes this combo behavior across devices for interoperability.
- bisby 4y ago
  If some devices aren't required to have WiFi, then how do they effectively mesh with other devices? If I have a camera on the far side of my house, and then have a daisy chain of light switches back to my hub... the camera can communicate over zigbee/thread back to the hub to get low data instructions. and all the switches can get on/off commands.... but the camera has to communicate all the way back to the hub via WiFi. Which makes the WiFi not really a mesh, but a standard WiFi connect to the hub. And I assume there is no way to make sure that the camera never connects to the internet without setting up firewall rules on my router. Because the announcement specifically calls out the ability for smart devices to phone home as a perk, I imagine blocking devices from phoning home isn't an option, and you have to assume that any device with WiFi will attempt to phone home even if it's not "smart". If there was a way on hubs to have mobile phone like permissions. "This device can use local WiFi" and "This device can access the internet for Smart stuff" as separate permissions, I might be ok. But since most WiFi IoT devices are dumb and just punch a tunnel through your firewall so you can access them with a mobile app and wind up in botnets, I don't have a lot of faith in IoT companies to do it right, so until I can be assured (and verify myself) that WiFi doesn't mean "can phone home", theres no way in hell Im going to use Matter wifi devices.
  - vineyardmike 4y ago
    > If some devices aren't required to have WiFi, then how do they effectively mesh with other devices? Thread is a mesh protocol. They won’t wifi mesh a camera. > Which makes the WiFi not really a mesh, but a standard WiFi connect to the hub. Yea. > Because the announcement specifically calls out the ability for smart devices to phone home as a perk It is a perk to some. > until I can be assured (and verify myself) that WiFi doesn't mean "can phone home", theres no way in hell Im going to use Matter wifi devices. Some devices will some won’t. Surely some devices will advertise being local only. Some companies won’t won’t the expense of a server. Some matter devices won’t need wifi at all (lights). You might be more comfortable with them instead of writing it all off. > wind up in botnets Ironically cheaper devices may bet better off here. They’re probably too cheap to use anything but embedded code instead of embedded Linux so there’s less attack surface (excluding vendor provided). Matter provides a secure channel to share OTA updates (eg through a thread hub) that is signed by the vendor. So this should be a step in the right direction in terms of security.

by bisby 4y ago

bryanlarsen 4y ago

> They will all have Wi-Fi. AFAICT, devices that don't need high-data rate connectivity aren't required to have WiFi. IOW a thread camera will have WiFi but a thread light switch doesn't have to.

clairity 4y ago
yup, i should have noted that wrinkle in my original comment. some devices will have wifi connectivity built in because they need the bandwidth (and maybe the wider access too), but many won't, because they don't need the bandwidth nor the higher power consumption that comes with it. zigbee/thread-only devices can't route to the wider internet directly because of protocol differences, which is why it needs the border router, but obviously wifi connected devices can. what matter does is standardizes this combo behavior across devices for interoperability.
bisby 4y ago
If some devices aren't required to have WiFi, then how do they effectively mesh with other devices? If I have a camera on the far side of my house, and then have a daisy chain of light switches back to my hub... the camera can communicate over zigbee/thread back to the hub to get low data instructions. and all the switches can get on/off commands.... but the camera has to communicate all the way back to the hub via WiFi. Which makes the WiFi not really a mesh, but a standard WiFi connect to the hub. And I assume there is no way to make sure that the camera never connects to the internet without setting up firewall rules on my router. Because the announcement specifically calls out the ability for smart devices to phone home as a perk, I imagine blocking devices from phoning home isn't an option, and you have to assume that any device with WiFi will attempt to phone home even if it's not "smart". If there was a way on hubs to have mobile phone like permissions. "This device can use local WiFi" and "This device can access the internet for Smart stuff" as separate permissions, I might be ok. But since most WiFi IoT devices are dumb and just punch a tunnel through your firewall so you can access them with a mobile app and wind up in botnets, I don't have a lot of faith in IoT companies to do it right, so until I can be assured (and verify myself) that WiFi doesn't mean "can phone home", theres no way in hell Im going to use Matter wifi devices.
- vineyardmike 4y ago
  > If some devices aren't required to have WiFi, then how do they effectively mesh with other devices? Thread is a mesh protocol. They won’t wifi mesh a camera. > Which makes the WiFi not really a mesh, but a standard WiFi connect to the hub. Yea. > Because the announcement specifically calls out the ability for smart devices to phone home as a perk It is a perk to some. > until I can be assured (and verify myself) that WiFi doesn't mean "can phone home", theres no way in hell Im going to use Matter wifi devices. Some devices will some won’t. Surely some devices will advertise being local only. Some companies won’t won’t the expense of a server. Some matter devices won’t need wifi at all (lights). You might be more comfortable with them instead of writing it all off. > wind up in botnets Ironically cheaper devices may bet better off here. They’re probably too cheap to use anything but embedded code instead of embedded Linux so there’s less attack surface (excluding vendor provided). Matter provides a secure channel to share OTA updates (eg through a thread hub) that is signed by the vendor. So this should be a step in the right direction in terms of security.