Datenlogging mit Mikrocontroller als Client und xively.com (Pachube) als Server

Daten Logging mal anders

Bei der Erfassung von Messdaten wird ein Mikrocontroller-Board öfters als Server verwendet. Siehe Grafik unten, Abschnitt a) "Mikrocontroller as Server". Die Aufgabe des Servers liegt am Festhalten der Messreihen (entweder auf einem EEPROM oder auf einer SD-Karte) sowie  dem Bereitstellen und Aufbereiten angeforderter Daten an einen oder mehrere Clients. In Verbindung mit dem Internet findet das HTML- oder UDP-Protokoll breite Anwendung. Beim HTML-Protokoll agiert im Fall a) das Mikrocontroller-Board als Web-Server und der Client als Web-Browser.

Umgekehrt  ist es möglich das Mikrocontroller-Board als Client einzusetzen. Siehe Grafik unten, Abschnitt b) "Mikrocontroller as Client". In diesem Fall dient der Client als reiner Datenlieferant. Er fordert den Server periodisch auf die Messpunkte entgegenzunehmen und abzuspeichern. Hier besteht die Aufgabe des Server die Daten entgegenzunehmen, festzuhalten, auszuwerten (z.B. Alarm per Push-Mail auslösen) sowie die Messdaten auf Anforderung z.B. als Grafik zur Verfügung zu stellen.

Prinzip Client Server 

 

Mikrocontroller als Client oder Server?

Im Folgenden werden kurz die Vor - und Nachteile der Variante a) und b) erläutert:

 
Kriterien Mikocontroller als Server Mikrocontroller als Client
Softwareumfang aus Sicht Mikrocontroller (Komplexität)
  • (-)  Umfang und Komplexität intensiv, da Funktionalität als (Web)-Server abgebildet werden muss.
  •  (+) Source Umfang klein und weniger komplex zu programmieren.
Hardwareumfang aus Sicht Mikrocontroller
  • (-)  Höherer Speicherbedarf für Source und Datenablage.
  •  (++) Hardwareumfang kann sehr klein gehalten werden, da Client als reiner Datenlieferant dient (kleinerer Speicher sowie kleinere leistungsfähige Mikrocontroller nötig).
Verfügbarkeit / Datenhaltung
  • (+) keine Abhängigkeit gegenüber anderen Applikationen oder Server.
  • (++) Bei Netzausfall werden Daten weiterhin aufgezeichnet.
  •  (- -) Wenn der Server über das Netz nicht erreichbar ist, können keine Daten gesammelt werden.
  • (- -) Bei Netzausfall (Internet) stehen alle Messstationen quasi lahm, da die Daten nicht mehr gespeichert werden / können.
Datenkonsolidierung
  • (- -) Datenkonsolidierung über mehrere Server (Messstationen) komplex.
  • (-) Grafische Aufbereitung der gesammelten  Daten ist Source intensiv und komplexe zu programmieren.
  •  (++) Datenkonsolidierung über mehrere unabhängige Messstationen einfacher möglich.
  • (++) Funktionsumfang (Datensammlung, grafische Darstellung, Allarmauslösung etc.) einfacher zu handeln und zu  programmieren, da Web-Server weitaus Leistungsfähiger ist.
Ausbaufähigkeit
  • (+) Grundsätzlich kann ein  Server flexibler ausgebaut und mit weiteren Funktionen zu versehen werden.
  • (-) Flexibler heisst in diesem Fall aber auch: Source intensiv und komplexere Programmierung
  •  (-/+) Flexibilität bezieht sich auf den Server, jedoch nicht hinsichtlich dem Client, welcher als reiner Datenlieferant agiert dito. bezüglich Ausbaufähigkeit.

 

 

xively-com als Dienstleister für Datenlogging

Zu Variante b) existiert ein Gratis-Server auf  https://xively.com . Der Dienstleister offeriert verschiedene Schnittstellenformate für die Anbindung (CSV, XML etc.). Über eine Konsole wird die Schnittstelle auf einfache Art konfiguriert und die gesammelten Daten grafisch dargestellt. Die Anbindung an den COSM-Server ist eigentlich Mikroprozessor unabhängig, trotzdem ist ein Adruino-Board vorzuziehen, da ein Codegenerator für den Arduino-Client von COSM bereits zur Verfügung gestellt wird (Ideal für Beginner).

Weitere Details siehe hier: