Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Ankündigung
Einklappen
Keine Ankündigung bisher.
MQTT API Server und MQTT Clients - LBS19001051 - LBS19001054
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:
Code:
[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.
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 :-)
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?
Bei MQTT kann man nur zertifikatsbasierte Authentisierung machen. Access-Token deutet eher auf OAuth2 hin. Ohne eine API Beschreibung ist das vermutlich viel Raterei.
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?
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?
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.
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.
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...
...
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.
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.
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.
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.
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.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar