Blog

(die #coronalearnings von z/da, eine blogpostserie)

Wir entführen diesen Blog kurzzeitig, um in den kommenden Wochen hier festzuhalten, wie die Digitale Agenda der Stadt Ulm auf die Covid-19-Pandemie reagiert. Im Nachhinein sind die Maßnahmen nicht mehr so einfach zeitlich zuzuordnen – zu viel ist zu schnell passiert, und nicht nur bei uns.

In der letzten Februarwoche haben wir begonnen, Worst-Case-Szenarien zu skizzieren: Was passiert eigentlich, wenn eine Infektionskrankheit einmal durch die Bevölkerung wandert und dabei auch die Funktion der öffentlichen Verwaltung mit ihrer starken Präsenzkultur stark einschränkt? Die Digitale Agenda ist dabei für Ulmer Verhältnisse relativ stark aufgestellt: Alle von uns haben Laptops und Möglichkeiten, mobil zu arbeiten. Es muss aber klar sein, dass dieses Prinzip auch bei kritischen Einrichtungen der Stadt durchgezogen werden können muss. Mein Lieblingsbeispiel ist die Stadtkasse, die auch bei weitgehender Isolation und mobilem Arbeiten der Beschäftigten noch in der Lage sein muss, Zahlungen und Bezüge anzuweisen, damit Menschen nicht finanziell auf dem Trockenen sitzen – diesen Fall habe ich auch auf Twitter mehrfach thematisiert, und die weitgehend ausbleibende Reaktion aus Verwaltungstwitter machte mich sehr nachdenklich.

Wir haben unsere Bedenken Stadt-intern in der ersten Märzwoche weitergemeldet und auf die schnelle Ausrollung mobiler Arbeitslösungen gepocht. Gleichzeitig haben wir Vorbereitungen getroffen, auf eine Losung hin quasi sofort ins mobile Arbeiten abtauchen zu können, um selber kein Infektionsvektor zu sein, wenn wir weiter zu mehrt in einem Büroraum sind.

In der zweiten Märzwoche haben wir auch im Verschwörhaus Maßnahmen ergriffen. Spannend anzusehen war der Effekt, dass die jeweilige Maßnahme bei der Planung erst einmal drastisch klang, einen Tag später bei der Umsetzung mindestens geboten wirkte und meist noch einen Tag später komplett überholt war. Am Dienstag (10.3.) wurde die namentliche Registrierung von Anwesenden überlegt und am Mittwoch (11.3.) nach Absprache mit den Ehrenamtlichen vollzogen. Donnerstag morgen (12.3.) wurde die prophylaktische Schließung des Hauses diskutiert, am Freitag (13.3.) für vorerst eine Woche verkündet, am Samstag (14.3.) griff die Allgemeinverfügung der Stadt und verlängerte die Schließúng bis Mitte April, und Dienstags (17.3.) darauf verlängerte die CoronaVO der Landesregierung eventuell die Schließung bis zu ihrem Außerkrafttreten im Juni – wir sind uns nicht 100% sicher, um ehrlich zu sein.

Seit eben diesem Freitag, dem 13. März, ist auch die Digitale Agenda weitgehend im „mobilen Arbeiten“. Das ist wohlgemerkt nicht dasselbe wie „Telearbeit“, wo die Bestimmungen der ArbStättV und des ArbSchG greifen würden – was womöglich diverse Arbeitgeber auch erst einmal davon abgehalten hat, die Fürsorgepflicht gegenüber den eigenen Beschäftigten so wahrzunehmen, dass sie mobil arbeiten und somit vor einer Rolle als Glied in der Infektionskette geschützt sein können.

Im Haus ist bei uns seither nur noch eine Rumpfmannschaft, um diejenigen Dinge zu bearbeiten, die wirklich zwingend physische Präsenz erfordern: Die Post bearbeiten, Pakete entgegennehmen, … Blumen gießen (nicht vergessen!)

Wir haben in den vergangenen 1,5 Wochen viel gelernt. Nicht vergessen werden darf, auch der Teil der Verwaltung, der den Rest der Verwaltung ins 21. Jahrhundert bringen soll, wird in der Regel und in der Breite nicht an der allervordersten Speerspitze der Digitalisierung mitmarschieren (das 21. Jahrhundert ist ja jetzt auch schon eine Weile alt). Selbst die Digital-affinsten Verwaltungsbeschäftigten können hier noch etwas lernen. Das ist auch nicht schlimm – schließlich zeigt das die noch bestehenden Klüfte auf, und aus denen lässt sich ganz hervorragend lernen, wo noch Potenzial ist.

Werkzeuge

Keine Übersicht ohne Tooldiskussion, klar. Wie kommunizieren wir seither?

Gruppenchat: Slack (eher per Zufall)

Für diverse Projekte mit Externen hatte die Digitale Agenda sich schon im Sommer 2019 einen kostenlosen Slack-Plan geklickt. Vorher gab es diversen Austausch im Verschwörhaus-Slack, der ist aber 1. durch den gemeinnützigen e.V. noch einmal in einer Sonderrolle, und 2. ist die Durchmischung von Arbeits- und Ehrenamtsslack vermutlich eher ungut. Erste Schritte waren also, alle Beschäftigten von Z/DA in den eigenen Slack-Workspace zu holen und diverse neue Kanäle einzurichten:

• #zda-daily ist der Guten-Morgen-Kanal: Wer mit der Arbeit anfängt, postet ein kurzes :wave:-Winkeemoji mit den anstehenden Aufgaben des Tages, die sie/er sich vorgenommen hat. So bekommt man noch ein wenig Flurfunk mit, was derzeit so passiert. (Idee vom Datenteam des Bayerischen Rundfunks geklaut)
• #zda-anleitungen ist der Kanal für Screenshare-Anleitungsvideos für die gerade frisch eingeführten Workflows (dazu später mehr)
• #zda-inbox als Hinweiskanal auf neue, digitalisierte Snailmail (dazu auch später mehr)
• #zda-random als Ort für Giphys und Katzenvideos (Moral ist wichtig!)

Lektionen:

• Nicht alle Workflows, die für Teamchat-Erfahrene intuitiv sind, sind das auch für EinsteigerInnen. Gerade der Punkt, möglichst weitgehend auf (Gruppen-)DMs zu verzichten und viel in öffentlichen Kanälen oder ggf. hierfür eingerichteten geschlossenen Kanälen zu kommunizieren, muss trainiert werden.
• Kurze Videos zu Dingen wie Netzlaufwerke einbinden, Unterschriften im PDF-Reader einrichten und andere frische eingeführte Workflows eignen sich super. Für uns hat eine Aufnahme mittels OBS Studio und Kompression durch Handbrake wunderbar funktioniert, um kleine 500kb-Videos schnell allen im Slack zugänglich zu machen.
• Auch andere Einrichtungen stürzen sich jetzt auf Teamchat-Systeme wie Slack oder MS Teams. Hier gilt es unbedingt, mögliche Lock-in-Effekte mitzubedenken und entweder Gegenstrategien für Zeiten mit mehr Luft oder aber die passenden langfristigen Finanzmittel einzuplanen! Ich schreibe das Fett, weil es unglaublich wichtig ist. Irgendwann ist das 10000-Nachrichten-Limit bei Slack erreicht, und alte Nachrichten sind nicht mehr auffindbar. Das heißt, dass Ergebnisse von Austausch auch in anderen Kanälen (Mail o.ä.) noch einmal festgehalten werden muss.
• Wer die Möglichkeit hat, ggf. ein eigenes Mattermost oder Rocket aufzusetzen und zu pflegen, soll sich auch diese Möglichkeit intensiv ansehen. Und sich dann bei mir melden für Erfahrungsaustausch. Bei Jugend hackt wird seit einer Weile Zulip als Freie Variante für die Kommunikation mit den Jugendlichen benutzt und ich bin recht zufrieden mit dem System.

Videokonferenz: Erst Jitsi, jetzt BigBlueButton

Die zweite Frage war, wie wir gemeinsam weiterhin Besprechungen und Austausch ohne physische Kontakte durchführen. Auf Twitter werden gerade einige kommerzielle Produkte sehr gelobt – uns war aber wichtig, auch hier keine Lock-In-Effekte einzuführen, sondern eine Interimslösung herzustellen, mit der wir akut leben können.

Cave: Wir haben die Möglichkeit, im Verschwörhauskeller auf eigener Hardware und mit 10Gbit-Uplink ruckzuck eigene Testsysteme hochzuziehen. Die Nachvollziehbarkeit unserer Erfahrungen hängt also davon ab, ob man selber auch entweder physisch oder irgendwo bei einem Dienst geklickt auf die Schnelle Maschinen hochziehen kann.

Getestet haben wir nach und nach folgende Systeme:

Jitsi basiert auf Freier Software und offen durchspezifizierten Protokollen wie XMPP/Jingle, SIP, WebRTC und Co. Neben Videotelefonie und verschlüsselten OTR-Textnachrichten geht auch Screensharing einer vortragenden Person. Zuerst hatten wir die öffentliche Jitsi-Meet-Instanz ausprobiert – das scheiterte an den städtischen Firewallregeln. Deswegen musste eine Instanz unter eigener Kontrolle her.

Bei der Installation fielen ein paar Probleme mit IPv6 im Dual-Stack-Betrieb auf, sodass sehr lange verwirrung bestand, warum die Ausstellung von TLS-Zertifikaten bei Lets Encrypt nicht funktionieren wollte. Die Maintendenden sind aber mittlerweile dran. Grundsätzlich scheint Jitsi auch recht freizügig mit der Datenrate bei Videos umzugehen; wir hatten immer wieder mal Aussetzer bei Leuten hinter schwachbrüstiger Anbindung. Das ist in jedem Fall kein Vergleich zu den derzeit hochgelobten proprietären Lösungen.

Whereby ist eine von drei kommerzielle Lösung, die wir zum Testen einfach einmal ausprobiert haben – und die einzige davon (unter anderem das anderswo so hochgelobte Zoom), die durch die städtische Firewall kam.

In diesen Zeiten zeigt sich wieder das Problem, dass so moderne Zahlweisen wie Kreditkarten (wie sie eben bei Onlinediensten üblich sind) nicht in das Raster kommunaler Zahlprozesse zu fallen scheinen. Wie nachhaltig die Buchung über private Kreditkarten und Auslagenerstattungen sind, ist unklar. Wir sind uns nicht sicher, ob das wirklich so ein absoluter Grundsatz ist, oder vielmehr eine Mentalitätsfrage – bei der Buchung im DB-Geschäftskundenportal scheinen kommunale Kreditkarten ja magisch auch möglich zu sein, habe ich gehört.
Zum Dienst selber gibt es wenig zu sagen. Streamt. Tut. Wir haben Dinge gelernt, was alles im Stadtnetz nicht geht (mehr dazu weiter unten).

Zuletzt testeten wir BigBlueButton (kurz BBB. Die Seite ist oft überlastet, siehe auch Wikipedia), ebenfalls freie Software, die ursprünglich aus dem E-Learning bzw. dem universitären Umfeld kommt. Hier kommen im Hintergrund ebenfalls WebRTC und Co. zum Einsatz – ein großer Unterschied ist, dass der ganze Telefoniepart im Hintergrund über FreeSWITCH läuft. Theoretisch können hier recht einfach SIP-Trunks für die telefonische Einwahl zu Räumen einkonfiguriert werden. Bei uns scheiterte das bislang daran, dass wir die in der Ausrollung befindliche UC-Lösung der Stadt derzeit nicht von einem Stadtnetz-externen Verschwörhausserver als SIP-Registrar verwenden können, und für die Verifizierung eines bei kommerziellen Anbietern klickbaren neuen SIP-Trunk-Accounts brauchts eine postalische Bestätigung, weswegen wir das erst einmal verschoben haben.

Von BBB bin ich persönlich sehr angetan. Screensharing funktioniert recht gut; als PräsentatorIn kann man aber auch eigene Slidedecks/PDF hochladen und auch live darin herumzeichnen. Man sieht hier sehr die Herkunft aus der Lehre; so sind z.B. auch Abstimmungen im Raum möglich, und mehrere PräsentatorInnen können gleichzeitig im Deck malen. Auch die Integration in verschiedenste Lernplattformen ist vorgesehen. Das Sharing mehrerer Screens gleichzeitig geht aber meines Wissens hier nicht.

In der von uns ausgerollten Installation bei uns kann jedeR einen BBB-Raum eröffnen, analog zur öffentlichen Instanz von Jitsi Meet. Die Software dafür haben wir auf GitHub veröffentlicht. Wer den Raumnamen kennt, kann teilnehmen. BBB bietet aber verschiedenste Management-Varianten an, z.B. dass nur privilegierte User Räume einrichten können, Passwörter je User, etc pp.

Lektionen:

• Nicht per Kreditkarte bezahlen zu können, ist schlichtweg ein Problem, das es zu lösen gilt. Mich persönlich interessieren die Probleme auf dem Weg dorthin nicht – ich will eine Lösung sehen.
• BBB ist ein bislang sehr schick wirkendes Werkzeug, das wir in den kommenden Tagen in den Lasttest schicken werden. Spannend finde ich auch, dass die Teilnehmenden selber die Qualität des eigenen Videofeeds festlegen können.
• Wichtig ist bei der Einführung, den KollegInnen einen Crashkurs in Video-Telko-Etikette zu geben. Das heißt zum Beispiel, unbedingt Headsets (oder allerallermindestens Kopfhörer) zu benutzen, die Mute-Funktion und Push-to-talk diszipliniert zu verwenden, mit dem Audiorouting der eigenen Geräte vertraut zu sein (z.B. Auswahl des richtigen Eingabegeräts), und wirklich vorher das eigene Setup zu testen und nicht regelmäßig die ersten Minuten der Konferenz damit zu verbringen. mediale pfade haben eine Anleitung zusammengestellt, wie gute Videotelko-Etikette funktioniert. BBB hat hierfür z.B. eine Handhebe-Funktion für Meldungen zu Wortbeiträgen über die Status-Funktion. Die durch die Moderation zu erkennen ist aber noch nicht so sehr intuitiv und bedarf guter Aufmerksamkeit. Workarounds sind z.B. der Raumchat.
• An vielen Stellen hakte der Rollout an Portsperrungen, Zwangsproxy oder alten Browserversionen im städtischen (VPN-)Netz. In der Citrix-Umgebung der Stadt läuft z.B. derzeit noch ein Firefox 45.5.0esr, damit ist man schlicht aufgeschmissen. Auch für Chrome müsste in einer Remote-Umgebung Citrix richtig konfiguriert werden. Für einen schnellen Test, ob im eigenen Netz WebRTC ordentlich tut, lässt sich dieser Test nutzen. Nicht immer steckt hinter der IT-Sicherheit in Verwaltungsnetzen ein ernsthaftes Threat model, sondern der Grundsatz „wir machen außen erstmal alles zu und jede Abweichung davon ist böse und wenn dann eine Ausnahme, weil wir die Geräte und Dienste innen als verwundbar ansehen“. Die Annahme geht natürlich nur solange gut, wie man den äußeren Schutzmaßnahmen vertrauen kann (i.a.W. gar nicht).

Dateiaustausch und Co

Hier sind wir in der glücklichen Lage, TestnutzerInnen der städtischen OwnCloud zu sein. Das heißt, dass wir gemeinsam Ordner teilen, Filedrops realisieren und auch auf den vielfach von uns genutzten Privatgeräten automatisch synchronisieren können (einige von uns brauchen für die eigenen Aufgaben eine zsh um arbeiten zu können, und das geht derzeit auf Stadtrechnern nicht). In der Owncloud läuft auch Onlyoffice, und das funktioniert derzeit alles sehr zufriedenstellend.

Ergänzend hat der Code-for-Germany-Einfluss aus dem Verschwörhaus dazu geführt, dass wir im Sachgebiet sehr intensiv Cryptpads verwenden; genauer gesagt die Code-Variante, mit der sich Markdown samt Vorschau schreiben lässt. Markdown ist intuitiv genug, dass es sich recht schnell bei den KollegInnen einführen ließ, und nur die komplizierteren Sachen bedürfen Hilfe (Klassiker ist der Zeilenumbruch mit zwei Leerzeilen).
Wir schreiben während Besprechungen schon länger gemeinsam die Protokolle im Markdown-Cryptpad; nach Besprechung und Protokoll-Kontrolle wird das .md-File exportiert und gemeinsam mit einem PDF im Laufwerk als yyyy-mm-dd xyprotokoll abgelegt. (Das PDF wird entweder lokal mit Pandoc erzeugt oder über die Druckfunktion exportiert oder mit einem beliebigen md-to-pdf-Konverter online „ausgedruckt“. Längerfristiges Ziel ist generell Dokumente in Markdown zu schreiben und einen eigenen Stadt-Ulm-Style für die LaTeX-Konvertierung nach PDF zu haben.)

Standardmöglichkeit, remote ins Stadtnetz zu kommen, sind aber VPN und wenn gewollt Citrix Receiver. Hier war bislang unintuitiv, dass man nicht den Remotedesktop starten muss, um z.B. auf die Netzlaufwerke zugreifen zu können, sondern dass diese nach dem VPN-Start auch per kleinem Script eingehängt werden können. Bewährt hat sich dafür ein Skripte-Ordner in der OwnCloud, samt Screencasts mit Anleitungen, wie was auszuführen ist.

Für die Kommunikation mit einigen anderen Projektpartnern sind außerdem bereits seit einiger Zeit Bitrix24 und kostenlose Trello-Boards im Einsatz. Zu Bitrix kann ich wenig sagen, weil ich es bislang kaum genutzt habe. Trello… ist halt Trello. In Zeiten, wo wir nicht mehr gemeinsam vor Post-Its sitzen können, ein gutes Werkzeug. Nein, Post-Its sind keine Marker für „Innovation™“

Lektionen:

• OwnCloud ist gut
• Es lohnt sich sehr, mit IT- und UX-Brille Prozesse anzusehen und sich beschreiben zu lassen, wo Dinge brechen. Vielfach wurden Dinge lange als „ist halt so“ hingenommen, die sich mit wenig Aufwand scripten und stromlinienförmiger gestalten liessen.

Abläufe und Zwangsdigitalisierung

Durch das weitgehende Remote-Arbeiten konnten wir die Gelegenheit am Schopfe greifen und weitere Prozesse betrachten, die bislang händisch funktionierten.

Die Post ist da

Zunächst möchte ich hervorheben, dass wir kein Fax haben.

…

Wir bekommen aber Post. Bislang landete die an mehreren Stellen: Im Vorzimmer des Oberbürgermeisters (Rathaus); im Büro des Leiters der Zentralstelle (Rathaus); im Briefkasten Hausnummer 7; im Briefkasten Hausnummer 9. Da das Rathaus jetzt für den Publikumsverkehr ohne Anmeldung geschlossen ist, wurde wenigstens der Rathaus-Teil vereinheitlicht: Post landet in der Botenmeisterei und kann uns gegen Dienstausweis-Vorlage durchs Fenster gegeben werden.

Da die meisten EmpfängerInnen der Briefpost aber remote arbeiten, haben wir folgenden Workflow gebaut:

1. Die Bürobesetzung vom Dienst öffnet die Post und eingangsstempelt sie, sofern es sich um dienstliche und nicht nur persönlich zu öffnende Post handelt (siehe hierzu auch den heiteren Leitfaden „Ein Brief geht ein – was nun?“ von Burkhard Oerttel, insbesondere die praktische Übung auf Seite 9)
2. Die Post wird durch den Verschwörhausscanner gejagt. Dort ist ein Shortcut im Bedienfeld, der den Scan auf ein Netzlaufwerk lädt.
3. Dadurch wird a) das PDF per WebDAV-Anbindung in den Snailmail-Posteingangsordner der Owncloud geladen, und b) im #zda-inbox-Slackkanal eine Nachricht durch den Scan-Bot ausgelöst, dass neue Post vorliegt. Per Emoji kann angezeigt werden, dass das Poststück bearbeitet wird/wurde. Sobald es halbwegs gut dokumentiert ist, kommt das Script auf Github :-x

Rechnungen und Dedigitalisierungsprozesse

Viele der eingehenden Poststücke bei uns sind Rechnungen. Der Prozess bei der Stadt ist, dass Rechnungen auf Papier sachlich und rechnerisch richtig gestempelt werden, auf dem Stempel Kostenstelle/Innenauftrag/Sachkonto, Rechnungsbetrag und SachbearbeiterIn ausgefüllt werden, und das Papier dann ins Rathaus getragen wird. Irgendwo passieren dann magische Dinge mit Controlling und SAP, und am Ende geht das alles zur Kasse, die die Auszahlung vornimmt.

Wir hätten jetzt also Prozesse, wo Rechnungen digitalisiert werden (wenn sie nicht eh digital kommen), irgendwann werden sie dann nochmal ausgedruckt, um einen Stempel zu bekommen, und wie wir nach Ende unserer Prozessüberarbeitung herausgefunden haben, werden sie am Ende im Rathaus nochmal gescannt, weil die Übertragung zur Kasse digital erfolgt.

Weil wir der Überzeugung sind, dass ein Digitalisierungs- oder Dedigitalisierungsprozess in der ganzen Prozesskette maximal ein einziges Mal stattfinden sollte, haben wir einfach den Stempel digitalisiert. Im PDF-Reader der Wahl wird der Stempel digital aufgedrückt, über die Formularbearbeitung die notwendigen Zahlen eingegeben, und der angenehme Nebeneffekt eines Convertibles ist, dass man darauf mit dem Stift auch unterschreiben kann. Das muss ja auch hinreichend rechtsgültig wie die Kuli-Unterschrift sein – denn sonst wären ja sämtliche rechtsverbindlichen digitalen Prüfungsanmeldungssysteme an Universitäten überhaupt nicht zulässig ;)

