Xenon lost connectivity

I just received my first Xenon yesterday. I was able to pair it with the Boron gateway, and load a test program. Everything appeared to be working fine.

Today, both devices appear OK (both breathing Cyan), but I’ve lost connectivity with the Xenon: I can’t ping it or call functions. Strangely, I CAN ping and call functions in the Boron even though the console says that both devices had their last handshake yesterday evening (about 13 hours ago)

I was able to recover by power-cycling the Xenon. But shouldn’t it give some visual indication when connectivity is lost? Afterr power cycling the Xenon, the console shows it’s last handshake a few minutes ago. It still shows that the last handshake was yesterday. (But I know it’s working because it’s the gateway to the Xenon)

Ideally, yes. So far, in practice, breathing cyan isn’t the greatest indicator . The mesh devices communicate with the cloud using UDP just like the Electron (to reduce data usage as compared to TCP). Unfortunately, UDP doesn’t guarantee packets are delivered causing unseen dropouts in connectivity with the cloud. They are aware of the status indicator issues on the console but I haven’t heard of any plans to overhaul it.

I too have had unresponsive Xenons that were breathing cyan. I haven’t seen that behavior with RC27 yet but that was just released. I have seen an unresponsive Argon gateway on RC27 though. It was breathing cyan but user code was not running for whatever reason. A reset fixed the issue.

My Xenon disconnects from Boron every 24-48 hours. Usually it’s flashing cyan but sometimes it’s breathing cyan when it disconnects.

Not sure if it’s my code or a bug.

To rule out your code, you could flash tinker to the Xenon and see if the disconnect still happens. You can also post your code for review.

By the way, the status led only indicates the state of the devices’ cloud connection… not the mesh connection. You can infer the mesh status from some of those status led modes but remember it’s primarily a cloud status indicator.

For what it’s worth, the same thing happened again today. On the console both the Boron and the Xenon show their last handshake as yesterday evening (about 14 hours ago). Both are breathing Cyan. However the Boron is still working (I can ping it and execute functions). The Xenon is breathing Cyan but I can’t ping it or execute functions. Resetting the Xenon fixed it, but the Boron still has very old handshake time.

It seems to be a pretty serious problem to me that neither the “last handshake time” nor the status LED provide any reliably useful information. (A very old last handshake doesn’t mean that the device is bad, and breathing cyan doesn’t mean that the device is good)

Edit 1: I just did what I should have done before and flashed the Xenon with a program that continually flashes the built-in LED. If/when it loses connectvity again, I’ll be able to tell if it’s still running the user code.

Edit 2: (Five hours later) The LED is still flashing (so presumable the user program is still running), but the Xenon has lost it’s connectivity to the outside world again.

2 Likes

Since the user program seems to be running, is there any way for the program to detect the loss of connectivity and “do something” (like trigger a reset of the device)

1 Like

Yes. On the Polo/node code, I attempt to reset the device if the mesh is lost for 10 minutes in my Marco polo heartbeat testing code. Although I can’t say it’s working. In the few times that my Argon or Xenons have gone “offline” while still breathing cyan, the system reset never gets triggered. I haven’t pursued the issue since stability was poor and the firware is still very rough.

I think on the Marco/gateway code I attempt the same reset for cloud loss as well.