Ich hatte jedoch noch so ein altes Schätzchen: Einen Fernsprechtischapparat FeTAp 611 in Grün. Es ist das Telefon meiner Schwiegereltern (und ja, die hatten damals tatsächlich eine dreistellige Telefonnummer!). Ich selbst habe es während meines Studiums in der Studentenbude genutzt. Da ich mich nur schwer von solchen Dingen trennen kann, fristete es seitdem sein Dasein irgendwo im Keller.

Der Make-Artikel inspirierte mich schließlich dazu, dem alten Teil wieder Leben einzuhauchen. Fast alle Geräte in unserem Haus werden mittlerweile über Home Assistant gesteuert – meist vollautomatisch über Sensoren oder Zeitpläne. Gelegentlich nutze ich aber auch das Tablet im Flur, auf dem noch eine alte FTUI von FHEM läuft (weil ich das Dashboard mit HA einfach nicht so schick hinbekomme), oder eben die Home Assistant App auf dem Handy.

Die Umsetzung

Mittels eines ESP32 WROOM wurde die notwendige Technik eingepflanzt. Das Schöne dabei: Das Innenleben blieb weitestgehend original, ich habe nichts ausgebaut.

• Hörergabel: Den Schalter habe ich direkt auf der Rückseite der Platine angelötet.
• Wählscheibe: Die Impulse werden einfach am ursprünglichen Stecker abgegriffen (Pin 1 & 2).
• Audio: Für die Tonausgabe sorgt ein MAX98357. Lediglich für den Anschluss des alten Lautsprechers habe ich zwei Kabel durchgeschnitten und per Lüsterklemme verbunden (ja, es musste am Ende schnell gehen).

Das Telefon kann nun

1. Sich ins WLAN einbinden
2. Verbindung zu meinem MQTT-Server aufbauen
3. WLAN und/oder MQTT-Status per LED anzeigen
4. Den klassischen 425-Hz-Wählton ausgeben, sobald der Hörer abgehoben wird.
5. Die gewählte Nummer an den MQTT-Server übermitteln

Anschlussbelegung

Der Code

Was bisher implementiert ist: Der ESP32 übernimmt das Management der WLAN-Verbindung, die MQTT-Kommunikation und die Dekodierung der Wählscheiben-Impulse. Über den MAX98357 wird der klassische Wählton via I2S direkt im Code generiert und mit einem leichten Rauschen unterlegt, um den alten analogen Charakter des Hörers beizubehalten.

#include <WiFi.h>
#include <PubSubClient.h>
#include <driver/i2s.h>

// ================== WLAN ==================
const char* ssid = "hier_die_ssid";
const char* password = "hier_das_wlan_passwort";

// ================== MQTT ==================
const char* mqtt_server = "192.168.xxx.xxx";
int mqtt_fail_count = 0;
const int mqtt_max_retries = 5;
bool mqtt_blocked = false;

// ================== LED ===================
const int ledPin = 26;

enum LedState {
  LED_WIFI_CONNECTING,
  LED_WIFI_CONNECTED,
  LED_MQTT_CONNECTING,
  LED_MQTT_CONNECTED
};

LedState currentState = LED_WIFI_CONNECTING;

// ================== Wifi ==================
WiFiClient espClient;
PubSubClient client(espClient);

// ================== Fetap ==================
const int dialPin = 14;
const int hookPin = 27;

// ================== I2S AUDIO ==================
#define I2S_BCLK 18
#define I2S_LRC  19
#define I2S_DOUT 23

bool toneActive = false;
uint32_t toneIndex = 0;

// ================== Waehlen ==================
volatile int pulses = 0;
volatile unsigned long lastPulseMicros = 0;
unsigned long lastActivity = 0;

bool lastHookState = false;

// ================== Interrupt ==================
void IRAM_ATTR onPulse() {
  unsigned long now = micros();
  if (now - lastPulseMicros < 80000) return;
  pulses++;
  lastPulseMicros = now;
  lastActivity = millis();
}

