ESP8266 - Was schafft das Ding?

Hallo zusammen

Ich arbeite aktuell an meinem Projekt zu Erfassung und Steuerung meiner Fußbodenheizung.
Ich nutze 8 x das Generic-Thermostate von HA und habe ein paar Automationen innerhalb von HA hinzugefügt um die verschieden Modi anzusteuern und individuelle Sollwerte über Helfer vorzugeben.

Meine Intention war/ist, über 8 Stellantriebe der Durchfluss der Heizkreise zu steuern.
Hierzu habe ich mittels einem ESP8266 und einem PWM-Modul PCA9685 alles so vorbeireitet, dass ich für jeden Heizkreis die min- und max-PWM- Stellgröße in Abhängigkeit des Generic Thermostate vorgeben kann.

Heute, endlich, habe ich meine 8 Dallas DS18B20 Sensoren in meinem Testaufbau eingebunden, welche ich über 2 Dallas-Hubs laufen lasse, mit denen ich zukünftig die Rücklauftemperatur der Heizkreise und Vorlauftemperatur meiner Heizung erfassen möchte.

Und jetzt gehen die Probleme los:

Der ESP8266 schafft es, ohne die Dallas-Sensoren, seine Aufgaben zur Generierung PWM Stellimpulse sauber auszuführen.

Der ESP8266 schaffte es, ohne die PWM Steuerung, seine Aufgaben zur Temperaturerfassung sauber auszuführen.

Lasse ich aber beide Programm-Code zusammen laufen, fangen meine Problem an, die sich wie folgt darstellen:

  • Ich kann nicht mehr sauber über Log ( Wireless ) auf den ESP zugreifen.
  • Ich kann wahrscheinlich deswegen auch nicht mehr über Wireless, das Teil mit einem neuen Code bespielen und muss auf USB umsteigen.
  • Die Kommunikation mit HA läuft sehr langsam und verzögert, d.h. im Vergleich zum Log über USB, kommen die gesendeten Werte in HA die Werte nicht korrekt (zeitverzögert oder gar nicht (Werte verschluckt) ) an.

Ich hatte ähnliches Verhalten schon einmal, als ich auf dem ESP8266 8xSoftware-PWM Kanäle laufen lasse wollte. Bis 6 Kanäle passte alles aber ab dem 7. Kanal wurde es schwammig mit der Kommunikation zu HA.
Interessanter Weise liefen mit diesem alten Versuch, wie auch jetzt mit der aktuellen Version meines Aufbaues, alle Funktionen auf dem ESP, aber eben zeitverzögert in der Kommunikation mit HA.

Hat da jemand eine Idee wie man die Kommunikation mit HA optimieren kann, z.B. Parameter auf dem ESP. Eventuell habe ich ja auch in meinem Code ungewollt Verzögerungen/Endlosschleifen eingebaut, kann diesen gern mal hier posten.

Vielen Dank für Eure Anteilnahme :slight_smile:

Grüße FunnyRS

Warum quälst du dich so rum, verwende einfach einen oder zwei ESP32, die sind nur unwesentlich teurer und leisten mehr. Nimm einen ESP32 (mit Tasmota) und hänge die DS18B20 an. Damit bekommst du die Daten sauber nach HA. Und den zweiten für die Ventile…

Mit einem ESP8266 und 15x DS18B20 die minütlich per Mqtt veröffentlichen hatte ich auch immer wieder merkwürdige Phänomene.

Mit ESP32 waren die merkwürdigen Phänomene verschwunden. Leider haben die ESP32 bei mir Probleme im Netzwerk. Scheinbar, immer wenn sich der Zugangspunkt innerhalb vom WLAN-Mesh ändert, dann sind die ESP32 (nur die) nicht mehr erreichbar.

Bin jetzt aktuell auf einen Raspberry umgezogen mit meinem hydraulischen Abgleich. Mal schauen was die nächsten Tage bringen

Ich habe eine komplette Relaisplatine mit ESP32 im Einsatz (tasmota), da dran hängen 8 DS18B20.
Man hat trotzdem noch einiges an Bastelspaß, Netzteil, Relais mit den Heizreglern verbinden usw.

Diese Platine sieht wirklich gut aus…

Danke für Euer Feedback.

Ich hatte mich relativ frühzeitig bei diesem Projekt auf einen ESP8266 mit entsprechende Hardware für eine Hutschien-Montage und Kommunikation über I2C festgelegt.

Mein erster Reinfall war, dass ich die Software-PWM Signale nicht über I2C an einen entsprechenden Wandler übertragen konnte und auf eine Hardware-Lösung mittels PCA9685 zurückgreifen musste, welche ich zwischen den ESP8266 und dem eigentlichen Ausgabemodul einfügen musste.

Heute bin ich von meinem Breadboard auf die angedachte “finale” Hardware-Umsetzung umgezogen, soweit hat alles funktioniert. Hier einmal mein aktueller Test-Aufbau:


Die beiden losen Platinen werden noch zusammengeführt und angepasst, so dass diese auch auf der Hutschiene Platz finden.

