WiFi / router setup

There are two reasons you might consider using multiple, dedicated SSIDs in your WiFi network (given you have multiple APs or mesh nodes). The first reason was described above, concerning battery powered Shelly devices. A second issue to consider is the combined network traffic handled by any one node in your network.

To understand this concept more thoroughly, a little knowledge about network traffic, topology, congestion, bandwidth, latency and throughput is desirable. There’s a lot to know, and plenty of resources on the web if you want to search some of those topics. Here, we’ll try to present just enough information to help you decide if dedicated nodes and SSIDs is an approach you should consider.

The network traffic on your WiFi network, mesh, and/or wired ethernet throughout your house has a topology. It is the set of connections running between all of these nodes as well as the connected WiFi devices they serve. Think of it like a roadmap. The analogy works really quite well. There are longer and shorter paths to get between any two places, and making less stops (or hops) at intervening nodes means faster communications, much like choosing a good route on a map. There are also faster and slower connections, depending upon your hardware, chosen frequencies, and amounts of congestion.

A mesh system tries to take all of this into consideration and dynamically move devices to the node that will serve them best. This implicit/automatic approach works well when it has all of the information it needs and makes informed decisions. We have seen too many cases where, with a mixture of IoT and other WiFi clients with completely different requirements, the automatic actions of a mesh system can cause issues of their own.

Let’s think about congestion in our map analogy. Some roads might be more direct, but knowing how much traffic is typically on that road, we choose a different route. This definitely happens in a mesh system, too. What kind of congestion would contribute to the phenomena? Say that you have a node in your front room, with a WiFi-connected TV streaming 4k video, and 3 family members with laptops. That node could be inundated with streaming traffic. The buffering in all of those devices helps to hide the fact that each one is being given high-bandwidth bursts of data, in turn, to effectively deliver the needed throughput. Streaming is throughput-intensive, but latency, the time it takes for the data to traverse the network, is less of an issue, because of buffering.

Now consider an IoT device connected to the same node in the front room, competing with the bursts of video streaming. While those other devices are using the node, the IoT device might be delayed from sending/receiving a signal. Consider an http request from a Button1 to a Shelly Duo Bulb. This is the kind of thing that makes the delay between pressing a button and seeing a response vary greatly in time. In the best case, an intelligent mesh system might move the Shelly device to a less busy, but more remote, node. What effect would that have on a Shelly Button1? Either the button might not successfully move, or if it does, it’s now using more battery power to reach a node that’s further away.

My recommendation? Dedicate one set of nodes or APs to just your Shelly and other IoT devices, and specifically design what connects where. This might sound expensive, and doubling the number of nodes in a mesh system could be costly. My approach has been to use much less expensive, even older equipment for the IoT network that has multiple dedicated SSIDs that are chosen geographically.

Allow laptops and phones to roam, but tie stationary devices to specific WiFi access points. Be aware of the wired topology of the network, so that the traffic from streaming-intensive parts of the network don’t pass through the wired hardware used for the IoT part of the network. Deploy as many low-cost access points as it takes to cover the geographical area of the home. Don’t worry about the count of how many devices connect to any one given AP, as IoT devices like switches, lights, buttons and sensors use very little bandwidth. Treat video security cameras the same as streaming, and keep them separate from the other IoT nodes.

In the end, you have a low-latency, low-bandwidth network segregated from the high-latency, high bandwidth clients.

I tested this scenario on my own network, by moving my laptop onto the IoT SSID and streaming youtube. This particular node serves 30+ devices and was humming along with practically no bandwidth utilization until the dramatic shift when the video streaming starts, shown in this graph: