Archiv für den Monat: Februar 2017

info-beamer-nodes auf dem Raspberry Pi laufen lassen

Schon eine ganze Weile lang steht im Verschwoerhaus mein alter Fernseher, der per HDMI und info-beamer-pi mit Inhalten beschickt wird – bisher fast nur Platzhalter, ein paar Bilder, die Uhrzeit.

Das wollte ich schon lange mal huebscher machen. So wie die Infoscreens beim Congress zum Beispiel. Mit kommenden Veranstaltungen. Und was da alles dazugehoert. Wann immer ich da aber eingestiegen bin, kam ich mir wie beim wildesten Yak Shaving vor: Die neueren Beispiele fuer info-beamer-Displays sind allesamt Packages fuer info-beamer-hosted, und so einfach laufen die nicht auf einem Pi, wenn man die Architektur von -hosted nicht kennt.

Nachdem ich aber heute ein paar der Fallstricke herausgefunden habe, hier mal fuer die Nachwelt erhalten:

In der Regel gibt es zwei bis drei Dinge zu beachten. Erstens: Beim Start von python2 service bricht der Prozess mit folgender Fehlermeldung ab:

[hosted.py] updated config
initialized hosted.py
Traceback (most recent call last):
  File "service", line 11, in <module>
    from hosted import CONFIG, NODE
  File "/home/pi/package-gpn15/hosted.py", line 184, in <module>
    NODE = Node(os.environ['NODE'])
  File "/usr/lib/python2.7/UserDict.py", line 23, in __getitem__
    raise KeyError(key)
KeyError: 'NODE'

Hier fehlt die Umgebungsvariable, wie der node heisst, an den die Uhrzeit geschickt werden soll. Das ist der root-node, der sich ueber die Konsole recht leicht ermitteln laesst:

In diesem Fall hilft ein vorheriges export NODE=package-gpn15 und alles funktioniert.

Zweitens: Die Config-Dateien. Die muessen aus den meist vorhandenen config.example.json angepasst werden. Was fuer den Fahrplan hilft ist ein Link auf ein frab-XML(!) in schedule_url in der config.json. Entweder ein kommendes Event aussuchen, das seinen Fahrplan ueber frab ausspielt, oder selber eins bauen. Das service-Script laedt das dann herunter und baut es in das etwas eigene json-Format um. Im package-conference-room-Readme ist das tatsaechlich beschrieben, das muss man aber erstmal finden 😉

Die 33c3-Infoscreens habe ich so leider trotzdem nicht zum Laufen bekommen, da ist die Konfiguration wohl noch ein wenig anstrengender. Aber immerhin verstehe ich jetzt ein wenig besser, wie info-beamer funktioniert. Jetzt muss ich nur noch herausfinden, warum der Bildschirminhalt trotz aller Overscan-Einstellungen ueber den Bildschirmrand hinauslaeuft (also keine schwarzen Rahmen, die gibts allenfalls in der Konsole, sondern abgeschnittene Raender rundum)

/edit: Rausgefunden, wie das mit den Raendern geht: X- und Y-Nullpunkt und dann die horizontale und vertikale Skalierung anpassen. In unserem Fall:


export INFOBEAMER_TARGET_X=50
export INFOBEAMER_TARGET_Y=30
export INFOBEAMER_TARGET_W=94%
export INFOBEAMER_TARGET_H=94%

Offene Daten für den Einzelhandel

Man kann eine ganze Reihe von Gruenden finden, warum man etwas im lokalen Einzelhandel und nicht online kauft. Weil man nicht dazu beitragen will, dass Menschen Robotergleich durch Versandzentren gescheucht werden, beispielsweise. Oder weil es um die Arbeitsbedingungen bei den Paketdiensten oft nicht besser ist. Oder weil man generell einen Wert darin sieht, vor Ort noch Ladengeschaefte zu haben – und die eben auch Umsatz brauchen, um zu ueberleben. Politischer Konsum, ganz klassisch.

In Ulm scheint man der Ansicht zu sein, den Einzelhandel vor allem durch Fahrspuren fuer Autos foerdern zu koennen. Weil, so die Logik, Leute ja staufrei mit dem KFZ in die Innenstadt fahren wollen, um dann zu konsumieren. Die angedachte Reduktion der Friedrich-Ebert-Strasse von vier auf zwei Fahrspuren wurde denn gleich als Untergang des Einzelhandels gebrandmarkt – egal was die verkehrsplanerische Vernunft sagt, denn das Braess-Paradoxon ist eben mal kontraintuitiv.

Aus Sicht einer, aeh, vielleicht mehr netz- als autoorientierten Generation laege die Loesung aber ganz woanders. Die Schmerzen bestehen fuer mich viel mehr darin, dass ich mich gar nicht damit beschaeftigen will, wo ich denn nun mein gewuenschtes Produkt im stationaeren Einzelhandel bekomme und wie ich da hinkomme. Je niedriger diese Schwelle ist, desto einfacher wird der Amazon-Verzicht. Eine Bierlaunenidee war da schnell gefunden:

Offene Daten ueber offene Schnittstellen aus dem Einzelhandel, dazu Soll-Fahrplandaten im GTFS-Format – damit waere das Feld bestellt, auf dem beliebige Browserplugins geschrieben werden koennten, um dem Ziel naeherzukommen.

Wie sich wenige Tage spaeter herausstellte, gibt es so etwas tatsaechlich schon:

Zugegeben, fuer den Buecher-Anwendungsfall ist die Angelegenheit etwas einfacher – jedes Buch laesst sich ja eindeutig ueber seine ISBN identifizieren, und quasi alle Bibliotheken haben irgendeine Form von OPAC, in den sich die ISBN fuettern laesst. Bei anderen Produkten ist das schwieriger aufzuloesen – und vor allem hat der Einzelhandel auch bislang seltenst ueberhaupt Schnittstellen fuer sein Inventar. Geschweige denn in standardisierter Form.

Langfristig waere aber genau das der richtige Ansatz: Offene, standardisierte Schnittstellen. Auf deren Basis dann jemand beispielsweise als Radkutschenkurier sein eigenes Geschaeft aufbauen kann, um entweder binnen einer Stunde die gewuenschte Ware aus dem Laden in der Stadt nach Hause liefert.

Das wird nicht gleich morgen entstehen, und es beraubt einen des befriedigenden Gefuehls der Geschaeftigkeit, das man beispielsweise beim Einrichten von Portalen hat (niemand braucht und/oder nutzt Portale). Geschaeftigkeit ist aber nicht Produktivitaet – und was ich fuer die nachhaltigere Loesung halte, duerfte klar sein, oder? 😉