NEWS
Unterstützung bei MQTT-Einpflegung
-
@igor123 Ich würde trotzdem mal den Sonoff deaktivieren und auf 1883 umstellen und dann schauen, ob es funktioniert. Dann lieber dem Sonoff einen anderen Port verpassen.
@mickym Hab es nun doch vor dem Wochenende angeschaut :-D
Also via MQTT-Adapter und eben einen anderen Port hat er sich erfolgreich verbunden. Nachdem ich die Objects erstmal wieder gelöscht hatte und den MQTT-Adapter neu gestartet hatte, erhielt ich alle notwendigen Topics :-D
Das Problem ist jedoch, dass ich zwar statusänderungen erhalte, aber Befehle die ich sende werden nicht angenommen, diese erscheinen nur rot:
Man muss doch nur hinten den Wert von einer der Punkte unter Command auf den gewünschten ändern und bestätigen - oder muss ich da noch etwas machen?
PS: Ändern auf Port 1883 und MQTT-Adapter hat auch nichts geholfen
-
@igor123 Das mit dem rot und grün hat nur den Hintergrund, dass rot = Nicht bestätigt sind und grün = bestätigt. Also hat nichts mit Fehlern zu tun. Kommandos schickst Du immer unbestätigt. Also Wert reinschreiben, aber unbestätigt. ggf. im Log nachschauen, ob irgendwelche Fehler mit message delete after 11 retries oder so.
-
@igor123 Das mit dem rot und grün hat nur den Hintergrund, dass rot = Nicht bestätigt sind und grün = bestätigt. Also hat nichts mit Fehlern zu tun. Kommandos schickst Du immer unbestätigt. Also Wert reinschreiben, aber unbestätigt. ggf. im Log nachschauen, ob irgendwelche Fehler mit message delete after 11 retries oder so.
-
@mickym ahso verstehe
Naja aber beim senden eines Commandos tut sich am Pool nichts 😫
Kann ich da irgendwie was überprüfen? -
@igor123 Nur ob irgendwas im Log steht und dann mach mal einen Screenshot Deiner mqtt Settings. Ich hoffe da steht noch weitgehendst Standard drin.
Zum Beispiel
bei Dir eben mqtt.0.*
-
@igor123 Mach mal bitte alle Haken raus.
weisst Du was das bedeuted - deswegen gehts wahrscheinlich nicht - da Änderungen nur über einen set Punkt unten drunter erfolgen. Wenn Du einen Haken rein machst, dann solltest Du genau wissen was Du tust.
-
@igor123 Mach mal bitte alle Haken raus.
weisst Du was das bedeuted - deswegen gehts wahrscheinlich nicht - da Änderungen nur über einen set Punkt unten drunter erfolgen. Wenn Du einen Haken rein machst, dann solltest Du genau wissen was Du tust.
-
@mickym
Ich hatte alles auf Standard, bis auf den Port eben.
Nachdem es nicht gefunkt hat, habe ich mal probehalber alles reingemacht :relieved:
Soll ich tatsächlich alle Haken raus machen?
Einige waren bereits standardmäßig drinnen -
@igor123 Vielleicht den states bei subscribe und beim Verbinden publizieren - mehr aber nicht.
-
@mickym bevor ich wieder was falsch mache, so oder?:
"Ausgabe jeder Nachricht loggen (debug)" wird wohl nicht schaden nehme ich an@igor123 Das loggen würde ich nicht machen. Nur die mittleren beiden Optionen in der 1. Zeile. Kaputt machst Du aber nichts - man kann das alles wieder anpassen.Das kannst höchstens bei der Fehlersuche einschalten - dann musst aber auch das Log für diesen ADapter auf debug Level einstellen.
-
@igor123 Das loggen würde ich nicht machen. Nur die mittleren beiden Optionen in der 1. Zeile. Kaputt machst Du aber nichts - man kann das alles wieder anpassen.Das kannst höchstens bei der Fehlersuche einschalten - dann musst aber auch das Log für diesen ADapter auf debug Level einstellen.
@mickym Hab nun folgende Einstellungen gemacht und werde am Abend alles nochmals beim Anschluss überprüfen und checken und mich nochmals melden
ggf. sollte es nicht funken dann den debug einschalten:
Danke erstmals soweit für den super Support!!! :beers:
-
@mickym Hab nun folgende Einstellungen gemacht und werde am Abend alles nochmals beim Anschluss überprüfen und checken und mich nochmals melden
ggf. sollte es nicht funken dann den debug einschalten:Danke erstmals soweit für den super Support!!! :beers:
-
@igor123 Ach und das javascript bei den eigenen States nimm mal raus. Das stimmt eh nicht, weil Du die Instanznummer vergessen hast und das brauchst DU auch nicht.
-
Kaum sind die richtigen Einstellungen drinnen, schon funkt alles einwandfrei :-D
somit funktioniert die Anleitung auch 1:1 für den Intex Simple Spa, falls es jemand dafür benötigt.
Link zum Pool:
https://www.steinbach-group.com/de/128482-simple-spa-73976de/ - kann ihn nur empfehlen!
Link zur Anleitung:
https://github.com/jnsbyr/esp8266-intexsbh20@mickym kannst du mir noch sagen was da bei den Einstellungen genau falsch war? für was sind die einzelnen punkte in den Einstellungen? vielleicht gibt es irgendwo eine Anleitung für diese einzelnen punkte, so dass auch ich als mqtt-neuling es verstehe :-D
-
Kaum sind die richtigen Einstellungen drinnen, schon funkt alles einwandfrei :-D
somit funktioniert die Anleitung auch 1:1 für den Intex Simple Spa, falls es jemand dafür benötigt.
Link zum Pool:
https://www.steinbach-group.com/de/128482-simple-spa-73976de/ - kann ihn nur empfehlen!
Link zur Anleitung:
https://github.com/jnsbyr/esp8266-intexsbh20@mickym kannst du mir noch sagen was da bei den Einstellungen genau falsch war? für was sind die einzelnen punkte in den Einstellungen? vielleicht gibt es irgendwo eine Anleitung für diese einzelnen punkte, so dass auch ich als mqtt-neuling es verstehe :-D
@igor123 Nun als Erstes freut es mich auch, dass nun alles klappt. Der eigentliche Fehler war sicher, dass Du den Punkt unterschiedliche Namen für setzen und lesen nutzen angehakt hast. Den gibts um Endlosschleifen zu vermeiden. Die meisten Geräte haben aber - wie bei Dir eben auch unterschiedlich topic-Äste in die das Gerät publiziert und in die Du als Anwender publizierst. Gäbe es nur einen Punkt hättest Du eben ganz schnell eine Endlosschleife.
Nehmen wir an es gibt ein Topic der den Status einer Lampe anzeigt. Zum Beispiel on oder off.
Gäbe es keinen Kommandopunkt würdest Du diesen Punkt mit "off" beschreiben, Deine Lampe würde ausgehen und die Lampe meldet nun ebenfalls off, für den ausgeschalteten Zustand. Gleichzeitig interpretiert sie es aber wieder als Kommando zum Ausschalten usw.
Mit dem Haken setzt der mqtt-Broker implizit zu jedem Datenpunkt ein set unter den Datenpunkt, der geschaltet wird. Sprich wenn Du ein Kommando unter pool/command/filter gesetzt hast wurde das als Zustand, aber nicht als Kommando interpretiert. Im Prinzip hättest Du unter pool/command/filter/set setzen müssen, um das Kommando on oder off absetzen zu können. Das macht aber gar keinen Sinn, weil das Dein Gerät entweder nicht verstanden hätte oder überflüssig ist, da es eh nur topics aus dem command Ast liest.
Die 2 Haken, die Du gesetzt hast, wären in meinen Augen auch überflüssig bzw. sind nur wichtig, wenn Du das Gerät initialisieren müsstest. Im Prinzip sind alle topics unter mqtt.0.* eigene States. Nur interessiert Dein Gerät nur die, die unter commando stehen, die anderen published es ja selbst oder stammen von fremden Geräten. Nun mit dem einen Haken werden alles states vom mqtt- Adapter gepublished, im anderen Fall wenn das Gerät subscribed hat. Wenn Du beide nicht anhakst, was ich Dir ja ursprünglich empfohlen hatte, bleibt der mqtt Adapter solange still bis Du einen Wert aktualisierst oder änderst . Das Aktualisieren kannst auch noch unterbinden, indem Du den ersten Haken setzt, dann wird nur was geschickt wenn sich der Wert geändert hat.
Zustände im iobroker sind immer bestätigte Werte (grün), während unbestätigte Werte immer rot sind. Jeder andere Hardware-nahe Adapter im iobroker arbeitet so (um wieder das Endlosschleifenproblem das ich oben beschrieben habe) zu vermeiden. MQTT kennt keine bestätigten oder unbestätigten Werte - deswegen nimmt man für die Kommandos an ein Gerät und die States von einem Gerät unterschiedliche topics.
Im iobroker kann man aber mit bestätigten und unbestätigten Werten arbeiten.
Wenn Du mit - wahrscheinlich deinen Blocklies - einen Wert in Deinen Sonoff Adapter schreibst, dann schreibst Du den unbestätigt (rot) in dem Du "steuere ... " nimmst. Auf bestätigte Werte würde der Adapter nicht reagieren, da er denkt, es sei ein Zustand. Da Du aber einen unbestätigten Wert in den Datenpunkt schreibst, weiss der Adapter, dass er was tun muss und schaltet das Gerät. Das Gerät wiederum meldet die Statusänderung zurück und wenn das Gerät das gemacht hat, was es soll, dann wird der Adapter den gleichen Wert nun bestätigt in den DAtenpunkt schreiben und der Wert wird von rot nach grün wechseln. Im Prinzip zeigen Dir also grüne Werte Zustände an, die von der Hardware oder den Adaptern bestätigt wurden. Der mqtt Adapter arbeitet genauso und mit dem Haken Sende auch Zustände kannst Du also veranlassen, dass der mqtt- ADapter auch bestätigte Werte schickt. Damit produzierst Du aber wieder ganz schnell Endlosschleifen - da mqtt wie gesagt keine ACK Flags kennt.Das retain flag dient der Initialisierung - indem (wenn man die oberen beiden Haken mit dem Publishen bei Verbinden und subscriben nicht gesetzt hat=. So ist das quasi redundant. Als broker oder generell finde ich diese OPtion eher unschön, da man sonst in der Anwendung durch das retain flag viel granularer steuern kann, ob ein Wert behalten wird oder nicht. Ist das retain flag nicht gesetzt - behält der mqtt-Broker die Werte nur so lange bis jeder subscriber informiert wurde. Ist jeder Abonnent informiert wird der Wert gelöscht. Das macht bei einem Adapter im iobroker aber auch keinen Sinn.
So das war ein kleiner Ausflug in die mqtt Welt - so wie ich sie verstehe. ;)
-
@igor123 Nun als Erstes freut es mich auch, dass nun alles klappt. Der eigentliche Fehler war sicher, dass Du den Punkt unterschiedliche Namen für setzen und lesen nutzen angehakt hast. Den gibts um Endlosschleifen zu vermeiden. Die meisten Geräte haben aber - wie bei Dir eben auch unterschiedlich topic-Äste in die das Gerät publiziert und in die Du als Anwender publizierst. Gäbe es nur einen Punkt hättest Du eben ganz schnell eine Endlosschleife.
Nehmen wir an es gibt ein Topic der den Status einer Lampe anzeigt. Zum Beispiel on oder off.
Gäbe es keinen Kommandopunkt würdest Du diesen Punkt mit "off" beschreiben, Deine Lampe würde ausgehen und die Lampe meldet nun ebenfalls off, für den ausgeschalteten Zustand. Gleichzeitig interpretiert sie es aber wieder als Kommando zum Ausschalten usw.
Mit dem Haken setzt der mqtt-Broker implizit zu jedem Datenpunkt ein set unter den Datenpunkt, der geschaltet wird. Sprich wenn Du ein Kommando unter pool/command/filter gesetzt hast wurde das als Zustand, aber nicht als Kommando interpretiert. Im Prinzip hättest Du unter pool/command/filter/set setzen müssen, um das Kommando on oder off absetzen zu können. Das macht aber gar keinen Sinn, weil das Dein Gerät entweder nicht verstanden hätte oder überflüssig ist, da es eh nur topics aus dem command Ast liest.
Die 2 Haken, die Du gesetzt hast, wären in meinen Augen auch überflüssig bzw. sind nur wichtig, wenn Du das Gerät initialisieren müsstest. Im Prinzip sind alle topics unter mqtt.0.* eigene States. Nur interessiert Dein Gerät nur die, die unter commando stehen, die anderen published es ja selbst oder stammen von fremden Geräten. Nun mit dem einen Haken werden alles states vom mqtt- Adapter gepublished, im anderen Fall wenn das Gerät subscribed hat. Wenn Du beide nicht anhakst, was ich Dir ja ursprünglich empfohlen hatte, bleibt der mqtt Adapter solange still bis Du einen Wert aktualisierst oder änderst . Das Aktualisieren kannst auch noch unterbinden, indem Du den ersten Haken setzt, dann wird nur was geschickt wenn sich der Wert geändert hat.
Zustände im iobroker sind immer bestätigte Werte (grün), während unbestätigte Werte immer rot sind. Jeder andere Hardware-nahe Adapter im iobroker arbeitet so (um wieder das Endlosschleifenproblem das ich oben beschrieben habe) zu vermeiden. MQTT kennt keine bestätigten oder unbestätigten Werte - deswegen nimmt man für die Kommandos an ein Gerät und die States von einem Gerät unterschiedliche topics.
Im iobroker kann man aber mit bestätigten und unbestätigten Werten arbeiten.
Wenn Du mit - wahrscheinlich deinen Blocklies - einen Wert in Deinen Sonoff Adapter schreibst, dann schreibst Du den unbestätigt (rot) in dem Du "steuere ... " nimmst. Auf bestätigte Werte würde der Adapter nicht reagieren, da er denkt, es sei ein Zustand. Da Du aber einen unbestätigten Wert in den Datenpunkt schreibst, weiss der Adapter, dass er was tun muss und schaltet das Gerät. Das Gerät wiederum meldet die Statusänderung zurück und wenn das Gerät das gemacht hat, was es soll, dann wird der Adapter den gleichen Wert nun bestätigt in den DAtenpunkt schreiben und der Wert wird von rot nach grün wechseln. Im Prinzip zeigen Dir also grüne Werte Zustände an, die von der Hardware oder den Adaptern bestätigt wurden. Der mqtt Adapter arbeitet genauso und mit dem Haken Sende auch Zustände kannst Du also veranlassen, dass der mqtt- ADapter auch bestätigte Werte schickt. Damit produzierst Du aber wieder ganz schnell Endlosschleifen - da mqtt wie gesagt keine ACK Flags kennt.Das retain flag dient der Initialisierung - indem (wenn man die oberen beiden Haken mit dem Publishen bei Verbinden und subscriben nicht gesetzt hat=. So ist das quasi redundant. Als broker oder generell finde ich diese OPtion eher unschön, da man sonst in der Anwendung durch das retain flag viel granularer steuern kann, ob ein Wert behalten wird oder nicht. Ist das retain flag nicht gesetzt - behält der mqtt-Broker die Werte nur so lange bis jeder subscriber informiert wurde. Ist jeder Abonnent informiert wird der Wert gelöscht. Das macht bei einem Adapter im iobroker aber auch keinen Sinn.
So das war ein kleiner Ausflug in die mqtt Welt - so wie ich sie verstehe. ;)
-
@igor123 Nun als Erstes freut es mich auch, dass nun alles klappt. Der eigentliche Fehler war sicher, dass Du den Punkt unterschiedliche Namen für setzen und lesen nutzen angehakt hast. Den gibts um Endlosschleifen zu vermeiden. Die meisten Geräte haben aber - wie bei Dir eben auch unterschiedlich topic-Äste in die das Gerät publiziert und in die Du als Anwender publizierst. Gäbe es nur einen Punkt hättest Du eben ganz schnell eine Endlosschleife.
Nehmen wir an es gibt ein Topic der den Status einer Lampe anzeigt. Zum Beispiel on oder off.
Gäbe es keinen Kommandopunkt würdest Du diesen Punkt mit "off" beschreiben, Deine Lampe würde ausgehen und die Lampe meldet nun ebenfalls off, für den ausgeschalteten Zustand. Gleichzeitig interpretiert sie es aber wieder als Kommando zum Ausschalten usw.
Mit dem Haken setzt der mqtt-Broker implizit zu jedem Datenpunkt ein set unter den Datenpunkt, der geschaltet wird. Sprich wenn Du ein Kommando unter pool/command/filter gesetzt hast wurde das als Zustand, aber nicht als Kommando interpretiert. Im Prinzip hättest Du unter pool/command/filter/set setzen müssen, um das Kommando on oder off absetzen zu können. Das macht aber gar keinen Sinn, weil das Dein Gerät entweder nicht verstanden hätte oder überflüssig ist, da es eh nur topics aus dem command Ast liest.
Die 2 Haken, die Du gesetzt hast, wären in meinen Augen auch überflüssig bzw. sind nur wichtig, wenn Du das Gerät initialisieren müsstest. Im Prinzip sind alle topics unter mqtt.0.* eigene States. Nur interessiert Dein Gerät nur die, die unter commando stehen, die anderen published es ja selbst oder stammen von fremden Geräten. Nun mit dem einen Haken werden alles states vom mqtt- Adapter gepublished, im anderen Fall wenn das Gerät subscribed hat. Wenn Du beide nicht anhakst, was ich Dir ja ursprünglich empfohlen hatte, bleibt der mqtt Adapter solange still bis Du einen Wert aktualisierst oder änderst . Das Aktualisieren kannst auch noch unterbinden, indem Du den ersten Haken setzt, dann wird nur was geschickt wenn sich der Wert geändert hat.
Zustände im iobroker sind immer bestätigte Werte (grün), während unbestätigte Werte immer rot sind. Jeder andere Hardware-nahe Adapter im iobroker arbeitet so (um wieder das Endlosschleifenproblem das ich oben beschrieben habe) zu vermeiden. MQTT kennt keine bestätigten oder unbestätigten Werte - deswegen nimmt man für die Kommandos an ein Gerät und die States von einem Gerät unterschiedliche topics.
Im iobroker kann man aber mit bestätigten und unbestätigten Werten arbeiten.
Wenn Du mit - wahrscheinlich deinen Blocklies - einen Wert in Deinen Sonoff Adapter schreibst, dann schreibst Du den unbestätigt (rot) in dem Du "steuere ... " nimmst. Auf bestätigte Werte würde der Adapter nicht reagieren, da er denkt, es sei ein Zustand. Da Du aber einen unbestätigten Wert in den Datenpunkt schreibst, weiss der Adapter, dass er was tun muss und schaltet das Gerät. Das Gerät wiederum meldet die Statusänderung zurück und wenn das Gerät das gemacht hat, was es soll, dann wird der Adapter den gleichen Wert nun bestätigt in den DAtenpunkt schreiben und der Wert wird von rot nach grün wechseln. Im Prinzip zeigen Dir also grüne Werte Zustände an, die von der Hardware oder den Adaptern bestätigt wurden. Der mqtt Adapter arbeitet genauso und mit dem Haken Sende auch Zustände kannst Du also veranlassen, dass der mqtt- ADapter auch bestätigte Werte schickt. Damit produzierst Du aber wieder ganz schnell Endlosschleifen - da mqtt wie gesagt keine ACK Flags kennt.Das retain flag dient der Initialisierung - indem (wenn man die oberen beiden Haken mit dem Publishen bei Verbinden und subscriben nicht gesetzt hat=. So ist das quasi redundant. Als broker oder generell finde ich diese OPtion eher unschön, da man sonst in der Anwendung durch das retain flag viel granularer steuern kann, ob ein Wert behalten wird oder nicht. Ist das retain flag nicht gesetzt - behält der mqtt-Broker die Werte nur so lange bis jeder subscriber informiert wurde. Ist jeder Abonnent informiert wird der Wert gelöscht. Das macht bei einem Adapter im iobroker aber auch keinen Sinn.
So das war ein kleiner Ausflug in die mqtt Welt - so wie ich sie verstehe. ;)
@mickym Grüß dich
du hattest mir ja bereits letztes Jahr super geholfen um dem MQTT zum laufen zu bringen - danke dafür nochmals :)Ich habe nun den Pool wieder aufgebaut und verbinden wollen.
Meine Hoffnung war:
Pool anschließen und einschalten und schon ist er wieder wie letztes jahr mit dem MQTT Adapter verbunden.
Leider verbindet er sich eben nicht - geändert habe ich aber in der Zwischenzeit gar nichts...
weis nicht mal so recht wo ich die Fehleranalyse starten soll....Ne idee was da sein könnte?
einzig was ich mir vorstellen kann ist, dass es da ein Update gab und dieses die Einstellungen zurückgesetzt hatte oder so... -
@mickym Grüß dich
du hattest mir ja bereits letztes Jahr super geholfen um dem MQTT zum laufen zu bringen - danke dafür nochmals :)Ich habe nun den Pool wieder aufgebaut und verbinden wollen.
Meine Hoffnung war:
Pool anschließen und einschalten und schon ist er wieder wie letztes jahr mit dem MQTT Adapter verbunden.
Leider verbindet er sich eben nicht - geändert habe ich aber in der Zwischenzeit gar nichts...
weis nicht mal so recht wo ich die Fehleranalyse starten soll....Ne idee was da sein könnte?
einzig was ich mir vorstellen kann ist, dass es da ein Update gab und dieses die Einstellungen zurückgesetzt hatte oder so...@igor123 Ist immer schlecht so was von der Ferne zu beurteilen. Wenn Du nichts geändert hast, würde ich auch erst mal nicht viel ändern. Ich vermute eher ein Netzwerkproblem.
Du kannst ja ein Mqtt-Explorer verwenden und schauen, ob Du Dich mit dem mqtt-Broker auf dem iobroker verbinden kannst und Du Daten empfängst und verschicken kannst. Wenn das geht - würde ich lieber auf der Pool bzw. Netzwerkseite suchen, anstelle auf der iobroker Seite.
-
@igor123 Ist immer schlecht so was von der Ferne zu beurteilen. Wenn Du nichts geändert hast, würde ich auch erst mal nicht viel ändern. Ich vermute eher ein Netzwerkproblem.
Du kannst ja ein Mqtt-Explorer verwenden und schauen, ob Du Dich mit dem mqtt-Broker auf dem iobroker verbinden kannst und Du Daten empfängst und verschicken kannst. Wenn das geht - würde ich lieber auf der Pool bzw. Netzwerkseite suchen, anstelle auf der iobroker Seite.
707
Online32.6k
Benutzer82.1k
Themen1.3m
Beiträge