Is there anyway of hard-coding several mesh names and Passwords into the device (Xenon or Boron) and have them able to be selected or automatic? that way I can move the device from network to network? I have looked at all the resources and am leaning towards no? if no, is this something that could be implemented in the future?
Hmm, I'm not sure about that.
It's not currently possible and AFAICT there are no such plans for HA networks.
One piece of circumstantial evidence is the absence of a Mesh.setCredentials() function and the lack of a Mesh.connect() call that would take a parameter to nominate the network to join.
Thanks all for taking the time to share this feedback. It all aligns pretty well with our expectations. For those counting at home, here’s the feedback tally (below).
We’ve already begun preliminary work on the first two (BLE APIs and Sleep modes) and will begin discussion of the features below internally.
BLE API ++++++++++++
Sleep modes +++++++++
Device recovery (HW watchdog) +++++
NFC API ++++
Topology mapper ++++
User access to external flash +++
HW debugging in workbench +++
High availability networks +++
Mesh management API +
One free HA network +
Stable threading
Sleepy end devices
"Efficient" mesh OTA (download once, distribute locally)
Boron Cellular API completeness
Cellular data metering in dashboard
Update CLI to support Mesh
Gateway can join mesh as an end device
Easier switching of Wi-Fi / mesh networks
XIP for external flash
This seems to be the feature in question, but the position in the priority list doesn't seem to suggest we'd see this any time soon (if at all).
However, I've marked it as a point of discussion in one of the next meetings.
I am with you on this feature. I would dearly like to see the ability to deploy a mesh endnode without needing a phone, particle app, etc. Really should be possible to implement Mesh. setCredentials and Mesh.connect(network);
My use cases for deploying mesh will generally have a high need for redundancy - so even if DeviceOS does not have auto (or configured) HA, then at least make the command(s) available so in my code I can retry on failure to a different mesh - this way overlapping mesh structures will work as well as some form of load balancing perhaps?
I would suggest that like WiFi - a limited number of mesh credentials be stored. even better would be a priority value for each one so you have simple failover/load balance scenarios. Register the individual mesh networks on the console (would need more than one in the free tier) and a mesh device will have to still validate to the cloud to allowed to join - thus preserving products and device limits and revenue for Particle?