zurück zum Artikel

29 Lampen zeigten auf der Berliner re:publica im Mai live die Lichtverhältnisse aus allen EU-Ländern. Hinter der Installation steckt ein Maker-Projekt: Ein autonomer Lichtsensor auf Arduino-Basis steuert über Mobilfunk eine RGB-Lampe mit Betonfuß.

Das Internet of Things bietet mehr als Kühlschränke mit WLAN – es kann virtuelle Dinge begreifbar machen. Mit "Finding Europe with Lights" machten 29 Lampen Europa erfahrbar. Als Bürgerinnen und Bürger Europas verbinden uns über die politische Idee hinaus weitere Faktoren, vom Wetter über Zeitzonen bis zum Licht. Die Lichtverhältnisse haben wir in den einzelnen Mitgliedsstaaten der EU gemessen und dann in Berlin bei der Konferenz re:publica [1] in einer Lampeninstallation zusammengeführt. Deren Motto lautete dieses Jahr "Finding Europe" und was wäre passender, als eine Erinnerung, wie der Himmel über den Staaten Europas gerade aussieht?

Grundsätzliche technische Entscheidungen

Die Beschreibung dieses Projekts soll zeigen, wie man ein Internet-of-Things-Projekt grundsätzlich entwickelt. Erste Überlegung ist die Datenverbindung. Die Sensoren sollten zuverlässig an nahezu beliebigen Orten in Europa zu betreiben sein, ohne dass der Sensor-Host irgendwelche Konfiguration vorzunehmen hatte. Die Lampen wiederum sollten ebenso autonom ins Netz gehen – damit war WiFi aussen vor. Stattdessen entschied ich mich, alles auf Basis von GSM zu betreiben, was Fragen bezüglich SIM-Card-Betreiber und Hardware zur Folge hatte.

Andere Fragen mussten ebenfalls gelöst werden, vom Stromverbrauch über das Gehäuse bis zur Ausfallsicherheit. Es musste ein autonom in ganz Europa zu betreibender Farb-Sensor her, eine passende Plattform fürs Speichern der Daten sowie Lampen, die ebenfalls an diese Plattform angebunden sein würden und das Licht anzeigen können. Schließlich brauchten wir Gastgeber in allen EU-Ländern für die Sensoren, versandten Geräte und erstellten eine interaktive Messe-Installation für 6000 Besucher.

Die Wahl des Boards

Die Wahl fiel auf ein selbst entworfenes Arduino-Board, das über einen Sockel das GSM-Modem Fona von Adafruit aufnehmen kann. Vorher hatte ich andere Lösungen getestet, wie zum Beispiel das Linkit One von Seeedstudio oder deren ArchGPRS-Board. Letzteres war zu kompliziert in der Programmierung und im Debugging, außerdem fehlte eine ausreichende Unterstützung durch Community und Dokumentation. Dies war beim Linkit One schon besser – ein beeindruckendes Board mit einer Vielzahl an Kommunikationsmöglichkeiten (WiFi, GSM, GPS, Bluetooth) und viel Rechenpower und Speicher im Vergleich zu normalen Arduinos. Aber leider auch mit hohem Stromverbrauch, womit das Board aus dem Rennen war.

Fona von Adafruit ist relativ neu auf dem Markt und ein reines GSM-Modul. Man braucht also einen Mikrocontroller, um es zu betreiben. In meinem Fall war das von Vorteil, denn so konnte ich mir einen maßgeschneiderten Mikrocontroller zusammenstellen und mit dem GSM-Modul verbinden. Dies war besonders beim Power-Management vorteilhaft.

Stromverbrauch minimieren

Der Stromverbrauch von Arduinos im Batteriebetrieb ist frustrierend hoch. Im normalen Betrieb verbrauchen Unos mit 35 Milliampere pro Stunde so viel, dass mittelgroße Lithium-Polymer-Akkus keine zwei Tage durchhalten. Und der Sensor benötigt noch mehr Strom, da das Mobilfunkmodul kurzzeitige Spitzenlasten bis zu zwei Ampere abruft. Allerdings bieten Arduinos zahlreiche Möglichkeiten, Strom zu sparen. Erste Versuche habe ich mit einem Bareduino gemacht, also einem nackten Atmel 328PU, dem Chip, der im Arduino steckt. Auf dem Breadboard waren nur noch der Oszillator, ein paar Kondensatoren und drei Widerstände.

