MQTT-Kommunikation mit ESP8266 funktioniert nicht

[cebulon]

Hallo,

ich möchte einen ESP8266 (mit der Arduino-Software programmiert) mit meinem RaspberryMatic-System via WLAN bidirektional kommunizieren lassen.

1. Dazu habe aus einem Sonderheft von „Make“ ein Programm für den ESP (Einheit A, Client) modifiziert, das diesen Datenaustausch per MQTT durchführt. Eine Programmschleife sendet über einen 1. Topic eine hochgezählte Variable als Nachricht aus, ein 2. Topic empfängt die Zahlen 0 und 1, um die Board-LED ein- und ausschalten.

2. Zum Kennenlernen und Testen habe ich zunächst einen weiteren RASPI 3B+ (Einheit C) benutzt, auf dem NODE-RED und Mosquitto als MQTT-Server (Version 2.0.5) laufen. Die ersten Versuche, aus einen Terminal-Fenster heraus, waren erfolgreich. Die gesendeten Variablen kamen an; ebenso konnte ich die LED über entsprechende Kommandos schalten.

Im nächsten Schritt habe ich NODE-RED eingesetzt um in dieser Umgebung die Darstellung und Bedienung der Daten vorzunehmen – läuft auch.

3. Nun auf dem RaspberryMatic-RASPI (Einheit B) zunächst nur NODE-RED (in der Variante REDMATC, Version 7.1.3) als weitere Zusatz-Software installiert und das vorgenannte Programm übertragen. Läuft auch, wobei die Einheit C (die wie die Einheit B am selben LAN hängt, nach wie vor) die MQTT-Server-Funktion hat.

Nun folgte der wichtigste Schritt: Einheit C mit dem MQTT-Broker ausgeschaltet und auf der RaspberryMatic-Einheit B den Mosquitto-Server als Zusatz-Software installiert. Bemerkt, daß diese Software aus einer anderen Quelle stammt (https://github.com/homematic-community/ ... -mosquitto), eine andere Versionsnummer hat (1.5.8+2), aber ausdrücklich als CCU-Addon gekennzeichnet ist. Beachtet, daß unter „Sicherheit“ in der RaspberryMatic-Umgebung die Ports 1883 und 1884 freizugeben sind.

Zum Testen zunächst MQTT.fx auf dem PC eingesetzt, natürlich unter Beachtung, daß der MQTT-Server in B nun eine andere IP-Adresse hat. Auch das Programm auf dem ESP A angepasst.

Der Test mit MQTT.fx bestätigt, daß der Mosquitto-Server funktioniert. Publish-Kommandos im entsprechenden Fenster eingegeben, tauchen anschließend im Subscribe-Fenster auf.

ABER DER ESP REAGIERT NICHT !!!, bzw. seine Nachrichten werden nicht erkannt.

Erläuterungen auf der Downloadseite wie

„Bei Aufrufen von mosquittopub via CUxD Exec muss dem Aufruf das setzen des lib Pfades vorangestellt werden, z.B.: `LDLIBRARYPATH=/usr/local/lib /usr/local/bin/mosquittopub -t 'test' -m 'test'`„

lassen ahnen, daß da etwas gründlich schief läuft und die Programmierung weder in NODE-RED noch im ESP darauf Rücksicht nimmt. Im ESP sieht die entsprechende Programmzeile so aus:

„mqttClient.publish("test", „test“);“

Die Raspberrymatic ist auf dem Stand 3.55.5.20201226 und auch der Speicherplatz ist nicht zu knapp.

Ich bin mit meinen Kenntnissen am Ende. Der MQTT-Server auf einem RaspberryMatic-freien RASPI (C) funktioniert im Zusammenspiel mit dem ESP (A) uneingeschränkt - auf dem RaspberryMatic RASPI (B) mit dem ESP (A) jedoch nicht. Es ist kein Trost, daß es laut MQTT.fx eigentlich funktionieren müßte…

Wer hat sich mit dieser Aufgabenstellung schon mal beschäftigt und kann mir Hinweise geben, was ich falsch mache?

mfg Gerd

[It-noob]

Hi,

zunächst mal würde ich mittels MQTT.fx nachsehen ob sich dein ESP überhaupt mit dem Broker auf der CCU verbinden kann, das sollte unter dem Reiter Broker Status über den Punkt Clients connected nachvollziehbar sein. Alternativ dazu bietet ggf. das ESP Code selbst Debug-Meldungen an die du über die den seriellen Monitor empfangen kannst. Der Einstieg an dieser Stelle in die Problemlösung setzt allerdings voraus, dass der ESP bereits mit deinem WLAN verbunden ist. Wenn vorgenanntes alles funktioniert, kann es sich fast nur noch um einen Tippfehler im MQTT Topic handeln, wie z.B. text/test/ oder /test statt test.

Daneben gibt es gern auch mal Schwierigkeiten mit der Windows Zeichenkonvertierung bzw. den LineEndings. Deine Schreibweise von „mqttClient.publish("test", „test“);“ zeigt, dass hier hoch und tiefgestellte Double-Quotes verwendet werden. Linux/Unix nutzt allerdings nur die hochgestellte Schreibweise.

Sei mir hier bitte nicht böse, aber insgesamt würde ich dir empfehlen auf eine mehr oder minder fertige Firmware des ESP zu setzen, dazu findest du in diesem Forum wesentlich mehr Informationen und Hilfe als bei der Eigenbauvariante. Ein paar Begriffe erwecken in mir den Eindruck, dass du noch sehr weit am Anfang mit den ESP stehst und auch wenn ich es sehr löblich finde sich mit den Basics vertraut zu machen, so gehört das dann doch eher in eine Dev Umgebung als in die Homematic Prod Umgebung. Beispielweise entspricht die MQTT Kommunikation nicht dem klassischen Client-Server Prinzip, hier gibt es Clients und den Broker und kommuniziert wird mittels pub/sub. Die Fertiglösung hat auch den Vorteil, dass das Fehlerhandling (bspw. mqtt reconnect) alles schon fix- und fertig implementiert ist. Wenn du im Forum mal nach Tasmota suchst wirst du u.g. Threads finden. Alternativ dazu wären noch ESPEasy und ESPurna zu nennen. Wobei dass dann ein anderer Thread wird.

viewtopic.php?f=31&t=62270&p=619899&hil ... ta#p619899
viewtopic.php?p=615892#p615892
viewtopic.php?f=37&t=64406&p=635124&hil ... ta#p635124
https://tasmota.github.io/docs/

[cloudman88]

Der Befehl um etwas zu senden ist übrigens mosquitto_pub nicht mosquittopub.

[ProfDrYoMan]

Schau dir ESPhome (oder auch Tasmota, auch wenn ich ersteres deutlich besser finde) an. Da hast du es viel einfacher. Und dann vllt. noch Home Assistant (speziell mit ESPhome weil direkte API Unterstützung, kein MQTT nötig) als Middleware (oder wenn es unbedingt sein muss iobroker mit einem MQTT Broker).

[muellerjm]

war das nicht so, ass mosquitto unter der aktuellen RM Version nicht funktioniert? 64 bit? Zumindest ist das bei mir so. Du solltest zum Testen mal auf iobroker ausweichen. BTW... Wenn Du Mqtt auf ESP einsetzt sind noch einige Dinge zu beachten -zb. den Powersave mode deaktivieren. Sonst hast Du lange Paketlaufzeiten und es kommt zu Verbindungsabbrüchen.

#

include "esp_wifi.h"
WiFi.mode(WIFI_STA);
esp_wifi_set_ps (WIFI_PS_NONE);

[cebulon]

Hallo,

herzlichen Dank für Eure Kommentare. Die mußte ich erst mal verdauen, denn ich bin kein IT-Experte und habe mir die Kenntnisse als Autodidakt selbst beigebracht.

Es fällt mir schwer, mit wenigen Sätzen zu antworten, denn Ihr könnt nicht wissen, was ich letztendlich eigentlich umsetzen will. Ich betreibe seit ca. 40 Jahren eine computergestützte Automatisierung meiner Heizung bezüglich der Regelung von Brenner, Mischerventil und Umwälzpumpe. Bestehend aus selbstgebauten Hardware-Komponenten, ergänzt mit gekauften Temperaturmodulen, Basic-Briefmarken, Sinclair-ZX81 bzw. diversen Laptops. Aufsetzend auf gar kein Betriebssystem, DOS und Windows; programmiert in Assembler, Basic, zuletzt in Visual Basic 6. Intern verdrahtet in Fädeltechnik; mit viel zu langen Sensorleitungen für Außen- und Wohnzimmertemperatur.

Das Ganze hat zwar über die Jahrzehnte nur wenige Ausfälle gehabt, ist aber trotzdem uralt. Wenn eine der Schlüsselkomponenten ausfällt, bekomme ich dafür keinen Ersatz mehr und alles steht still.

Also muß was Anderes ran. Das seit 3 Jahren laufende HomeMatic-System für die Wohnbereiche arbeitet sehr stabil, ist aber für die autarke Insellösung im Keller nicht geeignet. Beginnend mit einer fehlenden Kaskadenregelung und endend mit dem Thema Duty Cycle sollte die RaspberryMatic für die Versorgung der Komponenten im Keller die HM-Sensoren im Haus abfragen und nur wenige (sich langsam verändernde) Führungsgrößen per WLAN in den Keller schicken.

Vor 2 Jahren habe ich mit dem HomeDuino (Eugen Stall) schon mal einen Anlauf genommen; das Programm auf das Nötigste reduziert, aber kaum verstanden, was da im riesigen Overhead eigentlich passiert. Die Kommunikation mit der CCU via LAN läuft, aber WLAN ist nur mit Hilfe eines externen Umsetzers möglich.

So bin ich auf die ESPs in Verbindung mit MQTT gekommen. Eine kompakte Einheit, deren Programmierung ich kenne, die die erforderlichen 12 I/Os, hat 5 lokale 1-wire-Sensoren abfragt und WLAN an Bord hat - mehr brauche ich nicht.

Deshalb so viele Worte, um klar zu machen, daß es nicht mit einer Schaltsteckdose o.ä. mit ESP getan ist, auf die die Tasmota-Software geflasht wird. Nicht nur auf den Usertreffen ist die MQTT-Anbindung immer wieder Thema und Empfehlung gewesen – und sie funktioniert ja auch bei mir, wenn der MQTT-Server auf dem RASPI C läuft!

Im letzten Jahr hat es tatsächlich eine Raspberry-Version gegeben, die den Mosqitto-Broker blockierte. Jens Maus hat das aber nachgebessert, die aktuelle soll keine Probleme mehr machen – lese ich.

Ansonsten muß ich meine Beobachtung von gestern noch mal präzisieren:+

- Wenn der MQTT-Broker auf dem RASPI C läuft und NODE-RED auf dem RaspberryMatic-RASPI B, läuft alles ordnungsgemäß, die hochgezählte Variable erscheint im NODE-RED-Desktop und die LED kann von dort aus ein- und ausgeschaltet werden – auch MQTT.fx (auf dem PC) bestätigt die korrekte Kommunikation.

Aber jetzt wird’s kompliziert:

- Wenn sowohl der MQTT-Broker als auch NODE-RED auf dem RaspberryMatic-RASPI B laufen, signalisiert der serielle Monitor des ESP, daß er den MQTT-Broker nicht findet. Trotzdem werden wie zuvor im Entwicklungsmodus von NODE-RED alle MQTT-Knoten als verbunden angezeigt!

Außerdem ist die hochgezählte Variable in NODE-RED nicht zu sehen. Auch zeigt MQTT.fx keinerlei Reaktion.

Wenn man nun im Desktop von NODE-RED die Buttons für die LED betätigt, tauchen diese Kommandos in MQTT.fx auf, aber trotzdem wird die LED im ESP nicht geschaltet!

Ich begreife das schlichtweg nicht, weil ja auch im MQTT-Broker keinerlei Parameter einzustellen sind.

Über ESPeasy, ESPurna und ESPhome bin ich auch gestolpert, aber das schien mir schlichtweg überflüssig zu sein.

Ansonsten sind meine gestrigen Fehler mit den Hochkommas dem Editieren des Beitrags geschuldet – im Original ist das korrekt.

Ich vermute einen Bug im CCU-Addon Mosquitto, aber ich bin nicht in der Lage, ihn zu finden, geschweige denn, ihn zu beheben.

mfg Gerd

[schneidy76]

Wenn sowohl der MQTT-Broker als auch NODE-RED auf dem RaspberryMatic-RASPI B laufen, signalisiert der serielle Monitor des ESP, daß er den MQTT-Broker nicht findet.

Laufen auch beide Instanzen auf dem Raspi? Oder wurde die MQTT Instanz beendet?

VG Torsten

[cebulon]

Ja, Torsten,

beide Instanzen laufen auf dem RASPI, der unter RaspberryMatic läuft. Es gibt keinerlei Hinweise, daß der MQTT-Broker nicht läuft - aber der ESP8266 connected trotzdem nicht.

mfg Gerd

[It-noob]

soweit ich richtig verstehe heit dass für das Szenario B (MQTT Broker auf CCU aktiv)

a) MQTT.fx mit IP 192.168.x.x connected sich an CCU Addon Mosquitto mit der IP 192.168.x.x
b) Addon NodeRed = Redmatic connected sich an CCU Addon Mosquitto via localhost
c) ESP ist zwar im WLAN mit der IP 192.168.x.x registriert, kann sich aber nicht an CCU Addon Mosquitto mit der IP 192.168.x.x verbinden

