Mit LoRaWAN Lichter blinken lassen

Von stk | Veröffentlicht: 31. Mai 2017

Mir fiel die Tage auf, dass es wenige verstaendliche Anleitungen fuer LoRaWAN-Spielereien auf Deutsch gibt – was schade ist, weil a) die Technik zu Spielereien geradezu einlaedt und b) wir in Ulm ein recht enges Netz an Gateways haben.

Deswegen hier die kurze Dokumentation, wie wir ueber LoRaWAN Lichter an- und ausgeschaltet haben. Der verwendete Code ist vollstaendig auf github und ist zu ueberwiegenden Teilen von @Nitek geschrieben worden.

Teil 1: Der Empfaenger

Das wirkt jetzt etwas unintuitiv, aber weil das der einfachere und guenstigere Part ist, fangen wir mal mit dem Empfaenger an 😉

Verwendete Teile waren:

  • NodeMCU (oder WeMos D1 oder sonst irgendetwas ESP8266-basiertes)
  • WS2801-basierte RBG-LED-Lichterkette
  • Jumperkabel zum Verbinden der letzteren beiden Teile

Der Code basiert zu groessten Teilen auf dem Basic MQTT ESP8266 Example, und arg viel mehr ist es auch nicht. Der WiFiManager erspart uns, die WLAN-Credentials hart einzuprogrammieren, und am Ende geht es nur mehr darum, den passenden TTN-MQTT-Server einzutragen:

  • MQTT_USERNAME: Der Name der Application in der TTN-Console
  • MQTT_SERVER: Der URI des Handlers – laesst sich ueber die Application Settings in der TTN-Console ueber Settings → General → Handler herausfinden (z.B. eu.thethings.network)
  • MQTT_PASSWORT: Ein Access Key, am besten einer, der nur die Messages lesen und ansonsten nichts einstellen/konfigurieren kann. Den Key kannst du ueber „Settings/Access Keys“ in der TTN-Console anlegen, anschliessend taucht er im Console-Overviews auf und kann durch Klick auf das Augen-Symbol angezeigt werden (siehe Abbildungen unten, z.B. „ttn-account-v2.2[…]“)

Im Sketch selber (ja, da gehoert’s eigentlich nicht hin) sind noch PLACEID und MQTT_DEVICE zu definieren. PLACEID legt fest, auf welche Integer in der MQTT-Payload die Node reagiert. Steht hier z.b. ‚1‘ und in der Payload wird die 1 mitgeschickt, schaltet die Node ihr Licht ein. MQTT_DEVICE muss fuer jede Node eindeutig anders sein – d.h. selbst wenn mehrere Nodes auf dieselbe Payload reagieren sollen, brauchen sie unterschiedliche Device-Namen. Sonst kegeln sie sich bei der Registrierung im Endlosloop gegenseitig aus dem MQTT-Server.

Alles andere im Code ist lediglich Standard-Registrierung am Server und eine etwas laengliche Definition der LED-Lichterkette, die sich einschalten und beim Abschalten kurz rot leuchten soll. Das war’s auch schon.

Teil 2: Der Sender

Der Sender ist etwas komplizierter – erstens, weil ja ein „User Interface“ (sorry :D) dazugehoert, und weil das LoRa-Shield angesteuert werden muss. Notwendige Teile sind:

  • Stinknormaler Arduino Uno (oder Klon)
  • Dragino LoRa Shield (868 MHz) mit Rubberduck-Antenne
  • TM1638 LED and Key Module (unter dem Namen leicht in den einschlaegigen Shops zu finden)
  • DuPont-Verbindungskabel fuer Key/LED-Modul und Arduino

Der Arduino-Sketch ist auch relativ schnell gegessen: NWKSKEY[16] und APPSKEY[16] sind jeweils der Network Session Key und der App Session Key aus der TTN Console (ueber die Application → Devices → Dein registriertes Device). Wenn in der TTN Console DEADBEEF… steht, wird das im Sketch als { 0xDE, 0xAD, 0xBE, 0xEF, …} gespeichert. DEVADDR ist analog die Device Address aus der TTN Console.

Abhaengig vom abgefangenen Knopf auf der UI-Platine wird der Payload nun ein Integer uebergeben – und das wird in doSend() abgeschickt. Mehr gehoert nicht dazu 🙂

Und wozu das Ganze?

Das eigentliche Ziel war, an einem Aussichtspunkt ueber der Stadt ein Knopfbrettl mit spannenden Landmarken in der Stadt anzubringen, das mit LoRaWAN in die Stadt funkt. Und wer dort beispielsweise auf „Schwoerhaus“ drueckt, laesst eine auf den Punkt gerichtete Lampe blinken 😀