// ================== SETUP ==================
void setup() {
  Serial.begin(115200);

  pinMode(dialPin, INPUT_PULLUP);
  attachInterrupt(dialPin, onPulse, FALLING);

  pinMode(hookPin, INPUT_PULLUP);
  pinMode(ledPin, OUTPUT);
  digitalWrite(ledPin, LOW);

  // ================== I2S INIT ==================
  i2s_config_t i2s_config = {
    .mode = (i2s_mode_t)(I2S_MODE_MASTER | I2S_MODE_TX),
    .sample_rate = 8000,
    .bits_per_sample = I2S_BITS_PER_SAMPLE_16BIT,
    .channel_format = I2S_CHANNEL_FMT_ONLY_LEFT,
    .communication_format = I2S_COMM_FORMAT_I2S,
    .intr_alloc_flags = 0,
    .dma_buf_count = 8,
    .dma_buf_len = 64,
    .use_apll = false
  };

  i2s_pin_config_t pin_config = {
    .bck_io_num = I2S_BCLK,
    .ws_io_num = I2S_LRC,
    .data_out_num = I2S_DOUT,
    .data_in_num = I2S_PIN_NO_CHANGE
  };

  i2s_driver_install(I2S_NUM_0, &i2s_config, 0, NULL);
  i2s_set_pin(I2S_NUM_0, &pin_config);

  // ================== WLAN ==================
  currentState = LED_WIFI_CONNECTING;
  WiFi.begin(ssid, password);

  while (WiFi.status() != WL_CONNECTED) {
    updateLED();
    delay(300);
  }

  currentState = LED_WIFI_CONNECTED;
  client.setServer(mqtt_server, 1883);

  Serial.println("Telefon bereit");
}

// ================== LOOP ==================
void loop() {
  if (!client.connected()) reconnect();
  client.loop();

  updateLED();

  bool hookReading = (digitalRead(hookPin) == LOW);

  // ================== HOOK CHANGE ==================
  if (hookReading != lastHookState) {
    delay(40);

    if (hookReading == (digitalRead(hookPin) == LOW)) {
      lastHookState = hookReading;

      if (hookReading) {
        Serial.println("Hörer ABGENOMMEN");
        pulses = 0;
        sendStatus(true);

        toneActive = true;
        toneIndex = 0;
      } else {
        Serial.println("Hörer AUFGELEGT");
        sendStatus(false);

        toneActive = false;
        i2s_zero_dma_buffer(I2S_NUM_0);
        i2s_stop(I2S_NUM_0);
        i2s_start(I2S_NUM_0);
      }
    }
  }

  // ================== Wählscheibe ==================
  unsigned long now = millis();

  if (lastHookState) {
    if (pulses > 0 && (now - lastActivity) > 900) {
      int number = pulses;
      if (number == 10) number = 0;

      Serial.print("Gewählt: ");
      Serial.println(number);

      sendMQTT(number);
      pulses = 0;
    }
  }

  // ================== 425 Hz Ton ==================
  if (toneActive) {
    size_t written;

    float freq = 425.0;
    float t = (float)toneIndex / 8000.0;

    int16_t sample =
      (int16_t)(2000 * sin(2 * PI * freq * t));

    sample += random(-300, 300);

    i2s_write(I2S_NUM_0, &sample, sizeof(sample), &written, portMAX_DELAY);

    toneIndex++;
    if (toneIndex > 8000) toneIndex = 0;
  }
}

// ================== MQTT ==================
void sendMQTT(int number) {
  if (!client.connected()) return;

  client.publish("fetap_611/nummer", String(number).c_str());
}

// ================== STATUS ==================
void sendStatus(bool onHook) {
  if (!client.connected()) return;

  client.publish("fetap_611/hoerer", onHook ? "ON" : "OFF");
  client.publish("fetap_611/nummer", "-1");
}

