I just set up a mesh network in my house with 9x devices (Argon w/ ethernet featherwing as gateway and 8x Xenons communicating through it). Every device is running the same code, but 3x Xenons have trouble staying connected. At least one of these misbehaving Xenons gave me a lot of trouble during setup (botched updated, had to dfu update the whole thing. couldn’t set up with iPhone, had to connect to mesh network with serial).
All of my devices are on 1.3.0-rc.1.
These 3x devices typically blink (not breathe) cyan but sometimes I get a super short pulse of red LED.
The strangest thing I noticed about them is that they take turns connecting to the gateway.The screenshow below shows the 3x devices and you’ll notice that only one device at a time has good data (this GUI connects data points with a smooth line so that just means no data between those points)
What can I do to fix these devices?
Have you got external antennas fitted and enabled? That might be the issue.
The only device with an antenna is the Argon which really doesn’t need it because I’m using it as the gateway via Ethernet.
I’m willing to try an antenna but I have a bad and good device in the same room so I wouldn’t think the connection is the issue. The other bad sensor is just one room away from the gateway and some of the other good ones are even further away. If I remember correctly, I had all the devices powered in one room at the start of the project and I still saw these devices have trouble connecting.
It looks like I can use the Argon’s WiFi antenna on the Xenon for BT/Thread? If so, I can easily try that and see if it improves the connection quality.
Try them all on 1.3.1-rc.1.
There is only one mesh antenna connector on the Xenon on the top, with the Argon the BT connector is for the mesh.
Have you enabled the external antenna? The API has just been added in 1.3.1 but the enum value needs to be type cast.
@armor I am having the same issue mentioned by @Dillon1337, in my case I have the exact same behavior with Boron LTE and 6 Xenons. This is something I have been experiencing for quite some time, but I found that with 5 Xenons the mesh communication works “ok”.
Based on your recommendation, after setting up all the xenons with the mesh antenna and the boron with the mesh antenna and trying the latest version 1.3.1-rc 1 in all the devices, I keep seeing the same behavior, where 5 Xenons communicate “ok” with the boron, but the the 6th xenon keeps dropping from the mesh (flashing green rapidly) or it will keep itself connected but unreachable.
As mentioned before, I have kept almost every mesh network at 5 Xenons to keep a “healthy mesh network”. Therefore based on experience the max number of nodes in a mesh network should be 5, not more unless you have another suggestion to reduce the drops after 5 xenons connected.
Thanks for sharing your experience- the reason why >5 nodes on a mesh creates instability really needs to be addressed to Particle if you using latest OS and antennas. @rickkas7 can you help?
Did you get any resolution to this?
This seems very similar to mine. I just posted about this in thread.
I have only three Xenons but I cannot get them all stay in mesh at the same time. And for me the one that blinks green never gets into mesh. Only when I run particle update or get new keys I can make it connect. But then other one drops. Makes no sense.
No official resolution. One of the original three has been communicating OK since Oct 31. The other two devices haven’t communicated in months. I think I need to update them via USB but haven’t had a chance (and I know I tried that before so I don’t know what will be different this time). The rest of my network is on 1.4.0 or 1.4.2 and seems to be OK.
Sort of resolution. Device OS 1.4.2 is much better but I am seeing a problem with gateway not being stable. I have had 8 endnodes connected so you should be good at 5. Not sure whether you use it but I have experienced some problems with the PublishQueueAsyncRK library that have been solved with the very latest release of this 0.1.2. I have found that it is very easy for the Cloud publish queue to fill and in 0.1.0 and before of this library this wasn’t being correctly handled. See PublishQueueAsyncRK publish hanging
I have also implemented a FRAM storage device on I2C to provide a reasonable size of publish buffer and for my critical sensor data a Mesh publish with ACK. This is necessary because I was seeing mesh publishes being lost - See Mesh pub-sub at the gateway
This weekend, I went and updated the other 2x “bad” devices via my PC. I downloaded the 4x files from the 1.4.2 release on Github and ran these commands:
- Put the device into listening mode (blinking blue) by holding MODE button
- Manually flash 1.4.2 bootloader:
particle flash --serial firstname.lastname@example.org
- Put the device into DFU mode (blinking yellow)
- Flash the SoftDevice:
particle flash --usb email@example.com
- Flash the System:
particle flash --usb firstname.lastname@example.org
- Flash Tinker:
particle flash --usb email@example.com
- Hold mode for 10 seconds for the core to begin blinking white for factory reset process
- Unclaim device in app.
- Claim the device in the app and connect to mesh network.
I’ve tried so many other processes in the past and this was the first one that worked. Don’t know if it was due to fixes in 1.4.2 or this is just the most thorough process, but I’m happy to say that I have all 10x of my Particle devices communicating to the cloud now.
I do the bootloader after the system-part (I think this is correct order of update?) and I don't bother with softdevice. I am now curious whether I should be - I understood that softdevice was updated automatically?
This Device OS release will automatically update the SoftDevice for devices connected to the cloud.
I’m no expert and I only did it this way because I wanted to make sure I updated absolutely everything to give me the best chances of success. Maybe someone from Particle can chime in on the recommended method.