Die Rechnungen laufen nun also ab dem Moment, wo sie bei uns ankommen, durch einen digitalen Prozess und werden nicht mehr auf Papier, sondern digital ins Rathaus geschickt – wo man nun einen Scan-Prozess einspart. Derzeit rollen wir noch einen Rechnungstracker aus wie wir ihn von Jugend hackt kennen – schlicht ein Spreadsheet, um den Status der Bearbeitung pro Dokument festzuhalten.

Idealerweise würde so etwas natürlich in einem DMS mit digitaler Freigabe laufen. Hamwa aber noch nicht in der Breite ausgerollt bekommen.

Lektionen:

• Das läuft bislang sehr angenehm.
• Grundsatzfrage ist hier natürlich, ob sowas nicht generell als Dienst der Poststelle für alle nicht persönliche Post ausgerollt werden könnte. Siehe auch DMS-Rollout.
• Der offizielle Stadtdrucker kann das mit dem WebDAV-Scan nicht machen, weil er dafür ins Internet kommen können müsste, und das beisst sich mit dem ~Threat Model~ Vernagelungskonzept

Sonstige Erkenntnisse

• Wenn man Outlook bzw. Exchange benutzt und Funktionspostfächer hat, macht das ggf. Probleme, wenn die nicht auch im Mobiltelefon-Client eingehängt sind
• Wichtig auch: Abwesenheitshinweise in Exchange bei anderen setzen können, wenn diese ausfallen
• Genauso automatische Antworten für Funktionspostfächer setzen können

