MQTT API Server und MQTT Clients - LBS19001051 - LBS19001054

[Lapheus]

Siehe oben, weil ich die Clients unterscheiden will. Der LBS mit dem Filter auf die Wetter-API ist nicht der einzige Client. Aber diese Änderung hat mit dem eigentlichen Problem vermutlich nichts zu tun, da ich das ja erst gestern testweise geändert habe.
...

verstanden

Also Du hast mehrere MQTT Subscribe Client Baustein, und die willst Du unterscheiden, mit sprechenden Namen? Dann ist es in Ordnung, je einmal einrichten, dann nicht mehr verändern.

Ich benutze den MQTT-Client-Baustein.

In Edomi läuft auch der Subscribe-Server-LBS. Dort habe ich aber nichts speziell konfiguriert ausser ioBroker IP, Port, Username und Passwort.

Jetzt wird es interessant. Wenn du nur den MQTT-Client im ioBroker hast, läuft dann ein mosquitto Server (Console systemctl status mosquitto). Oder läuft ndoch eine Instanz des MQTT Moduls im ioBroker, der würde auch einen MQTT-Server aktivieren?

In den MQTT-Settings des ioBroker-Bausteines habe ich unter "Mask to publish own states" das folgende eingetragen:
vw-connect.0.*,swiss-weather-api.0.WeekForecast.*

Wieder mit Punkt, das ist ioBroker Objekt Schreibweise, beim Topic für den MQTT ist der Slash das Trennzeichen.
Meiner Meinung nach, brauchst du den MQTT Subscribe-Server-LBS nicht, deaktiviere den mal.
Es sei den du stellst die Topics entsprechend im ioBroker ein, siehe dazu meine Anleitung hier, muss halt auf Deine Topics angepasst werden. Läuft aber nach einigen Wochen nicht zuverlässig, der MQTT-Client stellt irgendwann das senden der Topics ein. Siehe Anmerkungen im Thread.

Wenn du Daten vom ioBroker haben möchtest reicht der MQTT Subscribe Client Baustein.
Entweder einer der dir nach entsprechenden Aufgaben filtert -> kein E6 oder E7 belegt, E9 auf # Mit entsprechenden Bausteinen die Ausgaben Filtern und jeweils bearbeiten.
Oder mehrere die dann entsprechend Ihrer Aufgabe schon beim subscribben entsprechend Filtern sollten -> E6 oder E7 filtern zusammen mit dem E9 (Beispiel oben
swiss-weather-api/0/WeekForecast/+/formatted_date)

Ich habe mir das Thema MQTT so zusammen gelesen, hoffe das ich es richtig wieder gebe und mich gegebenenfalls andere entsprechend korrigieren.

[starwarsfan]

Hi

Warum änderst Du den E14? Damit sagt der Baustein dem MQTT Server mit welcher ClientID er sich anmeldet. Die ClientID wird einmal fest eingestellt und dient nur zur Unterscheidung der Clients.

Und genau deswegen habe ich das eingetragen: Damit ich im ioBroker-Log unterscheiden kann, welcher Client aktiv ist. Ist das ein Denkfehler?

Ich kenne aktuell bzw. in Deinem Anwendungsfall keinen Grund das zu ändern. Der steht bei mir auf "auto", siehe Hilfe.

Siehe oben, weil ich die Clients unterscheiden will. Der LBS mit dem Filter auf die Wetter-API ist nicht der einzige Client. Aber diese Änderung hat mit dem eigentlichen Problem vermutlich nichts zu tun, da ich das ja erst gestern testweise geändert habe.

Du hast jetzt einmal alle Topics mit der alten ClientID gelöscht und mit der neuen ClientID wieder aboniert. Daher die Logeintröge auf dem ioBroker.

Verstehe.

Am E9 des MQTT Subscribe Client Bausteins sind das Punkte? Das Topic sollte so sein: swiss-weather-api/0/WeekForecast/#
Dann sollte es passen und der Parser bekommt das richtige geliefert, der E2 passt so.

Ja das sind Punkte und somit ist das offensichtlich falsch. Danke, werde ich anpassen.

Nutzt du den MQTT-Baustein oder den MQTT-Client Baustein im ioBroker?

Ich benutze den MQTT-Client-Baustein.

Wenn MQTT-Client wo läuft dann der MQTT Server und sind die zu sendenden Topics konfiguriert?

In Edomi läuft auch der Subscribe-Server-LBS. Dort habe ich aber nichts speziell konfiguriert ausser ioBroker IP, Port, Username und Passwort.

In den MQTT-Settings des ioBroker-Bausteines habe ich unter "Mask to publish own states" das folgende eingetragen:

vw-connect.0.*,swiss-weather-api.0.WeekForecast.*

Wie oft wird die "swiss-weather-api" vom iobroker aktualisiert?

Alle halbe Stunde.

