Best method for local network communication between devices now that mesh is gone

I have an application where I have an Argon acting to control hardware, with other argons acting as remote sensors. Small amounts of data, probably 1Hz or so.

Originally I was planning to use Xenons + Mesh for the communication, but I just started using these again and learned about the demise of the Mesh functionality.

I do plan to send some of the data to the cloud, but I need these to keep working even if the internet/cloud goes down.

UDP honestly sounds like the best idea right now, but please let me know if there is a better method. I think the mesh functions were supposed to work without the cloud? So maybe some of that functionality is going to survive?

(I would even consider a setup where a sensor broadcasts UDP until it is contacted by a controller via TCP, and self-registers. I don’t want to get too involved though.)

Thanks!

@jed, have you looked at the BLE_Group library in the Web IDE. It allows an Argon/Boron acting as a cloud gateway connecting via BLE to up to three other Argons acting as BLE devices, in a similar fashion to what Xenon mesh devices used to do.

3 Likes

That looks amazing, but do I need to use BT for this? Both of these devices will be on WiFi (Maybe I wasn’t clear about that; I am more interested in the group messaging and callbacks than I am in the BT/Mesh functionality).

What about when your local WiFi has gone down?

If you want a solution that will also function without WiFi, you still can use BLE (it’s built-in).

I have not used the BT on these devices previously, how strong is the signal? How far will it reach? My testing case is about 10 feet through a wall. But I will probably separate these by 25-50 feet and several walls, stories (and in my home, we have metal in the floor heating, which tends to kill signals).

Although wifi does go down, it’s probably 99.9% stable, as opposed to my internet, which conks out often enough (line of sight).

I will give it a shot though!

The BLE range would be the same the Mesh range was as it is using the same antenna and radio.

With an external antenna you can gain some extra distance.
There are some discussions in this forum about increasing mesh reach which can be applied to BLE just the same.

However, when your WiFi stability is fine for your use-case then I’d opt for TCP as it is easier to use due to its inbuilt packet resend in case of lost packets.

2 Likes

Ah, I had not looked into the BT/Mesh info to see what radios they were using. I assumed that the BT was included for communication with mobile devices, and that mesh was separate (I now understand they are using different protocols though). I was planning to use Xenons for cost reasons, and so mesh was the only option. WiFi is probably the best choice for this application, but I think I will play with the BT to see how it works.

All that aside, is there an analog of this messaging framework for TCP? Or should I just spin up my own rudimentary protocol with the TCP and UDP libraries?

Not sure what exactly you mean. TCP is already a mature protocol that can be used as is, but of course you can put another protocl ontop (like HTTP) but I wouldn’t see what for when merely communicating sensor readings.

I mean that @peekay123 above suggested using the BLE_Group library to send messages over BLE. This creates a group, formats the messages, and has a callback implemented to handle the messages.

Just wondering if there is the same thing over TCP/UDP.

Whether you need that or not depends on your use-case and how many devices will share the group.
For BLE you have a restriction of (currently) max. 3 peripherals connected to one central at any given time and very constrained advertising options.
For TCP and UDP things behave fundamentally different - there you can use broadcasting or multicasting virtually without size limit as well as “direct” connections.

Well, that definitely makes me want to shy away from the BLE_group for this application.

Have you considered a radio solution? I believe there is a RFM69 library available for Particle. It’s cheap, pretty easy (you can check out the guys at Low Power Labs for details) and will give you better than 100 metres range in most cases.

That is not a bad idea.