Durch die Abspeck-Kur verbraucht der Bareduino circa 10 Milliampere. Vor allem lässt er sich in einen Schlaf-Modus versetzen, in dem nur noch wenige Mikroampere benötigt werden. So kann man den Arduino Wochen oder sogar Monate mit einer Batterie betreiben. Jetzt hieß es, ein eigenes Board zu designen und anfertigen zu lassen – tatsächlich ein alter Traum von mir.

Das erste eigene PCB

Mit Hilfe eines Freundes war die aktuelle Schaltung auf meinem Breadboard schnell in Eagle übersetzt – die gängigste Software, um elektronische Schaltungen zu entwerfen und daraus Anweisungsdateien für Auftragsfertiger von Platinen zu erzeugen. Zusätzlich fügten wir einen Anschluss für das Fona-Board hinzu, der mit einigen Pins des Atmel-Chips verbunden wurde, unter anderem der seriellen Schnittstelle. Der Moment, als die Test-Boards nach zwei Wochen vom amerikanischen Hersteller Osh-Park [4] ankamen, das erste Mal die Lämpchen angingen und die Mobilfunkverbindung aufgebaut wurde, ist schwer zu beschreiben: Ardufona war geboren und funktionierte auf Anhieb einwandfrei.

In späteren Feldtests zeigte sich ein unangenehmes Stabilitätsproblem. Die Boards gingen teilweise nach Tagen des stabilen Betriebs immer wieder mal in einen undefinierten Zustand über und hingen sich auf. Tagelanges Debugging, Foren-Hilfe und diverse Test-Settings mit unterschiedlicher Taktung oder anderen Kniffen ließen das Problem nicht gänzlich verschwinden. Da die Boards für den autonomen Betrieb "in der Wildnis" funktionieren sollten, war eine derartige Instabilität nicht tolerierbar. Schließlich brachte mich ein Ingenieur aus den USA auf die Lösung. Der meistverkaufte integrierte Baustein der Welt musste her. Mit einem 555er [6] IC ist es möglich, einen Kondensator gezielt so zu laden, dass er nach x Sekunden einen Reset des Arduino auslösen kann. So wurde die Platine in Eagle um eine entsprechende Schaltung erweitert. Heute laufen die Boards wochenlang stabil und booten nur ab und zu neu. Der Atmel verfügt über einen internen "Watchdog", der prinzipiell die gleiche Funktion erfüllen kann. Leider erwies sich diese Funktion als unzuverlässig.

Auswahl des SIM-Card-Providers

Eine europaweite Mobilfunklösung ohne ausufernde Kosten zu finden ist eine Herausforderung. Glücklicherweise gibt es auf Machine-to-Machine-Szenarien (M2M) spezialisierte Firmen, die SIM-Karten für diesen Zweck anbieten. Internationales Roaming in nahezu beliebige Netze ist inklusive, ebenso wie die Verwaltung der Karten in einem speziellen Portal. Wir entschieden uns für die britische Firma eseye Ltd [7]. Die SIMs gab es mit relativ geringem Transfervolumen von einem Megabyte pro Monat, doch mit sparsamem Code bleiben wir mit zwei Sync-Calls pro Stunde im Rahmen. Die Karten können sich in nahezu jedes technisch verfügbare Netz einwählen und haben so eine hervorragende Netzverfügbarkeit, selbst in schlecht ausgebauten Regionen oder Gebäuden mit schlechtem Empfang.

Cloud-Service

Wohin mit den Daten der Sensoren? Inzwischen gibt es zahlreiche, meist Cloud-Lösungen, häufig mit kostenlosen Entwickler-Accounts. Kriterien für die Auswahl waren Stabilität, Preismodell, die Einfachheit der Schnittstelle und deren Dokumentation sowie Praxisbeispiele und Community-Support. Darüber hinaus die Möglichkeiten des Zugriffs auf die Daten zu Analysezwecken und zur Darstellung, um die Sensor-Farbwerte von den Lampen auszulesen. Nach einer ersten Internet-Recherche kamen Xively, Thingspeak und Ubidots in Betracht. Xively [8] war schnell wieder aus dem Rennen. Man konnte sich für einen Entwickler-Account anmelden – um auf eine Warteliste zu kommen. Bis heute hat sich niemand von Xively zurückgemeldet.

