0

I have a Raspberry Pi 4 and an HID Omnikey 5427G2. When I scan a card, the card reader acts as a keyboard and types out a series of 7 digits that correspond to the card. This works fine, but it only types it out like it were a keyboard to text files or text fields that I have open and selected

What I want to have happen is that when the card scans, the number that it gets from the scan is then placed into a file, "scan.txt" perhaps, and is saved in a certain location. How can I do this?

Once I have the number in a file, I also want it to automatically call a shell script. I already have the script made, I just need it to be called from the scan.

Thanks in advance!

  • try scanning cards into a spreadsheet ... write some code that manipulates the entered data in the required way – jsotola Mar 04 '20 at 07:24

2 Answers2

0

A 'quick and dirty' solution would be a bash-script running a infinite loop:

#!/bin/bash
while read scan; do
    scandate=$(date +"%F_%T.%N")
    echo "$scan" >> /tmp/scan_$scandate.log
    cat /tmp/scan_$scandate.log &
done

whereby cat /tmp/scan_$scandate.log stands for an application doing something with the scanned input. You also could deal with the scanned data within this script.

Be aware that any functionality reading input from your scanner/keyboard will block your keyboard and leave the Pi dedicated to this functionality.

bey0nd
  • 937
0

What you want basically is a plain keylogger.

Your device does keyboard emulation, and on Linux the keyboard device is a file, so you can do standard input redirect.

Alternatively you can use a program like logkeys (may already be available as a package in your distro). Some more doc here too.

Assuming you only want to capture input from that specific device and not any keyboard installed on your system, you need to identify the device. I would have a look at /dev/input/ for example then locate your device by path or by id.

Using logkeys the -d, --device=device option should help you filter events on the right device.

There are also other useful tools like evtest, xinput that can help you with testing and locating the correct device identifier.

It is also possible to set up a udev rule for your device, that runs a program or does something when plugging in the device (an intro tutorial on udev). I am not experienced enough with udev but it should be possible to set up the redirection this way. The only hurdle is to make sure you get plain characters and not raw input, or you have to take care of decoding it.

Another option is using the python-evdev library if you are into Python, and you monitor events from /dev/input/whatever-your-keyboard-is-using.

I would try a udev rule. I would not bother with a temp text file either, just monitor events from the device and react to them.


Update

I have done some testing with a barcode scanner, which behaves as a keyboard and is therefore technically similar to your card reader from the system's point of view.

First of all, one interesting thing to know is that it's possible to gain exclusive access to an HID device using the EVIOCGRAB function. That means you can have an application take over the device so that it will not send unwanted input and interfere with other windows. You will probably want this.

Note that evtest (mentioned above) has a --grab parameter too.

I have also previous mentioned python-evdev, that can be used to capture input from the device. It has a grab() function as well.

It's not needed to be root to use python-evdev but your permissions may need adjusting. From their doc:

If you do not see any devices, ensure that your user is in the correct group (typically input) to have read/write access.

To add yourself to the group:

usermod -a -G input user

then log in again. (Once you've done this, evtest will work for the non-root user too).

Here is one example of code here: How to “route” barcode TTY input to Python? and another one that worked for me: exclusive-keyboard-evdev.py.

Right now I don't know if there is a way to do that elegantly using bash only. But Python is a viable approach, or C.

Kate
  • 849