Using boron as mesh-only device

I there a way to connect to the cloud from a boron using mesh and an argon-wifi, as opposed to it starting up the cellular connection?

I’m asking for two slightly different use-cases:

  • I’m developing a device that has a boron in it but while I’m developing I really don’t want to rack up a crazy cellular bill, so I’d like its cloud communication to go through an argon, which has a “free” wifi connection

  • The device I’m developing is mobile, while it’s out and about I’d like it to use its cellular connection, but when it comes home I’d like it to switch to a “free” mesh + argon-wifi connection. Basically the same type of intelligent network selection that cell phones do. (Part of the motivation here is that I’d like to store data on the boron while it’s out and about that it then spools when it arrives home.)

What you’re asking for is what Particle considers a “High Availability” mesh network. I believe HA networks are on their roadmap but they haven’t implemented this feature yet. At this time, you cannot have 2 gateways on the same mesh network. (Currently on v0.8.0-RC27)

1 Like

If I understand correctly, you want your Boron to simply be a node and not a gateway. So I don’t know if this is would actually be classified as a “high availability” feature–I would need to check with our engineering team on that.

I do know that such a feature (turning gateways into nodes) has been discussed. I do believe it is something that is possible but I do not know of the timeframe at which this would be implemented. I suspect this will be on our roadmap at some point, but I cannot say for certain when.

Yes/no. For the first use-case, yes. For the second, no. For the second use-case I definitely want to use the cell radio when the boron is away from home, but then turn off the cell and use mesh at home.

What makes the device OS on a boron be a stand-alone cell node vs a mesh node (without cellular)? Is that something that can be reconfigured dynamically?

I do not believe that the HA mesh network functionality would cover this type of use-case because I suspect that a mesh network needs to be unpartitioned and as soon as the boron leaves home, that would cause a partition (one being the home mesh connected by an argon and the other partition being the lone boron on cellular).

Sounds like my best bet would be to figure out how to make the boron ignore the cell modem so it can be a part of the home mesh and then work the cell modem explicitly using AT commands…

1 Like

That’s an interesting use case. I can’t say that this has been addressed before. In theory, what you’re asking for could work. But in practice, I don’t know if there would be limitations or complications from a backend perspective. I’m not sure how all the data would be stored on the flash–and whether or not it would need to sandbox each configuration in order maintain it’s separate configurations.

I’m also unsure if the firmware is written to handle different configurations or if there’d be sufficient flash.

I’ll address this with my firmware team and see what their thoughts are on the matter.

But at this time, I would say it’s safe to say that this is not something that’s on the short term roadmap. It may be possible, but I would want to talk to engineering before giving you a definitive yes or no.

That may be true, but without the implementation of the HA feature there is currently no way for a potential gateway device to join an existing network.
Once HA is implemented that will be possible but that doesn’t necessarily mean that you will ever be able to demote a gateway to become a mere router/endnode to circumvent the HA price tier. Hence there are also no APIs (planned) to support “demotion”.
The discussion about that is still ongoing.

BTW, what is the reason behind the decision against a partitioned mesh network? Partitioning is allowed and expected to happen any time.
Once network topology APIs will be added your Boron could learn about the fact that it is the only device in its network and your code could call Mesh.off() to dissolve its partition.

I’m not sure how to read your question, but I went a bit on a tour wondering “what about mesh network partitions?”

So from a Thread perspective, if a network partitions then the two partitions continue happily, the partition that does not have the former leader elects a new leader. If the partitions are able to communicate with each other again, then they join together. While they are separated, nodes in one partition simply can’t communicate with nodes in the other partition (duh).

In my use-case, when I take the Boron on the road the mesh network will partition and there will be one partition with the Argon and any other mesh node at home, and a second partition with the lonely Boron.

Now, in the particle worlds there is the added notion of a cloud gateway, so the additional question is whether the cloud back-end can handle the partitioning. Initially, there would be one network, one partition, two gateways, all nodes reachable via either gateway. Once the Boron hits the road, there would be one network, two partitions, most nodes reachable via one gateway (Argon) and one node reachable via the other gateway (Boron).

Sadly it sounds like I get to hack my use-case…

That’s exactly where HA networks would come into play - once they are implemented.

That’s not obvious to me. It’s one thing for the cloud to maintain status on multiple gateways to reach a network such that if one fails it continues using the others. It’s a different thing to maintain a mapping of which devices of the network can be reached through which gateway such that it can deal with multiple partitions. I have not seen specs about what particle plans to implement…

If the cloud knows all gateways in charge and addresses them all at any time it’s irrelevant for the cloud which node is connected to which gateway, isn’t it?
The only downside of that would be extra data cost for addressing the “wrong” gateway(s) - which you’d need anyway if you had packet buffering with TTL for sleepy nodes.

With sleepy nodes, you’ll never know at which partition any given node may wake up to and hence each wake would mean extra data cost in order to inform the cloud about the new topology - this would most likely cause a lot more data traffic than addressing all active gateways. Additionally you’d have no control over that as it’d be done by the system. On the other hand you have control over your firmware and backend.

So the extra data cost with potentially addressing a gateway that can’t reach that node is the trade-off for the benefit of high availability.

But all of that is my private take on that from a pragmatic viewpoint.
Maybe @jberi can chime in and provide a rough overview on the intended behaviour of HA networks with regards to partitioning.

That could be a pretty high cost with cellular gateways!

I would argue the exact opposite. Network partitioning events are rare in any well-configured network. If you have a network that constantly partitions and heals you will have a slew of issues prompting you to fix things. So the extra signaling when partitions occur or heal is not a big deal.

:wink:

What about roaming and sleeping nodes and non-stationary meshes?

Heya @tve I know it’s been a bit, but I wanted to follow up on this.

I had this discussion with my engineering team in regards to the “dynamic gateway” we were discussing here. And the answer ultimately is it is not something we’ll be supporting.

Though it may be theoretically possible from an engineering perspective, it’s outside the paradigm that the firmware was originally built on and may have some negative implications and impact on reliability. Furthermore, having something that switches between being a gateway and non-gateway would have billing implications that we really haven’t accounted for and may prove to be costly in the end.

I imagine this isn’t quite the answer you were looking for, but I do hope that it clarifies things a bit.

Thanks for the clarification, bummer, but I understand.