Und zum Schluss: Kommunikation und Kultur generell

Es zeigen sich gerade je nach Organisation sehr große Unterschiede, wie mit der Situation umgegangen wird. Die Bandbreite reicht von der Verkündung aktueller Entscheidungen (die sich aufgrund der Dynamik der Lage auch schnell ändern) bis hin zu einer umfangreichen Erklärung und Begründung der Entscheidungen. Ein schönes Beispiel ist aktuell das Studierendenwerk Ulm, das auch die „internen“ Informationen für die Beschäftigten sehr transparent der gesamten Öffentlichkeit zeigt. Hierzu kommt aber eventuell noch ein weiterer Post mit einem Wunschzettel, was Verwaltungen (oder ArbeitgeberInnen generell) bieten könnten und sollten :)

Hashtag DankeCivicTech

Ganzganzganz zum Schluss: Ich bin gerade sehr froh über die Anbindung der Digitalen Agenda an die Civic-Tech-Szene über das Verschwörhaus. Das seit Mitte letzten Jahres laufende Fellowship-Programm, mit dem wir im Rahmen von Code for Germany entstandenen Ideen als Stadt weiter verfolgen, macht uns gerade als Stadt sehr viel handlungsfähiger beim schnellen Umsetzen von Notmaßnahmen. Unser längerfristiges Ziel war, sowohl solche Fellowships wie auch feste Stellen nicht nur für die Umsetzung von Förderprojekten, sondern eben auch für die vollkommen freie Umsetzung schrittweiser Verwaltungsdigitalisierung in Zukunft fest vorzuhalten. Gerade scheint eine gute Gelegenheit, den Nutzen solcher Konstrukte praktisch vorzuführen.

