Blog
  • Thema Neue Technologien

LoRaWAN: Vom Experiment zum Device

Placeholder image
  • Veröffentlichungsdatum 26.04.2021
Dr. Christian Hammel

Am 23.04. hat die Technologiestiftung das 14.Treffen der Berliner LoRaWAN und TTN-Community gehosted.

Ein Bericht ist wie immer im Communityblog zu finden. Dort finden sich auch die Zahlen zur Entwicklung der Community und zu den Highlights der letzten Wochen, zusammengestellt vom Initiator der Berliner TTN-Community. Deshalb hier nur Highlights.

Wir haben eine Reihe neuer Anwendungen gesehen, außerdem war viel Technik-Foo wie Stromverbrauch und die Migration auf einen neuen Stack Thema des Nachmittags.

Wir lernten ein Forschungsprojekt der HTW kennen, in dem man damit experimentiert, Drohnen via LoRaWAN zu steuern, die in Katastrophenfällen zum Einsatz kommen – keine Spielzeugflieger, sondern richtige Transporter mit Rotoren von 2 Metern (Slides auf  Googledrive)! Als Projekt im Demonstratorstatus konnten wir eine Anwendung bei der Feuerwehr Wiesbaden sehen, in dem ein engagierter Feuerwehr’ler und TTN’ler ein device entwickelt hat, das den Status der Starterbatterien von Geräten wie Pumpen überwacht, die nicht ohnehin ständig am Netz bzw. am Ladegerät hängen, um die 24/7-Einsatzbereitschaft zu sichern.

Wie gewaltig der Entwicklungsaufwand ansteigt, wenn aus erfolgreicher Forschung oder einem Demonstrator eine standfeste Anwendung werden soll, konnte man an zwei Berliner Beispielen sehen.

Clair Berlin stellte vor, welchen immensen Aufwand es für eine Plattform bedeuten kann, wenn sich ein Netzwerkstack, ein Kommunikationsprotokoll oder auch nur das Datenformat von Sensoren ändert. Einer der Mitgründer der Community zeigte auf der Hardwareseite, wie aufwändig es ist, aus einem Demonstrator und der Idee, den kleinsten verfügbaren Tracker zu bauen, ein Gerät zu entwickeln, das stabil funktioniert und zu erträglichen Kosten herstellbar ist. „Naheliegenden“ Herausforderungen wie dem Stromverbrauch folgen jede Menge unerwartete Herausforderungen von Ladestromreglern, die sich nicht verhalten wie vom Lieferanten spezifiziert, über leergefegte Märkte für einen wichtigen Chip bis hin zur TTN-seitig bisher nicht vorgesehenen automatischen Anmeldung am Netz bei der Erst-Inbetriebnahme. Herausgekommen ist ein Notfall- oder Diebstahlstracker, der Geokoordinaten dann sendet, wenn man sie via TTN anfordert oder z.B. ein Beschleunigungssensor die Sendung auslöst, der keine 10 Gramm wiegt, so groß ist wie eine 2 € - Münze, in der Stadt etwa drei Häuserblocks weit senden kann und mit einer Knopfzelle ein Jahr lang läuft. Gezeigt als Tracker für eine Rassekatze sind der Fantasie über mögliche Einsatzzwecke einer solchen Hardwareplattform natürlich kaum Grenzen gesetzt. Umso mehr, weil der Entwickler die Software als open source und die Baupläne als open hardware zur Verfügung stellt und sich gerade darum bemüht, ein Unternehmen zu finden, das das Gerät in der 30 € - Klasse in 1.000er Stückzahlen fertigen kann. Mein Kommentar: Respekt, wenn man so etwas kann! Und noch mehr Respekt, wenn man das auch noch mit derart maximaler openness verfolgt!

Mit einem Vertreter von TheThingsNetwork aus den Niederlanden konnte die Community sich schließlich  noch austauschen, welche Verbesserungen sich die Community für das öffentliche Community-Netzwerk wünscht, von einfacherer user experience und Automatisierung, die TTN auch weniger IT-affinen Kreisen besser erschließen, bis zu mehr Wissenstransfer über die Migration auf den neuen Netzwerkstack V3. Beantwortet wurde dies mit einer Einladung zur The Things Conference, online am 28.05., auf der genau diese Fragen Thema sind und das gesamte Entwicklerteam aus den Niederlanden Themen rund um die neue Generation Netzwerkserver vorstellt und mit den usern diskutiert. Wir danken für die Einladung!

Abschließend mein Dank an die Freifunk-Community aus München, auf deren öffentlich zugängliche Video-Meetingplattform wir mitten im Treffen spontan wechseln  konnten, nachdem die ursprünglich dafür vorgesehene Plattform nicht richtig funktionierte. Die Freifunker zeigen hier, dass openness deutlich mehr sein kann als nur die reine Nutzung von open source software für sich selbst.