We are having a livesite issue here, so please help urgently.
New devices being configured (connected, claimed, flashed) have the “current_build_target” set as 0.4.9. This change started sometime in the last 24-36 hours. I believe we used to have the build target set as 0.6.0 or 0.6.1 until very recently (devices configured early this week have this build target). The 0.4.9 firmware target breaks our current application and the devices get stuck indefinitely in safe-mode.
If we use the IDE and change the target to 0.6.0, the application is flashed correctly and the device comes back online. With 0.4.9 (or 0.6.2) as target, while it appears that the flash is successful, the device gets stuck in safe-mode.
Here’s an example of a new device with the build target set as 0.4.9
looping in @Dave in case he is aware of any rogue instance of the firmware endpoint.
Thanks in advance.
I don’t think this is a new behaviour - at least for Photon and Electron this has been the dafault behaviour as long as 0.4.9 was released.
Nevertheless defaulting to Default (x.y.z) (as set in Web IDE) would be a good idea.
Getting stuck in Safe Mode might be a misinterpretation of the Safe Mode Healer/Recovery to auto-update the device’s system firmware. Give it a few minutes to finish that.
current_build_target specifies what system version is currently on the device. You’re mentioning setting up new P1’s. It’s possible they still have 0.4.9 firmware that was flashed in the factory. Flashing a newer application (say targeting 0.6.0 or 0.6.1) would put the devices in safe mode but then immediately flashed with new system version via Safe Mode Healer. P1 should have SMH enabled but it’s possible that’s disabled in a product. Are those P1s part of a product? If no, can you PM me the device ID to see why SMH didn’t work?
We chatted about this internally, and @suda discovered that there was an issue with a service that automatically flashes updates to devices when they’re online in safe mode. We kicked that service and things should be operating normally again. We’re looking into why we weren’t automatically alerted and the service wasn’t automatically restored.
Guys, appreciate the fast response.
I will test and update with my findings.
Everything works great! thanks for the prompt fix - @suda and @Dave
Thanks for further looking into the issue. We only got notified when the users started reporting magenta breathing LED, which was not documented in our help sections, and unable to proceed.