Kleine Probleme

Einzig meine gewohnte Freiluftverdrahtung mit einem Gummi der den Reedkontakt am Zähler festhält (der die Klebeband-Halterung ablöste) wurde regelmäßig porös und der Reedkontakt fiel runter. Meistens merkte ich das erst Tage später. Da ich mir Ende letzten Jahres einen 3D-Drucker angeschafft habe, wollte ich bei diesem Projekt mein erstes ordentliches Gehäuse für meine Sensoren erstellen wo mal nichts irgendwo einfach nur herum baumelt.

Bei Makerworld, Printables & Co gibt es sehr viele fertige Modelle für entsprechende Halterungen. Danke an die kreativen Designer! Manche sind für den NodeMCU inklusive Reedkontakt, manche für einen Wemos D1 inklusive Reedkontakt und manche nur für verschiedene Reedkontakte alleine. Ich habe ein Gehäuse für beides gesucht. Nachdem ich ein passendes Model gefunden und ausgedruckt hatte, ging es an die Montage. Die meisten dieser fertig designten Gehäuse nutzen einen axialen Reedkontakt. Diese haben meistens nur einen simplen Glaskörper. Hier war schon mein erstes Problem das diese Glasreeds echt empfindlich sind wenn man mal an den Beinchen biegt. Ich bin wahrscheinlich zu grobmotorisch aber sie sind ja billig…

Das größere Problem war aber, dass diese Reedkontakte nicht oder unzuverlässig anziehen wenn der Magnet des Zählers vorbei kommt da dieser recht schwach ist (Stichwort Anzugsempfindlichkeit). Auch hundertmaliges Ausrichten in der Öffnung des Zählers, Ausrichten des Reedkontaktes parallel zum Magneten, testen verschiedene andere Reedkontakte (aus zylinderförmig eingegossene Exemplare) etc. war nicht zielführend und raubte mir den letzten Nerv weil alles ja schon mal gut funktionierte. Nur mein alter Meder MK471 funktionierte zuverlässig.

Das neue Gehäuse

Der MK471 passt aber in fast alle fertigen Gehäusedesigns nicht rein. Und die wenigen Gehäuse die den MK471 beherbergen können, passten nicht an meinen Gaszähler. Also hab ich mir ein schönes Gehäuse für den Wemos D1 Mini als Basis gesucht und mit FreeCad (ich komme mit dem 3D-Drucker eh nicht drumherum das zu lernen) entsprechende Anpassungen gemacht damit anstatt einem axialen Reedkontakt der MK471 rein passt. Das war nicht wirklich schwer und sehr viel Mühe hab ich auch nicht rein gesteckt. Die STL-Datei muss in Freecad einen Festkörper gewandelt werden und danach einfach die Aufnahme für den axialen Reedkontakt mittels „Pocket“ mit einem passenden Rechteck aus dem Sketch „durchbohrt“. Da klemmt sich der MK471 jetzt ohne Probleme fest.

Neue Softwareversion

Neben dem Gehäuse hab ich dann doch noch ein bisschen den Quellcode erneuert. Ich musste ja noch die LED die im Gehäuse vorgesehen ist einprogrammieren. Bisher blinke nur die interne LED des Mikrocontrollers. Aber die sieht man ja im Gehäuse nicht mehr. Dazu gab es noch ein paar andere kleine Korrekturen und Verbesserungen. Die LED muss mit Vorwiderstand an D3, der Reedkontakt bleibt wie gehabt an D4 wo jetzt per Software auch der interne Pullup aktiviert wird. Einen Plan für die Verdrahtung hab ich dafür hier nicht gemacht.

Aber wirklich schlecht implementiert hatte ich das Senden der Impulse an den MQTT-Server. Hier hatte ich bei jedem Impuls eine neue Verbindung zum Server geöffnet und dann das Publish gesendet. Das dauerte gefühlt immer ewig und war auch der Grund warum in der Vergangenheit der ein oder andere Impuls in Richtung MQTT verschluckt wurde.

Der neue Ansatz baut nun einmal bei Start die Verbindung zum MQTT auf, prüft im Loop ob diese Verbindung noch besteht und macht ggf. ein Reconnect. Bei einem Impuls durch den Reedkontakt wird dann nur noch der Impuls per Publish an den MQTT-Server gesendet. Viel besser

Den aktuellen Quellcode für die Version 1008 inkl. vorkompiliertem Binary gibt es wie immer auf Github:

https://github.com/diefenbecker/opengasmeter

Viel Spaß damit
Gruß Chris

Die Alterung von Lithiumionen Akkus läßt sich ganz nicht verhindern, aber merklich beeinflussen. Schnelles Laden und Tiefentladen (unter 20%) tut dem Akku weh, aber besonderen Stress bereitet ihm Vollladen auf 100%, und dann u. U. noch langes Halten dieses Ladeniveaus am angeschlossenen Ladegerät. Den Akku nur auf 80 oder 85% aufzuladen statt auf 100% verlängert die Lebensdauer nach Stephan Klapzus‘ Akkurechner von 800 auf 3500 bzw. 2800 Zyklen, immerhin über 4 bzw. 3 mal soviel. Wenn Ihr also auch mit 80 oder 85% Ladezustand über den Tag kommt, dann zeige ich Euch einen Weg wie ihr das einfach automatisieren könnt.

Wir brauchen dazu eine WLAN Steckdose mit der Firmware Tasmota und eine App (nur bei Android Geräten, bei iOS reichen Bordmittel), die der WLAN Steckdose – in der das Ladegerät steckt – bei Erreichen eines bestimmten Akkustands den Befehl zum Abschalten gibt.

WLAN Steckdose mit Tasmota in Euer Netzwerk einbinden

Zunächst benötigt ihr eine WLAN Steckdose (oder ein Shelly hinter einer „normalen“ Steckdose, welches diese schalten kann) mit der Firmware Tasmota von Theo Arends. Auf viele WLAN Steckdosen, die mit proprietärer Firmware ausgeliefert werden läßt sich Tasmota flashen. Da gibt es verschiedene Wege und viele Anleitungen im Internet, das soll nicht Gegenstand dieses Beitrags sein. Wer nicht flashen möchte kann auch WLAN Steckdosen kaufen, die schon mit Tasmota geflasht sind. Ich selber nutze selbst geflashte von OBI und Sonoff S20.

Wenn ihr so eine Tasmota WLAN Steckdose das erste mal bei Euch in eine Steckdose steckt, dann spannt sie ein eigenes offenes WLAN auf. Sucht es z. B. mit Eurem Smartphone und wählt es aus, die Frage bzw. Warnung ob ihr das WLAN nutzen wollt obwohl kein Internetzugang besteht müßt ihr bejahen. So sieht das z. B. aus:

Wahrscheinlich kommt dann die Meldung, dass Ihr Euch im WLAN anmelden müßt. Bestätigt sie und ihr landet auf dieser Seite (falls nicht, dann gebt die IP 192.168.4.1 im Browser Eures Smartphones in die Adresszeile ein. Falls die IP nicht funktioniert, schaut nach, ob ihr in dem WLAN, welches die Steckdose aufspannt – im Beispiel das von oben, „tasmota-12ABA9-2985“ – auch wirklich drin seid):

Hier gebt ihr unter „WiFi Network“ den Namen Eures WLANs an, oder ihr wählt es aus der Liste obendrüber aus. Unter „WiFi Password“ gebt Ihr Euer WLAN Passwort ein und drückt auf Save. Die WLAN Steckdose startet dann neu. Wenn ihr Euch nicht vertippt habt bucht sie sich beim Neustart in Euer WLAN ein. Meldet Euch nun in der Konfigurationsoberfläche Eurer Fritzbox an und sucht unter Heimnetz -> Netzwerk -> Reiter Netzwerkverbindungen nach der Steckdose, sie sollte genau so heißen wie das WLAN, welches sie im Schritt vorher aufgespannt hat:

Der Steckdose müßt ihr nun eine feste IP Adresse geben. Das solltet ihr sowieso tun, damit ihr die Weboberfläche der Steckdose eben unter dieser IP immer im Browser erreichen könnt. Klickt dazu auf den blauen Stift im hellblauen Kreis auf dem Bild oben. Auf der Seite, die dann aufgeht könnt ihr dem Gerät erstmal einen schöneren Namen geben, den Ihr Euch besser merken könnt, tragt ihn im Feld „Name“ ein:

Scrollt etwas nach unten, und setzt den Haken bei „Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen.“ Klickt dann ganz unten auf „Übernehmen“

