A lot of times the Xenons would reconnect just fine but a lot of times some or all of them would not.
It seemed to me that after the Boron would reset or loose it's cellular connection for a min and then reconnect that the Xenon's would not get updated on something and then would start flashing Green until reset manually. I created the code I shared with you to reset them without touching them and it always worked.
I have not tested with any of the last 5 Device OS software releases so I was hoping that issue would have been fixed by now but you may be seeing the same thing.
Youâre welcome. One recommendation I would make for someone moving from Python to embedded C++ is to think of your code as a process and not a script. Scripting encourages things like delays and linearly dependent paths, whereas a process needs to maximize value out of system resources (like time & memory) and needs to be able to self-manage. You can then think of your smaller system components (functions, classes, blocks of code) kind of like sub-processes. Think, âwhat are the conditions where this needs to be running?â and âwhat is the priority of doing this relative to other things?â.
Think of it like asynchronous code where somethings are linearly processed but other things require checking in to see if the result is available or if a state has changed outside of your control. Doing these things will help you properly modularize your code and reduce unnecessary dependancies.
Using classes and functions to formalize interfaces where information and other dependencies are shared is a great way to keep things organized. Be careful with global variables and where you use them. Debugging complex interdependent embedded code is a PITA, so breaking things down into units and also running the units in independent ways whenever possible will save you a lot of headache.
Iâm pushing mass OTA updates to all of the edge devices, and it takes 5+ minutes for them all to reconnect. That is definitely taking longer than I was expecting.
How long does it take your for the device to reconnect after the update?
I just did another large push, and that was at least 10 minutes. I just left with some still trying to connect. Iâll come back and see if they sorted themselves.
Didnât really test very much after a OTA update since when I was testing the OTA success rate was no where close to 100%. Hoping that has improved some since I was testing.
Does the MESH Publish & Subscribe still work even though itâs flashing green?
Yea, usually the Xenonâs would connect to the MESH network just fine even with the flashing green LED status which just means the Xenonâs do not have a direct Internet connection through the Boron or Argon.
As long as you have that MESH connection you should be able to send a publish to reset them via code which for me would always bring the Xenonâs back online to a breathing green status.
@emile Remember this post was back in May and in the days of 0.8.0-RC.26 etc. with OS 1.4.2 it is much, much better.
Seeing what you are trying to do; I have a gateway command that if I need to OTA a sleepy endnode (which is only Mesh network) will queue a command (Mesh publish) to the endnode that when it wakes for a regular check-in will receive the command and set itself to receive updates and Particle.connect() after the update it will reset and it is back to Mesh network only operation. It is slow though and updating 50 endnodes will take quite a while!