Ich war schon länger auf der Suche nach einer vernünftigen Lösung, um eingehende Dokumente (die aus Papier) direkt nach dem Auspacken ohne viel Aufwand einzuscannen, und danach als Bild, besser noch geOCRt (ist das überhaupt ein Wort? egal…) auf meinem Server zur weiteren Bearbeitung als Freigabe per NFS oder Samba/CIFS zur Verfügung steht.  Das Projekt wurde zugunsten Anderer immer wieder aufgeschoben, bis vor Kurzem der gute Ronald von der Schatenseite mit einer interessanten Lösung daher kam: Einen TP-Link MR3020 mit OpenWRT an einen Einzugscanner zu kleben, und auf Knopfdruck den Einzugscanner zu triggern, um zu scannen, und das Dokument auf einem Netzwerk-Share abzuladen. Das war so in etwa exakt Das, was ich gesucht habe, denn einen Einzugscanner hatte ich auch noch (der sollte eh für dieses Projekt herhalten), und auch einen MR3020 hatte ich noch. Ideal also, um das mal auszuprobieren.

Unterm Strich weicht mein Setup dann aber doch ein bisschen von dem ab, was Ronald’s Ansatz war, von daher hab ich mich dazu entschlossen, das noch mal neu komplett von Null an zu dokumentieren…

Der Artikel ist also wie folgt gegliedert:

1. Hardware
2. Konfiguration
3. Firmware flashen

Hardware

Es empfiehlt sich, die Modifikationen an der Hardware als allererstes zu machen. Diese sind zwar allesamt optional, aber in meinen Augen dennoch sinnvoll.

Paint It Black!

Ich persönlich empfinde es als sehr störend, dass die LEDs am MR3020 sehr stark in die Bereiche der benachbarten LEDs einstrahlen. Dadurch wird es relativ schwer (vor allem beim Betrachten von der Seite), wirklich zu erkennen, welche LED nun grade leuchtet. Dazu kann man das Gehäuse (vorsichtig) mit einem kleinen, flachen Schraubendreher aufhebeln. Das Gehäuse ist allerdings teilweise verklebt, darum ist hier Geduld vonnöten. Auch sollte man es vermeiden, die Haltenasen abzubrechen. Wenn das doch passiert, oder der Deckel hinterher nicht mehr ordentlich hält, kann man immer noch zu Kunststoffkleber – oder viel billiger – Aceton greifen, um das Gehäuse hinterher wieder zusammenzukleben. Da das Gehäuse aus ABS-Kunststoff ist, funktioniert das problemlos. Ansonsten gibts im OpenWRT-Wiki auf der Wikiseite vom MR3020 eine gute Beschreibung, wo man das Gehäuse genau aufhebeln sollte.

Einmal geöffnet, kann man anfangen, gewünschte Modifikationen am Gerät unterzubringen; denkbar wäre etwa ein Step-Down-Modul zur Stromversorgung mit im Gehäuse inkl. einer Hohlbuchse nach draussen, damit man das Gerät auch mit Spannungen größer 5V betreiben kann (dazu später mehr). Das hatte ich auch in Erwägung gezogen, allerdings habe ich mich dann für eine andere Methode entschieden. Also gings erstmal mit ein wenig „Schwarzmalerei“ weiter. Ich habe größere Teile des durchsichtigen LED-Diffusors mit einem schwarzen Edding angemalt, um das von der Seite einstrahlende Licht der LEDs zu minimieren. Wie sich rausstellt hätte etwas weniger Farbe  auch ausgereicht; die LEDs sind relativ dunkel bei mir, aber immer hoch hell genug. Wie auch immer, der Zweck der Aktion – dass LEDs besser vonneinander unterscheidbar sind – wurde voll erfüllt.

Stromversorgung