// ================== MQTT reconnect ==================
void reconnect() {
  if (mqtt_blocked) return;

  while (!client.connected()) {
    currentState = LED_MQTT_CONNECTING;

    if (client.connect("fetap_phone")) {
      mqtt_fail_count = 0;
      currentState = LED_MQTT_CONNECTED;
    } else {
      mqtt_fail_count++;
      if (mqtt_fail_count >= mqtt_max_retries) {
        mqtt_blocked = true;
        return;
      }
      delay(1500);
    }
  }
}

// ================== LED ==================
void updateLED() {
  static unsigned long lastBlink = 0;
  static bool state = false;

  unsigned long now = millis();

  switch (currentState) {

    case LED_WIFI_CONNECTING:
      if (now - lastBlink > 200) {
        state = !state;
        digitalWrite(ledPin, state);
        lastBlink = now;
      }
      break;

    case LED_WIFI_CONNECTED:
      if (now - lastBlink > 800) {
        state = !state;
        digitalWrite(ledPin, state);
        lastBlink = now;
      }
      break;

    case LED_MQTT_CONNECTING:
      if (now - lastBlink > 150) {
        state = !state;
        digitalWrite(ledPin, state);
        lastBlink = now;
      }
      break;

    case LED_MQTT_CONNECTED:
      digitalWrite(ledPin, HIGH);
      break;
  }
}

Die Herausforderung: Timing und Entprellung

Die Abfrage eines so alten mechanischen Geräts bringt ein paar Besonderheiten mit sich, die man im Code berücksichtigen muss. Hier sind zwei Punkte, bei denen man eventuell individuell nachjustieren muss:

• Entprellen der Wählscheibe: Im Interrupt nutze ich eine Sperrzeit von 80ms. Das ist notwendig, da die mechanischen Kontakte beim Öffnen und Schließen kurz „prellen“. Wenn eure Wählscheibe falsche Ziffern erkennt, ist dieser Wert der erste Hebel, an dem ihr ansetzen solltet.
• Der Hörerschalter (Gabel): Auch dieser Schalter ist mechanisch und neigt zum Prellen. Ich habe hier ein delay(40) eingebaut, um sicherzugehen, dass der Zustand stabil ist, bevor die MQTT-Meldung „Hörer abgenommen“ rausgeht.

Warum das Ganze?

Im Gegensatz zu moderner Digitaltechnik gibt die Wählscheibe einfach nur mechanische Impulse (Unterbrechungen) aus, etwa 10 Impulse pro Sekunde (10Hz). Eine gewählte „3“ sind drei kurze Unterbrechungen der Leitung. Da der ESP32 im Vergleich zur Wählscheibe sehr schnell ist, würde er ohne diese künstlichen „Gedenksekunden“ (Delays und Sperrzeiten) jedes mechanische Zittern als extra Impuls interpretieren.

Die aktuell im Code gewählten Zeiten und Mechanismen funktionieren bei meinem Telefon sehr zuverlässig.

Automatisierung in HA

Auf die Änderungen des entsprechenden MQTT-Topics reagiere ich mit einer Automatisierung im Home Assistant. Im folgenden Beispiel werden zwei Lampen bei Wahl der 1 oder der 2 getoggelt

alias: FeTap Steuerung
description: Schaltet Aktoren basierend auf Sensorwert 1-9
triggers:
  - entity_id: sensor.fetap_nummer
    trigger: state
conditions:
  - condition: template
    value_template: "{{ trigger.to_state.state in ['1','2','3','4','5','6','7','8','9'] }}"
actions:
  - choose:
      - conditions:
          - condition: state
            entity_id: sensor.fetap_nummer
            state: "1"
        sequence:
          - action: light.toggle
            target:
              entity_id:
                - light.lampe_fensterbank
      - conditions:
          - condition: state
            entity_id: sensor.fetap_nummer
            state: "2"
        sequence:
          - action: light.toggle
            target:
              entity_id:
                - light.lampe_couch
    default: []
mode: restart

Ausblick

