SlideShare ist ein Scribd-Unternehmen logo
1 von 20
Vom Node zur Visualisierung
Eine Einführung in unsere IoT Plattform
von Frank Radzio
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
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.
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
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.
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
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.
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.
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
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
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
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.
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.
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
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 ****
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
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.
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.
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.
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!

Weitere ähnliche Inhalte

Ähnlich wie Übersicht über die IoT Plattform im Freifunk SL-FL

Formale Methoden im Reverse Engineering
Formale Methoden im Reverse EngineeringFormale Methoden im Reverse Engineering
Formale Methoden im Reverse Engineeringzynamics GmbH
 
Topologien verstehen und erstellen - Methoden der Wirtschaftsinformatik-200329
Topologien verstehen und erstellen - Methoden der Wirtschaftsinformatik-200329Topologien verstehen und erstellen - Methoden der Wirtschaftsinformatik-200329
Topologien verstehen und erstellen - Methoden der Wirtschaftsinformatik-200329Claus Brell
 
Python in Computational Neuroscience & Modular toolkit for Data Processing (MDP)
Python in Computational Neuroscience & Modular toolkit for Data Processing (MDP)Python in Computational Neuroscience & Modular toolkit for Data Processing (MDP)
Python in Computational Neuroscience & Modular toolkit for Data Processing (MDP)nwilbert
 
Betriebsdatenerfassung einer Dimplex Wärmepumpe vom Typ LA 40TU
Betriebsdatenerfassung einer Dimplex Wärmepumpe vom Typ LA 40TUBetriebsdatenerfassung einer Dimplex Wärmepumpe vom Typ LA 40TU
Betriebsdatenerfassung einer Dimplex Wärmepumpe vom Typ LA 40TUJohannes Kinzig
 
Python in der Luft- und Raumfahrt
Python in der Luft- und RaumfahrtPython in der Luft- und Raumfahrt
Python in der Luft- und RaumfahrtAndreas Schreiber
 
OSMC 2008 | Nagios Hochverfügbar mit hearbeat V2 by Jan Dennis Bungart
OSMC 2008 | Nagios Hochverfügbar mit hearbeat V2 by Jan Dennis BungartOSMC 2008 | Nagios Hochverfügbar mit hearbeat V2 by Jan Dennis Bungart
OSMC 2008 | Nagios Hochverfügbar mit hearbeat V2 by Jan Dennis BungartNETWAYS
 
Crouzet Automation - em4 Ethernet Broschüre, deutsche Fassung
Crouzet Automation - em4 Ethernet Broschüre, deutsche FassungCrouzet Automation - em4 Ethernet Broschüre, deutsche Fassung
Crouzet Automation - em4 Ethernet Broschüre, deutsche FassungCrouzet
 
Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...
Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...
Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...Bernd Zuther
 
Event Driven Architecture - OPITZ CONSULTING - Schmutz - Winterberg
Event Driven Architecture - OPITZ CONSULTING - Schmutz - WinterbergEvent Driven Architecture - OPITZ CONSULTING - Schmutz - Winterberg
Event Driven Architecture - OPITZ CONSULTING - Schmutz - WinterbergOPITZ CONSULTING Deutschland
 
Nucleon e.V. Workshop LoRaWAN Grundlagen
Nucleon e.V. Workshop LoRaWAN GrundlagenNucleon e.V. Workshop LoRaWAN Grundlagen
Nucleon e.V. Workshop LoRaWAN GrundlagenFrank Radzio
 
C/ C++ for Notes & Domino Developers
C/ C++ for Notes & Domino DevelopersC/ C++ for Notes & Domino Developers
C/ C++ for Notes & Domino DevelopersUlrich Krause
 
cynapspro data endpoint protection 2010 - Installationsleitfaden
cynapspro data endpoint protection 2010 - Installationsleitfadencynapspro data endpoint protection 2010 - Installationsleitfaden
cynapspro data endpoint protection 2010 - Installationsleitfadencynapspro GmbH
 
CV - Olexandr Ostapenko - DE - Word97
CV - Olexandr Ostapenko - DE - Word97CV - Olexandr Ostapenko - DE - Word97
CV - Olexandr Ostapenko - DE - Word97Olexandr Ostapenko
 
B1 Acocon Lotus Day 08.09.2009
B1 Acocon Lotus Day 08.09.2009B1 Acocon Lotus Day 08.09.2009
B1 Acocon Lotus Day 08.09.2009Andreas Schulte
 
Dateisysteme und Datenbanken im Cloud Computing
Dateisysteme und Datenbanken im Cloud ComputingDateisysteme und Datenbanken im Cloud Computing
Dateisysteme und Datenbanken im Cloud ComputingLothar Wieske
 
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer InfrastrukturContinuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer InfrastrukturQAware GmbH
 
MongoDB Atlas – der beste Weg, MongoDB in der Cloud zu betreiben 2
MongoDB Atlas – der beste Weg, MongoDB in der Cloud zu betreiben 2MongoDB Atlas – der beste Weg, MongoDB in der Cloud zu betreiben 2
MongoDB Atlas – der beste Weg, MongoDB in der Cloud zu betreiben 2MongoDB
 