Schaut nach, ob Ihr unter dieser IP (im Beispiel 192.168.178.133) die Steckdose erreichen könnt, gebt dazu die IP in die Adresszeile Eures Browsers (PC oder Smartphone, im gleichen Netz wie die Steckdose) ein. Ihr solltet auf dem Webserver der Steckdose mit der Tasmota Oberfläche landen, bei mir sieht das so aus (Temperatur, Luftdruck und Luftfeuchtigkeit kommt bei mir nur deshalb, weil noch ein BME280 Sensor angeschlossen ist – bei Euch vermutlich nicht):

Die Steckdose ist jetzt soweit vorbereitet.

Smartphone (oder Tablet) mit Android:

Bei einem Android Gerät müßt Ihr Euch jetzt die kostenlose App Automate installieren, die beim Erreichen eines bestimmten Akkustands die WLAN Steckdose ausschalten kann (Apple Geräte können das mit Bordmitteln, das kommt später). Gebt der App die Rechte nach denen sie verlangt, u. a. muss sie im Hintergrund aktiv sein dürfen.

Da Automate alles mögliche automatisieren kann (wie der Name schon sagt) müßt ihr einen sog. „Flow“ programmieren. Das geht grafisch und Ihr könnt das entweder selber machen, oder Ihr importiert meinen Flow, dann müßt Ihr nur noch die IP Adresse der WLAN Steckdose anpassen, denn die wird vermutlich nicht mit meiner übereinstimmen. Der Flow ist ziemlich einfach, er schaut ob der Ladezustand einen bestimmten Wert überschreitet, ist das der Fall schickt er einen http request an die WLAN Steckose, der diese ausschaltet. Und das war’s auch schon.

Ladet Euch den Flow (Dateiendung flo) auf Eurer Smartphone:

Startet Automate, wählt im „Burgermenu“ (3 Punkte rechts oben) „Import“ aus und wählt die Datei aus. Sie sollte dann in Automate unter „Flows“ erscheinen. Tippt erst auf den Namen des Flows (Akku85pct_IP63), dann auf den Stift im Kreis:

Als nächstes auf das Symbol im grünen Quadrat und dann auf den grün umrandeten Block tippen:

Ändert in dem Feld „Request URL“ die IP Adresse auf die, die Ihr Eurer WLAN Steckdose gegeben habt und drückt dann auf SAVE:

Im Feld „Request URL“ sollte jetzt folgendes stehen:

http://<IP Eurer WLAN Steckdose>/cm?cmnd=Power%20off

Damit sind wir eigentlich fertig. Steckt das Ladegerät Eures Android Geräts in die WLAN Steckdose, schaltet sie ein. Startet die App Automate, drückt auf Euren Flow und dann auf Start:

Jetzt müßt Ihr nur noch warten, und wenn Ihr Euch nicht vertippt hat, dann schaltet Eurer Smartphone bei 85% Ladestand die WLAN Steckdose ab.

Anderes Ladeniveau zum Abschalten einstellen (Android)

Natürlich könnt Ihr auch andere Ladelimits z. B. 90% oder 80% einstellen. Geht dazu vor, wie zum Ändern der IP Adresse, nur dass Ihr den Block mit dem Ladelevel ändert:

Stellt den gewünschten Ladezustand ein und drückt auf Save:

Zeitschaltuhr von Tasmota nutzen

Wahrscheinlich geht Ihr immer zur gleichen Zeit zur Arbeit – und hättet dabei gerne ein geladenes Smartphone. Wenn Ihr es nun abends wie beschrieben auf z. B. 80% ladet, dann fehlen Euch morgens wahrscheinlich schon wieder ein paar Prozent Akkustand. Als Abhilfe könnt Ihr einfach einen Timer von Tasmota in der WLAN Steckdose nutzen. Wenn ihr z. B. um 7 Uhr los wollt und der Ladevorgang maximal 2 Stunden dauert, dann könnt ihr z. B. einstellen, dass sich die (abends ausgeschaltete) WLAN Steckdose um 4:30 Uhr einschaltet, und schon abends den Automate Flow zum Abschalten wie oben beschrieben starten. Geht auf die Weboberfläche Eurer Steckdose, in dem ihr die IP in einem Browser eingebt und stellt einen Timer ein:

Vergesst nicht die Häkchen bei „Enable“ (gilt für Timer 1) und „Enable Timers“ (gilt für alle Timer, es sind bis zu 16 verschiedene möglich) zu setzen und bei „Repeat“, wenn sich das wöchentlich wiederholen soll. Am Ende auf „Save“ klicken.

