PietteTech_DHT causing SOS 14 flashes on v1.2.1-rc.3

Tags: #<Tag:0x00007fe2259bc648>


It seems as though DHT.acquireAndWait() is causing issues on an Argon with Device OS v1.2.1-rc.3. I was able to reproduce the issue even with the DHT_simple example from the library. Whenever this line is executed, the device begins an SOS red led sequence with 14 flashes following the SOS. Has anyone else experienced this?


That is a very strange panic code for that library


The library doesn’t really have any busines with that.

Have you tried with any other device OS version?


Yes. It doesn’t have the same behavior on 1.1.0-rc.2 with the same example (or custom firmware).


Can you file an issue report at https://github.com/particle-iot/device-os/issues about that, please?

You may need to reference this thread and explicitly state that it’s not an issue with the library as it used to work prior 1.2.1-rc.3


Issue created: https://github.com/particle-iot/device-os/issues/1835

Thank you, @ScruffR.


Just got the same issue after updating my Argon to V1.3.0-rc-1 from V1.1.0


Hi there, I’ve been brought to this thread by a similar issue on my Photon.
I’m using the PietteTech_DHT library on a suite of Particle boards including Photons, Xenons and an Electron. The Photon in question just updated from 1.1.0 to 1.2.1


I have this issue on a Photon, is there a code fix that solves this issue ?


You could try the proposed workaround in this PR

I’m still waiting whether Particle is providing a detachInterrupt() variant that can be called from an ISR before considering an update to the library really.


The workaround worked for me. Thanks.


I believe I have now also experienced this “Panic, 14” issue with several Photons in my network, using this Piettetech_DHT library.

This is how it is in one sketch:

void ReadTempHum()  {
    dhtTemperature = DHT.getCelsius();
    dhtHumidity = DHT.getHumidity();
    dhtDewpoint = DHT.getDewPoint();

Or in another sketch:

void ReadTempHum() {
  int result = DHT.acquireAndWait(1000);
  ROOMTemp2 = DHT.getCelsius();
  ROOMHumi = DHT.getHumidity();
  ROOMTdf = DHT.getDewPoint();

None of these work!

It started after upgrading them to Device OS v. 1.4.2 (From v. 1.0.1)

Could this library be updated to work with the latest OS or is there any other idea to make this work again?

I also saw this thread , also about this library, but it’s not clear what the options for me are now…

This is a really disturbing problem for my whole home automation system as all Photons in use are going to be affected whenever I may decide to update user software on them …


As I don’t see any progress on the underlying issue - despite it beeing considered a bug in the device OS - I may have to (begrudgingly) incorporate the workaround provided in the link pull-request by rgiese although I won’t be able to test for any adverse side-effects.


Yes, I understand that this is not the most logical way to act, but I would be grateful to be able to test it!

Suggestion: Maybe we should clearly identify that library as a (temporary?) variation by giving it another name: “Piettetech_DHT-No-Panic” … :wink:


I’ll rather not create an entirely new library name but rather use compiler directives to conditionally apply the workaround depending on device OS version.


For me any fix will be great Andy, thanks!


I have now published v0.0.11v0.0.12 of the library - this should fix the SOS+14 issue.
Can you please give it a try and report back?


OK thanks!

I looked for your modified version and found this version. Is this correct?

I have flashed my application (which worked fine for 3 years) with this new version using Particle Dev:
The Photon runs without red panic flashes now.
But, the values of temperature and humidity remain at “-5” all the time now…

It looks indeed like these changes have negative side-effects…
I will do a few more tests tonight.


Hey Andy, I found your latest version PietteTech_DHT (0.0.11) also in the Web-IDE now and the results when I use it to flash my sketches from there are the same, unfortunately…
Here is a simple example of what I used a long time.



I feared this might happen - I guess I will have to cobble together a test rig but I can’t promise any time frame.
For the time being you may need to stick with 1.2.0 or before.


I studied earlier how I could roll-back to an earlier version OS but i’m afraid of “bricking” my controllers when I read some stories…
Can you recommend me a simple and safe way Andy?