Vom Node zur Visualisierung
Ein schneller Einstieg in unser Plattform als Grundlage weiterer Kurse.Wir bringen das Internet der Dinge in die Hand der Bürger und erleichtern den Einstieg in die neue Technologe
MongoDB Atlas – der beste Weg, MongoDB in der Cloud zu betreiben 2
Übersicht über die IoT Plattform im Freifunk SL-FL
1. Vom Node zur Visualisierung
Eine Einführung in unsere IoT Plattform
von Frank Radzio
2. Eine Übersicht über die Plattform
TTNTTN
Node
Gateway
Mücke
Server
Mücke
Server
InfluxDBInfluxDBMySQLMySQL
GrafanaGrafana
Andere PattformenAndere Pattformen
Node RedNode Red
Luftdaten.info
OpenSenseMap
3. Vom Node ins TTN
TTNTTN
Node
Gateway
Das TTN besteht für den User aus 2 Elementen
1.Gateways
2.Applikationen
Relevant ist für uns erst mal nur die Applikation
Die Application hält die Nodes eines bestimmten
Typs zusammen und bereitet die übertragenen
Daten des Payload auf.
Sie stellt auch Integrationen für einige Dienste
bereit. Dies ist interessant wenn man keine
eigene Datenhaltung benötigt.
Das Kernelement ist aber die Verwaltung von
Devices, unseren Nodes in der Fläche.
4. Aufbau der TTN Application
Die Application im TTN
Application ID ist der eindeutige Name
Der Händler sagt wohin die Daten
geliefert werden, hier ist es noch das
TTN EU
Innerhalb von TTN ist die App EUI die
eindeutige Nummer. Sie taucht auch
am Gateway auf wenn ein Node Daten
zu dieser App sendet
5. Das Device im TTN
Unter Devices stehen die registrierten
Nodes der Application. Es müssen immer
Nodes mit den selben Funktionen sein.
Ein erster Node mit dem Namen slfl_fs_1
Die folgenden Keys sind für uns wichtig
Methode OTAA
Device EUI im Format lsb
Application EUI im Format lsb
Application Key in Format msb
Diese Daten müssen wir so in das Programm des Node übertragen damit der Nodes sich
mit dem TTN über OTAA (Over The Air Authentification) anmelden kann und sich die
eigentliche Session zur Datenübertragung öffnet.
6. Das Arduino Programm
Die notwendigen Libs einbinden
App EUI im lbs Format
Device EUI im lbs Format
Den Application Key im mbs Format
Damit ist ein Node eingestellt um OTAA mit dem Netzwerk reden zu können
7. Den Payload erstellen
Ein Ausschnitt aus dem Programm welches Zeigt wie der Payload in die Bytes
verschlüsselt wird.
Dies muss mit dem Payload Decoder im TTN korrespondieren, sonst kommt nur Murks raus.
8. Den Payload zurück in Felder wandeln
In der TTN Application gibt es einen Reiter
Payload Formats.
Dort ist der Teil mit dem Decoder für uns
interessant.
Hier steht ein Stück Code der aus dem
Payload die Felder zurück rechnet.
Diesen Code schaue wir uns gleich an.
9. Den Payload zurück in Felder wandeln
Dieser Teil holt die Daten des BME280 zurück.
Der SDS011 ist hier noch nicht erstellt.
Am Ende gibt es die Felder batt, humidity,
temperature und pressure.
Es fehlen pm25 und pm10
10. Nach dem decodieren des Payload
Wenn der Decoder passt und der Node Daten
sendet stehen diese unter Data (flüchtig) in der
Application bereit.
Der Payload
wird von Decoder zu Feldern
Weitere hochinteressante Daten liegen jedem
Datensatz als Meta Daten bei.
Darunter Informationen über die
Übertragungsqualität, dem empfangenden
Gateway, die Location des Node und natürlich die
Zeitstempel aller Aktionen
11. Zwischenfazit
● Bis zu diesem Punkt sind alle Daten nur flüchtig im TTN und
gehen verloren ohne das man sie von dort abholt.
● Hier kommt nun unsere Plattform zum Einsatz welche die
Daten von TTN abholt und sie einer Datenbank oder einer
weiteren Verwendung zuführt.
● Natürlich kann man diese Daten nun mit Integrationen von dort
aus gleich speichern oder diversen Visualisierungen zuführen.
Das ist aber nicht unser Ziel. Wir wollen diese Daten
weiterverarbeiten und „smarte“ Applikationen erstellen
● Wir lassen die Daten nun von unserem Mücke Server abholen
und in eine eigene InfluxDB schreiben
12. Zwei Wege um Daten zu uns zu holen
TTNTTN
Mücke
Server
Mücke
Server
Node Red
Node Red
Wir haben zur Zeit zwei Wege um Daten zu uns zu holen.
1.Node Red
Eine Plattform die es ermöglicht Prototyping zu betreiben.
Hier kann man schnell mal eine Applikation zusammen
klicken um die Funktion eines Konzepts zu überprüfen.
Der Node Red Server kann zuhause auf einem Raspberry PI
laufen oder man nutzt die zentrale Installation unter
https://node-red.iot-usergroup.de/ Zur Zeit ist diese aber
noch nicht Multiuser fähig. Diese Erweiterung soll mit der
Version 0.18 kommen.
2.Mücke Server
Der Mücke Server ist eine Entwicklung aus Ulm.
Er ist eine Python Impementierung des MQTT Protokolls.
Hiermit kann man mittels einer MySQL Datenbank diverse
Applikationen im TTN einstellen von denen man Daten haben
möchte. Diese werden dann mittels definierten Tasks verarbeitet.
Zur Zeit ist nur das abholen der Daten und ablegen diese in unsere
InformixDB aktiviert. Ich habe aber mit Stuttgart geklärt wir wir
unsere Feinstaub Sensoren die über TTN ihre Daten abliefern
an die Luftdaten.info Seite versendet werden.
13. Ein spezieller Weg für die FSS mit NodeMCU
● Da wir aber nun schon Feinstaub Sensoren nach Stuttgarter
Modell haben können wir diese Daten natürlich auch zu uns
bringen.
● Diese Sensoren sind reine WLAN Sensoren die ihre Daten
direkt bei einigen Datensammlern abliefern können.
● Die Oberfläche des Sensors beinhaltet als Ziel einmal die
Luftdaten.info InfofluxDB, als weiteres Ziel ist das Projekt
OpenSenseMap hinterlegt.
● Für uns nutzen wir den dritten Punkt „eigenes Ziel“, dort tragen
wir die eigene InfoluxDB ein http://influx.ffslfl.net:8086 mit der
DB feinstaub User ttn*** Passwort **** ein.
● Nun werden die Feinstaub Daten auch in unsere Datenbank
gesendet.
14. Visualisierung mit Grafana
Zur Visualisierung der Daten haben wir erst einmal Grafana
im Einsatz.
Unter https://grafana.ffslfl.net/login geht es zum Login,
Passwort und Username können bei uns per Mail unter
info@iot-usergroup.de bestellt werden.
Jeder Nutzer bekommt einen eigenen Bereich mit seinen
notwendigen Datenquellen
15. Einstellen der Datenquellen
Unter Datenquellen könne neue Quellen eingerichtet
Werden.
Hier die Quelle Feinstaub die eine InfluxDB ist.
Sie liegt auf dem selben Server wie Grafana, kann
also direkt angesprochen werden.
Die DB Details lauten hier feinstaub
mit dem Usernamen ttngraf und dem Passwort ****
16. Anlegen eines neuen Dashboards
Ein neues Dashboard legt man links oben an.
Auf diese Dashboard kann man nun Elemente ablegen
Das Graf Element ermöglicht mehrere Werte in einen Grafen zu zeichnen
Mit dem Element Singlestat kann man einzelne Werte anzeigen, diese
können dann zum Beispiel als Gauge angezeigt werden
17. Ein erstes Graf Element erstellen
Nach dem Klick auf das
Panel Graf entsteht ein
neues Graf Element im
freien Space der Zeile
Mit der Maus auf den
Titel des Panel klicken
Um das Panel Menü zu
öffnen.
Dort auf Edit klicken um
Das Panel zu editieren.
Nun gelangt man in die Einstellungen, der Reiter Metrics ist ausgewählt
Dort müssen wir als erstes unsere Datenquellen festlegen.
18. Auswahl der Datenquelle für das Panel
Datenquelle Feinstaub (Stuttgart Nodes) Datenquelle Mücke Server (TTN FSS Nodes)
Bei der Datenquelle Mücke erkennen wir nun
das dort nicht nur die Payload Daten liegen
sondern auch eine Auswahl der Metadaten
in diese Datenquelle geschrieben wurde.
Dieses verhalten wird in den Tasks des Mücke Servers hinterlegt.
Es können für verschiedene Node Arten eigene Datendefinitionen erstellt werden.
19. Tags in der InfluxDB
Da wir in einer InfluxDB mehrere Applikationen mit mehreren Devices schreiben lassen
müssen wir diese nun auch wieder einzeln anzeigen können.
Dazu haben die Serien in der InfluxDB Tags mit dessen Hilfe man die Nodes auswählen
kann.
Um eine solche Auswahl zu
ermöglichen nutzt man das
Templating im Grafana Dashboard.
Diese übersteigt aber den Umfang
dieser Einführung und muss in einem
eigenen Workshop erklärt werden.
20. Weiterführende Informationen
● Wir konnten heute feststellen das die Umgebung jetzt schon
recht Komplex erscheint.
● Jeder Step kann als eigenständige Schulung vorgestellt werden
um auch etwas tiefer einzusteigen.
● Der Gateway Bereich wurde überhaupt nicht betrachtet.
● Die Programmierumgebungen der Nodes sind auch ein
spannender Bereich der hier nicht angesprochen wurde.
● Node Red als Prototyping Plattform bedarf auch einer nährern
Betrachtung
● Der Mücke Server könnte ein Team zur Betreuung gebrauchen.
Es bleibt spannend!