Ja, es gibt bereits allerhand Lösungen mit ESP Home, ESP Easy & Co. aber das gefällt mir alles nicht so besonders und bedingt immer eine zentrale Lösung wie FHEM, HA, Grafana etc. in der die Ergebnisse anzeigt und auswertet werden. Meine Lösung stellt die Daten aber, wie auch bei der Zisternenfüllstandsmessung, ohne zentrale Komponente direkt auf einer Webseite dar und bietet eine Anbindung an einen Heimautomatiserungs-Server. Dazu aber gleich mehr.

Installation

Zum flashen der bin-Datei auf den Mikrocontroller kann das Programm „ESPEasy Flasher“ genutzt werden. Dieses ist auf Github unter https://github.com/BattloXX/ESPEasyFlasher/releases/tag/1.1 zu finden. Nach dem Download einfach die ZIP-Datei entpacken, die bin-Datei des Gaszählers in den gleichen Ordner kopieren, Mikrocontroller anschließen und FlashESP8266.exe starten. Nach Auswahl des richtigen COM-Ports und der Firmware startet der Flash-Prozess mit Klick auf „Flash“.

Der Reed-Kontakt muss an GND und D4 angeschlossen werden. Ich spare mir für die zwei Litzen eine Fritzing-Zeichnung. Einen Pull-Down Widerstand habe ich aktuell nicht eingebaut. Bisher war die Messung des Schaltimpuls wenn der Magnet seine Runden machte immer erfolgreich. Falls es ohne Widerstand doch Probleme gibt kann ich ggf. noch eine Zeichnung nachreichen. Als Reed verwende ich immer noch das gleiche Bauteil wie in der vorherigen Lösung am Odroid (mk 471 b z.B. von Reichelt).

Hier die bin-Datei zum direkten Download:

http://www.bubux.de/heimautomatisierung/ota/gaszaehler_aktuell.bin

Ersteinrichtung und Anschluss des Reed-Kontaktes

Nach dem flashen startet der Sensor und baut ein eigenes WLAN-Netz mit dem Namen „WLAN-Gaszaehler“ auf (Access Point – AP). Mit diesem muss man sich z.B. mit einem Smartphone verbinden. Bis es gefunden wird kann es einen Moment dauern – nicht ungeduldig werden. Nach dem Verbinden kann das Smartphone meckern weil kein Internet „hinter“ diesem AP-WLAN verfügbar ist. Manchmal wechselt das Gerät dann wieder schnell zum „normalen“ WLAN. Ist man aber schließlich im AP-WLAN des NodeMCUs eingebucht, ruft man in einem Webbrower die Adresse 192.168.4.1 auf. Es sollte eine Konfigurationsseite zur Eingabe der SSID und des WLAN-Passwortes erscheinen. Hier dann die Daten des eigenen WLANs eingeben und speichern. Der NodeMCU muss anschließend neu gestartet werden (Reset oder vom Strom trennen) und sollte sich beim neuen Start mit den eingegebenen Zugangsdaten in das WLAN einbuchen. Welche IP der NodeMCU bekommen hat, kann man in seinem Router nachschauen. Ab jetzt jetzt ist der Sensor unter der entsprechenden IP im Heimnetz erreichbar. Ist der Sensor nicht in das eingene WLAN eingebucht muss nochmal geprüft werden ob eventuell wieder ein AP aufgemacht wurde.

Startseite und weitere Konfiguration

Auf der Startseite des Sensors werden der bisher gemessene Gesamtverbrauch im Kubikmeter (m³) und Kilowattstunden (kWh) angezeigt und eine Kachel die zu einer Seite mit Auswertungen führt. Die Berechnung des Verbrauchs in kWh erfolgt erst nach mindestens einem Impuls. Zudem werden einige technische Daten angezeigt die mit Klick auf den blauen Balken „Technische Daten“ ausklappen. Unter „Sonstiges“ klappt der Link zu der Konfigurationsseite und einem Button zum Restart des Sensors auf. Bei Impuls blinkt die eingebaute LED des NodeMCUs kurz auf.

In der Konfiguration unter „Sensordaten“ kann der auf der Startseite oben angezeigte Name definiert werden. Der Startwert muss vom Gaszähler abgelesen werden wobei hier die Angabe mit zwei Nachkommastellen erforderlich ist. An der dritten Nachkommastelle des Zählers ist in der Regel der Magnet befestigt dessen Impulse mit dem Reed erfasst werden.

Mithilfe der Werte „Brennwert“ und „Zustandszahl“ wird der Verbrauch in kWh berechnet. Diese Werte sind abhängig vom Gaslieferanten und in der Regel auf der Gasrechnung zu finden. Auch hier sind jeweils zwei Stellen hinter dem Komma einzugeben. Die Werte für Brennwert und Zustandszahl können sich mit der Zeit ändern und können in der Konfiguration entsprechend angepasst werden.