Es widerstrebt mir, extra eine Mehrfachsteckdosenleiste an dem Ort zu legen, wo der Scanner hinterher stehen soll, zumal der MR3020 (besonders wenn das WLAN aus ist) extrem wenig Strom zieht, nämlich deutlich unter einem Watt. Je nach dem, was für einen Scanner man hat, gib es hier mehrere Möglichkeiten. Zum einen sollte man mal testen, ob der Scanner an seiner USB-Buchse auch Spannung anliegen hat, denn wenn ich mich nicht ganz täusche, habe ich in der OpenWRT-Doku zum MR3020 was darüber gelesen, dass es wohl eine Lötbrücke gibt, mit der man – wenn gesetzt – den MR3020 auch über das angeschlossene USB-Gerät mitversorgen kann. Wenn der Scanner seinerseits über 5V versorgt wird, kann man sich mit einem Y-Stecker behelfen (allerdings dürfte das fast nur bei Flachbettscannern der Fall sein). Da die Versorgung über einen LiPo-Akku zwar möglich ist, für diesen Zweck allerdings nur mäßig sinnvoll scheint, bleibt sonst nur noch übrig  ein externes Step-Down-Modul zu verbauen. Das hängt man mit an die Versorgungsspannung des Scanners, und – je nach verwendetem Modul – stellt die Ausgangsspannung auf 5V (+/- 0.25V) und lötet am Ausgang die Reste eines abgeschnittenen Mini-USB-Kabels an. So braucht man nur ein Netzteil, und aufgrund des niedrigen Verbrauchs des MR3020 sollte das von der Netzteil-Dimensionierung hier eigentlich kein Problem darstellen. Ich habe hier einen Step-Down auf Basis des LM2596 benutzt; allerdings nur, weil der hier noch rumlag. Demnächst wird das auf einen LM7805 umgebaut, sobald der mal im Briefkasten liegt, denn der ist nicht nur kleiner, sondern der LM2596 ist für deutlich höhere Ströme ausgelegt, was hier einfach nicht benötigt wird. -> Nach einer kurzen Diskussion bin ich zu dem Schluss gekommen, dass ich beim LM2596 bleibe, weil der 7805 die Differenz nicht runterregelt, sondern einfach in Hitze verballert. Bei 15V->5V (das Scanner-Netzteil hat 15V) sind das selbst bei den <100mAh die der MR3020 braucht, halt 100mAh auf 10V Verlust, also ~1W die der verheizt. Das ist doppelt so viel, wie der Router selbst verbraucht. Am Ende das ganze Kabelgewirr noch mit Schrumpfschlauch eintüten und fertig.

Beschriften

Der Plan war, hinterher die LEDs als Status-Indikator für die Stellung des 3-Positionen-Schiebe-Schalters zu benutzen, und die Oberseite entsprechend zu beschriften. da ich das schon ausprobiert hatte, wusste ich, dass Das auch funktioniert den Schalter und die LEDs frei mit Funktionen zu belegen. Dieser Schritt kann also auch jetzt schon gemacht werden. Man nehme also eines dieser Beschriftungsgeräte (welche erstaunlicherweise relativ günstig sind…), und drucke sich passende Beschriftung aus, die die spätere Funktion der Schalterstellung wiederspiegelt. AP, WISP und 3G sind die jeweiligen Stellungen des Schalters und damit wird später festgelegt, in welchem „Modus“ der Scanner grade arbeitet (dazu später mehr). Die Power-LED ist sowieso hardwired und kann nicht mit einer Funktion blelgt werden. Die anderen drei LEDs in der ursprünglichen Funktion waren so nicht mehr wirklich sinnvoll. Die Netzwerk-LED: Naja, die braucht nicht dauernd blinken, ohne Netzwerk funktioniert das hier alles eh nicht. 3G? Ich hab kein UMTS-Modem dran und dann noch eine LED fürs WLAN… auf das aus Platzgründen auf dem 3020 hier eh verzichtet werden muss. Von daher sind die drei LEDs frei benutzbar, und was bietet sich da mehr an, als den Schalter damit zu visualisieren? Die LED am ehemaligen WPS-Taster kriegt hinterher auch noch eine Verwendung, aber Eins nach dem Anderen.

