Schlagwort-Archive: verschwoerhaus

Dystopien bauen

Ich durfte heute an einem Workshop zur Stadtentwicklung bei uns im Verschwoerhaus teilnehmen, und habe dabei eine fuer mich neue Methode kennengelernt, die ich unbedingt festhalten moechte – weil ich sie erfrischend anders fand und sie mir nach anfaenglicher Verwirrung geradezu diebische Freude bereitet hat.

Es ging – natuerlich – mal wieder um die Stadt der Zukunft, und die vom BBSR beauftragten Agenturen hatten vorher schon sogenannte Trendmolekuele entwickelt. Wenn ich das richtig verstanden habe, sind das Verkettungen einzelner Elemente, beispielsweise das Zusammenspiel von Civic Tech/„Open-Bewegung“, Kooperation von Verwaltung und BuergerInnen, Digitalem Ehrenamt, aber auch von Misstrauen gegenueber Eliten im Gesamtbild „Autoritaetsverlust der Eliten“. Klang ganz stimmig, teilweise ein wenig Buzzwordig, aber gut.

Wir sollten uns also Gedanken ueber eine Zukunftsstadt machen, z.B. eine wie Ulm, im Jahr 2050. Und das hier bekamen wir vorgesetzt (stichwortartiger Auszug):

Public Private Campus

  • Unistadt mit High-Tech-Unternehmen
  • Unternehmen investieren in Infrastruktur, erwarten dafuer ein unternehmensfreundliches Umfeld
  • oeffentliche Dienste sind quasi durchgehend obsolet oder privatisiert
  • Grenzen zwischen Verwaltung und Wirtschaft sind praktisch aufgeloest
  • Eigene Kryptowaehrung (natuerlich :D)
  • Viel Automatisierung, aber weniger qualifizierte Menschen bekommen auch ab und zu mal Jobs ab

Ich fragte mich ja erst, ob wir hier eigentlich verarscht werden sollen. Company Towns als Zielvision eines Gruppenprozesses? Inklusive Scrip als Kryptowaehrungsbullshit? Vor dem Hintergrund der aktuell laufenden Debatten? Wer hat denn da Lack gesoffen?!

Je mehr wir aber die Ideen umherwarfen, wie das Stadtquartier 2050 aussehen koennte (wir hatten den real existierenden Neuen Eselsberg als Beispiel), desto mehr kam ich in die Rolle hinein – und habe mit der Gruppe nach und nach quasi alles eingeworfen, was man so von Omni Consumer Products oder sonstiger dystopischer 1980er-Jahre-SciFi kennt. Die Quartiersbetriebsgesellschaft weist den fleissigen hochqualifizierten Beschaeftigten Wohnraum zu, haelt alles wunderbar sauber, organisiert sogar das verbliebene Ehrenamt mit (Wohlfuehlen durch soziales Engagement as a Service!), belohnt erwuenschtes Verhalten mit kostenlosem Netflix, etc. pp.

Im Nachgespraech waren wir Teilnehmende uns uneins, wie wir uns mit dem Format fuehlen sollten. Manche fanden das Szenario beklemmend und fragten nach dem Zweck, das so auszurichten. Ich hatte waehrend des Workshops immer wieder die ModeratorInnen deswegen geloechert, und an den richtigen Stellen ein Zwinkern als Antwort bekommen – und fand die Idee grandios. Denn: Der Hochglanz-Zukunftsvisionen gibt es ja nun wirklich schon genug. Egal ob das Le Corbusier war, oder die autogerechte Stadt, oder Grosswohnsiedlungen: Auf dem Papier sah das ja immer alles erstmal gut aus. Und bei den vorgestellten Szenarien konnte ich mir ganz problemlos vorstellen, dass die mal im Jahr 2000 mit einer Hochglanzbroschuere und grossen Erwartungen ihren Anfang gemacht haben koennten. Bevor sie eben nach und nach in so ein Huxley-Bilderbuchszenario abgedriftet sind.

Im Laufe des Nachgespraechs wurde dann auch allen klargemacht: Ja, genau das ist das Prinzip. Dinge so ueberspitzen, dass auch wirklich allen klar wird, dass diese Idee unerwuenschte Seiteneffekte haben wird – und welche Strukturen ursaechlich dafuer verantwortlich sein koennten. Eine Sensibilisierung fuer die Macht- und Strukturdynamiken, die man sonst bei der tollen Planstadt-Vision einfach ignoriert und 30 Jahre spaeter beissen sie einen in den Arsch. Ich fuehlte mich immer wieder auch an Towards a new Hacker Ethic erinnert, speziell die von Parrish postulierten neuen Leitfragen darin.

Ich wuerde das Konzept gerne mal im Kontext Smart City spielen. Und bin auch gespannt auf die Idee, diese Szenarien auch tatsaechlich in die Form eines Spiels zu giessen: StadtplanerInnen und IT-Buzzword-Ninjas sitzen im Pen-and-Paper-Rollenspielmodus zusammen und bekommen Quests nach dem Strickmuster „Der Lizenzvertrag fuer deine Cisco-Sensorinfrastruktur laeuft aus. Wuerfle fuer den Weiterfuehrungspreis“ gestellt 😉

 

PS: In unserer OCP-Stadt war nicht alle Hoffnung verloren. Ein moegliches Themenfeld war „Jugendhaus“, und ich habe einfach mal postuliert, dass das OCP-Jugendhaus von den nonkonformistischen Jugendlichen einfach links liegen gelassen wird – die sind naemlich auch 2050 so, wie Jugendliche schon immer waren: Sie finden scheisse, was ihre Eltern machen, schaffen sich ihre eigenen Freiraeume. Und eine kleine, aber wichtige Gruppe davon zieht nachts durch die Strassen, sabotiert mit umgebauten Mikrowellen die Quartiers-Sicherheitsinfrastruktur, laesst der Campuspolizei die Luft aus den Golfwagen und konsumiert illegalisierte Substanzen.

The kids will be alright.

Mit LoRaWAN Lichter blinken lassen

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

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%