we have a product with a p1 and recently update to device os 3.2.0. sometimes (particularly after wifi listen) the device will breath green although it is connected to the cloud. (previously we were on 2.0.1 and did not see this)
anyone any idea why this is and how to fix this. it is kind of confusing to our customers/helpdesk
@Colleen Were you guys able to figure out what was causing this. I am having the same issue with devices breathing green when claimed and coming out of listening mode to connect to the internet. Device connects to the cloud flashes cyan then breathes green. Device can be controlled from the particle console and seems to be connected like it should. We recently moved from OS 1.5.0 up to 3.3.0 and we did not have this issue in the past.
i am a bit confused now: we have p1 devices out there and will have p2 devices soon. first i assumed all would be running the latest deviceos but earlier already understood that p1 whould need < 4.x and p2 needs >= 4.x. that is okay.
now you are saying we should not use 3.x on p1? (why is there a 3.x?) for p1 devices we should be using 2.3.0?
the problem is very annoying and confusing for customers using the device: help desk: “what color is de led”, customer: “it is green”, help desk: “oh, then you have no cloud connection”… and if we need to run 2.3.0 on gen2 devices because of security if will basically never get fixed… i would say this is not an acceptable situation!
Odd numbered releases (3.x, 5.x) are developer preview releases and contain breaking changes, new platforms, and major features. For example, on Gen 3 devices, 256K user binaries, and support for the Tracker platform.
Even numbered releases (2.x, 4.x) are LTS releases. These only have changes necessary to fix bugs, and go through additional testing. They are also supported for a minimum of two years, one year of LTS and one year of ESM, though these timelines may be lengthened.
When a new LTS is created, it’s based on the prior developer preview release. So 4.0.0 was based on 3.3.0.
The situation with Gen 2 is somewhat unusual. Support for Gen 2 was removed from 4.x and 5.x because the MCU on these devices (STM32F2xx) is no longer available. Also the networking architecture on Gen 2 Wi-Fi and cellular devices is completely different than Gen 3, and the limited amount of flash on Gen 2 makes adding new features impractical.
Using 3.1.0 or later on a Tracker is required, and may be useful on the Argon/Boron/B Series SoM because of the 256K user binary support.
While it’s true we built Device OS 3.x for Gen 2 devices, there were very few changes that were not back-ported to 2.x LTS, so there is typically not a compelling reason to use it.
@rickkas7 Ok, I will roll back to 2.1.0 and see how it goes. At the very least this post provides a clear and concise place to answer this question. As usual thank you very much for your help. You are the man!
because of this “breathing green”-problem we set our target device-os back to 2.1.0. but we now notice that devices which previously had e.g. 3.3.0 and get this firmware are not automatically downgraded tot 2.1.0.
Unfortunately there is no automated way to downgrade devices by OTA. The problem is that the method used to upgrade (safe mode healer) only ever upgrades, because Device OS is intended to be backward compatible with firmware that targets previous versions.
The process to downgrade OTA involves sending the Device OS parts to each device, and doing it in the reverse order. So you’d flash:
2.1.0 System Part 2
2.1.0 System Part 1
After each flash you need to wait for the part to be loaded and the device to reboot and reconnect to the cloud. This is most easily done by monitoring its event stream.