Feature request - New primitive Local.Publish() for WiFi Devices

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 :wink:). 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.

Your thoughts?


This would be a very useful feature.

It would probably conflict with the mesh pricing structure (which is a mess anyway).


@ninjatill, I agree with @nrobinson2000 in regards to being a nice feature. However that makes the Argon into a mesh “bridge” allowing the expansion of a mesh begin Particle’s structured plans. It is certainly a worthwhile discussion to have with Particle nonetheless.

In the meantime, you may want to explore an external mesh antenna to extend the range. The PCB or duck antennas sold by Particle will do the trick I’m told so it is worth testing out. That’s on my to-do list!


@peekay123 I would rather have the Local.publish() functionality on the Photon. But since the path is towards Gen 3, then the Argon is the likely target for this functionality. The Photon hardware is strapped for RAM compared to the Argon so more features just make it difficult to manage large user firmware. I think discontinuing the Photon is a mistake but Particle may want to look at creating a “Photon Revision 2” with some extra flash in a similar setup to the Argon.

I was looking at external antennas last night. I’m going to get a few.

There are no current plans to discontinue the Photon - you may want to re-read Will’s response on the discussion about “legacy” devices.


Oh I read it… just didn’t get a “warm and fuzzy” about the longevity of it.

Sometimes you don’t need to get emotional but can just take the words for what they literally mean :wink:


@ninjatill, I have been strongly advocating for a Photon 2 as I don’t believe the Argon has what it takes for the job (MHz, RAM, Flash, etc.) However, for a LOT of situations, it will fit the bill nicely.

If the Particle future is Mesh then it would stand to reason that future devices support it as well. It also goes to reason that long range mesh “bridges” and longer range nodes should be in their future with suitable adaptations to their billing model.

Particle’s mesh journey is just beginning and a lot of work remains to be done. One thing I know about Particle is THEY LISTEN so suggestions like yours are great to bring up!


This feature would make a lot of my applications, and customer applications, much more robust and easy to use.


Yes, this would be a very valuable capability. I had made a question regarding basically the same functionality here:

However @ninjatill has explained it better, I think. One of my use cases would be better served by a photon network with a local publish, mesh not necessarily being crucial for me. But to be able to extend a mesh network into two locales not within mesh distance but within the same Wireless network would open up a lot of possibilities!



Would something like Multicast help with your use-case?


I also would love to see this local publish feature.

It’s exactly the easy to use local communication feature I’m desiring for a large 50 to 100 room networks that still allow communication when WiFi is down.

The MESH doesn’t look like it’s going to cut it.


Yes. I use UDP Multicast in another project. In that case, all packets are not encrypted. Any other device on the network would potentially have access to the data or be able to join the multicast without authorization. I was looking for a built-in solution that would be a drop-in replacement for Particle.publish() but localized to the subnet. UDP probably would be a component of such a solution. I believe the new mesh devices use secure comms over UDP… it would be great if it was adapted for use on the LAN-side instead of the mesh-side.


They can’t get rid of the Photon until they have something just as stable to replace it.

That stability/reliability takes some real time and a lot of end user feedback to accomplish.

1 Like

Yeah, I should have read more closely before I asked. I guess local cloud server isn’t being maintained any more? https://github.com/particle-iot/spark-server


Hi particles, I created a product for industry based on the Particle cloud and photon / electron – ubidots API and a radio mesh based on the great products and work by the guys at Low Power Labs (Moteino). For me the real-world problem is range from the Internet gateway (Particle) to the sensor node (Moteino) – and I’m getting over 400 metres (powered) and around 120 metres for ultra-low power battery operated sensor nodes. I’m using 433 Mhz radio – but LoRa will be the next step. I will be looking at a Particle Mesh based product as the security and regulatory compliance stuff is mostly done – and that is important in some markets – but not my current prospects. My product provides (through the particle cloud) two-way connectivity and control of external devices at the sensor node – and conditional (sensor reading thresholds) or un-conditional (operator clicks button on website) responses via ubidots.
OK – this was a shameless plug for my stuff – but on this forum most of you guys are more skilled makers than me and I’m sure you could build your own solution. If so, I spent a lot of time on various platforms and came to the conclusion that for an industrial SCADA-like solution Particle, radio and Ubidots were the best solution for range, reliability and functionality.
But if you want to save yourself a lot of time or have an actual industrial or other requirement - check out my stuff here www.scadascope.com

@DRCO The Particle MESH range is less than your getting with the LORA radios your using now so dont expect it to give you better range.

If you want long range certified radios you can also use the Xbee MESH radios. There is a Particle library for them already.

The LORA RFM69 radios can give you 1 mile urban city range but the radios do not have all the certifications like the XBee radios do.

Yes, I did some prototyping with X-Bee and for the cost I found them no better than RFM69HW and they were power hungry little guys. I can sleep my nodes and draw around 18nA - and still wake them up reliably at over 100 metres. For most of the applications I’m targeting that’ll give be over a year in-situ on three AA batteries. I agree the regulatory stuff is an issue - but have few work-arounds on the broadcast power that can see me operating under the rules in Australia - US is probably another matter. Regarding LoRa - there are a couple of SEMTECH- based platforms that should pass certification. The big problem is the slightest change in configuration or addition of connected devices voids the certification, including housings or antennas.
My view on an all Particle network is that while the MESH architecture is good and a single platform is a more solid base for a commercial product - they should make a LoRa- based low power node. Range is, in my experience, the absolute most desirable attribute in IoT applied to industry or commercial applications and while the MESH is solid you would need way too many nodes to achieve any workable range and that is just too many points of potential failure. I get it that the network heals itself and reroutes traffic in a single point of failure but if you are changing batteries, maintaining solar or supplying power to hundreds of units it is just unworkable.

1 Like

The particle OS is open source, correct? Would anyone be interested in trying to adapt udp/TCP communications (whichever would be better for the majority) into a local.publish setup? I may be over simplifying this, and its certainly beyond my knowledge and skill level, but the framework for any .publish should be in the mesh or particle firmware, and adapting that to what is known about udp/TCP. Anyone think this is doable?

1 Like

Theoretically it could be done, but a lot of the low-level OS stuff is way over my head.

1 Like