Xenon - Boron Communications

Firmware
1

Where can I find example code showing how a Boron can receive data from multiple Xenon boards? Is there any source available to show how it is done?

Thanks in advance for any help.

2

You can’t at the moment - system firmware is still not locked down and hence any information provided now would be subject to possible change.
You’ll have to wait a bit longer :wink:

1 Like
3

What ScruffR said is true for the local mesh communication APIs.

However, the Boron and Xenon (also Argon) fully support the existing Particle.publish and Particle.subscribe APIs, so it’s possible to write code to communicate between both mesh and non-mesh devices transparently using publish and subscribe.

1 Like
4

Thank you @rickkas7. I have not used subscribe before.

So if I understand you correctly, one can use .publish on several Xenon devices in the vicinity of a Boron (using the mesh network), and subscribe to these events on that Boron?

I basically need the Boron to get the data from nearby Xenon devices (using BLE or Mesh) then ship that data to a Ubidots channel.

Is this a feasible approach?

Thanks again.

5

Conceptually yes, though it’s not vicinity. You choose which network you join, and there can be multiple networks in a single location.

However just like the Photon and Electron, devices are claimed to a specific account. Doing a publish with the PRIVATE flag set will go to all subscribed devices claimed to the same account, regardless of location.

However it would work fine in your use case of having the Boron upload the data to Ubidots.

2 Likes
6

The mesh-specific APIs will allow more efficient communication between nearby devices joined to the same network, but those APIs are not available yet.

1 Like
7

Hi, I have a question.

Publish private message in Xenon mesh network have TTL?
I think when the Xeon publish the private message to some endpoint(like a [device_name]/data/put) in mesh network, that message is routing until TTL is expired if nobody can’t get that message. Is this right?

8

Also, if you publish from a Xenon that’s connected to a mesh with a gateway device (e.g. Electron) the publish will go through to the cloud transparently and you could use webhooks without the Electron firmware having to explicitly take care of the event.

However @rickkas7, another question arises - will the mesh also forward TCP/UDP traffic transparently?

1 Like
9

Thank you @ScruffR, but I do not want every publish from the Xenon to go to the cloud. This is to save on data costs.

So I want to send the data to the Boron which aggregates it then sends it.

10

In that case I’d say Particle.publish() is not an option and you need to wait for the mesh docs to get released.

1 Like
11

will the mesh also forward TCP/UDP traffic transparently

TCP is most likely no. The reason is that the Thread mesh is basically a store and forward network, which is not well suited for interactive TCP communication. There is a Thread extension proposed that would make it possible, but that certainly won't be available any time soon.

UDP is definitely possible, as it's a core feature of Thread mesh. But how much is exposed via the API hasn't been determined yet. So maybe not at launch, but maybe sometime later. Or maybe at launch. I don't know yet.

2 Likes
12

Now that the mesh products are out, I would appreciate the community's help with example code for Argon-Xenon communications.

So far, on the Xenon side, I have (and it is working):

Mesh.publish("SensorData", tMessage);

On the Argon side, I have:

Mesh.subscribe("SensorData", myHandler);

void myHandler(const char *event, const char *data)
{
Serial.printlnf("event=%s data=%s", event, data ? data : "NULL");
}

How can that Argon send data back to that Xenon (or other Xenons in the same mesh network)?

Is it also by "Subscribe" on the Xenon side and "Publish" on the Argon side?

13

Perhaps something as simple as this would work for you:

On Argon:

Mesh.publish("Command", sCmd);

On Xenon:

Mesh.subscribe(“Command”, myHandler);

void myHandler(const char *event, const char *data)
{
  Serial.printlnf(“event=%s data=%s”, event, data ? data : “NULL”);

  //Parse Command here:

}

If you want to target a specific device, then perhaps you need to add command suffix:

On Argon:

//This would subscribe to every command.
//We can parse to get just the ones targeted to this device or
//change this subscribe to include the specific device ID.
Mesh.publish("Command", sCmd);  //Receive every command
//Mesh.publish("Command-[target device ID]", sCmd);  //Receive only my commands.

On Xenon:

Mesh.subscribe("Command-[device ID]", myHandler);

void myHandler(const char *event, const char *data)
{
  Serial.printlnf(“event=%s data=%s”, event, data ? data : “NULL”);


  //Parse Command here:
  //If event includes [my device id], then parse the command.
}

Learning what device ID’s are on your mesh network isn’t straight-forward yet. There is another post on here asking for that type of information.

2 Likes