richtig?

Ich nehme an dass du alle IP Adressen gechecked hast und überall die IP von RPI Einheit C auf RPI Einheit B inkl. der richtigen Ports umgestellt hast, ClientID, Topic bleiben unverändert. Durch das WLAN kommen auch keine VLAN ins spiel, so dass da ein Routingthema hinzukommt?
Können neben MQTT.fx weitere (WLAN) Clients gegen das Mosquitto Addon verbinden? Wurde sowas wie max clients verändert? Der ESP ist auch sicher im WLAN oder in irgendeinem AP Modus? Doppelte IP Adressen sind ausgeschlossen

PS:ESPEasy hatte ich wegen der RuleEngine ggü Tasmota erwähnt. Und Tasmota ist weit weit mehr als eine Steckdosensoftware.Rules, I/O steuerung und Bibliotheken für diverse Sensoren sind in beiden enthalten. https://tasmota.github.io/docs/Supported-Peripherals/

[muellerjm]

Wenn du von einem 192.168.x.x sprichst. Sind deine Netze tatsächlich alle mit /16 also 255.255.0.0 konfiguriert? Ich vermute mal da liegt das Problem. Falls irgendwo die Maske nicht stimmt hast Du ein Routing Thema. Und manchmal funktionier es auch nicht wenn ein Client mit der z.B. 192.168.1.1/24 mit einem Client 192.168.1.2/16 spricht, obwohl das eine Netz das andere beinhaltet...Das kommt wieder darauf an wie gut der IP-Stack implementiert ist. Also gut darauf achten, dass überall die Maske gleich ist....

Und falls nicht.. sondern als klassisches Class C mit 255.255.255.0 - dann ist auch überall das 3.Byte gleich 192.168.178.0/24 z.B.