Was mir beim Debuggen meines Problems geholfen hat ist der MQTT Explorer. Damit konnte ich sehen was aktuell im MQTT passiert.

Interessant, muss ich mal danach suchen...

Danke für die Hilfe!

[Lapheus]

...
Als ich vorhin zum ioBroker-Log gegangen bin, hatte sich das Flooding auch beruhigt. Erst als ich in Edomi wieder etwas geändert hatte (Client-ID an E14) und daraufhin das Live-Projekt erneut deployed habe, hat das Fluten des Logs wieder angefangen und wird sich ggf. auch wieder beruhigen. Irgendwas mach' ich noch falsch...

Warum änderst Du den E14? Damit sagt der Baustein dem MQTT Server mit welcher ClientID er sich anmeldet. Die ClientID wird einmal fest eingestellt und dient nur zur Unterscheidung der Clients. Ich kenne aktuell bzw. in Deinem Anwendungsfall keinen Grund das zu ändern. Der steht bei mir auf "auto", siehe Hilfe. Du hast jetzt einmal alle Topics mit der alten ClientID gelöscht und mit der neuen ClientID wieder aboniert. Daher die Logeintröge auf dem ioBroker.


Am E9 des MQTT Subscribe Client Bausteins sind das Punkte? Das Topic sollte so sein: swiss-weather-api/0/WeekForecast/#
Dann sollte es passen und der Parser bekommt das richtige geliefert, der E2 passt so.
Nutzt du den MQTT-Baustein oder den MQTT-Client Baustein im ioBroker? Wenn MQTT-Client wo läuft dann der MQTT Server und sind die zu sendenden Topics konfiguriert? Wie oft wird die "swiss-weather-api" vom iobroker aktualisiert?

Was mir beim Debuggen meines Problems geholfen hat ist der MQTT Explorer. Damit konnte ich sehen was aktuell im MQTT passiert.

[starwarsfan]

Hi

welche Daten Werden den vom Client abgefragt. Zeige mal die Logikseite des Bausteins MQTT Subscribe Client.

Abgefragt werden diese Werte resp. hier die Logikseite:

2020-02-25_Logik.png

Es ist zu sehen, dass die Werte an den Klemmen nicht aktualisiert werden. Der oberste Wert sollte ja heute, also der 25.02. sein.

In E2 am Parser steht das hier:

swiss-weather-api/0/WeekForecast/+/formatted_date

In ioBroker sieht das so aus:

2020-02-25_Objects.png

Als ich vorhin zum ioBroker-Log gegangen bin, hatte sich das Flooding auch beruhigt. Erst als ich in Edomi wieder etwas geändert hatte (Client-ID an E14) und daraufhin das Live-Projekt erneut deployed habe, hat das Fluten des Logs wieder angefangen und wird sich ggf. auch wieder beruhigen. Irgendwas mach' ich noch falsch...

[Lapheus]

Hallo miteinander,

nachdem ich mich nun auch mal mit MQTT beschäftigt habe, laufen erfolgreich Subscribe Server, Subscribe Client und Parser in einer Edomi-Testinstanz und beziehen Daten von einer ioBroker-Instanz.

welche Daten Werden den vom Client abgefragt. Zeige mal die Logikseite des Bausteins MQTT Subscribe Client.

[Lapheus]

Ist es möglich die Kommunikationsobjekte automatisiert aus dem MQTT Subscribe Client 19001054 anlegen und aktualisieren zu lassen?

Hallo Jens,

eine Möglichkeit dafür habe ich hier beschrieben. Das kann ich aktuell nur nicht empfehlen, da es bei mir immer weider zu Ausfällen kommt da der MQTT-Client das senden einstellt.

[starwarsfan]

Hallo miteinander,

nachdem ich mich nun auch mal mit MQTT beschäftigt habe, laufen erfolgreich Subscribe Server, Subscribe Client und Parser in einer Edomi-Testinstanz und beziehen Daten von einer ioBroker-Instanz. Allerdings tauchen im Log von ioBroker am laufenden Band Meldungen dieser Art auf:

mqtt.0	2020-02-21 23:04:52.677	warn	(41849) Client [EDOMI_MQTT_Subscribe_Client_1-5e504dffaffb1] Message 1548 deleted after 11 retries
mqtt.0	2020-02-21 23:04:52.646	warn	(41849) Client [EDOMI_MQTT_Subscribe_Client_1-5e504dffaffb1] Message 1549 deleted after 11 retries
mqtt.0	2020-02-21 23:04:52.635	warn	(41849) Client [EDOMI_MQTT_Subscribe_Client_1-5e504dffaffb1] Message 1550 deleted after 11 retries

Nach einer Weile wechselt das dann auf diese Einträge:

