… und Software
Die Software folgt dem bekannten MVC-Prinzip (Model-View-Controller). Das Rahmenprogramm (Controller) ruft regelmäßig einen Daten-Provider auf (v6-API, Update des Modells) und delegiert die Anzeige an den View. Wie das im Detail funktioniert, lesen Sie im Quellcode nach [3]. Hier geben wir lediglich ein paar Hinweise.
Neben den im vorherigen Abschnitt erwähnten Bibliotheken verwendet das Programm noch eine eigene Hardwareabstraktionsschicht. Dabei handelt es sich je nach unterstützter Hardware um eine kleine Python-Datei, die Zugriff auf LED, Bildschirm und Taster abstrahiert. Für eigene Hardware müssen Sie also zuerst die passende Datei erstellen, am einfachsten durch Kopieren und Anpassen. Falls das von Ihnen genutzte Display keine Tasten besitzt, dann bietet sich ein Fünf-Wege-Button an, den es für wenig Geld auf den üblichen Marktplätzen gibt.
Damit die Mikrocontroller mit der Anwendung zurechtkommen, gilt es, mit dem Speicher sorgfältig zu haushalten. Dazu gibt es diverse Tricks. Einer davon nennt sich json_stream. Der naive Ansatz, die Daten der v6-API aus dem Netz zu laden und dann zu verarbeiten, scheitert womöglich an der Größe der zurückgelieferten Datei. Mit json_stream extrahieren Sie Informationen aus dem Datenstrom, ohne die gesamte Datei im Speicher zu halten. Jedes Byte des Datenstroms kommt aber immer nur einmal vorbei.
Völlig unproblematisch ist der Ansatz nicht, denn die interessanten Attribute müssen zum einen immer vorhanden sein und zum anderen immer in der richtigen Reihenfolge vorkommen. Im Fall des Abfahrtsmonitors gehören dazu plannedWhen, delay und direction. Das Attribut cancelled kommt dagegen einmal vor, einmal nicht. Die Suche danach mit json_stream leert den Datenstrom im ungünstigsten Fall also ohne ein Ergebnis, und für die anderen Attribute ist es dann zu spät.
Beim Pico genügt der Weg über json_stream aber noch nicht. Hier hilft ein automatischer Neustart vor jeder Datenabfrage. Wegen der minimalen Boot-Zeit des Mikrocontrollers fällt das jedoch nicht nennenswert ins Gewicht.
Fazit
Die Datenbeschaffung stellte sich letztlich doch als einfacher heraus als befürchtet. Auch wenn die Daten nicht perfekt sind, sie entsprechen in ihrer Qualität denen der offiziellen Webseiten beziehungsweise Apps. Der Zugang zu den eigentlichen Quellsystemen ist aufwendiger und mit einem Antrag samt Projektbeschreibung verbunden. Unter Open Data versteht der Autor aber definitiv etwas anderes als die deutschen Verkehrsverbünde.
Damit reduziert sich die Hauptaufgabe auf die Darstellung der Ergebnisse. Das Programm des Autors verfolgt einen minimalistischen Ansatz, der aber viel Luft nach oben lässt. Hier können Sie einsteigen und Ihrer Fantasie und Kreativität Raum geben. Bei Farbbildschirmen könnten Sie zum Beispiel Verspätungen rot einfärben. Damit auch lange Haltestellennamen auf das Display passen, zeigen Sie die Einträge alternativ zweizeilig an. Auch ein Portieren des Projekts auf MicroPython oder C/C++ dürfte kein Problem darstellen, denn die grundlegende Logik ist in jeder Programmiersprache dieselbe. (tle)
Der Autor
Bernhard Bablok ist im Ruhestand. Wenn er nicht Musik hört oder mit dem Radl respektive zu Fuß unterwegs ist, beschäftigt er sich mit Themen rund um Linux, Programmierung und Kleinstrechner. Sie erreichen ihn unter mailto:[email protected].
Infos
- v6-API für die Daten: https://v6.db.transport.rest/api.html
- Kontaktdaten Verkehrsverbünde: https://www.opendata-oepnv.de/ht/de/api
- Projekt-Repo des Autors: https://github.com/bablokb/cp-departure-monitor
- pyHafas: https://github.com/FahrplanDatenGarten/pyhafas
- Blinka: https://circuitpython.org/blinka
- Pygame: https://www.pygame.org
- Badger 2040 W (Pico W): https://shop.pimoroni.com/products/badger-2040-w?variant=40514062188627
- MagTag (ESP32-S2): https://shop.pimoroni.com/products/adafruit-magtag-2-9-grayscale-e-ink-wifi-display?variant=39306825826387





