Using incrontab to read GPIO's in pure bash

[sebastiannielsen]

I tried the following:

In rc.local, I have:

Code: Select all

echo 24 > /sys/class/gpio/export
echo 25 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio24/direction
echo in > /sys/class/gpio/gpio25/direction

In: incrontab -l

Code: Select all

/sys/class/gpio/gpio24/value IN_MODIFY date > /var/alarm/motion
/sys/class/gpio/gpio25/value IN_MODIFY date > /var/alarm/tamper

But when I wave the hand in front of motion detector, nothing happens. Its supposed to create a file in the directory /var/alarm/ containing the date & time of when the last change of the GPIO pin happened. (Ill will change that into a WGET command to fetch a CGI script on my main "large" server then)

However, when I "cat /sys/class/gpio/gpio24/value" I get a "1" when theres no motion, and "0" when theres motion.

And when I do "cat /sys/class/gpio/gpio25/value", I get a "1" when the cover on the motion detector is closed, and "0" when the cover is open.

So what im doing wrong? The file "value" in the folder "/sys/class/gpio/gpio24/" (and gpio25) IS CHANGED so why aren't incrontab executing the command I told it to execute?
Also verified that the command "date > /var/alarm/motion" does work.

[jojopi]

Inotify works because, when changing a file on behalf of one process, the kernel remembers that another process registered an interest in that file, and informs it of the change.

The gpio value psuedo-files are not changed by the kernel, they report the current state of the hardware, so the kernel does not automatically know when they have changed. It cannot continuously check the gpio state, because that is the kind of inefficient mechanism that inotify is intended to avoid.

On the Pi, the hardware can be configured to interrupt the kernel when a gpio changes state ("echo rising >/sys/class/gpio/gpio24/edge"). You might think that this would then allow inotify to work on the value file, but it is not implemented that way. Instead, an interrupt causes an urgent/exceptional condition on the gpio value file, and this condition must be checked or waited for using the poll() or select() system calls, not using inotify.

I am not aware of a good method of using poll() or select() at the shell level. However, most of the usual gpio libraries in C and Python do support waiting and reacting to level change interrupts.

[sebastiannielsen]

Is it possible to have it to just run a command when the state of the gpio pin Changes?
If the pin goes high or low does not matter, I just want to run a command at any change.

I could also have it to change only when the pin goes low, thats good too.

Since the rPI in question is a NTP server too, I want to avoid having a loop running and checking the pin all the time.

[gordon@drogon.net]

If you install wiringPi (http://wiringpi.com/ ) then use the gpio command, you can run:

Code: Select all

gpio wfi 0 falling

then the gpio program will wait for a falling edge on that pin (use -g to get bcm_gpio pin numbers - eg. gpio -g 17 falling)

It uses a non-busy wait - aka wait for interrupt.

Try it at the shell - you need 2 windows, in one type:

Code: Select all

gpio wfi 0 falling

and in the other type:

Code: Select all

gpio mode 0 up ; gpio mode 0 down

that's forcing the trigger using the internal pull-up/down resistors - on the 'down' command the gpio wfi in the first window will exit.

You can use falling, rising or both to look for any edge.

The difficulty is doing it on more than one pin in the same script, but that's left as an exercise to the user

-Gordon