Der Wert Impulszähler sollte zu Beginn auf „0“ gesetzt werden. Hier werden alle gemessenen Impulse hochgezählt, so das bei einem Neustart des Mikrocontrollers, nicht wieder der Startwert angepasst werden muss. Bei Bedarf kann dieser Wert aber auch im Betrieb geändert werden.

Wie auch bei der Messung des Zisternenfüllstandes sind auch hier die aktuellen Werte auch per JSON abrufbar:

Auch können die Daten an einen MQTT-Broker gesendet und/oder an eine eigene API welche die Daten per HTTP-Post entgegen nimmt übermittelt werden.

Auswertung auf bubux.de

Falls eine Datenübermittlung an die bubux-WebAPI aktiviert wurde, erscheint auf der Startseite eine Kachel mit einem Graphensymbol. Bei Klick auf diese Kachel öffnet sich eine weitere Webseite welche die übermittelten Daten darstellt. Eine Kachel für den Tagesverbrauch, eine Kachel für den Monatsverbrauch und eine graphische Darstellung der letzten 7 Wochentage. Diese Seite ist noch im Aufbau. Hier werden mindestens noch ein Graph für den Monatlichen- und den Jahresverbrauch dazu kommen. Die dafür gespeicherten Daten sind die lokale IP-Adresse des Sensors (damit der Klick auf den Link für den Rückweg zur lokalen Sensorseite funktioniert), die MAC-Adresse des Sensors zur Zuordnung der Daten sowie die Impulse. Beim Aufruf der Seite werden Brennwert, Zustandszahl und aktueller Zählerstand übermittelt. Diese Daten werden aber nicht gespeichert.

So, bleibt mir nur noch viel Spaß zu wünschen mit dem neuen Sensor. Kommentare sind gerne willkommen.

Eine Möglichkeit zum Logging der Daten mittels MariaDB und Darstellung mittels Grafana habe ich in einem weiteren Artikel beschrieben.

Gruß Chris

Hier findet ihr das Github-Repository: https://github.com/diefenbecker/zisternenmessung

Aber auch bei den Funktionen gibt es Neuigkeiten. Die Version 1030 unterstützt jetzt einen schaltbaren Ausgang an D4 mit dem z.B. eine Pumpe über eine Relais-Platine angesteuert werden kann. Gesteuert wird das über zwei prozentuale Werte die in der Konfigurationsseite zu finden sind.

Hier die bin-Datei zum direkten Download:

http://www.bubux.de/heimautomatisierung/ota/zisterne_aktuell.bin

Viel Spaß damit! Das kommende Wochende verspricht wettertechnisch ja den Einsatz der Zisterne…

Gruß

Chris

Offensichtlich waren aber die dunklen Wintermonate bei einigen Leuten Ansporn, um ihre Heimautomatisierung und Sensorik zu überarbeiten. Es gab viele Einträge im Blog und ich bekam viele Anfragen per Mail bzgl. des Time Of Flight-Sensor VL53L0X als möglicher Ersatz des Ultraschallsensors HC-SR04. Ich hatte ja auch bei der Version 1028 nach fleißigen Testern und Rückmeldungen gefragt. Vielen Dank euch dafür! Das hat mich auch motiviert mal wieder was an dieser Front zu tun.

Auch wenn mein Ultraschallsensor für seine 2,50€ seit 3 Jahren tadellos seine Arbeit in der Zisterne verrichtet und ich bisher keine Notwendigkeit sehe diesen zu ersetzen, habe ich mir einen weiteren Sensor zu Testzwecken beschafft und in die Software implementiert. Ergebnis ist die Version 1029 der Software.

Neben dem ToF VL53L0X kann nun auch der VL53L1X angeschlossen und genutzt werden. Zu den Unterschieden der beiden Sensoren findet man einiges im Internet. Welcher Sensor nun im jeweiligen Anwendungsfall die bessere Wahl ist, muss jeder selber herausfinden bzw. freue ich mich auch wieder auf Rückmeldungen im Blog oder per Mail bzgl. eurer Erfahrungen.

Zu den beiden ToF-Sensoren nur ganz kurz folgende Zeichnung bzgl. der Öffnungskegel in Abhängigkeit zum Messabstand. Dazu aber noch weiter unten ein bisschen mehr Details da es anscheinend bei den möglichen Abständen etc. nicht verallgemeinert werden kann, welcher Sensor die bessere Wahl ist. Ich habe dazu auch (bisher) keine Tests gemacht!