Konfiguration

Die Hardware-Modifikationen sind also abgeschlossen, jetzt braucht unser Mini-Router nur noch neue Firmware, und zwar eine mit OpenWRT. Wie Ronald schon angemerkt hat, kriegt man auf den SquashFS-Partitionen nur mühsam Platz freigeschaufelt, z.T. auch nicht durch Deinstallation diverser Pakete, also wird ein neues Image gebaut. Damit man nicht ein komplettes OpenWRT aus den Sourcen bauen muss (was durchaus ein paar Stunden dauern kann, je nach Rechner), bietet sich der Image-Builder von OpenWRT an, wo das meiste schon vorkompiliert ist, und nur noch das Image nach Wunsch zusammengebacken wird. Ach ja, die folgende Anleitung bezieht sich so erst mal auf Linux, für MacOS und Windows gibts aber die abweichende Schritte auf der grade verlinkten OpenWRT-Wiki-Seite beschrieben und erklärt.

Also neues Verzeichnis erstellen und erst mal den Image Builder runterladen und entpacken:

Danach innerhalb des Projektordners den Ordner „files“ anlegen, und da schon mal ein paar Dateien anlegen:

Alles was in „files“ liegt, wird hinterher so im Dateibaum angelegt, also legen wir schon mal ein paar Ordner an, und darin ein paar Dateien. Zunächst die Netzwerk-Konfiguration. Hier macht eine statische Konfiguration in den meisten Fällen wohl mehr Sinn als DHCP (dazu später mehr). In die „resolv.conf“ trägt man seine(n) DNS-Server ein (in den meisten Heimnetzen wohl die Addresse des Routers), und in „network“ seine restliche Netzwerk-Konfiguration, die könnte dann in etwa so aussehen:

Wlan und Optionen für IPv6 sind hier bewusst ausgelassen, da wir leider für Beides eh keinen Platz mehr für Software und Treiber auf dem MR3020 haben werden. 4MB Flash sind halt echt wenig Platz für so ein komplettes Linux.

An dieser Stelle sei noch kurz angemerkt, dass es sinvoll ist, in seine resolv.conf erst mal was einzutragen, auch wenn der Router seine IP per DHCP kriegt. Aus einem Gund, der mir noch nicht ganz klar ist, werden Optionen für den DNS-Server vom DHCP irgendwie nicht richtig übernommen, und es steht dann z.B. 127.0.0.1 in der resolv.conf, und „Upstream-DNS“ ins Internet funktioniert, aber lokal halt nicht. Ich würde mal vermuten, dass – ähnlich wie unter Ubuntu – dnsmasq hier versucht, einen lokalen DNS-Cache zu spielen, einen public-DNS by default eingetragen hat und da irgendwas nicht richtig funktioniert. Seis drum, der Einsatzzweck ist eh stationär, von daher geht das erst mal so, dass ich die resolv.conf von Hand setzte, auch wenns nicht „schön“ ist, weil es den eigentlichen Vorteil von DHCP schon irgendwie unterwandert, wenn Optionen, die dieser mitsendet ignoriert werden.

In „system“ kommen dann unter anderem der Hostname des Systems sowie z.B. NTP-Server:

Die Timezone können wir hier auch gleich schon richtig setzen, indem – wie etwas weiter oben schon beschrieben – ein String in die „/etc/TZ“ geht, der die Zeitzone auf unsere Mitteleuropäische Zeit mit Angaben über Sommer-/Winterzeit-Wechsel setzt. In die „/etc/fstab“ kommt der Mountpoint unseres Servers, wo hinterher die Scans liegen sollen (muss natürlich für den Router beschreibbar sein). Ansonsten werden schon mal unsere beiden Scripte angelegt. Nameserver, Hostname, Netzwerk-Konfiguration und Mountpoint des Servers müsst Ihr natürlich auf euer Setup anpassen.

