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

Firmware Libraries
21

Photons shouldn’t be too problematic rolling back (1.1.1 - I couldn’t find an official 1.2.0 release).
Just download the system binaries part1 & part2 from here and apply then via DFU Mode

particle flash --usb tinker -v
particle flash --usb photon-system-part2@1.1.1.bin -v
particle flash --usb photon-system-part1@1.1.1.bin -v
1 Like
22

OK, another challenge:

  • I have installed the CLI and DFU software for OS-X, then downloaded and unzipped the three files.
  • Then I put my Photon in DFU mode and run the tinker flash command:
particle flash --usb tinker -v
  • That flashed OK.
  • Then I run the next command:
particle flash -usb photon-system-part2@1.1.1.bin -v
  • A red error message appeared in the console: "Unknown arguments ‘u, s, b’ "
  • I modified the line with two hyphens instead and launched it…
particle flash --usb photon-system-part2@1.1.1.bin -v
  • Now a different red error message appeared in the console:
    “Error writing firmware: file does not exist and no known app found.”

So, I assume I should put the downloaded files in a specific location…

23

Of course, you either need to run the command from the location where you unzipped the file to or you need to provide the full path to the command.
I thought that would be obvious - how would CLI know where to find the file?

1 Like
24

Yes, of course, I was also wondering... :slightly_smiling_face:
I looked up the documentation and found no description of how to do that.
I'm only 65 and still trying to learn...

I unzipped the files in the "Downloads" folder, so that was open...

25

Did you cd into your Downloads folder in the terminal you were running the command from?
Alternatively you can run the command like this

particle flash --usb /yourPathToTheFile/filename.bin -v

That would be a matter for the docs of your host computer's OS.
File handling is foremost dictated by the OS and any application running on that OS should/would adhere to that.

e.g. in Windows the command above would be written slightly different

particle flash --usb C:\yourPathToTheFile\filename.bin -v
1 Like
26

OK, I was indeed in the downloads directory in terminal:
“MB-Air:downloads fidel$”

And when I tried again all files flashed OK.

When I checked the Console tho it was still on v. 1.4.2
In the Particle App it was in v. 1.1.1.
I flashed my old sketch with the old Piettetech_DHT library to that Photon using Particle Dev and all works again now!!!
Hurah!
:relaxed:

Thanks again for your help!

27

Is there a way to do this “Rollback” remotely, without having to press buttons and connecting through USB?
(Some Photons are in places which make this difficult...)

28

You can use CLI OTA just the same
particle flash <deviceID> system_part.bin

Just make sure to first flash an application that is targeted at (or below) your intended device OS version.

1 Like
29

@FiDel, I have tried the DHT_simple.ino sample and cannot reproduce your issue. I do get correct readings.

30

Maybe you can give this a try?

It's a part of my "room control" sketch, which has now been working since more than 3 years, until my "Photons orchestra" upgraded to the latest OS.

Now that I rolled-back to 1.1.1 they all run this sketch again, with the old Piettetech library, successfully.

I remarked that not only the DHT sensors stopped working, but also the DS18B20 ones.
The latter only fails if these sensors are used together with the Piettetech library on the same controller. In a sketch where DS18B20 sensors are used but not the Piettetech library, all runs OK with the latest OS.

This is really a major problem for my whole "carefully crafted" system.
If the issue is not solved, I may be stuck with v. 1.1.1. forever...

If you want a sketch where both DHT and DS18B20 are used together, I could distill it from one of my sketches.

31

You are not calling DHT.begin() in setup().
This was a requirement introduced some time before 1.2.1-rc.3 where the use of pinMode() and digitalWrite() became “illegal” in an object constructor (v0.0.8)

With 0.0.11 you should also have a delay(1000) after that, with 0.0.12 I’ll have that already incorporated in DHT.begin().

Additionally, this syntax has been outdated for years now

  Particle.variable("ROOM_Temp2", &ROOMTemp2, DOUBLE);
  Particle.variable("ROOM_Humid", &ROOMHumi, DOUBLE);
  Particle.variable("ROOM_Tout", &ROOMTout, DOUBLE);

this would not be written simpler like this

  Particle.variable("ROOM_Temp2", ROOMTemp2);
  Particle.variable("ROOM_Humid",ROOMHumi);
  Particle.variable("ROOM_Tout", ROOMTout);

Also, any variable that should store millis() values needs to be declared as uint32_t and not as int.

1 Like
32

Thanks for these remarks ScruffR!

I have edited my example sketch with those three points and as far as the DHT sensor is concerned, all works normally with your updated library 0.0.11 and OS v. 1.4.2!

Edit: Also my complete roomsketch works again (with DS18B20)

I would never have been able to solve this problem without your help…

2 Likes
33

@ScruffR, Just a quick Thanks! for resolving this issue. I have several devices in the field that use this library and I was moving to a new cloud service and updating my application. It compiled just fine, but got stuck on the DHT.acquireAndWait() when running. As usual, your commitment to users on this forum is amazing and I was able to benefit from the above thread as well. Thanks, again!

1 Like
34

Thanks Tom :+1: :blush:

Does this mean the lib doesn't work correctly for you?
I thought I tested all the samples :flushed:

35

Well…I wasn’t doing the DHT.begin() in setup() and that was my problem. I hadn’t updated the code from 0.7.0 and had just moved to 1.4.3 when the problem surfaced.

2 Likes