Zur Adresssuche benutzt digitransit den OpenSource-Geocoder Pelias. Leider wird dieser nach dem Ende von Mapzen so gut wie nicht mehr weiter entwickelt. Außerdem hatte Pelias in unserer Instanz Probleme bei der Zuordnung von administrativen Grenzen. Da Pelias die Daten dafür nicht aus Openstreetmap bezieht, erschwerte dies uns die Analyse und Lösung des Problems.

Glücklicherweise gibt es alternativ zu Pelias noch Photon, welcher eine vergleichbare API für suggest-as-you-type-Adresssuche anbietet. Da Photon auf dem Importer des Standard-OpenStreetMaps-Geocoder Nominatim basiert, ist die Auswertung der OpenStreetMap-Daten entsprechend ausgereift.

Leider sind die APIs von Pelias und Photon unterschiedlich, das Featureset aber ähnlich. Um Photon alternativ als Geocoder in digitransit benutzen zu können haben wir deswegen einen kleinen Adapter gebaut, der die aus digitransit kommenden Anfragen in einen Photon-Request und die Antwort aus Photon wieder zurück in das Pelias-Format übersetzt.

Es werden nicht alle Funktionen von Pelias unterstützt, sondern hauptsächlich die Funktionen, welche von digitransit benutzt werden. Der zusätzliche Verarbeitungsschritt kostet natürlich etwas Zeit, was auf Kosten des Nutzererlebnis geht. Deswegen sollte der Adapter als Provisorium gesehen werden, bis digitransit von Haus aus einen anderen Geocoder unterstützt. Das Projekt ist auf GitHub zu finden.