Der Anschluss des VL53L1X erfolgt analog des VL53L0X. Die notwendigen PINs zum Anschluss sind u.a. in der Applikation angegeben. Hier aber nochmal schnell das Anschlussschema für die beiden ToF-Sensoren.

Die Version 1029 unterstützt weiterhin den Ultraschallsensor sowie die Displays und den Temperatursensor. Für das komplette Anschluss-Schema schaut bitte in den älteren Blog-Eintrag hier.

Die beiden ToF-Sensoren unterstützen seitens der API noch verschiedene Einstellungen die ich in der ersten Version 1028 nicht implementiert hatte und für den VL53L0X nur die Nutzung der Default-Einstellungen möglich war. In der neuen Version habe ich im ersten Anlauf zumindest ein paar wenige Einstellungsmöglichkeiten implementiert.

Dazu gehört für beide ToF-Sensoren die Möglichkeit den Abstandsmodus anzupassen. Hier holt man auch aus dem VL53L0X noch mehr heraus als im Datenblatt angegeben ist und muss bei größeren Abständen nicht zwingend auf den VL53L1X wechseln. Zudem habe ich beim VL53LoX noch die mögliche Anpassung des Timings implementiert. Hier kann zwischen dem Default-Wert auch noch High-Accuracy (hohe Genauigkeit) und High-Speed gewählt werden. Auch hier gibt es anscheinend kein Patentrezept um gute Messwerte zu erreichen und ausprobieren scheint die Devise.

Da ich diese Werte im „Setup“ setze, ist nach Änderung in der WebUI ein Neustart des Sensors notwendig damit die neu eingstellten Werte greifen. Beim VL53L1X muss man den ESP auch ggf. mal vom Strom trennen. Der scheint da etwas zickig was ich auch schon erfahren musste als es nur seltsame Werte bei der Messung gab.

Die weiteren Einstellmöglichkeiten des VL53L1X muss ich mir noch genauer anschauen und implementiere sie dann ggf. in einem nächsten Update. Hier gibt es z.B. noch die Möglichkeit zur Anpassung des Timings (ähnlich dem VL53L0X was ich dort bereits implementiert habe), die Anpassung der Größe des Empfangs-Arrays (SPAD) sowie der Anpassung der Region of Interest (ROI) und Definition eines Offsets. Mit diesen Parametern kann man u.a. „spielen“, falls der Sensor hinter eine Glasscheibe verbannt werden soll.

Den Download der neuesten Version gibt es hier:

http://www.bubux.de/heimautomatisierung/ota/zisterne_aktuell.bin

Gruß Chris

Ich hatte das Glück auch zu Beginn der Corona-Zeit relativ normal Arbeiten gehen zu können was bis heute so geblieben ist. Das mit dem „Glück“ ist absolut ernst gemeint wenn ich da so einige gute Bekannte sehe die ganz schön zu knabbern hatten und immer noch haben.

Auffallend war aber, dass es in den letzten Monaten sehr viel mehr Anfragen bzgl. der Füllstandmessung der Zisterne mit dem ESP gab. Daher heute nochmal eine neue Version mit vielen größeren und kleineren Neuerungen.

Neuerungen in dieser Version (1022)

• Länge des WLAN-Passwortes auf 63 Zeichen verlängert (max. bei WPA2)
• Unterstützung unterschiedlicher Zisternenformen
• Integration von Displays
• Optionale tägliche Info per Pushover
• Weiterer Topic (Abstand) für MQTT hinzugefügt
• viele Kleinigkeiten…

Achtung! Aufgrund der Anpassung der maximalen Länge des Passwortes werden bei einem Update einer alten Version bereits vorhandene Konfigurationsdaten (z.B. Sensorabstände) im Speicher des ESP nach hinten geschoben und gehen dadurch verloren. Daher die Werte vorher merken!

Die Anleitung zur Installation der Software auf dem ESP und der grundsätzlichen Funktionen sind in einem älteren Artikel, der hier zu finden ist beschrieben.

Danach gab es noch zwei Artikel mit weiteren Hinweisen zu JSON und MQTT. Das neue MQTT-Topic für den Abstand in dieser Version funktioniert analog zu dem bisherigen für den Füllstand.

Externe Displays

Diesmal habe ich bei der Entwicklung anstatt der bisherigen „One-Man-Show“ nette Unterstützung gehabt. Vor allem bei der Integration der Displays. Vielen Dank an Patrick für Deine Arbeit und Hilfe!

Aktuell stehen drei Displays zur Auswahl, die an den ESP angeschlossen werden können:

• 1602 LCD mit I2C mit 2×16 Zeichen
• 1604 LCD mit I2C mit 4×16 Zeichen
• SSD 1106 oder 1306 OLED mit 128×64 Pixel