Vermutlich werde ich den Weg gehen, einen zweiten ESP8266 hinzuzufügen, muss aber dafür noch ein paar Test durchführen.

@Linos:
Ich habe bis keine Erfahrungen zu MQTT sammeln können.
Könntest Du bitte einmal beispielhaft Deinen Code zur Erfassung der Dallas Sensoren hier einstellen?
Ich möchte aktuell nicht auf Tasmota wechseln, sondern mich erst einmal weiter in der ESPHome Umgebung bewegen.

Gruß
FunnyRS

1 „Gefällt mir“

Hallo @FunnyRS ,

Mit mqtt kannst du keine Sensoren auswerten. Dies ist ein gängiges Nachrichtenprotokoll um zB Sensorwerte oder Befehle zwischen Broker (HA) und Client (ESP) zu verschicken. Bei deiner bevorzugten Verwendung mit ESPhome wäre es eine paralleler Kommunikationsweg zu dem von ESPhome bereits genutzten.

Ich habe mich von ESPhome abgewandt und verwende ESPeasy, welches meiner Meinung nach stabiler mit Automatisierungen klar kommt. In ESPeasy konfiguriert man dann Mqtt um mit seinem HA zu kommunizieren (wie auch bei Tasmota)

2 „Gefällt mir“

Ich hab bisher die Erfahrung gemacht, das ESPHome die bessere Wahl gegenüberTasmota ist.
Daher würde ich da auch bei bleiben.

( Sind das Platinen von Horter, die kommen mir so bekannt vor )

Ja, die Platinen sind von Horter.

Cool, hab gestern angefangen ne Bestellung zusammen zu stellen für eine größeres Projekt.
Leider haben die keine ESP32-Platinen, werde daher auch auf mehrere D1-Mini setzen müssen.

Ich werde auch noch einmal nachbestellen müssen, schlimm ist nur dass man SMD Chips verlöten muss. :wink:

Der ESP32 D1 mini ist doch kompatibel mit dem Wemos, hat das schon jemand mit diesem Board getestet?

Nee, nicht wirklich. Es gibt zwei unterschiedliche:

  • ESP32 D1 Mini NodeMCU - eben ein ESP32
  • D1 Mini Pro ESP8266 ( z.b. der WEMOS-D1 mini ) - eben ein ESP8266

die sehen auf den ersten Blick ähnlich aus, aber der ESP32 hat deutlich mehr Anschlüsse und zwei Pinreihen pro Seite.
Das Horter-Module hat den ESP8266 drauf, theoretisch sollte der aber auch per I/O Expander über I2C-Bus bis zu 128 Ports Input/Output bedienen können auch unter ESPHome

Habe heute noch einmal den Programm-Code in Dallas-Sensoren und PWM-Steuerung aufgeteilt und unabhängig von einander getestet, laufen im Einzel-Modus beide wie gewünscht.

Wenn es wirklich nur die Rechenleistung des ESP8266 ist, dann wäre die ESP32 D1-Mini Variante ja die Lösung. Von den beiden Pin-Reihen auf dem Board ist ja eine voll kompatibel zum ESP8266 D1-Mini, wenn jetzt auch der pysikalische Abstand passt, dann steht einem Test ja nix mehr im Weg. Die sonstigen Vorzüge des ESP32 blieben dann zwar für die Horter-Platine ungenutzt, aber ich brauch nur I2C.

Hab leider keine hier zum vergleichen, mein ESP32 Boards mit Adapterplatine haben leider ein anderes Layout, die passen defintiv nicht.
Währe interessant, wenn die vom Abstand passen - hab ch mir aber noch nie direkt angesehen

Du kannst davon ausgehen, dass sich das jemand überlegt hat… die Abstände sind ident.

Mein ESP8266 D1-Mini will keine Template mit Text darin verarbeiten (Irrigation von alengwenus). Scheint dann nicht mehr genügend Speicherplatz zu haben und geht in eine Rebootschleife. Umgestiegen auf einen ESP32 und alles flutscht seitdem.

ESP32 mini installiert.

  • I2C Bus funktioniert
  • Dallas Sensoren werden alle gefunden, aber kein Messwert.
    Meldung im Log:
    [W][dallas.sensor:261]: ‘T5_H2’ - Scratch pad checksum invalid!

Nachtrag:

Nach Google-Suche, habe ich die ursprünglichen angedachten GPIO´s für die Dallas Sensoren auf dem ESP32 D1 mini umlegen müssen.

Mit der Nutzung von GPIO00 und GPIO04 für meine beiden Dallas-Hubs funktioniert es.

Die ursprünglichen GPIO18 und GPIO23, entsprechend dem Layout des ESP8266, funktionierten nicht und haben immer den Checksum-Fehler generiert, obwohl die Sensoren erkannt wurden.

Der ESP32 ist jetzt ohne Probleme über OTA erreichbar und sendet auch wie gewünscht aller 60sec seine Daten, ohne das HA die Verbindung verliert.

Danke für den Tip mit dem ESP32 D1 mini.

und so macht sich der ESP32 D1 mini auf der Horter Platine


etwas eng am Rand, aber halt viele neue ESP32 Features nutzbar.