So weit sind wir noch nicht, aber Ende Mai war die Wirtschaftsministerin in Ulm an der TFU, und wir haben die Technik (mit den Lichterketten und den nodeMCUs) quasi gehighjackt, um die Ministerin reihum ihre Gespraechspartner*innen zu „erleuchten“. Hat geklappt 😉

via GIPHY

In Allgemein veröffentlicht | Getaggt , , , , | Kommentieren

Was mir an der re:publica am meisten fehlt

Von stk | Veröffentlicht: 10. Mai 2017

Haltung.

In Allgemein veröffentlicht | 1 Antwort

info-beamer-nodes auf dem Raspberry Pi laufen lassen

Von stk | Veröffentlicht: 21. Februar 2017

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)

In Allgemein veröffentlicht | Getaggt , , | Kommentieren

Offene Daten für den Einzelhandel

Von stk | Veröffentlicht: 2. Februar 2017

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? 😉

In Allgemein veröffentlicht | Getaggt , , , | Kommentieren

Dauerrauschen bei Mikrofonaufnahmen unter Linux

Von stk | Veröffentlicht: 16. Januar 2017

Es war schon bei meinem alten Netbook so, und auch beim Thinkpad hat mich das verfolgt: Aufnahmen ueber den externen Mikrofoneingang rauschen und sind kaum verstaendlich. Beim Netbook konnte ich dualbooten und unter Windows exzellente Aufnahmen mit ordentlicher Vorverstaerkung machen – unter Linux gab es nur Dauerrauschen und kaum verstaendliche Aufnahmen.

Das ist beim X220 umso seltsamer gewesen, da das internet Mikrofon ganz passabel aufzeichnet (wenn auch nicht so sonderlich laut), und ein USB-Audiointerface auch ganz problemlos funktioniert.

In der Arch-Linux-Dokumentation zu PulseAudio habe ich dann die Loesung gefunden: Es scheint wohl an einer falschen default-Samplerate bei PulseAudio zu liegen.

Mit $ arecord --list-devices werden die Audiointerfaces aufgelistet, in meinem Fall ist es wie im Beispiel beschrieben hw:0,0.

Danach wird mit arecord -f dat -r 6000 -D hw:0,0 -d 5 /tmp/test.wav eine Aufnahme unternommen. Die Ausgabe meckert dann, dass die Aufnahmerate nicht ganz passt, in diesem Beispiel wuerden 44.100 Hz unterstuetzt. Durch Weiterprobieren findet man dann heraus, dass auf dem X220 auch 96kHz funktionieren wuerden.

(Genau genommen gingen bei mir Werte zwischen 42000 Hz und 48000 Hz und zwischen 91429 Hz und 101052 Hz.)

Eine ordentliche Sampling-Rate wird dann in /etc/pulse/daemon.conf als default-sampling-rate eingetragen – und schon ist das Rauschen weg.

In Allgemein veröffentlicht | Getaggt , | Kommentieren

Input/Output

Von stk | Veröffentlicht: 13. Januar 2017

Input/Output from Terri Timely on Vimeo.

In Allgemein veröffentlicht | Getaggt , | Kommentieren

Lieber Clever als Smart: Civic Tech fuer Menschen

Von stk | Veröffentlicht: 21. Dezember 2016

Drei (plus x) Lese- und Ansehempfehlungen, die mir gestern nach und nach in den Twitterfeed gepurzelt sind und ebenfalls zur Frage passen, wie Civic Tech weitergesponnen werden kann.

Erstens das Boston Smart City Playbook, das schon gleich mit einem Kracher anfaengt:

The age of the “Smart City” is upon us!

It’s just that, we don’t really know what that means. Or, at least, not yet.

So far, every “Smart City” pilot project that we’ve undertaken here in Boston has ended with a glossy presentation, and a collective shrug. Nobody’s really known what to do next, or how the technology and data might lead to new or improved services.

Es folgt ein Rant ueber Vertriebsdrohnen von „Smart City“-Verkaufsbueros, eine Rueckbesinnung auf die Menschen, um die’s gehen soll, dass es nicht noch eine Plattform braucht (!!! zefix!!!), und dass im Zweifel eine „Clevere“ Stadt besser ist als eine „Smarte“: Mit einem Prototypen, einer intelligenten Strassenlaterne. Kleinen Spielplaetzen, die spaeter vielleicht hochskaliert werden, wenn sie sich bewaehren. Anstelle von Alles-oder-nichts-Megaprojekten.