iOS Gerät (iPhone oder iPad)

Bei iOS Geräten braucht Ihr keine App zu installieren, um der WLAN Steckdose bei einem bestimmten Ladelevel den Befehl zum Abschalten zu geben. Bei iOS ist schon die App „Kurzbefehle“ an Bord. Öffnet sie und wählt die Rubrik „Automation“ aus. Legt mit „+“ eine neue Automation an, dabei wird Euch eine Auswahl angeboten, sucht und wählt „Batteriestatus“ aus. Stellt das gewünschte Ladelevel ein (geht nur in 5% Schritten) und setzt den Haken bei „Steigt über“. Drückt auf „Weiter“. Jetzt müßt ihr eine Aktion auswählen, tippt auf das „+“ bei „Aktion hinzufügen“. Wählt die Kategorie „Web“ und dann „Inhalte von URL abrufen“ aus. Wählt als nächstes „URL“ und gebt da, wo Euch apple.com vorgeschlagen wird das hier ein:

http://<IP Eurer WLAN Steckdose>/cm?cmnd=Power%20off

Den Schalter „Vor Ausführen bestätigen“ (sollte er vorhanden sein, wie bei einem iPad mit iOS 16.7.10 der Fall) dürft ihr nicht aktivieren. Bei einem iPhone SE mit iOS 18.1.1 sieht das dann so aus:

Zwar läßt sich das Ladelevel nur in 5% Schritten einstellen, dafür ist die Automation immer aktiv, d. h. ihr müßt sie nicht jedesmal starten, wenn ihr das iPhone mit dem Ladegerät verbindet.

In den Einstellungen des Sensors gibt es daher nun die Möglichkeit das entsprechend zu konfigurieren zu können.

Zudem hatte ich noch in geistiger Umnachtung, den Namen/IP des Rechners, den Port und den Endpunkt zum Aufruf der eigenen API hart mit einer internen URL von mir verdrahtet. Immerhin hatte ich mir einen Kommentar im Quellcode geschrieben, dass das noch geändert werden muss. Hat nix geholfen, ist aber jetzt auch korrigiert.

Hier die aktuelle bin-Datei in der Version 1006:

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

Für die Installation, weitere Erklärungen etc. gilt noch die Beschreibung aus dem ursprünglichen Artikel. Zudem der Artikel zum Auswerten der Impulse in Grafana.

Gruß Chris

Das Zählen der Impulse habe ich bei mir mit einer kleinen PHP-Seite umgesetzt, die bei jedem Aufruf einen neuen Eintrag in eine Datenbank schreibt. Der Mikrocontroller ruft bei mir dazu die Seite „GasMeterImpuls.php“ auf, die auf einem Webserver liegt. Das PHP-Script macht dabei nicht anderes, als bei jedem Aufruf eine neue Zeile mit Zeitstempel und einer „1“ für den Impuls in eine Tabelle einer MariaDB zu speichern.

<?php
//********************************************
//Impuls vom Gaszaehler in Datenbank schreiben
//********************************************

$servername = "";
$username = "";
$password = "";
$dbname = "";

$conn = new mysqli($servername, $username, $password, $dbname);

if ($conn->connect_error) {
        die("Connection failed: " . $conn->connect_error);
}

$sql="INSERT INTO gaszaehler (timestamp,zaehlerstand) VALUES (CURRENT_TIMESTAMP,1)";

if ($conn->query($sql) === TRUE) {
        //echo "Neuer Eintrag erzeugt";
} else {
        echo "Fehler: " . $sql . "<br>" . $conn->error;
}

$conn->close();
?>

Die Tabelle in der MariaDB ist sehr einfach und besteht nur aus zwei Spalten. Einmal eine Spalte mit einem Zeitstempel und eine weitere Spalte für den Impuls. Der Spaltenname „zaehlerstand“ ist evtl. etwas irreführend. Hier werden nur die einzelnen Impulse und kein Gesamtzählerstand gespeichert!

Hier das Create-Table für die Tabelle:

CREATE TABLE `gaszaehler` (
  `timestamp` datetime NOT NULL,
  `zaehlerstand` int(11) NOT NULL
) ENGINE=InnoDB