Optional kann man – besonders wenn man vorher schon ein WRT auf dem MR3020 drauf hatte – seine SSH-Keys und was so dazugehört, von der alten Installation hinüberretten. Dann funktionieren gleich alle schon eingetragenen SSH-Keys und der Router meldet sich mit dem selben SSH-Fingerprint wie vorher, dafür einfach alles was in „/etc/dropbear“ ist, so auf den neuen Router bringen. Das sollten 3 Dateien sein:

Scan-Scripte

Nun zum Herzstück der Funktionalität: Dem Scan-Script, bzw. den zwei Scripten. Als erstes brauchen wir eine Definition für den Hotplug-Daemon. Unter OpenWRT kann dieser auf Hardware-Events reagieren. Wir wollen Buttons, also kommt folgendes Script in unsere frisch angelegte Datei files/etc/hotplug.d/button/buttons :

Im ersten Teil prüfen wir darauf, dass der WPS-Button gedrückt wird. Wenn das passiert, schalten wir die LED des WPS-Buttons ein, schreiben ins Log, dass der Knopf gedrückt wurde, rufen unser eigentliches Scan-Script auf und schalten die LED wieder aus, wenn unser Script erfolgreich beendet wurde. Das hat den Vorteil, dass man sofort sieht, OB und WANN das Script erfolgreich beendet wurde. Auch wenn der Scanvorgang durch eventuelles Post-Processing (OCR, begradigen, beschneiden, sowas halt) etwas länger dauert, sieht man hier sofort, ob und wann unser Scanvorgang erfolgreich war (oder halt auch nicht).

Der zweite Teil dient dazu, je eine LED an, und die anderen beiden auszuschalten, wenn der Schiebeschalter betätigt wird. Das sieht relativ kompliziert aus, ist aber nötig, denn zum einen weil die /bin/sh auf dem WRT offenbar keine Funktionen kann (zumindest sind meine scripte immer abgestürzt, wenn ich Funktionen benutzt hab; is halt nur ne sh, keine bash), und zum anderen, weil der Schiebeschalter hardwareseitig eigentlich 2 GPIO-Schalter sind, dessen truth-table wie folgt aussieht:

Weiter geht es mit dem zweiten Script, dass den eigentlichen Scan ausführt, und unter /root/scan.sh gespeichert wird:

Hier wird zunächst mal der Mountpoint festgelegt und dann mehr oder weniger umständlich festgestellt, in welcher Position sich der Schiebeschalter befindet. Abhängig davon wird dann unser Scan-„Modus“ festgelegt. Ich habe 3 Positionen zur Verfügung, also habe ich folgende Modi definiert:

Schalter auf AP: Scan in Farbe, nur Vorderseite.
Schalter auf 3G: Scan in S/W, im Duplex-Modus
Schalter auf WISP: Scan in S/W, nur Vorderseite

Danach kommt noch ein bisschen Error-Handling, ob die Schalterposition auch lesbar ist und der Mountpoint auch verfügbar ist, und dann wird mit „scanimage“ entsprechend das Dokument eingescannt. Die Exitcodes, die hier
0 (alles in Ordnung),
1 (Schiebeschalter in undefiniertem Zustand),
2 (Mountpoint nicht vorhanden/nicht beschreibbar) oder
3 (kein Scanner angeschlossen/USB-Fehler)
sein können, werden hier entsprechend ausgewertet, und die WPS-LED blinkt in Abhägigkeit dazu auch 1,2 oder 3 mal, je nach Error-Code. So sieht man direkt, was nicht stimmt. Mehr visuelles Feedback kann man aus einer LED wohl nicht rausholen.

Image bauen

Wenn wir soweit fertig sind, können wir nun unser Image mit einem Befehl bauen lassen:

jedes Paket vor dem ein Minus („-„) steht, gehört zur Standardinstallation, wird aber hier ausgelassen, um Platz zu gewinnen. Dazu gehört unter anderem die IPv6-Unterstützung und WLAN-Treiber. Die Weboberfläche ist bei selbst gebauten Images sowie so erst mal nicht installiert.

Image flashen

Am einfachsten kann man das Image flashen, wenn schon ein WRT auf dem Gerät vorhanden ist. wie weiter oben beschrieben, hat das auch direkt den vorteil, seine SSH-Config weiternutzen zu können, und direkt danach sich per SSH auf dem Ding einloggen zu können. Wir schieben das Script einfach mit scp nach /tmp (da is platz, weil RamFS) auf den Router, loggen uns per SSH drauf, und flashen den Router:

„-n“ sorgt dafür, dass keine Konfiguration vom alten Firmwarestand übernommen wird. Nach abschliessendem Reboot ist unser Scanserver dann eigentlich auch schon soweit. Ob das Update auch vom OpenWRT-Webinterface aus oder gar vom TP-Link Webinterface aus funktioniert, kann gut sein, habe ich aber nicht getestet. Von daher auf eigene Gefahr…

Abschliessende Konfiguration

Wie man sich auf einem frischen OpenWRT einloggt, erkläre ich jetzt hier mal nicht, dazu gibt es genug Dokumentation online. Wenn man von einer vorigen Installation seine SSH-Keys und Konfiguration wiederverwendet hat, kommt man eh einfach per SSH wie zuvor auf den Router, ansonsten muss man sich ggf. mit Telnet und TFTP behelfen. Weiter im Text; wenn wir uns auf dem Router eingeloggt haben, können wir mal unseren Scanner anstöpseln, und gucken, ob der auch richtig erkannt wird:

Wenn der Scanner nicht erkannt wird, kann es daran liegen, dass die Sane-Treiber fehlen. die kann man aber auch noch jetzt nachinstallieren, wenn nötig. Für meinen Canon DR-2080C Scanner brauchte ich das Paket „sane-canon_dr“. Da i.d.R. nur ein Scanner angeschlossen ist, muss dieser im Scan-Script auch nicht unbedingt dediziert angegeben werden; es wird dann der einzig verfügbare benutzt.

Auch muss man ggf. überprüfen, ob die Skripte noch mit chmod ausführbar gemacht werden müssen. Ich erinnere mich ehrlich gesagt nicht mehr so ganz daran, aber ich glaube die Skripte haben die Berechtigungen, die sie auch vor dem Bauen des Images hatten, aber das ist ja nun kein Hexenwerk.

Conclusion

Das ganze Konstrukt funktioniert wirklich hervorragend und ohne größere Macken, und ich bin sehr zufrieden mit dem Ergebnis. Ein kleines Manko bleibt jedoch: Direkt nach dem Booten wird die Position des Schalters noch nicht richtig angezeigt, erst nach einmaliger Betätigung des Sliders. Um dafür Abhilfe zu schaffen, wollte ich in der /etc/rc.local einmalig den Status auslesen und entsprechend die LED setzen, aber das hat aus unerfindlichen Gründen nicht funktioniert. Vermutlich habe ich einfach irgendwas übersehen. Wenn jemand eine Lösung für dieses Problem hat, dann immer her damit.

Auch ärgert es mich ein bisschen, dass ich auf Wlan verzichten muss wegen dem sehr eingeschränkten Platz auf dem Router. Ich benutze hier aus mehreren Gründen eh ein Kabel, aber ich finde doch es schränkt einen etwas ein, denn die meisten Menschen haben ja (leider) keine feste Netzwerkverkabelung zu Hause, sondern benutzen weitestgehend WLAN. Eventuell findet ja noch jemand was, was man einsparen kann, damit es fürs WLAN reicht, aber ich habe da nicht mehr so genau nachgeforscht, da ich ja wie schon erwähnt eh ein Kabel benutze.

An dieser Stelle auch noch mal ein Dank an Ronald, auf dessen Idee ich dieses Projekt hier aufgesetzt habe 🙂 .

-zeus