Having trouble using two sensors with Argon

[firehazard]

Hi,

So, I’m trying to use the DHT22 and a PIR Motion Sensor with a single Argon. Neither of them seem to work. The PIR Motion Sensor just seems to regularly switch between outputting 1s and 0s, while the DHT22 sometimes seems accurate and sometimes jumps to outputting over 40C a bunch of times. I think it’s something to do with the Argon outputting only 3.3V. I’m not a hardware guy but I thought putting the two sensors in parallel would allow them both the voltage they need. I saw some stuff saying to use a resistor and I’ve played around with putting different resistors in but I’m making no progress.

Sorry, I just have no idea about this stuff. I bought an RPi Zero that I might use instead given it has two 5V outputs but this is a Uni project and since my proposal was to use the Argon (because it’s part of the lab equipment for the unit), I’d rather use that if possible.

These are the sensors:

DHT22 Temperature and Relative Humidity Sensor Module

PIR Motion Sensor - Large Lens version (Seeed Studio)

Here’s how the circuit is currently set up. This diagram uses a Photon because Fritzing doesn’t have an Argon, but otherwise it’s the same. The black thing is the PIR Motion Sensor because I couldn’t find something suitable in Fritzing.

The code I’m using on the Argon is here. It sends the data to a RPi and I’m currently just viewing it by having a script on the RPi print the data.
https://hastebin.com/xumejusuja.cpp

[gusgonnet]

@firehazard

the DHT22

Hi,
usually the DHT22 requires a pull up to VCC:

Comes with a 4.7K - 10K resistor, which you will want to use as a pullup from the data pin to VCC.

Maybe that will improve the readings.

For the PIR, when it detects movement, its output will switch to 1 for a period of time (few seconds, I forgot now) and come back to 0.
Then when it detects movement again, it will again switch to 1, and so on.
Are you sure it is not detecting you moving around?
Best

[peekay123]

@firehazard, everything @gusgonnet said. The DHT22 protocol is “bit-banged” which is susceptible to timing errors leading to false or invalid values. If you don’t mind “giving up” two GPIO pins plus a third for the actual DHT sensor, the DHT22GEN3_RK library uses the I2S peripheral and DMA to interface with the DHT22 without any bit-banging. For me, it has yielded very good and consistent results.

Additionally, I am not sure why you use “const” declarations for your local variables. These are stack-allocated variables which don’t have any scope outside their functions so “const” is not adding any value.

Also, in loop(), you may want to consider using “sprintf()” and C-strings instead of std::to_string() which uses dynamic memory allocation which can lead to heap fragmentation.

[DaveH]

How quickly are you polling the DHT22? I’ve seen issues with that (and the DHT11) if you poll more than once per minute. I get the same using a Pi.

Even then it can throw out the odd very high or very low reading. I usually wrap it in a bit of logic which says if the temperature is >100 degrees c or <-10, then ignore that reading.

[firehazard]

Thanks for the replies everyone.

usually the DHT22 requires a pull up to VCC:

I have tried that, by connecting the resistor to the vcc pin and the data pin but I'm not sure if that was the right place for it. I can give it another go.

Are you sure it is not detecting you moving around?

Yes, I faced it directly away from me and my room has nothing beside me moving around in it. I even covered it in a cardboard box for a few minutes and it still just regularly switches between 0s and 1s.

The DHT22 protocol is “bit-banged” which is susceptible to timing errors leading to false or invalid values. If you don’t mind “giving up” two GPIO pins plus a third for the actual DHT sensor, the DHT22GEN3_RK library uses the I2S peripheral and DMA to interface with the DHT22 without any bit-banging. For me, it has yielded very good and consistent results.

Thanks, I have plently of free pins so I'll give that a try. Do you have any links to guides or anything to get me started with that?

Additionally, I am not sure why you use “const” declarations for your local variables.

I've just adopted the convention of consting everything. It declares intent and means I don't accidently change variables I don't mean to . You can be sure that if something in my code isn't const that means it's meant to change. That's all there is to it really.

Also, in loop(), you may want to consider using “sprintf()” and C-strings instead of std::to_string() which uses dynamic memory allocation which can lead to heap fragmentation.