Ähnlich wie Übersicht über die IoT Plattform im Freifunk SL-FL (20)

Formale Methoden im Reverse Engineering
Formale Methoden im Reverse EngineeringFormale Methoden im Reverse Engineering
Formale Methoden im Reverse Engineering
 
Feature satip2
Feature satip2Feature satip2
Feature satip2
 
Topologien verstehen und erstellen - Methoden der Wirtschaftsinformatik-200329
Topologien verstehen und erstellen - Methoden der Wirtschaftsinformatik-200329Topologien verstehen und erstellen - Methoden der Wirtschaftsinformatik-200329
Topologien verstehen und erstellen - Methoden der Wirtschaftsinformatik-200329
 
Python in Computational Neuroscience & Modular toolkit for Data Processing (MDP)
Python in Computational Neuroscience & Modular toolkit for Data Processing (MDP)Python in Computational Neuroscience & Modular toolkit for Data Processing (MDP)
Python in Computational Neuroscience & Modular toolkit for Data Processing (MDP)
 
Betriebsdatenerfassung einer Dimplex Wärmepumpe vom Typ LA 40TU
Betriebsdatenerfassung einer Dimplex Wärmepumpe vom Typ LA 40TUBetriebsdatenerfassung einer Dimplex Wärmepumpe vom Typ LA 40TU
Betriebsdatenerfassung einer Dimplex Wärmepumpe vom Typ LA 40TU
 
Python in der Luft- und Raumfahrt
Python in der Luft- und RaumfahrtPython in der Luft- und Raumfahrt
Python in der Luft- und Raumfahrt
 
OSMC 2008 | Nagios Hochverfügbar mit hearbeat V2 by Jan Dennis Bungart
OSMC 2008 | Nagios Hochverfügbar mit hearbeat V2 by Jan Dennis BungartOSMC 2008 | Nagios Hochverfügbar mit hearbeat V2 by Jan Dennis Bungart
OSMC 2008 | Nagios Hochverfügbar mit hearbeat V2 by Jan Dennis Bungart
 
Crouzet Automation - em4 Ethernet Broschüre, deutsche Fassung
Crouzet Automation - em4 Ethernet Broschüre, deutsche FassungCrouzet Automation - em4 Ethernet Broschüre, deutsche Fassung
Crouzet Automation - em4 Ethernet Broschüre, deutsche Fassung
 
Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...
Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...
Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...
 
Event Driven Architecture - OPITZ CONSULTING - Schmutz - Winterberg
Event Driven Architecture - OPITZ CONSULTING - Schmutz - WinterbergEvent Driven Architecture - OPITZ CONSULTING - Schmutz - Winterberg
Event Driven Architecture - OPITZ CONSULTING - Schmutz - Winterberg
 
Nucleon e.V. Workshop LoRaWAN Grundlagen
Nucleon e.V. Workshop LoRaWAN GrundlagenNucleon e.V. Workshop LoRaWAN Grundlagen
Nucleon e.V. Workshop LoRaWAN Grundlagen
 
C/ C++ for Notes & Domino Developers
C/ C++ for Notes & Domino DevelopersC/ C++ for Notes & Domino Developers
C/ C++ for Notes & Domino Developers
 
cynapspro data endpoint protection 2010 - Installationsleitfaden
cynapspro data endpoint protection 2010 - Installationsleitfadencynapspro data endpoint protection 2010 - Installationsleitfaden
cynapspro data endpoint protection 2010 - Installationsleitfaden
 
CV - Olexandr Ostapenko - DE - Word97
CV - Olexandr Ostapenko - DE - Word97CV - Olexandr Ostapenko - DE - Word97
CV - Olexandr Ostapenko - DE - Word97
 
PLUX.NET – SOFTWAREKOMPOSITION DURCH PLUG & PLAY
PLUX.NET – SOFTWAREKOMPOSITION DURCH PLUG & PLAYPLUX.NET – SOFTWAREKOMPOSITION DURCH PLUG & PLAY
PLUX.NET – SOFTWAREKOMPOSITION DURCH PLUG & PLAY
 
B1 Acocon Lotus Day 08.09.2009
B1 Acocon Lotus Day 08.09.2009B1 Acocon Lotus Day 08.09.2009
B1 Acocon Lotus Day 08.09.2009
 
Cloud Computing
Cloud ComputingCloud Computing
Cloud Computing
 
Dateisysteme und Datenbanken im Cloud Computing
Dateisysteme und Datenbanken im Cloud ComputingDateisysteme und Datenbanken im Cloud Computing
Dateisysteme und Datenbanken im Cloud Computing
 
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer InfrastrukturContinuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
 
MongoDB Atlas – der beste Weg, MongoDB in der Cloud zu betreiben 2
MongoDB Atlas – der beste Weg, MongoDB in der Cloud zu betreiben 2MongoDB Atlas – der beste Weg, MongoDB in der Cloud zu betreiben 2
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!