NodeMCU + ESPeasy + DS18b20

[Beta-User]

Für die Verbindung ESPEasy und FHEM brauchst Du doch überhaupt kein MQTT, das ist ja grad das Gute daran.  Ich muss mich nicht auch noch mit MQTT-Programmierung befassen und muss auch keinen MQTT-Broker betreiben   

Vermutlich hat howy-1 recht, dass es für ESPEasy einfacher ist, die speziellen Module zu verwenden.

Trotzdem eine Anmerkung zu MQTT:
Mit MQTT2_SERVER ist es völlig stressfrei, einen MQTT-Broker zu betreiben, man braucht keine zusätzlichen Perl-Module und keine externen Dienste.
Was "MQTT-Programmierung" sein soll, weiß ich nicht, aber das Konfigurieren von MQTT2_DEVICE-Geräten ist sehr flexibel und es gibt zwischenzeitlich so viele Beispiele, dass die größte Kunst die ist, rauszufinden, was denn grade für ein neues Gerät die richtige Kombination ist...

MQTT hat afaik gg. reinen HTTP-Lösungen einen Vorteil: es ist asynchron ausgelegt (es muß also nicht zwangsweise sowohl der sendende Client, der Broker und der empfangende Client gleichzeitig "am Netz hängen"), man kann es daher auch gg. kurzfristige Ausfälle "härten".

[jumperger]

Ich bin auf die MQTT Idee gekommen da in meinem FHEM schon MQTT2-SERVER läuft und ich damit 2 shellys ganz stressfrei eingebunden habe.
Den NodeMCU habe ich hauptsächlich angeschafft um Temperaturfühler (DS18b20) an meinem Schwimmteich an FHEM zu übermitteln um dann hoffentlich die Pumpen entsprechend zu schalten.

Im Sommer sollen Solarmatten entsprechend der Temperaturfühler in den Filterkreis eingebunden werden.
Als Einstiegsprojekt möchte ich nun im Winter die Filterpumpe nur einschalten wenn die Aussentemperatur am Teich gegen 0 geht um ein Gefrieren der Pumpe zu verhindern ohne dass die Pumpe dafür 24/24 eingeschaltet sein muss.

Als MQTT-Protokoll  habe ich aktuell PiDome MQTT eingestellt, ich weiss aber nicht ob dies das richtige/beste Protokoll ist.
Es wurde automatisch ein MQTT2-Device angelegt namens ESPClient_MAC-Adresse welches ein Reading namens PoolWaterTemp enhält. Dies wurde in ESPeasy konfiguriert.

[Beta-User]

Klingt doch gut...Jetzt ist auch klar, was mit "Protokoll" gemeint war. FHEM ist da afaik nicht wählerisch, wenn da ist, was da sein soll, ist das ok., und wenn du sowieso MQTT2_SERVER schon am laufen hast, musst du auch nichts anderes nehmen.

[Gisbert]

Klingt doch gut...Jetzt ist auch klar, was mit "Protokoll" gemeint war. FHEM ist da afaik nicht wählerisch, wenn da ist, was da sein soll, ist das ok., und wenn du sowieso MQTT2_SERVER schon am laufen hast, musst du auch nichts anderes nehmen.

Bei ESPEasy hatte ich bisher immer Openhab MQTT eingestellt, weil ich einer Anleitung vor Jahren gefolgt bin, unter der irrigen Annahme, dass es nur damit in Zusammenarbeit mit Fhem geht.

Gut zu wissen, dass andere Einstellungen auch funktionieren, mit OpenhabMQTT geht es auch.

Viele​ Grüße​ Gisbert​

[Beta-User]

Hmm, MQTT ist ein generisches Protokoll, spannend ist eigentlich immer "nur", ob
- JSON verwendet wird (finde ich zwischenzeitlich@MQTT2_DEVICE ganz praktisch, weil das in der Regel die subscribe-Liste verkürzt, aber ohne JSON geht's auch)
- irgendeine LWT-Info gesendet wird (wenn es unterstützt wird, ist es vermutlich egal, welches "Protokoll" man wählt), und
- ob diese "autodiscovery"-Geschichte für OpenHAB (?) gesendet wird (das finde ich wirklich lästig, da für FHEM völlig unnötig...)

Kurz: FHEM (und vor allem MQTT2_DEVICE) kommt mit "fast allem" klar, der Rest ist eine Frage der persönlichen Vorlieben .

Übrigens: Vor kurzem kam hier im Forum die Frage auf, ob ESPEasy (also die FHEM-Module) mit "wandernden" Devices klarkommt, also solchen, die sich zwischendurch mit anderen AP's verbinden und dann eine neue IP bekommen. Antwort war: bislang nicht.
Für die MQTT-Implementierungen dürfte das kein Problem sein, solange das Device den Broker wiederfindet, um sich neu anzumelden...