Well, I could be wrong but I think what I'm doing will benefit from small string optimization, so there won't be any heap allocations anyway. In Visual Studio's implementation of the C++ standard library, strings less than 16 characters are stack allocated. I'm compiling with VS Code and just assuming it'll be similar. Honestly, I'm not too concerned about performance anyway.

How quickly are you polling the DHT22? I’ve seen issues with that (and the DHT11) if you poll more than once per minute. I get the same using a Pi.

I'm polling ever 100ms so I can certainly try doing it less frequently. I'm only doing it so often because I need to detect motion so I thought I might as well just do the DHT22 at the same time. It won't be difficult to change the code a little and poll less frequently so I can try that.

Ok, because no one is saying that there's an issue with using two sensors, so I'll take that to mean it's a problem with how I have things connected or with my code. I'll try using a pullup resistor for DHT22 and poll less frequently. If that doesn't work, I'll try what peekay123 suggested. As for what to do about the motion sensor... well I still have no idea I'm afraid. I have tried using a resistor between ground on it and ground on the Argon but that didn't help.

Thanks everyone.

[gusgonnet]

@firehazard

Ok, because no one is saying that there’s an issue with using two sensors,

That, in general, is not an issue. One can find ways to connect multiple sensors to a Particle device.
Good luck and let us know how it goes!
Gustavo.

[gusgonnet]

@firehazard

As for what to do about the motion sensor… well I still have no idea I’m afraid.

it does not look normal behaviour that its output goes up and down...
May be a missunderstanding from the sensor datasheet (may be worth taking another look?) or a faulty sensor? Unsure

[dreamER]

Hi,
you can easily power up both, PIR and DH22 from 3.3V as shows in datasheet

and IMHO i don’t think that you need pull up resistor for DH22.
Also if your PIR (which is AD22100 in your pic) is facing towards to you I guess the GND and OUT is on the opposite side as shown on here.

Will be also easier for us to T/S when you can show your code
Best Regards,
Arek

[ctmorrison]

I’ll echo the need for a pull-up resistor on the DHT22. I’ve used them many times without issue, but always with a pull-up and had trouble without. Just use the resistor (10K) that’s normally included, as @gusgonnet suggests.

Also and FWIW, I always use the PietteTech_DHT.h library. Not knockin’ the Adafruit library, but I believe I had tried it in the past and had better success with the Piette version. As always, there are example apps and I’d follow their suggestions on declaring DHTTYPE and DHTPIN via #define statements.

[Zonker]

If the PIR sensor seems to be giving “false alerts”, consider whether there is any breeze around the device. Besides being designed for a “hot spot” to be crossing the detector elements (causing positive or negative signal spikes, which trigger the sensor circuit to then trigger the one-shot timer that gives you your output signal), these sensors are sensitive to drafts! Try it with a puff or breath if it seems to be stable, and see what happens. You may also have some other hot or visible light (tiny, neglectable to you) in the field of view of the sensor. Try covering the setup with a small cardboard box (weighted down to minimize drafts) and see if it becomes stable…

[friedl_1977]

Hi @firehazard -

It seems you have received a lot of good advice on this issue, so I will just briefly comment;

@firehazard

I’m polling ever 100ms so I can certainly try doing it less frequently. I’m only doing it so often because I need to detect motion so I thought I might as well just do the DHT22 at the same time. It won’t be difficult to change the code a little and poll less frequently so I can try that.

IMHO... I won't poll any DHT sensor that often. Doing this (even at 1s) has presented me with a number of challenges in the past. One can also ask the question, how often do you expect temperature to change, so is it necessary to do tis every 100ms. More often than not, if using DHT sensors, I would take readings every 10s or so. If you need faster readings (and it might have been mentioned before) you might want to consider switching to sensor using I2C like this one from Renesas

Best of luck!! Friedl.

[friedl_1977]

@firehazard

Seems I deleted part of my response

With regards to running multiple sensors; I am in agreement with the other posters here. There is absolutely no reason for you not to be able to run multiple sensors of a single Particle device. I am currently designing a PCB with 6 sensors running off a single Boron.

Cheers!

[DaveH]

I would say Particle hardware is designed for running multiple sensors.

My brief journey with Particle has been buying the Xenon and Argon mesh dev kit on the kickstarter style scheme they did, finding on first use there was a firmware issue and they didn’t really work well, putting them at the back of the cupboard and leaving them for over a year.