Heute würde ich anstelle der MariaDB eher eine auf Zeitreihen spezialisierte InfluxDB nehmen. InfluxDB arbeitet auch besser mit Grafana zusammen. Die Nutzung der MariaDB ist bei mir aber „historisch“ bedingt ;-).

Die Daten aus der MariaDB stelle ich dann mit Grafana graphisch dar. Diagramm-Typ ist hier ein „Bar Chart“.

Im Grafana verwende ich dazu für die Bar-Charts die drei folgenden SQL-Statements, die über Summen-Funktionen aus den einzelnen Impulsen die entsprechenden Tages-, Monats- und Jahreswerte berechnen:

SELECT
  timestamp as "time",
  sum(zaehlerstand)/100 as 'jährlicher Gasverbrauch'
FROM gaszaehler
GROUP BY year(timestamp)
ORDER BY year(timestamp) ASC;

SELECT 
  timestamp as "time",
  sum(zaehlerstand)/100 as 'monatlicher Gasverbrauch'
FROM gaszaehler
WHERE year(timestamp) >= YEAR(CURRENT_DATE - INTERVAL 7 MONTH)
GROUP BY month(timestamp), year(timestamp)
ORDER BY month(timestamp)

SELECT 
  timestamp as "time",
  sum(zaehlerstand)/100 as 'täglicher Gasverbrauch'
FROM gaszaehler
WHERE timestamp >= DATE_SUB(NOW(),INTERVAL 7 DAY)
GROUP BY day(timestamp),month(timestamp), year(timestamp)
ORDER BY year(timestamp),month(timestamp),day(timestamp) asc

Die Beschriftung der X-Achse erfolgt über einen „Override“ im Grafana, da die Beschriftung der X-Achse sonst eher unschön wird. Hier im Bild ist ein solcher Override z.B: für den täglichen Verbrauch dargestellt.

Anzeigen lasse ich mir die Diagramme von Grafana dann in der TabletUI von FHEM mittels iframe. Ja, ich nutze immer noch FHEM obwohl das sooo Old School ist und ich im Home Assistant doch alles per klicki klacki machen kann. Will ich aber nicht…

Mit TabletUI von FHEM schaut dann die Oberfläche mit den eingebundenen Diagrammen aus Grafana auch ganz nett aus.

Viel Spaß mit den Auswertungen.

Gruß Chris

Aber nun die drängende Frage: Wohin mit der Hülle der Vinylplatte während diese auf dem Plattenspieler dreht? Bisher lag die Hülle neben dem Plattenspieler. An sich ein guter Platz und kein Problem, aber es gibt ja auch schicke Halter im Internet. Diese zeigen meistens den Schriftzug „Now playing“ oder „Now spinning“ und halten die Platte mittels eines entsprechend geformten Holz-, Acryl- oder Metall-Konstruktes an der Wand, auf dem Sideboard oder wo auch immer. Das fand ich langweilig und daher musste eine andere Lösung her.

Wenn schon so ein Halter da rum steht, kann der auch was tun während keine Schallplattenhülle drin steht. Was liegt da näher als mal wieder einen Mikrocontroller mit einem Display zu bemühen. Heraus gekommen ist ein erster Prototyp meines „Now Spinning“-Plattenhalters.

Genutzt habe ich wieder einen NodeMCU mit ESP8266 und acht MAX7219 LED 8×8 Matrix-Module. Mittels Taster, der von der eingestellten Schallplattenhülle gedrückt bleibt, wird die Anzeige auf einen dauerhaften Text (bei mir „NOW SPINNING“) gesetzt. Das folgende kurze Video zeigt die Funktion des Tasters (Entschuldigung für die Focus-Probleme…ich werde in diesem Leben kein You-Tuber mehr…):

Wird der Taster nicht betätigt (also die Platte wieder woanders verstaut), werden auf dem Display verschiedene Informationen angezeigt deren Anzeige im 5-Sekunden-Takt wechselt. Das wäre einmal die Innentemperatur die mittels BME280-Sensor erfasst wird und dann noch verschiedene weitere Daten die nicht lokal gemessen werden, sondern durch den Aufruf eines HTTP-Endpunktes des NodeMCUs an diesen „von aussen“ übergeben werden.

Dieser HTTP-Post erfolgt durch ein einfaches PHP-Script welches per Cron auf einem Raspberry Pi aufgerufen wird. Die anzuzeigenden Daten werden von diesen Script aus meinem FHEM (ja, ich nutze immer noch FHEM und bin weiterhin sehr zufrieden damit) ausgelesen und die URL des NodeMCUs mit den zu übergebenen Daten aufgerufen. Aktuell werden fünf übergebene Argumente verarbeitet:

• Aussentemperatur
• Akkustand der PV-Anlage
• Aktuelle Leistung der PV-Anlage
• Temperatur des Wasserpuffers oben
• Temperatur des Wasserpuffers unten

Der Aufruf der URL und die Übergabe der Daten an den NodeMCU schaut beispielhaft wie folgt aus:

<ip_des_nodemcu>/receivedata?aussentemperatur=17.3&akkustand=67&pv=1.5&pufferoben=70&pufferunten=56

Das folgende Video zeigt den Wechsel der Daten:

PHP-Script zum übermitteln der Messwerte

Im PHP-Script (nowspinning.php) werden die Reading-Daten aus FHEM per CURL abgefragt, dann die URL mit den Messwerten zusammen gebaut und anschliesend wiederum per CURL vom NodeMCU aufgerufen. Warum PHP: Weil´s für mich am schnellsten ging. Wenn ich mal Muße habe ändere ich es nach Python. Es funktioniert jedenfalls bisher völlig unproblematisch.

<?php
function getFhemReading($readingName, $fhemUrl) {
    $fhemCmd = "list $readingName";
    $cmd = "curl -s \"$fhemUrl/fhem?cmd=".urlencode($fhemCmd)."&XHR=1\"";    
    $output = shell_exec($cmd);
    $value = null;
    $match=explode(" ", $output);
    $match=array_filter($match);
    return str_replace(array("\r","\n"),'',end($match));
}

$fhemUrl = "http://<url_zum_fhem>:<fhem_port>";

$aussentemperatur = round(getFhemReading("Aussenthermometer temperature", $fhemUrl),1);
$akkustand = round(getFhemReading("MQTT2_openWB_Client SOC",$fhemUrl),1);
$pvleistung = round(getFhemReading("MQTT2_openWB_Client SolarPower",$fhemUrl)/1000,1);
$pufferoben = round(getFhemReading("HeizungPufferOben state",$fhemUrl),1);
$pufferunten = round(getFhemReading("HeizungPufferUnten state",$fhemUrl),1);

$cmd = "curl -s \"http://<ip_nodemcu>/receivedata?aussentemperatur=".$aussentemperatur."&akkustand=".$akkustand."&pvleistung=".$pvleistung."&pufferoben=".$pufferoben."&pufferunten=".$pufferunten."\"";

shell_exec($cmd);
?>

Hier der Aufruf des Scriptes in der Crontab alle 3 Minuten:

*/3 * * * * php /usr/local/bin/nowspinning.php

Code für den NodeMCU

Der Code für den NodeMCU ist bisher relativ schnörkelfrei. Die WLAN-Zugangsdaten müssen aktuell noch fest im Code vergeben werden. Für das MAX7219 nutze ich die Parola-Bibliothek . Für den BME280 die Bibliothek von Adafruit. Der Schalter hängt an D0 und GND.

#include <MD_Parola.h>
#include <MD_MAX72xx.h>
#include <SPI.h>
#include <Wire.h>
#include <Adafruit_Sensor.h>
#include <Adafruit_BME280.h>
#include <ESP8266WebServer.h>

//WLAN
const char* ssid = "<wlan_ssid>";
const char* pass = "<wlan_passwort>";
ESP8266WebServer server(80);

// Hardwaretyp des MAX7219
#define HARDWARE_TYPE MD_MAX72XX::FC16_HW

// PINs und Anzahl der MAX-Elemente
#define MAX_DEVICES 8
#define CS_PIN 15

MD_Parola display = MD_Parola(HARDWARE_TYPE, CS_PIN, MAX_DEVICES);

// BME280
#define SEALEVELPRESSURE_HPA (1013.25)
Adafruit_BME280 bme; // I2C

//Schalter um Platte zu erkennen
int pinNowSpinning = D0; 

//Warteschleifen
unsigned long startMillisTemp;
unsigned long currentMillisTemp;
unsigned long startMillisWechsel;
unsigned long currentMillisWechsel;

//Externe Daten deklarieren
String aussentemperatur = "keine Daten";
String akkustand = "keine Daten";
String puffer = "keine Daten";
String pvleistung = "keine Daten";

//Sonstiges
int anzeigennummer=0;