Zweitens The Engine Room’s Advent Calendar mit einem Lesetipp fuer jeden Tag. Beispielsweise, dass „Startup-Kultur“ eine denkbar depperte Denkweise und Rahmenbedingung fuer gesellschaftsveraendernde Projekte ist. Dass „Innovation“ vollkommen ueberbewertet ist und „Wartung und Unterhalt“ eigentlich die wichtigeren Buzzwords sein sollten. Oder dass im Westen nach wie vor nicht-wohlhabende nicht-weisse Nicht-Akademikerinnen (hier: spezifisches Femininum) vergleichsweise wenig von Civic Tech haben.

Um Ausschluesse geht es – drittens – auch in Programming is Forgetting: Towards a New Hacker Ethic. Der etwas mehr als 20minuetige Vortrag (siehe oben) ist hier komplett transkribiert und lohnt sich zu lesen, gerne auch haeppchenweise. Am Beispiel einer Anekdote um die juengst mit der Presidential Medal of Freedom ausgezeichneten Margaret Hamilton zerlegt Allison Parrish Stueck fuer Stueck die „Hackerethik“, wie sie Steven Levy 1984 in seinem Buch “Hackers” dargestellt hatte. Nach einem Exkurs ueber soziale Kontexte stellt sie den urspruenglichen Lemmas jeweils eine Frage gegenueber. Und ich finde sie grossartig:

allison-parrish-programming-forgetting-26

(danke @lorz und @mjays fuer die Links. Ich weiss leider nicht mehr, von wem ich den Vortrag retweeted bekam.)

In Allgemein veröffentlicht | Getaggt , , , , , , , | Kommentieren

Von Hackathons und Communityfoerderung

Von stk | Veröffentlicht: 18. Dezember 2016
Foto: Sebastián Laraia für Deutsche Bahn / CCBY4.0

Foto: Sebastián Laraia für Deutsche Bahn / CCBY4.0

Mittlerweile hat sich herumgesprochen, dass Hackathons eine ganz gute Moeglichkeit sind, die eigene Stadt, Behoerde oder Konzern zu oeffnen und sich frischen Wind in die verstaubten Hallen zu holen. Das BMVI lud derletzt zum zweiten Mal zum Data Run, und die Deutsche Bahn hatte gestern den fuenften Hackathon binnen 20 Monaten ueber die Buehne gebracht. Nicht schlecht, koennte man sagen.

Was mir aber schon bei unseren OpenCityCamps auffiel: Nach einer Weile scheint sich das etwas totzulaufen. Die ausrichtende Einrichtung darf von Mal zu Mal neue Datenquellen freischaufeln, um sich nicht dem Vorwurf auszusetzen, es bewege sich nichts mehr. Ob diese – muehsam irgendeiner grantelnden Fachabteilung abgetrotzten – Daten dann helfen, tatsaechliche Probleme echter Menschen zu beheben, weiss vorher kein Mensch. Und irgendwann ist auch der Punkt erreicht, an dem die naechsten grossen zu beackernden Baustellen einfach gar nicht mehr an einem 24-Stunden-Hackathon bearbeitet werden koennen.