Die Displays zeigen neben Informationen zum Füllstand auch Informationen zur Verbindung mit dem voreingestelltem WLAN während des Boot-Vorganges. Ersteres Display ist die preisgünstigste Alternative und reicht für alle wichtigen Infos.

In den Bildern von Patrick ist auch zu sehen wie ein Aufbau der Elektronik aussehen kann. Sehr schön gemacht!

Bei mir schaut das seit der Inbetriebnahme wie folgt aus und ist im Holzschuppen untergebracht:

Hier das Anschluss-Schema inkl. optionalem Display. Der ebenso optionale Taster dient zum Aktivieren der Hintergrundbeleuchtung des Displays. Der Widerstand am Taster sollte mit 10kΩ gewählt werden.

Zisternenformen

Neben der bisher zylindrischen Zisternenform werden nun auch Zisternen mit anderen Grundflächen unterstützt. Die Berechnung des Füllstandes kann zudem basierend auf dem Maximalvolumen erfolgen. Voraussetzung für alle Berechnungen ist aber eine Form mit senkrechten Wänden.

Pushover Notifications

Auch wenn Pushover nicht kostenlos ist (die App selber, Versand der Nachrichten bis zu einer gewissen Menge (7400) schon), bietet es eine einfache und schnelle Möglichkeit Infos auf ein Handy zu senden die ich u.a auch schon im Homematic-Umfeld einsetze. Daher fand es auch Einzug in die Software zur Füllstandsanzeige.

Um Pushnachrichten senden zu können müssen die beiden Token die man in der App oder nach Login auf der Pushover-Webseite findet in der Konfiguration eingetragen werden.

Viel Spaß mit der neuen Version und nochmal Danke an Patrick!

Gruß Chris

Mit der Version 1.017 bekommt der NodeMCU mit dem Sensor für die Füllstandsmessung der Zisterne (siehe auch die beiden anderen Artikel hier und hier) das MQTT-Protokoll beigebracht. Was MQTT ist, erfahrt ihr ausführlich hier in der Wikipedia oder hier mit weiterführenden Erklärungen wie das ganze z.B. in FHEM genutzt werden kann. Im Heise-Artikel wird MQTT auch sehr anschaulich erklärt.

Benötigt wird ein MQTT-Server (z.B. Mosquitto) dessen IP in die Konfiguration eingetragen werden muss. Optional kann ein Benutzername und ein Passwort genutzt werden. Dann noch das Topic unter dem der Sensor seinen Wert (Füllstand in %) an den MQTT-Broker veröffentlichen soll. Unter „Intervall“ dann noch die Zeit in Sekunden zwischen den Veröffentlichungen angeben.

http://www.bubux.de/heimautomatisierung/ota/zisterne_aktuell.bin

Gruß Chris

Heute nochmal ein Update bzw. eine vollständige Zusammenfassung zur Messung des Füllstands der Zisterne mittels Ultraschall. Ich habe den Sketch für den ESP8266 (den ich immer noch in Form eines NodeMCU betreibe) mal etwas aufgebohrt.

Zu den alten Artikeln geht es hier und hier.

Im folgenden werden alle notwendigen Schritte beschrieben um die Firmware auf den ESP8266 zu flashen und den Sensor in Betrieb zu nehmen.

Benötigte Hardware

Die benötigte Hardware besteht aus einem NodeMCU mit ESP8266 und einem HC-SR04 Ultraschallsensor. Die Beschaltung folgt weiter unten.

Dann noch ein mindestens vieradriges Kabel und ein Gehäuse zur Unterbringung des Ultraschallsensors in der Zisterne z.B. eine kleine Aufputzdose aus dem Baumarkt.

Firmware installieren

Zur Installation der Firmware auf dem ESP8266 muss zuerst die Arduino Software auf einem PC installiert werden. Diese ist für Linux, Windows und MAC unter https://www.arduino.cc/en/main/software verfügbar.

Um in der Arduino IDE den ESP8266 nutzen zu können, muss in den Einstellungen (Datei -> Voreinstellungen) in das Feld „Zusätzliche Boardverwalter URLs“ folgende URL eingetragen werden: http://arduino.esp8266.com/stable/package_esp8266com_index.json

Dann unter „Werkzeuge -> Board … -> Boardverwalter…“ nach „esp8266“ suchen und „esp8266 by ESP8266 Community“ installieren. Hiermit werden u.a. die Tools zum flashen der Firmware auf den ESP8266 installiert.

Herunterladen der aktuellsten Firmware für die Füllstandmessung der Zisterne www.bubux.de/heimautomatisierung/ota/zisterne_aktuell.bin.

Den NodeMCU mit dem Rechner verbinden. In der Arduino IDE unter „Werkzeuge -> Port“ den COM-Port des NodeMCU ermitteln. Das Flashen der Firmware funktioniert leider nicht direkt aus der Arduino IDE heraus. Hierfür muss die Kommandozeile bemüht werden:

Flashen des ESP8266 unter Windows

Unter Windows dazu die Kommandozeile öffnen (cmd.exe) und dort den folgenden Befehl eingeben:

%USERPROFILE%\AppData\Local\Arduino15\packages\esp8266\tools\esptool\0.4.8\esptool.exe -vv -cd nodemcu -cb 57600 -ca 0x00000 -cp COMXY -cf Pfad_zur_Firmwaredatei

Wichtig: Die Versionsnummer des esptool kann ggf. abweichen, das Device hinter -cp (COMxy) muss entsprechend angepasst werden sowie der Pfad zur Firmwaredatei muss entsprechend angepasst werden.

Flashen des ESP8266 unter Linux

Auf der Kommandozeile folgenden Befehl ausführen:

~/.arduino15/packages/esp8266/tools/esptool/0.4.9/esptool -vv -cd nodemcu -cb 57600 -ca 0x00000 -cp /dev/ttyxxxx -cf Pfad_zur_Firmwaredatei

Wichtig: Die Versionsnummer des esptool kann ggf. abweichen, das Device hinter -cp muss entsprechend angepasst werden sowie der Pfad zur Firmwaredatei muss entsprechend angepasst werden.

Anschluss des Sensors

Von HC-SR04 an NodeMCU:

Vcc an VU
Gnd an GND
Trig an D2
Echo an D1

Inbetriebnahme

Ist die Firmware auf den NodeMCU geflasht und der SR04-Ultraschallsensor angeschlossen, kann die Inbetriebnahme erfolgen. Dazu den Sensor mit Strom versorgen.

Der Sensor versucht sich mit einem konfigurierten WLAN zu verbinden. Funktioniert dies nicht (was bei der ersten Inbetriebnahme der Fall ist), erstellt der Sensor einen WLAN Accesspoint mit dem Namen „WLAN-Zisterne“ der z.B. im Smartphone gefunden werden sollte. Mit diesem WLAN verbinden.

Nun im Browser des verbundenen Gerätes die Adresse http://192.168.4.1 aufrufen. Diese Adresse wird in der Regel auch in den Verbindungseinstellungen des verbundenen WLAN angezeigt und verlinkt. Es öffnet sich nun die Konfigurationsseite des Sensors.

Dort die SSID und das Passwort des Heim-WLAN eingeben und auf „Konfiguration speichern“ klicken. Die weiteren Einstellungen können später erfolgen.

Der Sensor startet daraufhin neu und versucht sich mit dem Heim-WLAN zu verbinden. War dies erfolgreich ist der Accesspoint nicht mehr erreichbar und des Sensor sollte eine IP-Adresse im Netzwerk zugewiesen bekommen haben. Diese kann im Router nachgeschaut werden )in der Friztbox z.B. unter „Heimnetz -> Netzwerk„).

Ist der Accespoint „WLAN-Zisterne“ weiterhin sichbar, war die Verbindung mit den Heim-WLAN nicht erfolgreich. Dann die obigen Schritte erneut ausführen.

Betrieb

Die Oberfläche des Sensor ist nun im Browser nach Eingabe der IP-Adresse verfügbar. Für den weiteren Betrieb müssen zuerst weitere Einstellungen vorgenommen werden. Dazu den Bereich „Sonstiges“ aufklappen und auf „Konfiguration“ klicken.

Einstellungen des Sensors

Unter „Abstand Sensor/Boden“ muss der Abstand in Zentimeter zwischen Sensor und Boden der Zisterne angegeben werden. Unter „Abstand Sensor/Max. Höhe“ muss der Abstand zwischen Sensor und Wasseroberfläche bei maximalen Wasserstand angebenen werden. Ist die Zisterne nicht voll, kann der Wert auch jederzeit korrigiert werden

Daten an eigene API übergeben

