I have an Argon set up on my home wifi, and a Xenon that setup on the mesh network quickly and easily, unfortunately it doesn’t stay connected. After a few minutes (anywhere from 1 to 5) the Xenon disconnects, tries to reconnect by flashing fast green, fast cyan, then blinking SOS with 7 flashes. From the docs 7 flashes indicates “Exit” with no additional description. The only way to reconnect the Xenon is to power them both down and then back up, resetting the Mesh network completely.
Jumped the gun on a solution for this. The Xenon still regularly disconnects, flashing SOS - 7 blinks, but seems to reconnect after the SOS. Anyone know what the SOS - 7 pattern is? Docs just say “Exit”.
I’ve got one doing that as well. Haven’t gotten around to trying to figure it out. Connects, seems fine for a random amount of time, then does SOS + 7 blinks + SOS a couple times, then reconnects. I plan on setting it up to log to ttyUSB, just haven’t had time yet.
We are having the same issue here. Power down the Argon and they reconnect. But after 1-5 minutes the Xenons begin to blink green and will continue to blink green unless we power down. Anyone have any ideas how to keep the Xenons connected?
Many people here were able to establish a somewhat stable mesh Network by disabling IPv6 on their routers. This is a known issue with ARRIS routers. This does not however address the stability issue that I am having, as the mesh network will still go down but the mesh devices will reconnect after a period of time on their own, but will continuously disconnect after 1-3 minutes.
I’m thinking the MESH instability may have something to do with the delayed shipping. They may be trying to iron out all the firmware kinks as much as possible before everything ends up in people’s hands.
Have the Argon-Xenon up now on IPv4. Had a little instability after 7 minutes (rapid cyan for 10 seconds then back to breathing). Going to let it burn all night with an ESP32 “watching” it.
Break out your old routers (like has been suggested). Only sporadic issues on an IPv4 only network.
Also found that a few feet difference makes things better. Putting 3 feet or more between the Argon and Xenon helped. Making sure the WiFi antenna was 90 degrees to the built in antenna on the Argon made the most difference though.
I am also experiencing this issue. Mesh is composed of 1x Argon and 3x Xenons. 2x of the Xenons are having the instability (“exit” blink code) issue. Problem follows the devices themselves and is independent of power supply and location.
All devices in the mesh are still running the default “Tinker” user code.
There are a couple different issues going on in this thread:
If the Argon is disconnecting from the cloud periodically, it could be the Arris modem/IPv6 issue. When the device receives DNS responses with IPv6 addresses, the cloud connection is broken. This is fixed in 0.8.0-rc.26.
There are also other stability issues that can help in 0.8.0-rc.26. I’ve found the gateway stability to be much improved. This is a fix for the periodic SOS.
There is a separate issue where if you reboot your gateway (Argon or Boron), the mesh devices can’t reconnect. This has the appearance of being fixed, however there is still one bug in openthread that needs to be fixed. The reason it seems fixed in 0.8.0-rc.26 is that the Argon is no longer constantly rebooting.
I am having the same issue. My network consist of 1 Argon and 2 Xenons.
Argon connects fine and stays connected 100% of the time. However, the Xenons connect and stay connected for about 20 to 30 seconds. After that it goes into flashing green.
Restarting and establishing new network connections did not help.
Wanted to follow-up with this thread to let everyone know that a fix for the SOS-7 issue has been released with v0.8.0-rc.27. The issues was tracked to a problem with the Nordic 802.15.4 driver. Instructions for upgrading are available below. We'd love to know if applying the release fixes the issue SOS-7 issue that you're experiencing.
Note that we have seen some reports of change in behavior for rc.27 when users call the Mesh.subscribe() function within the setup() loop that can result in a separate SOS-10 code which we're currently investigating. If this issue affects you, please note the following workaround.