The Hunting of the Snark

So i want to us a raspberry pi to implement an easy to use scan to mail solution. My Brother printer/scanner can only do this when a Windows PC with the Brother software is running. That is not really what i wanted.

Should be easy - right? just do something like

scanimage ...
convert to pdf
ocrmypdf
mail the resulting pdf

but wait: installing sane-utils and running scanimage on raspbian does not know about this scanner:

root@shrink:~# scanimage -L

No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate). Please read the documentation
which came with this software (README, FAQ, manpages).

root@shrink:~# sane-find-scanner
[ ... ]
found USB scanner (vendor=0x04f9 [Brother], product=0x036f [DCP-9022CDW]) at libusb:001:003
could not fetch string descriptor: Pipe error
  # Your USB scanner was (probably) detected. It may or may not be supported by
  # SANE. Try scanimage -L and read the backend's manpage.

Oh well - maybe installing sane-airscan will help? This is a generic IP based scanning protocol that most vendors implement. After installing this package i get:

root@shrink:~# scanimage -L
device `airscan:w1:Brother DCP-9022CDW' is a WSD Brother DCP-9022CDW ip=192.168.###.###

and it kind of works: you can scan - but only via the network, not over USB. And it does not work elegantly with the automatic document feeder (ADF): you have to either invoke it with

scanimage -d 'airscan:w1:Brother DCP-9022CDW' --source ADF

to get it to use the ADF (and it fails if there is nothin in there) or invoke it without the ADF option to get it to use the flatbed. I remember, that with the brother module fore sane scanning, it was possible to do this by magic: if something was in the ADF: use that. otherwise use the flatbed.

There is Linux support on the brother support pages. Right?
NOOO! Brscan is only available precompiled for i386. And the source brother provides seems incomplete and unusable. Tough some people seem to be working on that.

So let's do the most complicated means to get what i want: use quemu and a virtual i386 environment on the ARM arcitecture of the raspberry pi to get scanimage to work with the original brother scanner drivers:

wget -O /tmp/brscan4-0.4.11-1.i386.deb https://download.brother.com/welcome/dlf105201/brscan4-0.4.11-1.i386.deb
apt-get install qemu-system-x86 qemu-user-static debootstrap binutils
mkdir /opt/scanberryd-i386
debootstrap --arch=i386 --variant=minbase --foreign bullseye /opt/scanberryd-i386/
mount -t proc proc /opt/scanberryd-i386/proc
mount -t sysfs sys /opt/scanberryd-i386/sys
mount -o bind /dev /opt/scanberryd-i386/dev
mount -o bind /dev/pts /opt/scanberryd-i386/dev/pts
mount -o bind /tmp /opt/scanberryd-i386/tmp
chroot /opt/scanberryd-i386/
/debootstrap/debootstrap --second-stage
apt install /tmp/brscan4-0.4.11-1.i386.deb

This sets up an (allegedly minimal) i386 debian environment in /opt/scanberryd-i386 of nearly 600MB. I am sure that could be trimmed down a lot.
And voila: we have an environment in which the scanner can be used via USB and with the magic ADF detection:

root@shrink:~# chroot /opt/scanberryd-i386/
root@shrink:/# scanimage -L
device `brother4:bus1;dev4' is a Brother DCP-9022CDW USB scanner
root@shrink:/# scanimage -d "brother4:bus1;dev4" \
--mode "True Gray" --resolution 300 \
--source "Automatic Document Feeder(centrally aligned)" \
--format tiff --batch=/tmp/scan%03d.tiff

To make this transparently usable (at least as the root user) i set up this script to /usr/local/bin/scanimage:

#!/bin/bash

if [ ! -d /opt/scanberryd-i386/dev/net ]; then
     mount -t proc proc /opt/scanberryd-i386/proc
     mount -t sysfs sys /opt/scanberryd-i386/sys
     mount -o bind /dev /opt/scanberryd-i386/dev
     mount -o bind /dev/pts /opt/scanberryd-i386/dev/pts
     mount -o bind /tmp /opt/scanberryd-i386/tmp
     mount -o bind /home /opt/scanberryd-i386/home
     mount -o bind /var /opt/scanberryd-i386/var
     mount -o bind /root /opt/scanberryd-i386/root
fi

chroot /opt/scanberryd-i386/ /usr/bin/scanimage "$@"

Wenn man schon ein Relais einsetzt, das Netzspannung schalten kann, warum dann nicht gleich das Netzteil des Pi "an der Quelle" schalten? Damit kann gleich eine andere Netzspannungskomponente, die mit dem Pi zusammen genutzt wird, mit geschaltet werden: der 3D Drucker, der Scanner, ...

z.B. hat OctoPrint eine Option, nach dem Ende des Drucks den Pi herunterzufahren. Mit dieser Lösung schaltet man gleich den 3D-Drucker mit aus.

Die Logik ist eigentlich die gleiche wie in Ältere Raspberry Pi ohne Anmeldung herunterfahren Teil 2: Mit einem Relais ganz ausschalten : Ein Einschalt-Taster überbrückt den Schaltkontakt eines Relais. Aber in dieser Schaltung wird nicht der 5V Strang der Stromversorgung über das Relais geschaltet, sondern die Netzspannung, an der das Netzteil des Pi selbst erst nach dem Einschalten mit Strom versorgt wird.

Sobald dadurch die Versorgungsspannung des Pi hergestellt ist, hält dieser den Steuerkontakt des Relais (über einen Pull-Up Wiederstand) aktiv und das Relais bleibt eingeschaltet. Und das so lange, bis ein GPIO-Pin des Pi diesen Steuerkontakt zum Ausschalten auf 0V herunter zieht.