Anders bei Ubidots [9], einer Plattform speziell für Sensordaten und das Internet of Things. Ubidots stellte eine Reihe von praktischen Code-Beispielen zur Verfügung, hatte einen schnellen und angenehmen Support und eine gut dokumentierte Schnittstelle. Außerdem gibt es ein beeindruckendes Interface zur Abfrage der Daten mit schönen Visualisierungen und sogar Karten-Applets für die Anzeige von GPS-Daten. Ubidots ist sehr empfehlenswert, dennoch haben wir uns schließlich für Thingspeak [10] entschieden. Die Open-Source-Lösung erfordert für ernsthafte Anwendungen ein eigenes Hosting und damit umfassende Anpassungen. Das war uns erst zu viel, ständig hinzukommende Spezialanforderungen machten es aber nötig.

Nach einer holprigen Installationsphase wurden wir von der Funktionalität und Zuverlässigkeit angenehm überrascht. Thingspeak nutzt MySQL als Backend und ist als Rails-Anwendung konzipiert. So lassen sich leicht Zusatzmodule entwickeln – entweder als echte Module in der Thingspeak-Umgebung oder als Eigenentwicklung. In unserem Fall war zum Beispiel ein flexibles Mapping von Lampen auf die jeweiligen Sensoren nötig, das mit einer App gesteuert werden kann. Mit der eigenen Lösung war das mit ein paar Zeilen Code und einer trickreichen SQL-Abfrage möglich.

Software

Beim Entwickeln der Software gab es zwei Herausforderungen. Zum einen musste maximale Ausfallsicherheit erreicht werden, da die Sensoren beim Transport und Betrieb über Wochen autonom arbeiten sollen. Zum anderen sind die Ressourcen eines normalen Arduino begrenzt, es stehen nur 2 Kilobyte Arbeitsspeicher zur Verfügung. Zahlreiche Speicherprobleme gab es mit der String-Bibliothek, sodass ich, als Hobbyprogrammierer, erstmals auf C-Funktionen ausweichen musste. Am Ende funktionierte alles gut und es war sehr befriedigend zu sehen, wie der Speicherverbrauch Kilobyte um Kilobyte mit jeder Optimierung des Codes (Software siehe Link am Ende des Artikels) nach unten ging. Hier zeigte sich, dass Programmierung für Embedded Devices sehr viel anspruchsvoller sein kann als etwa Web-Programmierung, wo im Vergleich nahezu endlose Ressourcen zur Verfügung stehen. Wenn irgendetwas schiefläuft, kann ein Web-Service neu gestartet werden. Bei einem Arduino, der 3000 Kilometer entfernt in einem Baum hängt, ist das nicht möglich.

Ein Solar-Panel muss her!?

Für das re:publica-Projekt war ein Solar-Panel nicht direkt erforderlich – allerdings für die Vision, die Sensoren dauerhaft autonom zu betreiben. Der erste Gedanke war, das Fona-Modul mit einem Solar-Panel über seine vorhandene Lade-Elektronik mit der angeschlossenen Batterie zu laden. Das funktionierte zunächst, die Lade-Lampe leuchtete selbst bei geringem Lichteinfall auf. Dann wurde klar, dass Lithium-Polymer-Akkus spezielle Elektronik benötigen, um die extrem variierende Spannung des Solarmoduls auszugleichen. Der Akku wurde vom Solar-Panel nur betrieben, nicht aufgeladen. Entsprechende Module gibt es, leider teuer oder kompliziert zu konfigurieren. Für die Installation auf der re:publica haben wir sie nicht verwendet, testen aber derzeit, ob die Sensoren dauerhaft mit Solarenergie betrieben werden können.

Ein passendes Gehäuse

