Mesh setup is such a disaster!

Every time I have to register a device or change something about it I have to waste countless hours. The non-transparency of what’s happening is maddening. The tools all have a “it just works” UI, except that it just doesn’t work.

I have a boron I set-up as non-mesh and for the past 4 hours I’ve been trying to change it to a mesh gateway. To start with, I don’t see any way to tell whether it’s configured as a gateway or not.

I then disowned it and tried to set it up from scratch using the mobile app (android, pixel 3a). I was able to pair and then when I got to the step of choosing the mesh/no-mesh clicking “yes, use in mesh network” brought up a spinner for 2-3 seconds which then went away to leave me with the same choose mesh/no-mesh UI. Clicking again brings up a spinner for a fraction of a second and it goes away with no forward progress.

I was on 1.3.0-alpha and figured that maybe I have to downgrade to 0.9.0, which is the version for which the instructions are written. I started over. The mobile app upgraded my device (thanks for not telling me to which version!!!). Then I landed again in the same endless loop clicking “yes, use mesh network” just to see a spinner come and go with no forward progress.

But wait, there’s a tutorial for “Mesh setup over USB”: https://docs.particle.io/support/particle-devices-faq/mesh-setup-over-usb/#boron-gateway-setup. I followed that until I got the step where particle serial identify is supposed to chow the ICCID that I can type into the web portal. Well, here’s the output I get (obfuscated device id):

> particle serial identify

Your device id is e00fce68b3c5cf7900000000
Unable to determine system firmware version

Previously, when I had 0.9.0 running I also tried that, at that time I got:

> particle serial identify

Your device id is e00fce68b3c5cf7900000000
Your system firmware version is 0.9.0

Maybe someday particle can reconsider writing “it just works” software and instead provide tools and add diagnostic output so when it doesn’t work – 99% of the time in my experience – one can figure out what’s going wrong.

What version CLI have you got?
Can you run a particle serial inspect and post the result?
What code was your device running before entering Listening Mode?
Was the cellular module on?
Are you using 3rd party SIM?

> particle serial identify

Your device id is e0...000
Your IMEI is 3...0
Your ICCID is 8...0
Your system firmware version is 0.9.0

What version CLI have you got?

> particle version
1.41.1

Can you run a particel serial inspect and post the result?

Nope, serial now always times out. Perhaps because I have an app loaded. What are the conditions for particle serial to work? No documentation…

What code was your device running before entering Listening Mode?

My app doing lots of stuff, from UDP to i2c…

Was the cellular module on?
Are you using 3rd party SIM?

I’m using a 3rd party SIM, I had it removed but I now realize it may have been selected.

I eventually realized I didn’t need the ICCID anymore, because the device was already registered. I only needed to run particle add mesh. This is really the issue, there is no documentation about the various registration states and how to go from one state to the next, nor how to determine which state a device is in. I’m not talking about the dynamic states indicated by the LED but the registration states, e.g., whether it’s registered with the cloud, whether it has mesh creds, whether it acts as a gateway, etc.

Now I’m stuck trying to turn Mesh on! I have a xenon that I paired with the boron. On the Xenon, when I call Mesh.on() and Particle.connect() I see debug info, the last of which is

0000006249 [net.th] TRACE: OpenThread state changed: 12a5
0000006252 [net.ifapi] INFO: Netif th1 link UP
0000006254 [system.nm] INFO: State changed: IFACE_UP -> IFACE_LINK_UP
0000006257 [net.th] TRACE: OT_CHANGED_THREAD_NETDATA
0000006259 [net.th] TRACE: Synchronizing IP state with LwIP
0000006262 [net.ifapi] TRACE: Netif th1 ipv6 addr state changed
0000006265 [net.ifapi] TRACE: Netif th1 ipv6 addr state changed
0000006268 [net.th] TRACE: Added FD26:C55:2FC::FF:FE00:FC00 0
0000006271 [system.ot] TRACE: IPv6 address was added
0000006273 [system.ot] INFO: Role changed: leader
0000006275 [system.ot] TRACE: RLOC was added
0000006277 [system.ot] TRACE: Partition ID changed
0000006279 [system.ot] TRACE: Thread network data changed
0000006281 [system.ot] TRACE: Subscribed to IPv6 multicast address

After that, the xenon says Mesh.read()==true and Particle.connecting()==true, but it never connects. I believe the issue is Role changed: leader: even though the Boron is breathing blue and clearly has a cloud connection it’s not active on the mesh.

On the Boron, I call Mesh.on(), but I never get Mesh.connected(). It’s stuck in connecting state. Also, I never see the net/system debug messages that I see on the Xenon. Impossible to tell where it’s stuck/confused…

Was your Xenon ever set to be used with the Ethernet FeatherWing?
That’s also a sticky setting that needs to be reset.

Nope, I don’t have a featherwing :slight_smile:

Aha, hal/build.mk has some if statements to the effect that for a Boron a non-debug, non-hybrid build gets -DLOG_COMPILE_TIME_LEVEL=LOG_LEVEL_ERROR, how inconvenient. And why???

Update: I removed that -D and now get trace/debug statements, however, there is nothing about openthread/mesh showing up. I tried to trace down into what happens when Mesh.on() is called but it quickly turns into a complex mess in the network manager… So go figure why my Boron doesn’t want to turn Mesh on…