void setup() {

  Serial.begin(115200); 

  display.begin();
  display.setIntensity(0);
  display.displayClear();
  display.setTextAlignment(PA_CENTER);
  
  pinMode(pinNowSpinning, INPUT); 

  bool status;
  status = bme.begin(0x76);  
  if (!status) {
    Serial.println("Kann BME Sensor nicht finden. Verkabelung prüfen!");
    while (1);
  }

  startMillisTemp = millis();
  startMillisWechsel = millis();

  //WLAN
  Serial.print("Verbinde zu: ");
  Serial.println(ssid);
  display.print("Verbinde Wifi");
  WiFi.begin(ssid, pass);
   
  while(WiFi.status() != WL_CONNECTED){
    delay(500); 
    Serial.print(".");
  }

  Serial.println("");
  Serial.println("WiFi verbunden");
  Serial.print("IP-Adresse des ESP8266: ");  
  Serial.println(WiFi.localIP());
  display.displayClear();
  display.print(WiFi.localIP());
  delay(3000);

  //Webendpunkte
  server.on("/",handleRoot);
  server.on("/receivedata", receiveData);

  server.begin();
}

void loop() {
  //Client-Anfragen abfragen
  server.handleClient(); 

  if (digitalRead(pinNowSpinning) == HIGH) {
    //Text wenn eine Platte abgestellt ist    
    display.print("NOW SPINNING");
    Serial.println("Now Spinning");  
  } else {
    currentMillisWechsel = millis();    
    if (currentMillisWechsel - startMillisWechsel >= 5000) {
      startMillisWechsel = currentMillisWechsel;
      anzeigennummer++;
      Serial.print("Anzeigenummer: ");
      Serial.println(anzeigennummer);
      switch (anzeigennummer) {
        case 1:
          //Temperatur alle 30 Sekunden abfragen
          currentMillisTemp = millis();        
          if (currentMillisTemp - startMillisTemp >= 10000) {
            startMillisTemp = currentMillisTemp;
            String temperatur = String(bme.readTemperature());
            display.print("> "+temperatur.substring(0,temperatur.length()-1)+" \"C");

            Serial.print("Temperatur: ");
            Serial.print(bme.readTemperature());
            Serial.println(" °C");

            Serial.print("Luftfeuchte: ");
            Serial.print(bme.readHumidity());
            Serial.println(" %");
          }
          break;
        case 2:
          display.print(aussentemperatur);
          Serial.println(aussentemperatur);          
          break;
        case 3:
          display.print(akkustand);
          Serial.println(akkustand);          
          break;
        case 4:
          display.print(pvleistung);
          Serial.println(pvleistung);          
          break;
        case 5:
          display.print(puffer);
          Serial.println(puffer);          
          break;
        default:
          // statements
          break;
      }
      if (anzeigennummer>=5) { 
        anzeigennummer=0; 
        Serial.println("Anzeigenummer reset");
      }
    }  
  }
}

void handleRoot() {
  String message="<h1>Now Spinning</h1>";
  message += "Das ist die lieblose Webseite des 'Now Spinning'-Anzeigers</br></br>";
  message += "Temperatur: ";
  message += bme.readTemperature();
  message += " °C<br>";
  message += "Luftfeuchte: ";
  message += bme.readHumidity();
  message += " rel%<br>";
  server.send(200, "text/html", message);
}

void receiveData() {
  String message="<h1>Empfange Daten</h1>";
  message += "Daten werden empfangen...</br></br>";
  server.send(200, "text/html", message);

  Serial.println("Daten empfangen...");
 
  //Aussentemperatur
  Serial.print(server.argName(0));
  Serial.print(F(": "));
  Serial.println(server.arg(0));
  aussentemperatur="< " + server.arg(0) + " \"C";

  //Akkustand
  Serial.print(server.argName(1));
  Serial.print(F(": "));
  Serial.println(server.arg(1));
  akkustand="Akku "+ server.arg(1) + "%";

  //PV Leistung
  Serial.print(server.argName(2));
  Serial.print(F(": "));
  Serial.println(server.arg(2));
  pvleistung="PV "+ server.arg(2) + "KW";

  //Puffer oben u. unten
  Serial.print(server.argName(3));
  Serial.print(F(": "));
  Serial.println(server.arg(3));
  Serial.print(server.argName(4));
  Serial.print(F(": "));
  Serial.println(server.arg(4));
  puffer = "- " + server.arg(3) + "  _ " + server.arg(4); 
}