Das war ein erster PoC was man mit dem alten Telefon alles machen kann. Der Quellcode ist nicht wirklich aufgeräumt und die WLAN Credentials noch direkt im Code enthalten. Ich glaube die alten Telefone haben auch mit dem 425Hz-Ton aufgehört sobald man gewählt hat.

Ideen für die nächsten Schritte:

• WLAN-Credentials komfortabel über eine Webseite z.B. im SPIFFS/LittleFS konfigurieren.
• Wählton deaktivieren, sobald die erste Ziffer gewählt wurde (originalgetreuer).
• Ein kurzes akustisches Signal ausgeben, wenn das MQTT-Telegramm erfolgreich gesendet wurde.
• Mittels Step-Up-Wandler die alte mechanische Klingel des Telefons für Benachrichtigungen integrieren.
• Das Mikrofon in Betrieb nehmen (eventuell durch eine moderne Elektret-Kapsel ersetzen).
• Ziffernfolgen implementieren (aktuell funktioniert das nur mit einzelnen Ziffern)

Viel Spaß beim Bauen und erweitern!

Gruß
Chris

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

Auf der Suche nach einer Möglichkeit den Eigenverbrauch zu erhöhen, fiel ein Batteriespeicher aufgrund der hohen Anschaffungskosten raus. Was tun?

Vor einigen Jahren wurde der Kachelofen mit Wassertasche vom Schornsteinfeger wegen Umweltauflagen still gelegt (sehr schade drum). Dadurch ist aber noch der Warmwasserspeicher im Heizungsraum vorhanden. Diese hatte nach der Stilllegung des Kachelofen keine weitere Wärmequelle als die Ölheizung. Solarthermie ist leider nicht vorhanden und auch für eine Neu-Installation zu aufwändig.

Wir dachten dann über einen Heizstab nach. Der Wasserspeicher hat die Möglichkeit einen Heizstab von oben einzuschrauben. Leider ist es aber sehr schwierig, Heizstäbe mit entsprechend langer heiz-freier Zone zu bekommen, da das Wasser im Wasserspeicher ja nicht randvoll gefüllt ist. Bei anderen Herstellern von Warmwasserspeichern kann man den Heizstab seitlich einschrauben. Und der Heizstab vom Hersteller des Wasserspeichers ist leider raus, da er zu lang ist und wir den Warmwasserspeicher hätten kippen müssen. Es musste also eine andere Lösung her.

Wärmekreislauf im Selbstbau

Ein guter Freund meines Vaters ist Heizungsbauer und hat eine Vorrichtung gebaut, die analog der Wassertasche des alten Kachelofen das Wasser mittels Umwälzpumpe, an einem Heizstab vorbei, in den Warmwasserspeicher pumpt. Die Pumpe war noch vom Kachelofen vorhanden und der Heizstab ist ein günstiger ~ 2KW Heizstab mit 1 1/2 Zoll Gewinde. Dieser steckt nun in einem Eisenrohr/T-Stück mit entsprechendem Gewinde und ist über Kupferleitungen an den Warmwasserspeicher angeschlossen. Zudem wurde dieser Kreislauf noch an das Ausdehnungsgefäß des normalen Heizkreislauf angeschlossen, damit wir uns ein zweites Ausdehnungsgefäß sparen konnten.

Im Bild erkennt man den Heizstab, der senkrecht in dem Eisenrohr steckt, die grüne Umwälzpumpe und die entsprechende Verrohrung. Später wurde die Konstruktion noch isoliert.

Jetzt soll der Heizstab aber nur eingeschaltet werden, wenn auch PV-Überschuss vorhanden ist. Kauflösungen wie z.B. „intelligente“ Heizstäbe von ELWA kosten > 500 €. Soviel wollten wir aber nicht ausgeben, da die Ausbeute und der Wirkungsgrad um Wasser mit elektrischer Energie mittels Heizstab zu erhitzen nicht sehr effizient ist und sich schlecht amortisiert. Eine kleine Wärmepumpe schied übrigens vorerst aus Kostengründen auch aus.

