Project

General

Profile

Resolved: pir problem

Added by lrueter about 6 years ago

Hi,

I am struggling with the PIR on a room board that I have bought 2 weeks ago.
The issue is very similar to the one described in a previous post here:
http://webcache.googleusercontent.com/search?q=cache:forum.jeelabs.net/node/1454

When the room-node starts and nothing is moving, then it reports all 5 minutes, with no motion. => OK
When there is a motion, then it reports the motion. => OK
When there is no other motion, then the room-node reports every 5 minutes a motion. => wrong

There was a fix submitted for this issue
https://github.com/jcw/jeelib/commit/f421d56e7bea3c129dda2d29216942ffe2af206e
and I am using the latest roomNode sketch but it is still not working for me.

I am using the following settings in the sketch:

#define SHT11_PORT 1 // defined if SHT11 is connected to a port
#define LDR_PORT 4 // defined if LDR is connected to a port’s AIO pin
#define PIR_PORT 4 // defined if PIR is connected to a port’s DIO pin

#if PIR_PORT
#define PIR_HOLD_TIME 30 // hold PIR value this many seconds after change
#define PIR_PULLUP 1 // set to one to pull-up the PIR input pin
#define PIR_INVERTED 1 // 0 or 1, to match PIR reporting high or low

I have tried changing the PIR_INVERTED value to 0, but the issue remains the same.

I have attached images of the serial monitor, the housemon status and the board.


Replies (12)

RE: pir problem - Added by martynj about 6 years ago

@lreuter - approximately what date was your order for the PIR?

RE: pir problem - Added by lrueter about 6 years ago

Hi Martyn,
it was ordered on 18. December 2012 (sorry more then two weeks ago) order #8431

RE: pir problem - Added by jcw about 6 years ago

This appears to be a new issue. The roomNode sketch always reports a packet once every 5 minutes (#define MEASURE_PERIOD 600), but the motion bit should be off. Motion is reported in a different way: right when it happens, a packet is sent out with the ACK bit in the header set - so that’s another way to distinguish motion packets from the rest.

I’ve added an issue on github for this, to make sure it doesn’t get lost - https://github.com/jcw/jeelib/issues/39

RE: pir problem - Added by padvinder95 about 6 years ago

Could you attach your complete roomNode.ino scketch?

RE: pir problem - Added by padvinder95 about 6 years ago

Hmm, maybe you could change the measurement period to 5s (#define MEASURE_PERIOD 50), enable debug and show the output on the Serial monitor? That might give some more clues.

I don’t use the roomNode sketch myself and I must admit I don’t fully understand your serial monitor output in Housmon_2.png: I thought the scheduler.pollWaiting would sleep until the next event. With report_every set to 5, there should be 5 or 6 dots between every “ROOM 207 1 xxx” message. This could just be from RFM12 interrupts, though (other nodes sending messages on the same group, but not meant for this node).

To verify whether your PID module itself is working correctly, you could put a very simple test program on it, something like this:

#include 
#define PIR_PORT 4
#define PIR_PULLUP 1
#define PIR_INVERTED 1

Port pir (PIR_PORT);

void setup (){
  Serial.begin(57600);
  Serial.print("\n[PIR tester]");
  pir.digiWrite(PIR_PULLUP);
}

byte characters = 70;
void loop(){
  Serial.print(pir.digiRead()^PIR_INVERTED);

  if(characters--==0){
    //wrap lines
    Serial.println();
    characters = 70;
  }
}

Don’t move, see a train of 0’s; wave your hand a bit and see some 1’s. Stop moving, see 0’s (maybe after a while: most PIR sensors have a hardware hold time built in). If this works, at least you can be sure the sensor is working alright and it must be something with the code.

RE: pir problem - Added by lrueter about 6 years ago

I have attached the modified sketch with (#define MEASURE_PERIOD 50) and the corresponding output.
After the first motion was detected the regular packets always report a motion. Even after prolonged periods with no motion.

The test program from the last post reacts on each movement in front of the PIR sensor.

#define PIR_INVERTED 1
[PIR tester]11111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111

produces 0000’s when movement is detected

#define PIR_INVERTED 0
[PIR tester]00000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000

produces 1111’s when movement is detected

RE: pir problem - Added by lrueter about 6 years ago

After seeing the test sketch output I have changed PIR_INVERTED from 1 to 0 in the original github sketch. Now the output looks like I would expect it (attached).

My apologies! I was 100% sure I have tried that setting yesterday without success.

Thanks for everyone’s support!

jcw - I think that github issue can be closed https://github.com/jcw/jeelib/issues/39

RE: Resolved: pir problem - Added by jcw about 6 years ago

Great to hear that this has been resolved, I’ve closed the issue.

RE: Resolved: pir problem - Added by lrueter about 6 years ago

Even though this issue is resolved i am adding some more pictures of the PIR board to make it easier to identify the type of PIR board used.

RE: Resolved: pir problem - Added by padvinder95 about 6 years ago

By the way, I think you can/should also set PIR_PULLUP to 0: since the PIR sensor is providing a logical HIGH when it detects movement, you don’t need to also add a pull-up—if you’re unlucky it could even change the “0” output of the PIR to a “0.1” (I don’t know what output drivers are in the PIR).

@Martynj/jcw: Would it be an option to include a slip of paper with each PIR sold through JeeLabs that has some info on the PIR: active HIGH or LOW, or even 2 lines that reflect the proper #defines, e.g.

#define PIR_INVERTED 0
#define PIR_PULLUP 0

? (I’ve seen one or two more messages on the forums asking about the proper settings for the PIR, so it seems there’s some confusion.)

RE: Resolved: pir problem - Added by lrueter about 6 years ago

padvinder95 - good idea! It certainly would have helped me. I changed the values as suggested and initial tests show the expected output. Thanks!

#define PIR_INVERTED 0
#define PIR_PULLUP 0
    (1-12/12)