It is so demoralizing not being able to have all the other would-be improvements in the new version because the thing randomly fixates on eternal-seeming flashing green in certain unpredictable occurrences before a power cycle, such as right now when I just said to myself, “hell, why don’t I try 2.0.0 rc4”, and after flashing systempart1 and tinker, it is now flashing eternal green, having been connecting perfectly on 1.5.4-rc1 which preceded, and I guarantee if I power cycled right now it would connect.;
Does Particle acknowledge that this has happened and is absolutely the direct and proximate result of a software change they made, or does Particle not even have the business wherewithal to realize that this business-killing bug is currently re-introduced after having been fixed in 2019.
I am beyond any willingness to handhold with tests, detailed descriptions, diagnostic logs, etc. I am not on Particle’s payroll. By far enough information has already been posted on these forums.
Does Particle acknowledge the 2020 reintroduction of cellular reconnection killing misbehavior, previously having been fixed in 2019 (before it was caused by a memory leak) and is working on a fix?
UPDATE: After multiple solid minutes my 2.0.0rc4 just connected. This never happened before - before it would connect in 30 seconds. Even if the bug isn’t a reintroduction of the eternal no-connect, it is a significant degradation from 1.3.1-rc1 through 1.5.4-rc in reconnection performance.
We are working hard to make LTS (2.0.0) a game-changer when it comes to reliable connectivity.
Our Device OS team took a look at your devices and have found one Boron that has had two Cloud connections on 2.0.0 - one connection was 25 seconds, the other was indeed almost 5 minutes. We definitely want to investigate that 5 minute connection! If you could DM me the Device IDs you’ve been testing on, that would at least help our Engineering team confirm that they are investigating the right device.
Ultimately, we do need device-side logging in order to assess and take targeted action. I understand that sourcing logs is a time-consuming endeavor, and I ask you to please reconsider attempting to produce logs using the SerialLogHandler logHandler(LOG_LEVEL_ALL) Device OS API and the particle serial monitor --followCLI command.
I appreciate this @marekparticle I can report that the Device ID that had the 5 minute connect today was e00fce68f159b5fc1c206d36
But there have been other devices (I don’t know which) which have formed my observations and the majority of datapoints I have probably aren’t datapoints that ever made it to your server.
Hopefully I will be able to join your " particle serial monitor --follow" recommendation with another happenstance occurrence so as to be able to give you meaningful logs.
I did downgrade to 1.5.4-rc2 but I’ll try the 2.0.0-rc4 upgrade again and see if I can get anything useful your way.
P.S. I signed up for the bounty program and am reassured that Particle is taking action to improve stability. Thank you.
Thanks @Paul_M. Please rest assured that you can always reach out to me if you need help acquiring those logs and please be aware that your report here had the full attention of our DeviceOS team this afternoon.
If you’re so able (it ideally shouldn’t take more than 20 or so minutes), we would request:
a) upgrade to 2.0.0-rc4, with app firmware running the serial logger API referenced above
b) document (if possible) one connection attempt that takes around five minutes - if it’s easy, we’d be pleased to receive a second - using the particle serial monitor --follow call in the CLI
c) downgrade back to 1.5.2 (or .4, as you like - whatever you have been able to use that allows you to connect successfully) with app firmware running the serial logger API referenced above
d) document 5 or so minutes of successful connection attempts using the particle serial monitor --follow call in the CLI
Again, I’m just a DM away and will do my best to prioritize help getting you set up for logging!