We have a MUNBYN scanner that connects to a Raspberry Pi via USB. I believe its output is indistinguishable from that of a keyboard. While we were able to get a connection using Ignition's TCP driver, the message we see is just "SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u1" and doesn't change when a scan is made. I assume that's because the output from the scanner isn't getting piped to the port we're connecting to (22). Does anybody here happen to know how to get that to happen?
Hard to say without the device here to poke at...
Can you find the scanner listed under /dev somewhere?
Not sure what to look for there but my coworker found this:
Device= 4.21
[ 1.960351] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 1.960369] usb 1-1: Product: USB2.0 Hub
[ 1.962485] hub 1-1:1.0: USB hub found
[ 1.962776] hub 1-1:1.0: 4 ports detected
[ 2.257713] usb 1-1.2: new full-speed USB device number 3 using xhci_hcd
[ 2.362206] usb 1-1.2: New USB device found, idVendor=e851, idProduct=1000, b cdDevice= 2.33
[ 2.362240] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber =0
[ 2.362257] usb 1-1.2: Product: Barcode Reader
[ 2.362270] usb 1-1.2: Manufacturer: Manufacturer
[ 2.370696] input: Manufacturer Barcode Reader as /devices/platform/scb/fd500 000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:E851 :1000.0001/input/input0
[ 2.430741] hid-generic 0003:E851:1000.0001: input,hidraw0: USB HID v1.01 Key board [Manufacturer Barcode Reader] on usb-0000:01:00.0-1.2/input0
[ 2.510915] brcmstb-i2c fef04500.i2c: @97500hz registered in polling mode
[ 2.511605] brcmstb-i2c fef09500.i2c: @97500hz registered in polling mode
[ 2.686488] [drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
[ 2.763921] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[ 2.766711] Registered IR keymap rc-cec
[ 2.766883] rc rc0: vc4-hdmi-0 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[ 2.767069] input: vc4-hdmi-0 as /devices/platform/soc/fef00700.hdmi/rc/rc0/i nput1
[ 2.772587] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[ 2.775361] Registered IR keymap rc-cec
[ 2.775552] rc rc1: vc4-hdmi-1 as /devices/platform/soc/fef05700.hdmi/rc/rc1
[ 2.775741] input: vc4-hdmi-1 as /devices/platform/soc/fef05700.hdmi/rc/rc1/i nput2
[ 2.785287] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[ 2.787334] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
[ 2.788169] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 2.788670] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 2.789188] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 2.789517] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 2.789994] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 2.795573] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 1
[ 2.797771] vc4-drm gpu: [drm] Cannot find any crtc or sizes
[ 2.807293] vc4-drm gpu: [drm] Cannot find any crtc or sizes
[ 2.807873] vc4-drm gpu: [drm] Cannot find any crtc or sizes
[ 3.216638] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Q uota mode: none.
[ 3.834978] systemd[1]: System time before build time, advancing clock.
[ 4.013197] NET: Registered PF_INET6 protocol family
[ 4.014929] Segment Routing with IPv6
[ 4.014972] In-situ OAM (IOAM) with IPv6
[ 4.095346] systemd[1]: systemd 252.17-1~deb12u1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +B LKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCR E2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
I did manage to get keyboard input to show up in Ignition by using the netcat command to open a port:
sudo netcat -l -vv -p 23
...so I'm thinking if we can figure out how to get the Pi to automatically start up with a terminal open (and without login), then scanning a barcode with that command might work...?
Ideally instead of a focused terminal being open and receiving input, you find the device on the filesystem, and then cat the contents of that file and pipe it to your netcat command.
Or write a script that opens the file and prints the content to stdout, then run the script and pipe it to netcat.
In any case you're going to have a bit of work ahead of you to make this a robust solution and not just a prototype/hack.
Also consider not using port 23. That's reserved for another known service and requires root or the NET_CAP_BIND_SERVICE capability. Just use something above 1024, e.g. 1234.
Thanks for the suggestion! I found that file and was able to pipe its output to the netcat command. Scanning a barcode resulted in gibberish showing up in the file, but also in Ignition, so at least we're getting closer, and now we're looking into the configuration of the scanner...
The file may be outputting some kind of binary that needs conversion to ascii/text. Not sure.
We got it working with a different approach, maybe not ideal and a bit of a hack, but it works: we installed Linux without the GUI, so it just runs as a CLI. That way when it boots up, we can scan a barcode that sends the netcat command to open up that port. (These machines are all running on a closed network, so we're not real concerned with security implications.)
The only problem we have now is that when the power to the Raspberry Pi is cut, Ignition doesn't seem to recognize that the connection is broken. It still says it's connected, and when the machine boots back up, issuing the netcat command doesn't work to reestablish the connection. Only when we disable and reenable the connection in the Ignition gateway are we able to get a connection again.
Is there a way to get Ignition to periodically check if a TCP connection is still intact?
If it's not a clean disconnect you're at the mercy of the operating system's TCP keep alive mechanism, which is usually on the order of hours.
The only option you have in the TCP driver is to set the "Inactivity Timeout" to something non-zero, which means it will force a reconnect after whatever that period is.