Aktuell verbauen wir für den Test an unseren Rädern simple, durchaus schwere, Zahlenschlösser. Jedoch wären Schlösser, die sich von selbst öffnen können, ziemlich praktisch – und so haben wir doch wieder ein Auge auf die fertigen “smarten” Schlösser, die wir vor einiger Zeit schonmal zerlegt hatten geworfen.

Leider hatten wir bei dem Schloss wieder ein Befestigungsproblem, mit dem auch schon andere Bikesharer zu kämpfen hatten — es passte in unseren Versuchen einfach nicht an den Rahmen am Hinterrad, zudem war bei unseren Fahrradmodellen auch wieder die Hinterradbremse im Weg.

In Unterstützung durch den ADFC wurde dann ein Stück Gepäckträger gekürzt und das Rücklicht nach unten versetzt, sodass das Schloss jetzt einigermaßen stabil hinten am Fahrrad hängt.

An der Integration in den modularen OpenBike-Software-Stack sind wir gerade dran. So bauen wir gerade einen Adapter für cykel, um die Kommunikation mit dem Schloss unabhängig von der eigentlichen Sharingsoftware betreiben zu können. Das Repository und erste Tests für die Protokollimplementation gibt es unter cykel-lock-b10.

---

Wer jedoch nur mit dem Schloss reden möchte, ohne gleich ein ganzes cykel + adaptern aufsetzen zu müssen, oder einfach flott experimentieren möchte, kann auf Traccar zurückgreifen. Das ist ein Open Source System zur Kommunikation mit einer ganzen Reihe von unterschiedlichen GPS-Trackern, meist eher mit (Auto)fahrzeug-Fokus.