Die Daten des Sensors können an eine eigene Schnittstelle übergeben werden. Hierzu kann ein Server, Port und der Pfad angegeben werden. Die Sensordaten werden als Argumente in der URL angehangen. So kann z.B. ein PHP-Script auf dem Server aufgerufen werden welches die angehangenen Argumente empfängt und weiter verarbeitet (z.B. an FHEM übergibt oder in eine Datenbank schreibt.

Update 20.07.2019

Die URL für die eigene API kann mit zwei Variablen frei definiert werden. Dazu die Variablen „_abstand“ und „_fuellstand“ in einer beliebigen URL nutzen. Im NodeMCU werden die beiden Platzhalter durch die echten Werte ersetzt.

Zum Beispiel wird aus der konfigurierten URL:
/umwelt/zisterne_neu.php?abstand=_abstand&fuellstand=_fuellstand
beim Aufruf der eigenen API dann:
/umwelt/zisterne_neu.php?abstand=29&fuellstand=100.00&vcc=2.75

Hier ein Beispielscript welches das Schreiben der Werte in eine Textdatei und in eine MySQL-Datenbank vornimmt sowie die Übergabe der Werte an eine FHEM-Installation:

<?php

$fuellstand=$_GET["fuellstand"];
$abstand=$_GET["abstand"];
$vcc=$_GET["vcc"];

//*************************
// Werte in Datei schreiben
//*************************
$datum = date("d.m.Y H:i");
$handle = fopen ('zisterne.txt', 'a');
fwrite ($handle, $datum.",".$fuellstand.",".$abstand."\n");
fclose ($handle);

//****************************
//Werte in Datenbank schreiben
//****************************
$servername = "localhost";
$username = "benutzer";
$password = "passwort";
$dbname = "dbname";

$connection = new mysqli($servername, $username, $password, $dbname);
if ($connection->connect_error) {
        die("Connection failed: " . $connection->connect_error);
}
$sql = "INSERT INTO zisterne (timestamp,fuellstand,spannung) VALUES (CURRENT_TIMESTAMP,$fuellstand,$vcc)";
if ($connection->query($sql) === TRUE) {
        //echo "INSERT war erfolgreich";
} else {
        echo "Error: " . $sql . "<br>" . $connection->error;
}

//***********************
//Werte an FHEM übergeben
//***********************
$fhemhost = "192.168.178.1";
$fhemport = 7072;
$fhemsock = fsockopen($fhemhost, $fhemport, $errno, $errstr, 30);
$fhemcmd = "set ZisterneFuellstand ".$fuellstand."\r\nquit\r\n";
fwrite($fhemsock, $fhemcmd);
fclose($fhemsock);

$fhemsock = fsockopen($fhemhost, $fhemport, $errno, $errstr, 30);
$fhemcmd = "set ZisterneSpannung ".$vcc."\r\nquit\r\n";
fwrite($fhemsock, $fhemcmd);
fclose($fhemsock);
?>

Daten an bubux.de übergeben

Steht kein eigener Server zur Historisierung der Daten zur Verfügung, können die gemessenen Werte an bubux.de gesendet werden. Dort ist (aktuell) eine Auswertung des letzten 30 Tage verfügbar und wird graphisch dargestellt. Nach der Aktivierung mittels der Checkbox ist ein entsprechender Link auf der Startseite des Sensors verfügbar.

Es werden der prozentuale Füllstand, die MAC-Adresse zur Zuordnung der Daten, die lokale IP des Sensors zur Verlinkung von der Webseite auf bubux.de zur Webseite des Sensors und die Version der Firmware übergeben.

Startseite des Sensors

Sind alle Einstellungen vorgenommen kann der Sensor genutzt werden. Auf der Startseite werden der prozentuale Füllstand und der aktuelle Abstand zwischen Sensor und Wasseroberfläche angezeigt.

Einbau

Da der Einbau je nach Zisterne individuell ist, will ich nicht viel Worte darüber verlieren. Nur soviel, das ich den Sensor in ein Baumarkt-Aufputzdose gepackt habe und mit Heißkleber „vergossen“ haben. Harz wäre wahrscheinlich besser gewesen, aber der Sensor funktioniert bisher einwandfrei. Der Sensor hängt nach unten an einem Brett in der Zisterne. Der NodeMCU ist an ein etwa 6m langes Kabel angeschlossen und ist in einem Lagerräumchen untergebracht.

Ich würde mich über Rückmeldungen (Fehler, Verbesserungswünsche, …) bzgl. der neuen Firmwareversion freuen. Todo wäre noch die Daten per JSON abrufbar zu machen und z.B. ein Plugin für FHEM zu bauen.

Viel Spaß beim basteln!

Chris

Der Sensor kann zwei Partikelgrößen parallel messen:
– PM₁₀, inhalierbarer Feinstaub mit 10µm Durchmesser
– PM_2,5, lungengängiger (alveolengängiger) Feinstaub mit im Mittel 2,5 µm Durchmesser

Mehr zu diesem Thema gibt’s im Wikipedia-Artikel.

Also, Sensor bestellt und drei Wochen später ohne Zollprobleme frei Haus geliefert bekommen.

Der Sensor kommt mit USB-Adapter für den einfachen Anschluss am Odroid (oder auch am Raspberry Pi wie im Artikel beschrieben). Im Make-Artikel wird ein Shellscript vorgestellt, mit dem die Sensordaten gelesen und verarbeitet werden. Ich habe am Ende des Scriptes nur noch eine Zeile zum Speichern der Daten in meine MySQL-Datenbank eingefügt. D.h. nach 10 Minuten Bastelei lief schon alles…das war fast zu einfach. Das Script wurde dann alle 10 Minuten per Cron aufgerufen um die gemessenen Daten in meine MySQL-Tabelle zu schreiben. Der Lüfter des Sensors läuft bei dieser Lösung durchgehend (dazu unten mehr).

Jetzt konnte ich die Feinstaubbelastung im Heizungsraum bestimmen. Irgendwie musste der Sensor nun noch nach draußen. Da ich kein Loch in den Fensterrahmen bohren wollte, stellte sich das als Problem heraus.

Auf der Suche nach einer kabellosen Lösung und mit einem NodeMcu in der Schublade, bin ich nach kurzer Internet-Recherche auf die Webseite http://luftdaten.info aus Stuttgart gestoßen. Dort wird eine sehr einfache Selbstbaulösung zur Feinstaubmessung auf Basis des NodeMcu vorgestellt. Es werden verschiedenen Sensoren zur Feinstaubmessung und Temperatur- und Luftfeuchtemessung unterstützt. Unter anderem ist dort auch der im Make-Artikel verwendete SDS011-Feinstaubsensor integriert. Die Firmware gibt es als Bin auf der Webseite zum Download und die Quellen bei Github. Die Lösung mit den HT-Rohren als Gehäuse fand ich auch sehr gelungen und günstig. Das Aufspielen der Firmware, die Verkabelung und Verstauung der wenigen Teile im HT-Rohr sind in wenigen Minuten erledigt.

Nach Anschluss des NodeMcu an ein herkömmliches USB-Netzteil ist der NodeMcu als Access Point (AP) unter der Standardadresse http://192.168.4.1/ eines ESP8266 erreichbar. Dort können dann unter anderem die Zugangsdaten für das eigene Wifi-Netzwerk eingerichtet werden. Zudem können die angeschlossenen Sensoren ausgewählt werden sowie die Übertragung der ermittelten Daten an verschiedene Datenbanken z.B. zur Aufnahme in die Karte de/aktiviert werden. Hier gibt es auch die Möglichkeit eine API zur eigenen Verarbeitung der Daten anzusprechen. Das funktionierte bei mir leider nicht, so das ich im ersten Anlauf die vom NodeMCU generierte Webseite parsen musste um die Daten in meine MySQL-Tabelle zu speichern. Schon ein paar Tage später konnte man aber mittels der neuen Firmware (die OTA ausgeliefert wird, wenn aktiviert) die Sensordaten per JSON abfragen. Das ist komfortabler und zukunftssicherer als das Parsen der HTML-Seite.

Hier ein PHP-Beispiel zum parsen der JSON-Daten welches z.B. auch per Cron aufgerufen werden kann:

/data.json');
$json_ergebnis=json_decode($json);

$PM10=$json_ergebnis->sensordatavalues[0]->value;
$PM25=$json_ergebnis->sensordatavalues[1]->value;
?>

Die Lösung aus Stuttgart unterstützt den Sleep-Mode des Sensors der in der Lösung der Make nicht genutzt wurde. D.h. die Messung und der Lüfter werden nur alle ~30 Sekunden gestartet anstatt dauerhaft zu laufen. Das erhöht die Lebenserwartung des Sensors die mit 8000 Betriebsstunden angesetzt ist. Nach dem Sommer werde ich mal die Luftkammer des Sensors öffnen und schauen was sich dort so angesammelt hat.

Die mittels JSON in einer Datenbank gesammelten Daten werte ich auf meiner Webseite aus. Das schaut dann wie folgt aus (zweimal war der Sensor nicht aktiv):

Die Weltgesundheitsorganisation (WHO) hat folgende Richtwerte für Feinstaubgrenzwerte heraus gegeben:

Jahresmittel PM10	20 µg/m³
Jahresmittel PM2,5	10 µg/m³
Tagesmittel PM10	50 µg/m³ ohne zulässige Tage, an denen eine Überschreitung möglich ist
Tagesmittel PM2,5	25 µg/m³ ohne zulässige Tage, an denen eine Überschreitung möglich ist

Somit sind wir hier trotz plattem Land schon recht nah (bzw. darüber -> Tagesmittel PM_2,5) an den Werten der WHO dran.

Die Initiative aus Stuttgart zur einfachen Feinstaubmessung finde ich eine super Sache! Vielleicht findet sich ja noch der ein oder andere Nachbauer um die Karte zu füllen.

Gruß Chris

Die ursprüngliche Idee ist von Michal. Er nutzt allerdings einen Kürbis aus Keramik. Ich hab den Arduino in einen echten Kürbis verfrachtet. In dem Kürbis gibt es nichts, was Isopropanol an der Elektronik nicht wieder sauber bekommt.

Also Kürbis schnell ausgehöhlt, Mund, Nase und Augen reingeschnitten und an der Innenseite der Augen etwas Platz für die beiden „MAX7219 LED 8×8“ geschnitzt. Diese habe ich mit Zahnstochern von innen fixiert. Der Arduino liegt frei verkabelt im Kürbis.

So schaut es dann aus: ein freundlich schauender Halloween-Kürbis!

Gruß

Chris

An einem der letzten Wochenenden habe ich mit zwei Bekannten ein Wortuhr-Bau-Wochenende gemacht. Dabei sind an zwei Tagen 3 Wortuhren entstanden. Nach dem Bestücken der Platinen, dem Erstellen der LED-Matrix und der Verkabelung sollte der Sketch auf den Mikrocontroller geladen werden.

Bei dem Versuch wehrte sich die Arduino IDE allerdings den Sketch auf den Mikrocontroller zu spielen. Grund dafür war ein fehlender Bootloader. Da hatte ich bei der Bestellung der Platinen und der Bauteile wohl das entsprechende Häkchen für einen bereits vorprogrammierten Atmel vergessen.

Warum ein Bootloader?

Der Bootloader auf dem Atmel AVR wird benötigt um den Arduino mittels serieller Schnittstelle einfach mit Programmen (Sketch) z.B. mit der Arduino IDE programmieren zu können. Hierbei übernimmt der Bootloader zwei Dinge:

1. Der Bootloader versucht beim Start festzustellen, ob ein neuer Sketch vom PC auf den Mikrocontroller geladen werden soll. Ist das der Fall, wird das Programm vom PC auf den Mikrocontroller geladen. Daher wird der Mikrocontroller beim Versuch neuen Code hoch zu laden, vorher immer durch die Arduino IDE resetet.
2. Wenn nicht mittels PC versucht wird ein Sketch auf den Mikrocontroller zu laden, wird der der bereits installierte Code ausgeführt.

Eine Möglichkeit um den Bootloader auf den Atmel zu laden, ist einen anderen Arduino als Programmer zu nutzen. Da ich noch einen Arduino Nano hier rumliegen hatte, musste der dafür herhalten.

Einen Arduino Nano als AVR ISP (In-System Programmer)

Folgende Schritte sind zu befolgen um den Bootloader auf einen Atmel AVR zu spielen:

1. ArduinoISP-Sketch auf Arduino laden

In der Arduino IDE das Beispiel „ArduinoISP“ öffnen. Eine aktuelle Version ist auch auf GitHub zu finden.

Den Arduino Nano mittels USB an den Rechner anschliessen und ggf. unter „Werkzeuge->Port“ den entsprechenden Port einstellen. Den geladenen Sketch anschließend mit der „Pfeiltaste“ auf den Arduino Nano laden.

Den Arduino Nano wieder vom Rechner trennen.

2. Arduino Nano mit dem Mikrocontroller verbinden auf den der Bootloader aufgespielt werden soll

Auf dem Arduino Nano müssen die Pins 10 (SS/RST), Pin 11 (MOSI), Pin 12 (MISO), Pin 13 (SCK), GND und VTG (5V) mit den entsprechenden ISP-Pins der Platine, auf die der Bootloader gebrannt werden soll, verbunden werden.

3. Den Bootloader aufspielen

Der PC kann nun wieder mittels USB mit dem Arduino Nano verbunden werden. Durch die Verbindung des Arduino Nano und dem Ziel-Mikrocontroller (was in meinem Fall die Platine für eine Wortuhr ist), sollten nun jeweils die Power LEDs leuchten.

Jetzt in der Arduino IDE unter „Werkzeuge->Platine“ das Board auswählen auf den der Bootloader gebrannt werden soll. Im Fall der Platine für die Wortuhr ist das ein „ARDUINO Duemilanove or Diecimila“

Dann unter „Werkzeuge->Programmer“ den Eintrag „Arduino as ISP“ auswählen.

Im letzten Schritt den Bootloader mit Klick auf „Werkzeuge->Bootloader brennen“ auf den Ziel-Atmel übertragen.

Im Ergebnis sollte in der Arduino IDE die folgende oder eine ähnliche Ausgabe mit dem Erfolg der Installation des Bootloaders zu sehen sein.

Während des Brennvorganges blinken die LEDs auf den Arduino Nano. Bei mir brauchte es, warum auch immer, ab und an einen zweiten Klick auf „Bootloader brennen„.

Die detailierte Ausgabe beim Hochladen des Bootloaders oder auch eines Sketches kann übrigens unter „Datei->Voreinstellungen“ eingestellt werden.

Viel Spaß beim Bootloader-Brennen!

Gruß

Chris