SimplySNAP Mesh Networking¶
This document will help you understand how a SimplySNAP Gateway interacts with controllers that are in the same network. If you haven’t read Best Practices for RF Deployments yet, we suggest that you read it first to best understand how to place controllers and antennas for good network communications.
Our goal for this document is to provide foundational information for building stable and upgradable large lighting networks. If you are setting up a SimplySNAP Site Controller and 10 lighting controllers, you likely do not need to worry about things like hop counts or good neighbors. However, understanding the communications principles behind these networks will help ensure success with any size installation.
Mesh Routing¶
Automatic mesh routing is one of the features that makes the SimplySNAP system so useful. As soon as you power up a SimplySNAP controller, it automatically becomes a peer in the SimplySNAP network.
All controllers in a SimplySNAP network are peers. Each can talk directly to any other controller within radio range, and indirectly to any other node in the network, provided they all have the same channel, network ID, encryption settings and enhanced CRC settings. (By default, SimplySNAP controllers are set to channel 1, network ID D110, no encryption, and no enhanced CRC.)
Though it’s easy to think of the SimplySNAP Site Controller as “the boss” of the network, (and in terms of command/control it serves that function), the underlying communication structure does not require – or even accommodate –any one controller acting as a hub or traffic director.
Consider a network where you have a SimplySNAP Site Controller and a series of lighting controllers extending in a line away from the gateway over a distance of several miles.
If the distance is great enough, the controllers farthest from
your SimplySNAP Site Controller might not be able to directly hear
messages sent by the SimplySNAP Site Controller. With mesh networking,
the system automatically forwards messages out to the farthest reaches
of the network. This means that you’re not limited by proximity to the
controller, and you don’t have to install an expensive wireless backbone
to ensure connectivity to remote devices.
In some cases, the SimplySNAP Site Controller may need to send a message to a specific controller. The message is transmitted to the network “addressed” to the intended recipient. If the intended recipient is out of range, the mesh network automatically determines a viable path for the message to travel to its destination node. The message then “hops” from one node to another (leapfrogging intermediate nodes when appropriate) until the destination node receives and acts on the message.
Homogeneous and Heterogeneous Networks¶
The best kind of network for upgrading scripts and firmware is a homogeneous network where nodes have the same hardware type. If everything is the same hardware type, then the firmware and scripts needed are the same for every node, and they can all participate in neighbor to neighbor upgrades.
If a network has different hardware, it can still have the same firmware.
Meanwhile, if you have a completely heterogeneous network with multiple firmwares and multiple scripts, you will want to either have a good neighbor for every controller, or have the least represented controllers nearest to the gateway.
A good neighbor is a controller of the same firmware and script within one hop. If two controllers have direct line of sight of each other, they are normally one hop from each other. We look at neighbors during script and firmware uploads, so a controller can have a good neighbor for firmware uploads and not have one for script uploads. It is more important to have a good neighbor for firmware uploads at this time, as the firmware upload is larger and takes longer than the script upload. However, both are important for a functioning network.
Upgrades, Census, and Hop Counts¶
When a system is first installed or upgraded, the system might need to push new firmware, scripts, or both. The system can do this effectively within a few hops of the gateway. After 4-5 hops, the system might or might not be able to directly upgrade a controller’s firmware or script.
This is where neighbor to neighbor upgrades come into play. If a system has done a census, it will know all the neighbors for all the controllers that were powered on at the time the census was performed. If a controller needs to be updated and has a viable neighbor, then that neighbor will upgrade it. If the neighbor to neighbor upgrade fails for any reason, then the system will try to directly upgrade the controller. If both of these fail and all retries have been made, an alarm will be activated.
The census is also important for getting the topology of the mesh network, so it will know how many hops the network extends to and how far it needs to send a message to reach the edge of the network. If a census is never performed, the system might not be able to talk to all nodes with the default values for sending messages. For more information on performing a census, please see the SimplySNAP User’s Guide.
Creating a Good Mesh Network¶
In a good mesh network, each controller can talk to at least two other controllers, hopefully having at least one viable neighbor. For outdoor lights, if two controllers have direct line of sight, then they can most likely talk to each other.
There should never be a location in the mesh network where there is only one path available back to the gateway. If something should happen to that controller, then a portion of the network would be stranded from the gateway.
Path Example¶
One scenario for lights involves path lighting. If you have a
SimplySNAP Gateway at the end of the path, then controllers can talk to
the next two or three controllers in the path. This should work fine if
all the controllers are the same lighting controller type. (i.e.
DIM10-100.) If you want to place a sensor, and therefore a controller,
from the DIM10-250 family every 4-5 lights, the system will most likely
not be able to update the DIM10-250s that are more than 4 hops from the
SimplySNAP Gateway. In the image below, the SimplySNAP gateway is
located at A, with B, F, and I being DIM10-250s, and the rest are
DIM10-100s. In this scenario B and F can get updated directly, and the
DIM10-100s can get upgraded directly or by using their neighbors. The
gateway would try to directly upgrade I, but might or might not be able
to , as it is, at best, 4 hops from the gateway and has no good
neighbors.
However, if you locate the gateway at G, instead of A, the gateway will be able to update all controllers without an issue.
Conclusion¶
Homogeneous networks work best from an upgrading standpoint, but are not practical for all customers. If you have to have a heterogeneous network, one solution is to only have a heterogeneous network within 3-4 hops of the gateway, and any controllers that are far from the gateway could be of one controller type only. Another solution would be to make the ratio of controllers closer to 50% of each type of controller with each type of controller being distributed equally and having multiple possible neighbors.
Once a good mesh network has been achieved, a SimplySNAP gateway can communicate and update a large number of controllers, even up to 500 and beyond. However, if a good network cannot be achieved, using multiple SimplySNAP gateways is always a viable option.