Das Gehäuse sollte wetterfest und lichtdurchlässig sein, genügend Platz für Arduino, Sensor und Batterie bieten sowie gegebenenfalls das Solarpanel aufnehmen können. Wir begannen mit einer speziellen Variante: Weckgläser. Inspiriert von der Firma Seeed, die mit ihrem ArchGPRS-Projekt schon mal einen ähnlichen Ansatz verfolgte. Also wurde der erste Prototyp in ein Weckglas gepackt, verschlossen und draußen an den Baum gehängt. Das konnte nicht gutgehen. Zwar verfügt das klassische Weckglas über eine Gummidichtung und sogar einen Spann-Verschluss, die Abdichtung kommt bei eingekochter Marmelade aber durch den Unterdruck zustande, den der langsam abkühlende Inhalt verursacht. So befand sich der Arduino nach wenigen Tagen unten in einer kleinen Pfütze.

Nun konzentrierten wir uns auf zwei Gehäuse-Familien. Zum einen die Otterbox, die es in verschiedenen Größen gibt, zum anderen das "project case" von Adafruit, ebenfalls in mehreren Größen verfügbar. Die Otterbox ist extrem stabil (angeblich kann ein Auto ohne Schaden drüberfahren), hervorragend verarbeitet und hat einen praktischen, sehr gut abdichtenden Schließmechanismus. Leider ist das Gehäuse nur mäßig lichtdurchlässig und etwas eigenwillig geformt. Die Wahl fiel auf die eleganten quadratischen Gehäuse von Adafruit, die einen transparenten Deckel haben und ebenfalls über gute Abdichtungen verfügen.

Zwei Fragen bleiben offen und müssen im Praxisbetrieb geklärt werden: Erstens konnten wir nicht ermitteln, ob Probleme durch Kondenswasser entstehen, wenn sich die Elektronik aufwärmt und die Außentemperatur sehr gering ist. Hier müsste vielleicht für Luftausgleich gesorgt und Material beigefügt werden, das überschüssige Feuchtigkeit aufnimmt. Zweitens bleibt die Frage, ob das geplante Solar-Panel im Gehäuse oder außen montiert werden sollte. Das Panel verliert an Leistung, wenn es hinter einem Acrylglas betrieben wird, es könnte verschmutzen und beschlagen. Erste Dauertests mit dem im Gehäuse angebrachten Solar-Panel verliefen vielversprechend. Demnächst werden wir Varianten mit außen angebrachten kleineren Panels testen, die sich auch selbst ausrichten.

GPS ohne GPS

Auf ihrer Reise durch Europa wollten wir die Sensoren verfolgen. Ein GPS-Modul für den Arduino kam nicht in Frage, da es viel Strom benötigt, Ortung nur bei Sichtkontakt zu Satelliten funktioniert und es uns zu teuer war. Im GSM-Netz gibt es eine spannende Alternative: viele GSM-Module können die GPS-Koordinaten der aktuellen Mobilfunkzelle per AT-Befehl auslesen. Die Angaben sind ungenauer als echte GPS-Daten, aber sie stehen kostenlos und ohne zusätzliche Hardware zur Verfügung, auch wenn das Modul keinen Sichtkontakt zum Himmel hat. In den Liefer-LKWs der Post-Dienste hätten GPS-Module nur selten ein Signal empfangen – unser GSM-GPS funkte zuverlässig einmal pro Stunde die aktuelle Position durch.

Kennzeichnung, Datenschutz und Transparenz

Das Internet of Things bringt große Herausforderungen im Datenschutz mit sich. Daher wollten wir mit Lösungen herumexperimentieren. Wir statteten die Sensoren mit einem QR-Code aus, der auf die Thingspeak-Seite des Projekts verwies. Dort konnten die Sensor-Daten sowie weitere Informationen zum Projekt und zum Sensor-Standort nachgelesen werden. Zukünftig könnte es wichtig sein, zusätzlich auf dem Gerät mit allgemein verständlichen Symbolen aufzuklären, was es konkret tut. Verarbeitet es personenbezogene Daten? Werden diese Daten mit anderen Parteien geteilt? Liegen Quellcode und Hardware-Design des Gerätes unter offener Lizenz vor, sodass überprüft werden kann, was das Gerät genau tut? Auf diesem Feld ist noch viel Arbeit vonnöten, wenn das Vertrauen der Passanten in das Internet of Things nicht verspielt werden soll.

Das Projekt auf der re:publica