Die Daten…woher bekommen?

So, wie kommt man nun an die Daten wann die Anlage Überschuss produziert? Der SMA-Wechselrichter ist ohne „Sunny Boy“ nicht wirklich auskunftsfreudig (es war ja ein Low-Budget-Selbstbau-Anlage). Aber welche Daten werden denn benötigt?

• den Eigenverbrauch des Hauses und
• die aktuelle Leistung, die durch die Solaranlage geliefert wird

Die Werte für den Eigenverbrauch hatten wir schon relativ schnell nach Inbetriebnahme der Solaranlage durch Einbau eines Powerfox am digitalen Stromzähler erledigt. Dieser misst am Energiezähler die aktuell benötigte Leistung, sowie die elektrische Energie des Verbrauchs und der Einspeisung. Den Powerfox kann jeder einfach anbringen, da er nur mittels Magnet an der entsprechenden Stelle am Zähler befestigt wird. Hier sind keine Arbeiten im Stromkasten notwendig. Der Powerfox ist mit den meisten digitalen Stromzählern kompatibel. Ggf. in die Modell-Liste von Powerfox schauen. Ich selber nutze hier eine Selbstbaulösung, aber der Powerfox ist „adminfreundlicher“.

Die Messung der Leistung der Solaranlage kam dann etwas später durch den Einbau eines Shelly 3EM mit drei Stromzangen im Stromkasten dazu. Die Stromzangen werden einfach um die drei Phasen gelegt, die vom Wechselrichter kommen. Der 3EM kommt auf die Hutschiene im Stromkasten und benötigt noch Versorgungsspannung. Für den Einbau ggf. besser einen Elektriker zu Rate ziehen!

Damit hatte mein Vater schon vor der Idee mit dem Heizstab alle wichtigen Informationen der Solaranlage und des Hausverbrauches zur Verfügung. Allerdings über zwei unterschiedliche Apps und ohne zentrale Einheit wie ein Smart-Home-Server.

Zurück zum Heizstab. Alle Infos, um den Heizstab bei PV-Überschuss anzuschalten waren also schon vorhanden. Um nun aus diesen Infos den eigentlich Überschuss zu berechnen und den Heizstab zu schalten, kam ich nicht mehr drumherum, einen kleinen Server mit entsprechender Software aufzusetzen.

Die Steuerung

Das Erste was mir als Software in den Sinn kam war openWB. Ich habe eine openWB-Wallbox und nutze sie schon zum Überschussladen des E-Autos und hatte mich auch schon mal in das von mir nicht genutzte SmartHome-Menü der openWB verirrt. Die Software selber kann auch ohne Wallbox-Funktionalitäten auf einem RaspberryPI betrieben werden. Ich hatte noch einen Pi 3 hier liegen und die Software war schnell installiert. Der Powerfox und der Shelly 2EM (sowie andere Produkte von Shelly) werden bereits von openWB unterstützt. Die Integration funktioniert einfach mit Eingabe der Shelly-IP bzw. der Powerfox-Cloud-Daten über die Weboberfläche der OpenWB.

Danach zeigt die Startseite der openWB die gemessenen Werte an. Im Screenshot aktuell sehr wenig Sonne und relativ viel Hausverbrauch.

Verschiedene Smart-Home-Geräte (unter die auch der zukünftige Heizstab fällt) können nun in der openWB konfiguriert werden und mit Aktionen hinterlegt werden. Der Heizstab selber ist natürlich nicht „Smart“. Ein- und ausgeschaltet werden soll er über einen Shelly Plug S. Den Shelly sieht man auch auf dem ersten Bild oben links. Daran angeschlossen ist der Heizstab und die Umwälzpumpe. Auch dieser Shelly wird von openWB als Smart-Home-Gerät unterstützt.

Was jetzt noch bleibt, sind verschiedene Einstellung am Smart-Home-Gerät:

