I received my package of the Particle Mesh devices recently, and used the same code I had functioning for a Photon + DHT22 sensor for my Argon and Xenon devices. If I use the exact same sensor that I have on the Photon, wired up the same way (same pins), etc, same code–the sensor does not read any data (all 0s). I’ve gone back and forth to confirm between the Photon and the Mesh devices, thinking somehow my sensor was bad, but no luck–Photon always works, Mesh devices don’t. Do you have any suggestions what could be causing it? With the Photon I was able to power the sensor off of two of the digital pins (one high and one low), with a 3rd pin for the data. With the Mesh devices I’ve tried both ways–powering from the digital pins as well as directly off of the 3.3V and GND pins.
Without seeing your actual hookups or looking at some code, it’s hard to make any recommendations. Can you post a picture of your setup and your code?
Are you using the PietteTech_DHT library? This is the most commonly used library for the DHT sensors, as far as I am aware. This library uses interrupts to function. However, interrupts function differently between the STM32F (used on the Photon) and the Nordic (used on Argon, Boron and Xenon) processors. It is very likely that this library would need to be updated to work with the mesh devices.
Maybe another library that does polling instead of using interrupts may work?
Since the new devices are meant to be low-power, I would suggest checking the datasheets to see if they are capable of supplying the power needed for the DHT22. I have not received my mesh devices, so have not yet looked at this aspect.
@ninjatill DHT22 sensor with output connected to D5 (this unit has a built in pull up resistor), sensor is powered directly from 3.3V and GND pins. I’m using the Adafruit DHT 22 Particle library, I’ve also tried the standard Adafruit DHT22 library as well.
@cyclin_al I’m using the Adafruit library, but I can imagine that probably the same issues exist. This is a great explanation that I wasn’t aware of–I’m excited that the new Mesh devices are lower power, but also a bit disappointed that the compatibility isn’t there.
It should just be a matter of patience. All the libraries need to be checked, and in any case where they no longer function, the library needs to be “ported” to the new hardware platform. In theory, this is the responsibility of the library owner. There are a few cases where porting will not work; for example the new processors to not have built in support for CANbus.
In the distant past, it was the same situation where the libraries had to be developed when the Photon and Electron were new.
I’m currently testing
PietteTech_DHT library with mesh devices and in general this library works.
One minor issue I’m currently seeing, but haven’t found the reason yet.
When I power-up the device for the first time the results are always -5 (aka DHTLIB_ERROR_ACQUIRING) but after a reset everything works as expected.
Search for cause and cure ongoing.
That’s fantastic to hear! I’ll try that library and see if I can get it working.
I’ve had similar issues, one work around I’ve found is to to power the DHT22 from the 5v USB pin. They still occasionally read -5, but good readings are far more constant.
(YMMV, I’m as green as they come)
The Mesh devices are NOT 5V tolerant like the Gen 2 (Photon, Electron) devices so this is not an option. Only a 3.3v supply can be used unless a level shifter (5v to 3.3v) is used.
In this case, I’m powering the Xenon from the usb port, and then jumping off the USB pin to the hot bus on the breadboard. Measures 4.85v.
Is this a bad thing using the USB pin in this way?
@okeefe, as long as you don’t present more than 3.3v to any Xenon pin, that’s fine. I would suggest, instead, to use the 3V3 pin for your breadboard hot bus to prevent any possible damage.
I have just pushed an update to the PietteTech_DHT library (now v0.0.6) to work around this issue
Hello @ScruffR thank you for your help here. Life got in the way and I’m just coming back around to getting this set up–I’m using the Particle Web IDE and the PietteTech_DHT library, with an Argon updated to the latest 0.9.0 device OS. When I try to use any of the examples in the library, I get an error “sigPin was not declared in this scope”. I’m a bit confused since it seems like others have had success with this library–do you have any suggestions?
Have to try (again)
Might be that a recent change to counteract a possible race condition broke something.
Till I can fix it, you should be able to use the previous version 0.0.7
I was using the PietteTech_DHT library last night on a Xenon and it was working. I have not tested on an Argon.
Yup, that was before I pushed the borked v0.0.8
I just published 0.0.9 which should work again
You may need to use in Web IDE to see the new version
Bingo, works great now. That was fast! Thanks for the help.
I’m not sure what I’m doing wrong here, I’m trying to get the PietteTech_DHT library working with a DHT22 on a Boron running 0.9.0 system firmware. I see PietteTech_DHT version 0.0.9 in the IDE, and am using the Simple example, but it always returns -5 when requesting DHT.getFahrenheit(). DHTPIN is A0 if thats a factor.
When I look in the PietteTech_DHT.h file, it says it’s version 0.0.7
Is there something else I need to do? I already did the Clear Cache trick…
That was an oversight when pushing another fix I forgot to nudge up the “internal” version number
I haven’t tested on A0 but some other pins and do see “regular” failures due to this (not yet resolved) issue
OK, longer wires should do it! I just jumped it back to D3 and its working. Thx @ScruffR