Über eine Online-Ausschreibung hatten sich im Vorfeld Freiwillige als Gastgeber für die Sensoren melden. Aus allen Ländern trafen Bewerbungen ein. Unter den 28 Ausgewählten waren unter anderem Paul Nemitz, Leiter der Direktion für Grundrechte und Unionsbürgerschaft der Generaldirektion für Recht der EU-Kommission in Belgien, und Dušan Chrenek, Leiter der Vertretung der EU-Kommission in der Slowakei, sowie zahlreiche Makerspaces.

Nach wochenlangen Testläufen, Optimierungen und Abstimmungen rückte der Tag näher, an dem die Sensoren verschickt werden sollten, und zehn Tage später die Installation der Lampen auf dem Gelände der re:publica in Berlin. Die Boards vom chinesischen Auftragsfertiger Seeedstudio erreichten uns termingerecht und funktionierten einwandfrei – auch die Produktion von Betonsockeln für die Lampen schritt zügig voran, ebenso die der Lampenschirme.

Da die Batterie-Tests erfreuliche Ergebnisse erbracht hatten, konnten wir die Sensoren früher als geplant verschicken. Das erwies sich als extrem hilfreich, denn mehr als zehn Sensoren erreichten nicht auf Anhieb ihr Ziel. Durch das GPS-Tracking konnten wir auf einer Europa-Karte den Weg der Sensoren verfolgen und sahen schnell, dass einige auf Abwegen waren, einer ist bis heute in China verschollen. Wir mussten sie noch einmal bauen und verschicken. Ein Versand-Hindernis war die Batterie mit einer Kapazität von 6600 Milliamperestunden. Laut DHL wäre ab einer Größe von 5000 Milliamperestunden eine Kennzeichnung notwendig gewesen.

Der nächste Schrecken: Weniger als 48 Stunden vor Beginn der re:publica waren alle Sensoren offline! Die Fehlersuche mit dem Provider lief schleppend, dort wurde jegliche Verantwortung zurückgewiesen. Zum Glück war einer der verirrten Sensoren zurückgeschickt worden und lag auf meinem Schreibtisch, sodass ich Versuchsreihen starten konnte. Ich testete verschiedene Software-Varianten des Sensor-Codes und schließlich nur den Test-Code des Fona-Moduls, um andere Probleme auszuschließen. Jedes Mal: kein Kontakt mit dem Netzwerk. Erst als klar war, dass mit einer neuen SIM-Karte alles funktioniert, fand die Firma plötzlich das Problem und reaktivierte alle Karten. Sie waren versehentlich deaktiviert worden.

Wenig später begann endlich der Aufbau in der Berliner Veranstaltungshalle Station. Eine Europa-Karte wurde mit einer riesigen gelaserten Schablone auf einer Fläche von sechs mal sechs Metern auf dem Hallenboden aufgebracht. Alle Lampen wurden aktiviert und überprüft, weitere SIM-Probleme, die wohl durch einen Status-Cache des Fona-Moduls ausgelöst wurden, konnten in letzter Minute mit Kurzschließen des spannungslosen Fona-Moduls behoben werden. Ein Zeitraffervideo des Aufbaus kann im Internet angesehen werden (siehe Link).

Am 5. Mai um 10 Uhr öffnete die re:publica schließlich ihre Tore und unsere Installation war online – 29 Lampen leuchteten in den Farben von 29 Sensoren, die über ganz Europa verteilt worden waren und zeigten, wie Europa zusammenhängt.

Mit dem Internet of Things wird die Verbundenheit sichtbar, die der politischen Idee Europas in den letzten Jahren manchmal fehlt.

• Links und Foren [12]

(hch [13])

URL dieses Artikels:
https://www.heise.de/-3079605

Links in diesem Artikel:
[1] https://www.heise.de/news/Das-Tageslicht-in-Europa-in-RGB-und-vereinigt-ueber-GSM-2568914.html
[2] http://www.heise.de/make/inhalt/2015/3/112/
[3] http://shop.heise.de/artikel-archiv/ch/2015/3/112/
[4] https://oshpark.com/
[5] http://www.heise.de/make/inhalt/2014/03/152/
[6] http://www.heise.de/make/inhalt/2015/5/114/
[7] https://www.eseye.com/
[8] http://xively.com/
[9] http://ubidots.com/
[10] https://thingspeak.com/
[11] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[12] https://www.heise.de/make/links/1503112
[13] mailto:hch@make-magazin.de

Copyright © 2016 Heise Medien