Traccar hat uns auch geholfen, um das Protokoll des Schlosses grundlegend zu verstehen. In den Logs taucht dort die komplette Kommunikation als Hexdumps auf, was auch super für test-driven Development ist, um herauszufinden, ob unser Parser schritt-für-schritt die Pakete richtig geparst bekommt.

Um selbst mit Traccar und einem Schloss loslegen zu können, reicht die Installation von Traccar nach Anleitung auf einer Maschine mit öffentlicher IPv4-Adresse.
Zudem braucht das Schloss eine SIM-Karte, die in den Netzen am Verwendungsort funktioniert und Konfiguration für die Adresse und der Port des eigenen Traccar-Servers. Das wechseln der Simkarte hat der Hersteller gut bebildert dokumentiert.

Die Konfiguration erfolgt entweder per SMS (haben wir bislang nicht getestet) oder mit dem mitgeliefertem USB-Serial-Kabel: dazu den blauen Draht an den schwarzen halten, um das Schloss neuzustarten und die serielle Schnittstelle zu aktivieren. Mit 115200,8N1 verbinden, danach mittels AT^GT_CM=SERVER,0,<IP>,5023,0 (Format: Server, IP(0) oder DNS(1), IP/DNS-Name, Port, TCP(0) oder UDP(1)) den eigenen Traccar-Server hinterlegen. Traccar verwendet für das BL10 den Port 5023 um das kompatible gt06-Protokoll zu sprechen.

Das Schloss kann dann als neues Gerät in Traccar angelegt werden, die Gerätekennung ist die IMEI.

Über die Upload-Symbol-Schaltfläche über der Geräteliste lassen sich Befehle an das Schloss senden. Im auftauchenden Dialog kommt man über Neu > Benutzerdefinierer Befehl dann zum Eingabefeld für das eigentliche Kommando: UNLOCK#

---

Lust darauf, selbst mehr vom Schlossprotokoll zu verstehen? In cykel-lock-b10 gibt es den Protokollaufbau und Tests dafür. Mehr Infos zu den Innereien und der verbauten Firmware haben wir schon mal aufgeschrieben. Wir sind auch weiterhin noch auf der Suche nach möglichst allen AT-Kommandos, die das Schloss versteht - falls ihr noch mehr findet, freuen wir uns gern über eine Nachricht.