hello,
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
thanks
frank
Hi Frank-
Can you DM me the device id?
Thanks,
Colleen
@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.
Hi @bfernandez , @boddeke , and @Colleen
This looks very similar to the issue reported here.
FYI then.
The original user did not send over the device ID so this fell off my radar. This does sound similar to the issue @gusgonnet pointed out.
@lanceseidman do you have a fix for this?
Is there a reason you need to upgrade to 3.x? The recommended version for Gen 2 devices is 2.x LTS, so 2.3.0.
Now that Device OS 5.0.0 has been released, the 3.x developer preview release line is now closed and will no longer have any updates, even security updates.
Gen 2 devices including the P1, Photon, and Electron/E Series cannot upgrade to 4.x or 5.x, however.
Device OS 2.x LTS, such as 2.3.0, however, will soon enter the extended security maintenance (ESM) phase when Device OS 4.0.0 final is released. This will extend for a minimum of one year.
If the issue is the same as the one I (and others) faced, the problem appears in DeviceOS 2.2.0-rc.2 and onwards.
So maybe the safest bet here is 2.1.0.
hi rickkas7,
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?
where can we find this kind of information?
thanks,
frank
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!
The two relevant references are:
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.
The P2 requires Device OS 5.0.0 or later.
This doesn’t explain the issue with gen2 devices on os 2.2.x and later, which should be LTS.
thanks, that makes it clear
it is unfortunate that this “green” problem will not be fixed for the p1. it is confusing for customers
is there a work around?
thanks
frank
The SoftAP breathing green issue does appear to be a regression in 2.2.0 and later. Because of this, probably using 2.1.0 makes the most sense on the P1.
There are no security fixes in 2.1.0 to 2.3.0, so there is currently no harm in using 2.1.0.
If we did have to release an ESM security fix in 2.x, there are a few possibilities:
(These are all hypothetical. There is currently no plan to make any more 2.x releases.)
@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.
how do we het devices in the field to downgrade?
thanks
frank
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:
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.
thanks rickkas7, makes sense but good to know.