gpio as input for PIR

[geronimobb]

Hy,

I'm using a pin as input, connected to a pir. Which is working fine in general. However when in off state, now and then it reports again it's in off state. The log gives me:

2015-02-05 19:38:10 GPIO: Interrupt for GPIO 25 already queued. Ignoring...
2015-02-05 19:38:10 GPIO: 1 interrupts in queue.
2015-02-05 19:38:10 GPIO: Acknowledging interrupt for GPIO 25.
2015-02-05 19:38:10 GPIO: Processing interrupt for GPIO 25...
2015-02-05 19:38:10 (Raspberry GPIO) Lighting 1 (Pir_Hal)
2015-02-05 19:38:10 GPIO: Done processing interrupt for GPIO 25.

Since my alarm system reports every time a PIR has reacted, i keep receiving reports the alarm is closed, when the pir repeats the off state. I use most of the other gpio's as outputs, to switch lights. I do see it is happening with a bigger chance when i press these output gpio's.
I'm not sure if the pir is the cause (Bosch PIR), or the raspberry who possibly interrogates it's inputs on regular times, or something else.
Anyone any idea?

Grtz.

[Conn-artist]

Hi,

Anyone any idea?

How did you configure the interrupt 25? Each GPIO can be configured to throw an interrupt on high/low/rise/fall/change.

If yours is configured to throw an interrupt when the signal is 'low', you may have success if you change that to 'fall' - assuming the GPIO pin is normally held in the high state by a pull-up resistor or something.

[klaaas]

my 2 cents from the manual

$ man gpio

edge This exports a GPIO pin in the /sys/class/gpio directory, set the direction to input
and set the edge interrupt method to none, rising, falling or both. Use like the
export command above and note that BCM_GPIO pin number is used not not wiringPi pin
numbering.

[geronimobb]

Hello, thanks for the replies

I have them configured as:

gpio export 23 in
gpio edge 23 both
gpio -g mode 23 up

I think the first is not really needed. It doesn't make a change to the problem when i omit it.

Edge both is needed to see the high and low values. Mode up is necessary to avoid a floating value. As mentioned, all works fine, except the motion sensor in domoticz (connected to the gpio) keeps repeating it's off state as an event.

[smq]

Hi,

Did you fix your problem?

The reason of this problem could be inherence of 230V cables near PIR cables or near RPI GPIO.
I have the same situation in my home - I have connected several PIR, contact switches in windows and in door locker (to get locker status) and I receiving off status repeatedly.
I noticed that mostly when I opening/closing roller shutters powered by 230V.

In fact, off status don't rising my alarm system, but still 'last seen' of device is depend of last 'off state' so it could be misleading.
The solution here I beleive could be pull-up resistors for each sensor (http://midihacker.com/wp-content/upload ... pullup.jpg)
But I didn't checked it yet.

Greetings.

[RidingTheFlow]

10K resistor is not really enough for cable ~1m. You'll need ~2k resistor for that. And don't even try to rely on built-in pullup - its about 40K and barely good even for things which sit straight near.

Also I recommend using shielded cable. Really easy & cheap solution is to solder RJ45 jacks at start and end devices and use store-bought Cat7 Ethernet patch cables - they really good shielded cables and give you a lot of signal wires to use (I recommend wiring each pair signal + earth for best integrity since twisted pair original design was for balanced signals).

But you will find that when you make cable long-ish you will be unable to remove RF noise whatever you do. At this point you will need to filter noise out on software (debouncing) or hardware (low-pass filtering).

Also the easiest way may be just buy cheap Arduino Nano (~1.5 euro if you buy in bulk from China), connect it to PIR directly (its tiny, so in many case you can actually place it *inside* the PIR case), and use long&cheap USB 2.0 cable - this will not have any problems with signal

[ogroot]

Also had issues with 230v cables casing interference on cables connected to gpio inputs.
Causing frequent "ghost" gpio input events.
Was able to solve this by adding 100n capacitors to each input port.