Vor diesem Hintergrund deswegen mal ein paar halbgare Einwuerfe, was mir die letzten eineinhalb Jahre so durch den Kopf gegangen ist:

  1. Mit das wichtigste Ergebnis einer Open-Data-Veranstaltung ist, dass sich die Teilnehmer*innen live treffen und austauschen. Egal ob Freiwillige mit Ministeriumsleuten, Ministeriumsleute mit Konzernbeschaeftigten oder sonstwas: Diese Aufeinandertreffen motivieren, inspirieren und sorgen fuer die notwendige regelmaessige Hirnbelueftung mit frischen Ideen. Fuer diesen Austausch muss genuegend Zeit und Raum vorhanden sein. Das haben wir als blutjunge Fachschaftler*innen bei der Konferenzorga zwar gelernt, bei Behoerden darf man von dem Wissen aber nicht unbedingt ausgehen 😉
    Hierzu gehoert auch: Wenn ein Ministerium, eine Landeseinrichtung, ein Staedtetag oder sonstwer eine schicke Austauschveranstaltung macht, dann sollte sie unbedingt auch die Freiwilligen aus der Community mit einladen. Die OPEN! hat das nach der Kritik von 2015 dieses Jahr gemacht, das VDV-Verkehrscamp ebenso. Weiter so!
  2. Irgendwann ist jedoch der Punkt erreicht, an dem das klassische Hackathon-Wettbewerbs-Format nicht mehr traegt. Erstens, weil beim Coden immer die Frage im Raum steht, mit welchem Projekt man denn Preise gewinnen kann. Anstelle der Frage, was nuetzlich, wichtig und sinnvoll waere. Zweitens, weil es das Potenzial verschenkt, gemeinsam mit den vielen tollen, kompetenten Leuten mal ein Wochenende lang strategisch wichtige Dinge auszuarbeiten. Mal dieses Werkzeug uebersetzen. Oder dieses Tool schreiben, das es noch nicht gibt und das bisher jedes Mal irgendwie fehlte. Gruppenuebergreifende Metaprojekte, bei denen jede Gruppe einen kleinen Teil fuer das Gesamtprojekt entwickelt
  3. Aus 1) und 2) folgend: Der konsequente naechste Schritt waere, genau solche Zusammenkuenfte zu foerdern. Bei denen nicht kompetitiv Prototypen gebastelt, sondern gemeinsam die Dinge beackert werden, die fuer die Weiterentwicklung von Open Data in Deutschland wichtig sind.
  4. Die Teilnahme an den Aktionen in 3) darf nicht mehr nur auf den Schultern von Leuten mit viel Zeit oder ausreichend Geld oder beidem ruhen. Die Freiwilligen, die sich ein Wochenende um die Ohren schlagen, duerfen nicht auch noch aus eigener Tasche Anreise und Unterkunft bezahlen muessen, oder per Anhalter anreisen und dann irgendwo auf WG-Sofas pennen. Wer quer durch Deutschland zu so einer Aktion reist, gibt fuer solch ein Wochenende je nach Zeit-Geld-Tradeoff irgendwas zwischen 30 und 300 EUR aus. Das kann sich nur eine ueberschaubare Gruppe privilegierter Leute leisten.

An jeder Ecke wird derzeit haufenweise Kohle auf Big Data, Blockchain 4.0 in der Cloud as a Service und andere Ideen mit ueberschaubarer Halbwertzeit geworfen, die aus irgendeinem Berater-Powerpoint gefallen sind. Foerderfunds werden ins Leben gerufen, auf die sich aufgrund der Rahmenbedingungen letztlich eh nur die ueblichen Verdaechtigen bewerben und die Kohle in bekannter Manier zum Fenster rauswerfen.

Ich wage zu behaupten: Die Foerderung von Veranstaltungen wie in 3) beschrieben und die Vergabe von Reisestipendien fuer Open-Data-Aktivist*innen haette ein deutlich besseres Preis-Leistungs-Verhaeltnis. Da wuerde auch wirklich ein Bruchteil der 100 Millionen des BMVI reichen.

In Allgemein veröffentlicht | Getaggt , , , , , , | 3 Antworten

Bitte immer alles gleich richtig machen, Verwaltungsinformatikversion

Von stk | Veröffentlicht: 23. November 2016

Grossartiger Text von Dan Sheldon, seines Zeichens Digitalstrategiechef im britischen Gesundheitsministerium: Wie mache ich mich als Regierung oder Verwaltung mit IT-Projekten selbst kaputt?. Genuesslich zerlegt er den offenbar in der Verwaltung eingebauten Drang zu immer neuen Portalen, Pseudoclouds, mangelnde Exitstrategien und die kuriose Zuneigung zu allem, worauf „Enterprise“ steht. Leseempfehlung.

Achja, eigentlich wollte ich das schon ewig mal hier lang und breit erklaeren, aber seit 15. Juni bin ich nun auch Teil dieser Verwaltung. Bei der Stadt Ulm. Und es ist ein wenig erschreckend, wie leicht mittlerweile die Erklaerung von der Zunge rollt, warum Kommunen offenbar haeufig kein Devops haben. Dafuer habe ich aufgrund des verlinkten Artikels einen wunderbaren Digitalstrategiegenerator gefunden. Grossartig.

In Allgemein veröffentlicht | Getaggt , , | Kommentieren

Gute Nachrichten aus den USA

Von stk | Veröffentlicht: 10. November 2016

Was auch immer da gestern Nacht passierte: Es gibt immer noch gute Nachrichten aus den USA. Zum Beispiel der Code for America Summit, den Eileen Wagner von der OKFDE in einem Blogpost zusammenfasst.

Mit einer inspirierenden Geschichte, wie sich moderne IT-Methoden auch in einer Verwaltung durchsetzen lassen:

In Allgemein veröffentlicht | Getaggt , | Kommentieren