Right, thanks. But this can be easily resolved by:
Removing devices’ access to WAN, which also vastly reduces the external actor’s ability to compromise them in the first place.
Isolating devices from each other with internal firewall rules, allowing them to only interact with the hub host.
Is this correct, or am I missing something?
With a good router, it’s not that hard to do. But even then it took me a long time to get around to setting up the separate network, and I don’t think I’ve migrated all of my devices over to it still (some got moved, new ones go there, but there are some older devices still sitting on the original network). So, yeah, there’s definitely extra effort, and it’s not really fun like getting that new smart device integrated. I will say the stuff on that network works perfectly - I haven’t noticed any side effects.
Oh I did allow them access to the pool ntp server so they can pick up the correct time, and some require temporary access to the internet while setting up (the linknlink RF device needed it to download the Home assistant version of their firmware, for example).
ZigBee/Thread are just better for this, you’re protected without doing anything.
Requirements like the ones you listed above make widespread adoption impossible, short of forcing routers to have a separate IoT network and forcing devices to use only that, with all the issues that may prop up along the way.
Good luck explaining how to do any of this to my parents, for example. For someone with a technical background that’s feasible, for someone with an it background it’s even easy. For the other 90 or 95% of people who are actually supposed to buy and use these things, it isn’t. They don’t even know something like this can be done, let alone that it should be done.
But that is not a fault of WiFi as a medium, but rather of the ecosystem of devices as we know them. Some company might launch a “Home Automation WiFi” product, which would be simply a home hub with a builtin WiFi router pre-configured with the recommended security settings. Zero config nor admin work required, just buy the right (hypothetical) hub.
Though the real problem is that every other device relies on cloud connectivity, which highly limits such hubs effectiveness. Again, that isn’t an inherent fault of how WiFi works, rather I see it as a problem with the ecosystem and how consumers want their devices to work without any hub. Hopefully with more local-only devices that trend can still be reversed.
but it is a fault of WiFi as a choice for that application. Just because it does wireless communication doesn’t mean it’s suited for any application that needs a wireless protocol. Using it for very-low traffic applications is simply not what it was designed to do, and it has significant negative effects if you do. Any device you add basically slows down any other device by a bit. And wifi network you add in a physical area decreases the effectiveness of all other wifi networks in it’s vicinity. In even medium densly populated areas, wifi is already borderline unusable due to congestion. Your proposed (dedicated) hub is a good idea for network isolation, assuming it’s designed and configured correctly, but that also comes with more and frankly just as bad security implications, just different ones. To be clear, having like a light bulb or two wifi is a fine choice. For 50 or a whole smart home network, it no longer is.
Both Zigbee and Matter do not rely on cloud connectivity as a protocol, though many of the manufacturers implementations do effectly add that on top: you get the exact solution you propose here as well. At least with these standards you can control everyhing locally, if you want to, and you don’t congest the spectrum nearly as much as wifi does.
Using it for very-low traffic applications is simply not what it was designed to do
Was it not? Sure, it wasn’t specifically designed for low traffic, but it was designed with a wide range of traffic levels in mind; after all, virtually every WiFi capable device, home automation or not, uses very little traffic most of the time as it idles. Now, I absolutely appreciate Zigbee or ZWave being optimized for minimal energy consumption, which is useful for some device types; but I feel it isn’t right to call WiFi a poor choice for low traffic just because it also handles very high traffic well.
You raise an interesting point about congestion, though, and that is very much was I hoped to learn about. I am sometimes under impression that device designers assume everyone lives in a detached house so interference can be ignored. Do you know how specifically is Zigbee better in this regard? Living in a condominium I always had very poor experience with Zigbee reliability, which might or might not have been due to local radio noise at various ares of the spectrum, so I’m curious to learn about details how exactly these purpose-specific transfer layers deal with noisy neighborhoods.
In the context of communication networks, WiFi is a high speed netowrk. It was designed to be basically a “normal” (ethernet-like) network, but wireless. It acts for all intents and purposes like an ethernet network. There are significant requirements that devices need to follow, many include frequently saying “hello” (simplified). The complexity of the protocol to be able to send at gigabit and faster speeds over dozens of meters is significant. Having relatively low latency adds to this as well. If all you need is a few bytes every now and then, that isn’t ideal. Having devices in your network that follow older/slower standards is essentially like pulling the handbrake for your network (again, very simplified). But explaining this in detail is also very much beyond the scope of a comment here.
ZigBee devices form a mesh network, which WiFi devices don’t do. This means I can have my hub on one side of my house and a bunch of bulbs and smart outlets maintain a backbone through the house for a bunch of low power devices (like thermostats and door sensors) to connect to it.
If you’re having a bad ZigBee experience, I recommend making sure your bulbs can serve as a general ZigBee bridge, and not just a bridge for other bulbs of that brand. Otherwise, a well placed smart outlet can serve the same purpose.
Both Zigbee and Matter do not rely on cloud connectivity as a protocol
In my ideal world, no devices would not rely on cloud connectivity ever, regardless of their choice wireless transport layer. The fact that the nature of Zigbee or Thread stop device manufacturers from stupid practices (such as relying on direct WAN access) is nice, sure, but does being less capable really make them better suited for the job? I would prefer to appreciate Zigbee or Thread for what they are and have, rather than by the fortunate side effects of what they can’t do.
Zigbee or Thread doesn’t actually stop them from adding cloud connectivity, they all still do. But you yourself can stop it. Similar to the “gateway” you suggested with dedicated WiFi, they sell you a gateway for Zigbee or Thread, which then connects to the cloud/internet to allow you to control your stuff. As they would with a WiFi gateway.
The protocol isn’t “less capable”, it’s intended use is around (home-)automation. It is low power, low bandwidth and most importantly both are a mesh network. That means that while you have a central point to access them (at least Zigbee has exactly 1), they all talk to each other and for a fully connected mesh. A device doesn’t need to be able to see/hear that central point. It can send it through a multi-hop route, and that route is dynamic so when a device leaves (out of power, turned off, …) the packets basically just find their way. Generally anything that has a stable power sounce will act as a router and forward packets. The low power part means that if you have a battery powered thing (remote switch, thermometer, …) it can run off a single button cell for like a year or so. With wifi it would last a week, maybe two. The bandwidth thing is related to that as well, as a thermoeter needs to send the temperature and/or humidity maybe every few minutes, or even just when it changes and there is no need for that. That comes with power usage, complexity and many other downsides, but of course a zigbee device can’t stream video or something (like a security camera would need to).
When using wifi, any device needs to be in range of the access point. You can have multiple access point but those aren’t that cheap, and should be wired in. Devices only ever talk to the access point. When multiple devices talk to each other, it goes to the access point who then sends it out again to the other device.
There are great writeups on the internet, just google “zigbee vs wifi” or something. I’m not gonna repeat what
Side note: you can reply to more than 1 paragraph in a reply. No need to reply three times, but I guess I’ll stick with it now.
I also don’t want devices I’m actively using to needlessly compete with random logistical packets from a dozens of devices around my house. I also don’t want the devices themselves to need all the power of a WiFi connection when another protocol suited to low power home automation devices is sufficient.
ZigBee/zwave were fine for me, though. I personally haven’t seen a clear benefit to matter+thread yet.
My favourite thing about these non-wifi wireless protocols is that devices using them seem to want cloud connectivity a lot less than those that come with wifi.
but that also comes with more and frankly just as bad security implications, just different ones
What do you have in mind? Surely, no solution is perfect, but at least on the surface it sounds much better than the alternative of no isolation at all, so I’d love to learn what worries you.
If I’m gonna install a device by some random manufacturer that acts as a wifi access point inside my network, I also give them full access to my network. That access point can do all sorts of things, and I would describe this as a security nightmare. It also doesn’t even have to be malicious: the manufacturer could get hacked, and now the hacker has access to all these wifi access points all over the world, and all their home networks. Fun.
Right, thanks. But this can be easily resolved by:
Sounds like an admin job I don’t want to do.
With a good router, it’s not that hard to do. But even then it took me a long time to get around to setting up the separate network, and I don’t think I’ve migrated all of my devices over to it still (some got moved, new ones go there, but there are some older devices still sitting on the original network). So, yeah, there’s definitely extra effort, and it’s not really fun like getting that new smart device integrated. I will say the stuff on that network works perfectly - I haven’t noticed any side effects.
Oh I did allow them access to the pool ntp server so they can pick up the correct time, and some require temporary access to the internet while setting up (the linknlink RF device needed it to download the Home assistant version of their firmware, for example).
ZigBee/Thread are just better for this, you’re protected without doing anything.
Requirements like the ones you listed above make widespread adoption impossible, short of forcing routers to have a separate IoT network and forcing devices to use only that, with all the issues that may prop up along the way.
Good luck explaining how to do any of this to my parents, for example. For someone with a technical background that’s feasible, for someone with an it background it’s even easy. For the other 90 or 95% of people who are actually supposed to buy and use these things, it isn’t. They don’t even know something like this can be done, let alone that it should be done.
But that is not a fault of WiFi as a medium, but rather of the ecosystem of devices as we know them. Some company might launch a “Home Automation WiFi” product, which would be simply a home hub with a builtin WiFi router pre-configured with the recommended security settings. Zero config nor admin work required, just buy the right (hypothetical) hub.
Though the real problem is that every other device relies on cloud connectivity, which highly limits such hubs effectiveness. Again, that isn’t an inherent fault of how WiFi works, rather I see it as a problem with the ecosystem and how consumers want their devices to work without any hub. Hopefully with more local-only devices that trend can still be reversed.
but it is a fault of WiFi as a choice for that application. Just because it does wireless communication doesn’t mean it’s suited for any application that needs a wireless protocol. Using it for very-low traffic applications is simply not what it was designed to do, and it has significant negative effects if you do. Any device you add basically slows down any other device by a bit. And wifi network you add in a physical area decreases the effectiveness of all other wifi networks in it’s vicinity. In even medium densly populated areas, wifi is already borderline unusable due to congestion. Your proposed (dedicated) hub is a good idea for network isolation, assuming it’s designed and configured correctly, but that also comes with more and frankly just as bad security implications, just different ones. To be clear, having like a light bulb or two wifi is a fine choice. For 50 or a whole smart home network, it no longer is.
Both Zigbee and Matter do not rely on cloud connectivity as a protocol, though many of the manufacturers implementations do effectly add that on top: you get the exact solution you propose here as well. At least with these standards you can control everyhing locally, if you want to, and you don’t congest the spectrum nearly as much as wifi does.
Was it not? Sure, it wasn’t specifically designed for low traffic, but it was designed with a wide range of traffic levels in mind; after all, virtually every WiFi capable device, home automation or not, uses very little traffic most of the time as it idles. Now, I absolutely appreciate Zigbee or ZWave being optimized for minimal energy consumption, which is useful for some device types; but I feel it isn’t right to call WiFi a poor choice for low traffic just because it also handles very high traffic well.
You raise an interesting point about congestion, though, and that is very much was I hoped to learn about. I am sometimes under impression that device designers assume everyone lives in a detached house so interference can be ignored. Do you know how specifically is Zigbee better in this regard? Living in a condominium I always had very poor experience with Zigbee reliability, which might or might not have been due to local radio noise at various ares of the spectrum, so I’m curious to learn about details how exactly these purpose-specific transfer layers deal with noisy neighborhoods.
In the context of communication networks, WiFi is a high speed netowrk. It was designed to be basically a “normal” (ethernet-like) network, but wireless. It acts for all intents and purposes like an ethernet network. There are significant requirements that devices need to follow, many include frequently saying “hello” (simplified). The complexity of the protocol to be able to send at gigabit and faster speeds over dozens of meters is significant. Having relatively low latency adds to this as well. If all you need is a few bytes every now and then, that isn’t ideal. Having devices in your network that follow older/slower standards is essentially like pulling the handbrake for your network (again, very simplified). But explaining this in detail is also very much beyond the scope of a comment here.
ZigBee devices form a mesh network, which WiFi devices don’t do. This means I can have my hub on one side of my house and a bunch of bulbs and smart outlets maintain a backbone through the house for a bunch of low power devices (like thermostats and door sensors) to connect to it.
If you’re having a bad ZigBee experience, I recommend making sure your bulbs can serve as a general ZigBee bridge, and not just a bridge for other bulbs of that brand. Otherwise, a well placed smart outlet can serve the same purpose.
And that’s a great example of how Zigbee design principles are fundamentally better suited for home automation purposes than WiFi. Thank you.
In my ideal world, no devices would not rely on cloud connectivity ever, regardless of their choice wireless transport layer. The fact that the nature of Zigbee or Thread stop device manufacturers from stupid practices (such as relying on direct WAN access) is nice, sure, but does being less capable really make them better suited for the job? I would prefer to appreciate Zigbee or Thread for what they are and have, rather than by the fortunate side effects of what they can’t do.
Zigbee or Thread doesn’t actually stop them from adding cloud connectivity, they all still do. But you yourself can stop it. Similar to the “gateway” you suggested with dedicated WiFi, they sell you a gateway for Zigbee or Thread, which then connects to the cloud/internet to allow you to control your stuff. As they would with a WiFi gateway. The protocol isn’t “less capable”, it’s intended use is around (home-)automation. It is low power, low bandwidth and most importantly both are a mesh network. That means that while you have a central point to access them (at least Zigbee has exactly 1), they all talk to each other and for a fully connected mesh. A device doesn’t need to be able to see/hear that central point. It can send it through a multi-hop route, and that route is dynamic so when a device leaves (out of power, turned off, …) the packets basically just find their way. Generally anything that has a stable power sounce will act as a router and forward packets. The low power part means that if you have a battery powered thing (remote switch, thermometer, …) it can run off a single button cell for like a year or so. With wifi it would last a week, maybe two. The bandwidth thing is related to that as well, as a thermoeter needs to send the temperature and/or humidity maybe every few minutes, or even just when it changes and there is no need for that. That comes with power usage, complexity and many other downsides, but of course a zigbee device can’t stream video or something (like a security camera would need to).
When using wifi, any device needs to be in range of the access point. You can have multiple access point but those aren’t that cheap, and should be wired in. Devices only ever talk to the access point. When multiple devices talk to each other, it goes to the access point who then sends it out again to the other device.
There are great writeups on the internet, just google “zigbee vs wifi” or something. I’m not gonna repeat what
Side note: you can reply to more than 1 paragraph in a reply. No need to reply three times, but I guess I’ll stick with it now.
I also don’t want devices I’m actively using to needlessly compete with random logistical packets from a dozens of devices around my house. I also don’t want the devices themselves to need all the power of a WiFi connection when another protocol suited to low power home automation devices is sufficient.
ZigBee/zwave were fine for me, though. I personally haven’t seen a clear benefit to matter+thread yet.
My favourite thing about these non-wifi wireless protocols is that devices using them seem to want cloud connectivity a lot less than those that come with wifi.
What do you have in mind? Surely, no solution is perfect, but at least on the surface it sounds much better than the alternative of no isolation at all, so I’d love to learn what worries you.
If I’m gonna install a device by some random manufacturer that acts as a wifi access point inside my network, I also give them full access to my network. That access point can do all sorts of things, and I would describe this as a security nightmare. It also doesn’t even have to be malicious: the manufacturer could get hacked, and now the hacker has access to all these wifi access points all over the world, and all their home networks. Fun.
firewall rules? who cares about firewall rules if the switch still forwards packets to the printer?
firewall rules only work on end devices, and routers when the destination is in a different subnet and broadcast domain.
Sounds like homework