Meanwhile, I’d been looking at various other projects, the most complicated was a solar power soil moisture sensor, with the moisture sensor itself, a solar panel and INA219 board to measure incoming charge, BME280 for pressure, humidity and temperature (better than DHT22 by the way), plus monitor the battery charge status. I’d tried with a Wemos D1 Mini but even with deep sleep mode, I got very poor battery life, just a few days. Got the Particle devices out the cupboard again, updated the firmware and never looked back. Started getting months out of a battery, which could be measured and charged directly off the board. They are now deployed and letting me know how my veg patch is doing while I’m away at the moment,

I had been reluctant to use some boards as I felt that it was overkill using a Xenon in small projects, and looked at the D1 or Arduino nano. With the memory and processor, they can do so much more. They cost more, but after being able to pick up more really cheap on eBay, they are now my first choice for a project.

My feeling is, they can cope with loads of sensors, you don’t need multiple devices if you have multiple sensors.

[friedl_1977]

@DaveH

100% agree… they can easily handle multiple sensors.

Sounds like a good project you have going I loved Particle Mesh, was really sad to see it deprecated.

Regards, Friedl.

[DaveH]

I’m working on a small test project and to throw a sensor into the project to get some real data in, I used a DHT22. I was finding that the DHT22 occasionally give a ‘nan’ (not a number), which was messing up results. I’m using a module which has a couple of resistors added but still I get the rogue value. It seems better using the internal pullup, but also having some error checking.

A very condensed version of the code is:

#define DHTPIN D3
#define DHTTYPE 22
DHT dht(DHTPIN, DHTTYPE);

float temp=0;     // Global for storing temperature
float humid=0;    // Global for storing humidity
void setup() {
  pinMode(DHTPIN, INPUT_PULLUP);
  dht.begin();
}

void getTemp() {
  float tempIn = dht.getTempCelcius();
  float humidIn = dht.getHumidity();
  // Sometimes the DHT22 can give an error, only update temperature if 
  // we have something sensible
  if(!isnan(tempIn)) {
    if(tempIn>-20 && tempIn<100) {
      temp=tempIn;
      humid=humidIn;
    } else {
      Log.info("Temperature out of range, ignoring (%f)", tempIn);
    }
  } else {
    Log.info("Generated a nan value for temperature, ignoring");
  }
}

Within the loop, it calls getTemp every 60 seconds.

It is possible the INPUT_PULLUP causes a conflict with the DHT library, but it doesn’t seem to break anything. I still get the odd ‘nan’ value thrown, but when I’m polling every 60 seconds, I can ignore until the next cycle.

I did use something similar on a battery operated project and deep sleep, but decided to back off for 10 seconds, try again, on failure back off another 10 seconds, have one last try and then not bother and sleep again.

This project doesn’t seem to be throwing anything out of range but I have seen issues before where it suddenly reports a really cold or really hot temperature, which is why I have a range check. Another alternative is to check for a change of 20 degrees to the last reading. That can cause problems if your first reading is the wayward one.

Basically, a DHT22 (and I suppose any sensor, but particularly these) can throw occasional errors. The best advice is find ways to live with it.

[friedl_1977]

@DavidB -

I have had the exact same issue regardless of what my polling time was. I have used different dashboards and different payloads but on all of them encountered this rogue value.

IMHO the DHT sensors are easy to use for prototyping or maybe some projects where these values won’t cause any plane crashes, but usually my data is more mission critical so I have opted for other sensors using I2C as mentioned in my first post. The Renesas HS300x sensor has been serving me well and quite easy to implement.

Cheers!

[firehazard]

Hi everyone,

Thanks for all the replies and sorry I haven’t said anything for a while, I was focusing on finishing my assignment on time. I was able to get the DHT22 to work much better with a more powerful resistor than the one I had tried before. It still outputs occaisonal 0s but I was able to just have the code ignore those.

I didn’t manage to get the PIR motion sensor to work. However, I wrote some tests to send data to my app without the Argon and sensors, so I didn’t need everything to work to test it. Hopefully that’s good enough for the markers.

[friedl_1977]

Hi @firehazard -

Seems you are sorted, glad to hear

Regards, Friedl.

[jverive]

The datasheet cautions that the collection time (time between readings) should be at least two seconds. Shorter time periods can result in “NaN” because the analog to digital conversion may not be completed yet, so the output data register is likely to have invalid data.