Um diese Schaltfunktion ganz am Ende des Herunterfahrens des Betriebssystems auszulösen gibt es ein Raspbian Modul: gpio-poweroff. Wenn das Herunterfahren nicht über die Kommandozeile oder irgendein Web-Interface ausgelöst werden soll, kann mit dem Modul gpio-shutdown ein zusätzlicher Taster an einem GPIO-Pin diese Funktion auslösen.

Zusammen sind also wieder folgende Einträge in /boot/config.txt notwendig:

dtoverlay=gpio-poweroff,gpiopin=26,active_low=0,input=0,active_delay_ms=3000
dtoverlay=gpio-shutdown,gpio_pin=3,active_low=1,gpio_pull=up

Hier ist das ganze noch mal als loser Aufbau auf dem Tisch zu sehen: der Einschalt-Taster, der das Relais überbrückt muss dabei für Netzspannung geeignet sein und auch den Einschaltstrom aller angeschlossenen Verbraucher schalten können.

Weil die Einschalt-Funktion und das Signal zum Herunterfahren vollkommen unabhängig voneinander sind, und sich auch zeitlich nicht überlappen, kann auch ein einziger Taster mit zwei unabhängigen (und gut voneinander isolierten) Kontakten verwendet werden. Dann schaltet der erste Tastendruck den Pi ein. weiteres Drücken bis zum Abschluss des Boot-Vorgangs bewirkt erst mal nichts. Wenn der Boot-Vorgang abgeschlossen ist, löst ein neus Tippen auf den Taster das Herunterfahren und das abschließende Ausschalten aus.

... jetzt fehlt nur noch ein passendes Gehäuse...

ACHTUNG: Netzspannung kann lebensgefährlich sein. Immer die notwendigen Vorsichtsmaßnahmen ergreifen um sicherzustellen, dass aktive Kontakte nicht versehentlich berührt werden!!!

Update 07. Januar 2024 - das Gehäuse:

ich glaube nicht, dass irgend jemand das genau so übernehmen kann - man müsste schon genau die selben Microschalter, Lüsterklemmen, Relais-Platinen und sogar die selbe Baumarkt-Steckdose haben, damit es genau so passt... Zur Inspiration: hier das FreeCad Modell.

anyway: ich habe mit FreeCad eine Grundplatte entworfen, in die diese Elemente und ein Raspberry Pi 4 genau reinpassen (blau). Dazu denn eine etwas schräge Frontplatte, die alle Elemente genau so in ihre Einpassungen drückt, dass innen keine Schrauben notwendig sind (gelb) und dann noch eine haltende Klammer an der Rückseite, die (mit Schrauben aus der Bodenplatte) alles zusammenhält (schwarz). Hier ein paar Fotos:
Zwischendurch (zwischen dem 2. und 3. Foto) musste ich dann doch noch was an der Halterung der Microschalter ändern. Es klappt eben doch nie so, wie geplant...

Dazu kamen dann noch drei zusätzlich Buttons und eine 2-farbige LED im Power-Button. Weil der Raspberry ja nicht nur an- und aus-gehen soll, sondern auch noch eine Aufgabe bekommen wird. Damit sieht der Kabelsalat, der von der Frontblende ausgeht, doch etwas wirrer aus.

Einen Raspberry Pi mit der Funktion dtoverlay=gpio-shutdown in /boot/config.txt sauber runter fahren ist gut - aber aus ist er damit noch nicht.

Dafür gibt es noch das Overlay gpio-shutdown: eine Funktion, die am ende des Shutdown noch mal einen gpio-pin steuern kann, der dann z.B. ein Relais schaltet.

Als Schaltung kann man dafür ein Relais mit einem Pull-Up Wiederstand gegen +5V und an einen normalerweise als Eingang geschalteten GPIO-Pin schalten (hier GPIO 26 an Pin 37). Wenn der dann beim Herunterfahren des Pi auf 0V gezogen wird, schaltet das Relais ab.

Ein Taster, der den Schalter des Relais selbst kurz überbrückt dient als Einschalter. Sobald Spannung am Raspberry anliegt, sorgt der Pull-Up Wiederstand dafür, dass das Relais angezogen wird und bleibt.

Der zweite Taster zwischen GPIO 3 und 0V löst ein shutdown Signal aus. Wenn dann das Herunterfahren beendet ist, wird GPIO 26 auf 0V geschaltet und das Relais schaltet ab. Als loser Drahtverhau auf dem Tisch sieht das so aus:

Als Relais habe ich eine kompakte Platine mit Optokoppler genommen. Nicht, dass ich hier etwas glavanisch trennen will. Aber so kann man sicher sein, dass der GPIO-Pin und der Pull-Up Wiederstand auf jeden Fall nur eine LED als Last bedienen müssen und auch keine plötzlichen Spannungsspizten aus der Relais-Spule beim Ein- oder Ausschalten auf den Pi zurückschlagen.

(um nicht mit abgeschnittenen USB Kabeln hantieren zu müssen um die vom Relais geschalteten 5V in den Raspberry einzuspeisen: das geht gut über Pins an der 40-poligen Steckerleiste: GND/0V z.B. an Pin 39 und +5V an Pin 2)

Dazu sind dann folgende Einträge in /boot/config.txt notwendig:

dtoverlay=gpio-poweroff,gpiopin=26,active_low=0,input=0,active_delay_ms=3000
dtoverlay=gpio-shutdown,gpio_pin=3,active_low=1,gpio_pull=up

Mit einem modernen USB Netzteil, das laut Aufdruck 0,01W verbraucht wenn keinerlei Leistung am Ausgang abgenommen wird, sieht das auch Energie-mäßig schon ganz gut aus...