While getting my feet wet with the Mesh devices, I am concerned that the Mesh network has limited use in industrial settings because of the limited range. I understand the range is a bit subjective right now as there isn’t a lot of empirical evidence as to what the useful range is and how the environment will affect it. But still, in my warehouse, the support columns are 50 feet (~15 meters) apart which may be pushing the mesh limits when you consider the shelving and product obscuring direct line-of-sight.
One of my Mesh use-cases is for a distributed lighting control system in industrial buildings. I was originally working on a large, modular relay panel. However, I tabled that project while waiting for the Mesh devices. The new concept is to have a junction box attached to each electrical circuit with a single relay that will control and measure power consumption on the circuit. The junction boxes could be in excess of 50 feet apart. While brainstorming the issue I thought going back to WiFi, which is readily available in the warehouse, was the best solution. But now I’m thinking about secure communication between the WiFi devices.
The one thing that makes the Mesh so attractive is the local Mesh network that works independently of the cloud and is secure. When the Mesh network just doesn’t have the range, WiFi is the next-best ubiquitous mode of connectivity. But, how can I communicate securely among a group of WiFi devices (Argon, Photon, P1, etc.), on the same subnet, when the cloud is unavailable? Or perhaps, between 2 mesh networks (Argon to Argon)? You are left with a homegrown solution using TCP, UDP, etc. All of which you have to secure yourself.
Would it make sense to create a new primitive for Local.publish() which would allow secure, direct communication among devices on the same WiFi network, VLAN or subnet? This wouldn’t make sense for cellular but I think this is a missing feature for WiFi/subnet comms. While the Gen 2 devices may not have the flash space to implement this, the Mesh devices do. Adding this local communication feature would also plug the hole for mesh gateways to communicate to each other when on the same subnet but out of mesh network range. Yes, the Cloud.publish() works also but if you only want local communication, it doesn’t make sense for messages to leave the local network only to return to another device on the same network; it requires unnecessary external bandwidth.
Just one though on using Local.publish() in conjunction with mesh: I could imagine there could be a scenario with 2 mesh networks and each network needs to relay data to the other. Each network has a Boron for cloud connections. These separate networks are out of mesh range to connect each other. Then you could add an Argon to each network (perhaps even in “ad hoc” mode negating the need for an AP… which doens’t exist for Gen 3 devices… yet ). The Mesh networks can pass data back and forth via the Argons which preserve cellular data consumption. For redundancy, if a Boron drops the cloud from one network, the Boron on the sister network could pick up the slack via the Argon redundant connections.