mqtt.0	2020-02-21 23:08:37.821	warn	(41849) Client [EDOMI_MQTT_Subscribe_Client_1-5e504dffaffb1] Received puback for unknown message ID: 1465
mqtt.0	2020-02-21 23:08:37.665	warn	(41849) Client [EDOMI_MQTT_Subscribe_Client_1-5e504dffaffb1] Received puback for unknown message ID: 1652
mqtt.0	2020-02-21 23:08:37.510	warn	(41849) Client [EDOMI_MQTT_Subscribe_Client_1-5e504dffaffb1] Received puback for unknown message ID: 1464

Die Einträge gehen in die Tausende und ich habe gerade keine Idee, was da schief läuft!? Wie bekomme ich das weg resp. was fehlt da noch in der Konfiguration?

[Ballerzonk]

Super LBS, habe nun auch meine Kommunikationsobjekte im IOBroker.
Nur umgekehrt hapert es noch IOBroker -> Edomi die Daten kommen an, aber wie bekomme ich die in die Kommunikationsobjekte.
Ist es möglich die Kommunikationsobjekte automatisiert aus dem MQTT Subscribe Client 19001054 anlegen und aktualisieren zu lassen?


MQTT.png

[jonofe]

Bei MQTT kann man nur zertifikatsbasierte Authentisierung machen. Access-Token deutet eher auf OAuth2 hin. Ohne eine API Beschreibung ist das vermutlich viel Raterei.

[Glotzkowski]

Worx macht es übrigens so, dass Username/Password nur für eine HTTPS API verwendet werden. Darüber muss man dann ein Client Zertifikat abholen, welches man zur MQTT Authentifizierung verwendet. Wenn dies bei AEG auch so ist, dann wird es ohne Kenntnis der API zum Download des Zertifikats schwierig.

Nach weiteren Analysen hat sich herausgestellt, dass dies bei AEG scheinbar ähnlich ist.
Die HTTPS API kann ich nun dazu nutzen die Stati der Waschmaschine abzufragen.
Es gibt aber parallel noch eine MQTT-Sitzung und bei dem Verbindungsaufbau der App wird bei der Anmeldung neben dem "sessionKey" für die HTTPS API ein "access_token" (token_type: Bearer) generiert, welcher bei der HTTPS API nirgends genutzt wird.
Daher vermute ich, dass dieser für die Anmeldung via MQTT genutzt wird und der "MQTT-Kanal" dann für die direkte Übertragung von Änderungen der Statusinformationen verwendet wird.
Im Worx-LBS wollte ich gerade nachsehen, wie Du das dort realisiert hast, wenn ich das richtig sehe ist dieser LBS aber unleserlich gemacht, was verständlich ist.
Beim MQTT-Subscribe-Client-LBS kann man keinen Token angeben, oder?

[Michael85]

Hallo,

ich nutze jetzt schon einige Zeit die MQTT Bausteine von André. Es läuft eigentlich auch alles ganz gut.
Habe jetzt aber eine Verständniss Frage.

Kann ich mit dem Baustein Subscribe Client am besten einmal Zentral abfragen für alle Themen und mir die Message dann in ein iKo schreiben?
Und dann auf den jeweiligen Logikseiten das iKo mit dem Topic Parser zerpflücken?

Oder den Subscribe Client für jedes Thema (shellies, phoniebox usw) einzeln abrufen lassen?

Vielleicht ist die Frage auch sau blöd, aber bitte nicht steinigen :-)

Gruß Michael

[vento66]

Nein, da es das benötigte Repo für 6.5 nicht mehr gibt.

solange es läuft und keine Notwendigkeit dazu besteht.

die ist ja jetzt wohl gegeben

[ThomasCologne]

Servus zusammen,

dass die MQTT-LBS nur noch auf CentOS 7.x laufen, ist ja bereits bekannt.
Folgender Fehler bei der zusätzlichen Installation unter 6.5 wird ausgegeben:

[root@edomi ~]# git clone https://github.com/jonofe/lib_mysqludf_sys
Initialized empty Git repository in /root/lib_mysqludf_sys/.git/
error: while accessing https://github.com/jonofe/lib_mysqludf_sys/info/refs

fatal: HTTP request failed

Derzeit läuft es bei mir noch aktiv auf 6.5 und der LBS v0.2.4.

Ich wollte nun zu testzwecken eine VM, ebenfalls mit 6.5 aufsetzen. Besteht die Möglicheit, die fehlenden Umgebungen aus der laufenden zu entnehmen?

Hintergrund ist, dass ich das laufende 6.5er System eigentlich noch nicht auf 7.x umstellen möchte solange es läuft und keine Notwendigkeit dazu besteht.

[TobiDD]

Super, danke dir, jetzt klappt es

[jonofe]

Solange E2 im Parser leer ist, wird es keine Ausgabe geben.
Für genau deinen Anwendungsfall habe ich ein Beispiel in der Hilfe.

E2: /Generic ESP32/Terrasse/#
E6: Temperatur
E7: Feuchtigkeit
E8: Druck
usw.

Übrigens sollten bei MQTT die Topics nicht mit einem / beginnen.