• Schwellenwerte (in Watt) zum Ein- und Ausschalten,
• Nachlaufzeiten (in Sekunden) damit der Stab nicht ständig an- und ausgeht wenn Wolken aufziehen,
• Zeiträume und Gesamtdauer pro Tag in denen überhaupt geschaltet wird (zur Sicherheit falls die openWB den Shelly Plug aus irgendwelchen Gründen nicht ausschaltet)
• und einige andere Einstellungen.

Das ist natürlich abhängig vom Heizstab, dem Warmwasserspeicher und der gesamten PV-Anlage. Hier muss ein bisschen ausprobiert werden welche Werte für die jeweilige Anlage am besten passen.

Zur Sicherheit wird der Shelly Plug an Pumpe und Heizstab auch noch täglich mit Sonnenuntergang durch die Shelly-App ausgeschaltet und der Heizstab besitzt noch ein eigenes Thermostat, wodurch er sich selber ab einer einstellbaren Temperatur ausschaltet. Mit diesen Mitteln und den Einstellungen in der openWB sollte ein überhitzen bzw. zu langes laufen des Heizstabes ausgeschlossen sein.

Die Apparatur läuft seit dem Herbst 2024. Die Tage, an denen Sonne war und der Schwellwert für den PV-Überschuss in der openWB erreicht wurde, schaltete den Heizstab und die Umwälzpumpe über den Shell Plug einwandfrei ein und aus. Den Status des Heizstabes (An/Aus) sowie die aktuell benötigte Leistung und die pro Tag in den Heizstab geflossene Energie zeigt die openWB auch auf der Startseite an.

Grundsätzlich funktioniert das also. Wirklich viel PV-Überschuss gab es aber leider nicht, so das wir das nächste Frühjahr abwarten müssen.

Wunder wird der kleine Heizstab im Warmwasserspeicher nicht vollbringen, aber auch im Sommer wird warmes Wasser benötigt und es sollte dann Wärme produziert werden, die mehr als 8 Cent wert ist. Die Ausgaben hielten sich auch sehr in Grenzen. Eigentlich war es nur der Heizstab für < 100 € und der Shelly Plug für 23 €. Der Rest war schon vorhanden (Powerfox und Shelly 3EM) bzw. lag irgendwo herum (Raspi, Umwälzpumpe). Das Installations-Material kostete ein Feierabendbier.

Ich werde mal berichten wie das Ganze im Sommer funktioniert.

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

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

In der Webseite der Software kann in den Einstellungen zwischen den beiden Sensoren gewählt werden. Neu ist zudem noch der frei wählbare Name für den Sensor welcher auf der Sensor-Webseite oben links angezeigt wird. Hiermit kann man nun beim Einsatz mehrerer Sensoren in verschiedenen Zisternen unterscheiden oder auch einen Öltank-Füllstandssensor korrekt benennen.

Der ToF-Sensor besitzt eine I2C-Schnittstelle und wird an die gleichen PINs wie der Ultraschallsensor angeschlossen. Es geht aber nicht mit beiden Sensoren parallel, sondern nur der eine oder der andere!

Der ToF-Sensor wird wie folgt angeschlossen:

Die beiden übrigen Anschlüsse bleiben frei.

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

Hier findet ihr die vorherigen Artikel zur Zisterne mit den grundlegenden Anleitungen und Anschlussschema.

Gruß
Chris

Da wäre z.B. „Der Zwölfender“ mit seinem imposantem (aber verbogenem) Geweih:

Oder die beiden…mmmh… Ziegen, Rehe? Wie auch immer – ein sehr gut gelungenes Duo!

Dann noch der Sichel-Tukan mit der auffälligen, namensgebenden Sichel als Schnabel, dem kleinen Fächerbesen als Schwanz und den etwas globigen Holzfüssen damit er auch sicher steht. Heimisch im Taunus!

Kleines Update: Hier noch der Scherenkopf-Pelikan

Dann noch ein schönes Osterwochenende.

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

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