Schaltungsplan von Fritzing kommt noch und wenn ich mal Zeit finde, packe ich den Code auch noch nach Github.

Holzarbeiten

Hier hat mir dankenswerterweise Arnim (der immer mit meinen Kritzeleien zurecht kommen muss) sehr geholfen und hat mir einen ersten Prototyp aus Fichte gebaut.

Die Nut um die Platte zu halten, wurde mit leicht schräg gestelltem Sägeblatt der Tischkreissäge angefertigt und ist etwa 1 cm breit. Der vordere Ausschnitt um den NodeMCU und das Display unter zu bringen ist mit der Oberfräse gefräst.

Den Taster hab ich von unten in ein zweistufig gebohrtes Loch mit Heißkleber befestigt. Im Bild unten ist der Taster als kleines schwarzes Ding zu erkennen. Die Kabel des Schalters sind dann schräg nach vorne in die Ausfräsung verlegt.

Das Anschlusskabel verläuft duch eine Bohrung unter der Nut für die Platte und dann auch schräg nach oben in die Ausfräsung. Hier hab ich ein normales Micro-USB-Kabel genutzt, kurzerhand durchgeschnitten und wieder zusammengelötet.

Für die Unterbringung des Temperatursensors brauche ich noch eine gute Lösung. Dieser liegt aktuell einfach mit in der Ausfräsung in der Ecke. Ich kann mir aber vorstellen, dass dort durch das Display und den NodeMCU die Messung verfälscht wird.

Todo´s

Es ist ja der erste Prototyp des „Now spinning“-Plattenhüllenhalters und an der Software als auch an der Hardware (für den Mikorcontroller und den Halter selber) ist noch ein bisschen was zu tun. Spontan fällt mir da noch folgendes ein:

• Acrylfront (dunkelrot oder milchig…muss ich mal testen) und Frage der Befestigung
• Helligkeitssensor mittels simplem LDR (wenn dunkel, dann dunkler. wenn Heller, dann heller)
• Uhrzeit (entweder per POST mit den anderen Messwerten übergeben oder Echtzeituhr-Modul)
• Übergabe der Messwerte etwas flexibler gestalten (ohne das bei neuen Werten der Code des NodeMCU geändert werden muss sondern nur beim Aufruf der URL)
• Maximalzeit nach der „Now Spinning“ wieder zu der Anzeige der anderen Daten wechselt
• „Now spinning“ abwechselnd mit einen Spektrum Analyzer (FFT) per Mikrofon aufgenommen
• Einen besseren Platz für den internen Temperatur-Sensor
• Den Halter aus Eiche anstatt Fichte (Grüße an die Fräser)
• Die Luftfeuchte vom BME280 anzeigen
• Befestigung des Temperatursensors

Das war´s erstmal. Falls ihr Den Plattenhalter nachbauen wollt, würde ich mich über Erfahrungen, Verbesserungen, weitere Ideen und Bilder freuen. Bis dahin

Gruß Chris

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

• Eine weitere Zisternenbauform (liegender Zylinder)
• Temperatur- und Luftfeuchterfassung mittels DHT22
• Literanzahl, Temperatur und Luftfeuchte mit in die MQTT-Topics aufgenommen

Falls ein Temperatursensor angeschlossen und aktiviert ist, werden dessen Messwerte auf der Startseite angezeigt. Die Anzeige der Temperaturdaten wird alle 60 Sekunden abgefragt und zeigt daher im ersten Moment nach Neustart keine Werte an.

Aktuell kann als Temperatursensor ein DHT22 genutzt werden (weitere Sensoren sind in Arbeit). Aktiviert wird der Sensor in der Konfiguration.

Die neuen MQTT-Topics können ebenfalls in der Konfiguration hinterlegt werden.

Die neue Zisternenbauform ist auch in der Konfiguration zu finden. Die Berechnung funktioniert bei einer runden liegenden Zisterne. Eine ovale Form wird aktuell nicht unterstützt.

Hier gibt es die aktuelle Version zum Download:
http://www.bubux.de/heimautomatisierung/ota/zisterne_aktuell.bin

Für den genauen Aufbau (Anschluss Sensor, Anschluss Diplay etc.) bitte die vorherigen Artikel beachten.

Dann euch noch einen guten Rutsch ins neue Jahr!

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