NEWS
MQTT Broker empfängt Daten, sendet aber nicht an Client
-
@bananajoe Dann liegt bei Dir was im Argen - der mqtt Adapter macht doch keinen Unterschied in welchem Ast er was published - bei mir geht das mit den Tasmota Punkten ebenfalls einwandfrei. Wenn man ein 1:1 Abbild macht - dann nutzt man auch gar KEIN Präfix - woher soll den Tasmota das kennen - der ganze Pfad stimmt ja dann nicht mehr. Man macht am Besten alle Haken raus und lässt den Adapter machen. Ein Präfix ist nur sinnvoll, wenn ich anderes States publishen möchte und das unter einem eigenen Präfix verwalten möchte.
Der Präfix MUSS in der Regel leer bleiben:
Du solltest lieber mal schauen, ob Du nicht zusätzlich Deinen ganzen tasmota topics unter /iobroker/cmnd nochmals angelegt hast. ;) Und das Tasmota nichts subscribed was mit einem topic iobroker/# losgeht, das dürfte ja für Dich als Tasmota Spezialist bekannt sein. ;) Natürlich nur, wenn Du es so eingetragen hast. Bei mir habe ich ja alle tasmotas mit Präfix Tasmota definiert und die Struktur umgedreht - deswegen habe ich eigene cmnd Aste für jedes Device und nicht für jedes Gerät einen Ast unter cmnd. ;)
@mickym den Präfix habe ich da mit Absicht drin - um eben solche Sachen zu bemerken. Bei vorhandenen Topics gibt es das Problem ja auch nicht - aber wenn vorhandene, durch andere Geräte erstellte Topics erweitert werden sollen
Aber du hast Recht, kaum hatte ich das "iobroker" als Präfix aus den Adaptereinstellungen entfernt hat es zum ersten mal funktioniert. Obwohl es es dann keinen native-topic Eintrag an dem Datenpunkt gibt - den die automatisch erzeugten Datenpunkte aber haben. Oder die per
sendToerzeugten.@haus-automatisierung wie wichtig der Eintrag nun ist vermag ich nicht zu sagen
ioBroker@Ubuntu 24.04 LTS (VMware) für: >260 Geräte, 5 Switche, 7 AP, 9 IP-Cam, 1 NAS 42TB, 1 ESXi 15TB, 4 Proxmox 1TB, 1 Hyper-V 48TB, 14 x Echo, 5x FireTV, 5 x Tablett/Handy VIS || >=160 Tasmota/Shelly || >=95 ZigBee || PV 8.1kW / Akku 14kWh || 2x USV 750W kaskadiert || Creality CR-10 SE 3D-Drucker
-
@mickym sagte in MQTT Broker empfängt Daten, sendet aber nicht an Client:
@bananajoe Selbstverständlich kann man die Datenpunkte im MQTT Adapter einfach anlegen - habe ich immer so gemacht und das funktioniert auch.
Wenn Du das native-Attribut für das topic richtig setzt geht das - ja.
Beispiel:
{ "_id": "mqtt.0.service.weather.forecast.temperature.today", "common": { "name": "service/weather/forecast/temperature/today", "write": true, "read": true, "role": "variable", "desc": "mqtt client variable", "type": "string" }, "native": { "topic": "service/weather/forecast/temperature/today" }, "type": "state", "from": "system.adapter.mqtt.0", "user": "system.user.admin", "ts": 1657460180836, "acl": { "object": 1636, "state": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" } }Würde ich aber nicht unbedingt empfehlen. Lieber einfach eine Nachricht senden und automatisch anlegen lassen.
@haus-automatisierung Das muss auch nicht - der mqtt sendet auch wenn das da nativ fehlt - habe es gerade gemacht. Darüber habe ich mir bis jetzt in 2 Jahren, in dem ich das so mache noch nie Gedanken machen müssen. Ich verstehe auch nicht, was man dagegen hat, dass es mit direktem Anlegen der Datenpunkte im Adapter macht.
Und das hat bei dem Adapter von Anfang an funktioniert. Ich ändere dann meist nur noch den Namen, da es einfach ist den zu kopieren.
Man muss es auch nicht kompliziert machen. Ich als NodeRed Nutzer kann gar nicht per sendTo was an den Adapter schicken Natürllich kann ich auch über andere mqtt Clients was publishen. Bei mir funktioniert das seit ich den Adapter in verschiedenen Versionen seit über 2 Jahren und man kanns auch kompliziert machen. Jedenfalls wenn kein anderen mqtt-Client zur Verfügung steht, der published, muss ich nicht Blockly oder Javascript lernen, um ein neues Topic via Adapter zu publishen.
Wenn natürlich die Maske zu publishen nicht passt oder man Präfixe einträgt - dann wissen halt manche nicht was sie tun.
In einer 2. Instanz nutze ich ein Präfix um die Daten des tr064 Adapter zu Publishen
Es steht übrigens, dass das Präfix für alle Topics genutzt wird.
Um es auch nochmal zu sagen, habe ich schon mehrfach getan. Ein Broker sendet in erster Linie erst mal von sich nichts. Ein mqtt-Broker verwaltet die Informationen nur. Ein Client subscribed ein Topic und dann sendet der MQTT Broker an ALLE Clients, die diesen Topic abonniert haben.
Im Log siehst Du bei dem obigen Beispiel das gerade neue Topic:
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@mickym den Präfix habe ich da mit Absicht drin - um eben solche Sachen zu bemerken. Bei vorhandenen Topics gibt es das Problem ja auch nicht - aber wenn vorhandene, durch andere Geräte erstellte Topics erweitert werden sollen
Aber du hast Recht, kaum hatte ich das "iobroker" als Präfix aus den Adaptereinstellungen entfernt hat es zum ersten mal funktioniert. Obwohl es es dann keinen native-topic Eintrag an dem Datenpunkt gibt - den die automatisch erzeugten Datenpunkte aber haben. Oder die per
sendToerzeugten.@haus-automatisierung wie wichtig der Eintrag nun ist vermag ich nicht zu sagen
@bananajoe Sobald der Adapter topics published macht er das Präfix dran - Jedenfalls hat KEIN Präfix daran was verloren, wenn ich die Topics 1:1 übertragen will. Ich oben gerade beschrieben, wie ich es mit meiner 2. Instanz mache, wenn ich iobroker Daten über ein Präfix in mein mosquitto übertragen will. Warum es bei Dir bislang überhaupt funktioniert hat er der Adapter nicht überall was davor setzt kann ich Dir nicht beantworten - jedenfalls wenn er es täte dann wäre es richtig.
Es steht ja Prefix für ALLE topics davor:
Warum der Adapter dann bei Deinem Tasmota Ast keinen Präfix davor macht, ist mir zwar ein Rätsel - aber in meinen Augen ist es in erster Linie falsch ein Präfix zu definieren, wenn ich keinen brauche. Und ich muss auch nicht die Welt bis ins Letzte verstehen, wenn das Teil in der Regel das tut, was es soll . :grin:
-
@haus-automatisierung Das muss auch nicht - der mqtt sendet auch wenn das da nativ fehlt - habe es gerade gemacht. Darüber habe ich mir bis jetzt in 2 Jahren, in dem ich das so mache noch nie Gedanken machen müssen. Ich verstehe auch nicht, was man dagegen hat, dass es mit direktem Anlegen der Datenpunkte im Adapter macht.
Und das hat bei dem Adapter von Anfang an funktioniert. Ich ändere dann meist nur noch den Namen, da es einfach ist den zu kopieren.
Man muss es auch nicht kompliziert machen. Ich als NodeRed Nutzer kann gar nicht per sendTo was an den Adapter schicken Natürllich kann ich auch über andere mqtt Clients was publishen. Bei mir funktioniert das seit ich den Adapter in verschiedenen Versionen seit über 2 Jahren und man kanns auch kompliziert machen. Jedenfalls wenn kein anderen mqtt-Client zur Verfügung steht, der published, muss ich nicht Blockly oder Javascript lernen, um ein neues Topic via Adapter zu publishen.
Wenn natürlich die Maske zu publishen nicht passt oder man Präfixe einträgt - dann wissen halt manche nicht was sie tun.
In einer 2. Instanz nutze ich ein Präfix um die Daten des tr064 Adapter zu Publishen
Es steht übrigens, dass das Präfix für alle Topics genutzt wird.
Um es auch nochmal zu sagen, habe ich schon mehrfach getan. Ein Broker sendet in erster Linie erst mal von sich nichts. Ein mqtt-Broker verwaltet die Informationen nur. Ein Client subscribed ein Topic und dann sendet der MQTT Broker an ALLE Clients, die diesen Topic abonniert haben.
Im Log siehst Du bei dem obigen Beispiel das gerade neue Topic:
@mickym sagte in MQTT Broker empfängt Daten, sendet aber nicht an Client:
Das muss auch nicht - der mqtt sendet auch wenn das da nativ fehlt - habe es gerade gemacht.
Ach guck, wieder was gelernt. Und direkt mal im Code nachgeschaut: Es gibt eine Funktion, welche die aktuelle ID in ein Topic umwandelt: https://github.com/ioBroker/ioBroker.mqtt/blob/47a0106676eb4f13395c66d12cc599d94229433b/lib/common.js#L3-L23
Dann muss es damit aber in irgend einer Version mal Probleme gegeben haben, weil ich mich definitiv schon mit Leuten unterhalten habe, welche Objekte manuell erstellt haben und dann nix gepublished wurde.
Empfehlen würde ich es deswegen nicht, weil man als Nutzer (meiner Meinung nach) nur eigene Objekte in
0_userdata.0undalias.0anlegen sollte. Das gibt ja auch der Admin vor und erlaubt das in anderen Namespaces gar nicht (außer, man wechselt in den Expertenmodus).🧑🎓 Autor des beliebten ioBroker-Master-Kurses
🎥 Tutorials rund um das Thema DIY-Smart-Home: https://haus-automatisierung.com/
📚 Meine inoffizielle ioBroker Dokumentation -
@mickym sagte in MQTT Broker empfängt Daten, sendet aber nicht an Client:
Das muss auch nicht - der mqtt sendet auch wenn das da nativ fehlt - habe es gerade gemacht.
Ach guck, wieder was gelernt. Und direkt mal im Code nachgeschaut: Es gibt eine Funktion, welche die aktuelle ID in ein Topic umwandelt: https://github.com/ioBroker/ioBroker.mqtt/blob/47a0106676eb4f13395c66d12cc599d94229433b/lib/common.js#L3-L23
Dann muss es damit aber in irgend einer Version mal Probleme gegeben haben, weil ich mich definitiv schon mit Leuten unterhalten habe, welche Objekte manuell erstellt haben und dann nix gepublished wurde.
Empfehlen würde ich es deswegen nicht, weil man als Nutzer (meiner Meinung nach) nur eigene Objekte in
0_userdata.0undalias.0anlegen sollte. Das gibt ja auch der Admin vor und erlaubt das in anderen Namespaces gar nicht (außer, man wechselt in den Expertenmodus).@haus-automatisierung In der Regel gebe ich Dir Recht, aber diese Möglichkeit über eigene Datenpunkte was zu publishen, da habe ich hier lange für "gekämpft" und Diskussionen geführt und ich bin froh, dass es so funktioniert, wie es tut.
Man legt ja auch nicht Punkte in diesem Adapter an, um das als Datenspeicher zu nutzen - auch der alias Objektbaum hat eine bestimmte Funktion und muss published den Wert seiner Originaldatenpunkte. ;)
Deswegen würde ich dem Fall Deine Liste durchaus erweitern:
0_userdata.0 - zur Speicherung für eigene Daten jeglicher Art
alias.0 - für das Mappen und Veröffentlichen von bereits vorhandenen States unter "neutralem" Namen
mqtt - zum Publishen von mqtt topicsWie gesagt ich habe da lange Diskussionen geführt, dass der mqtt Adapter eine Sonderstellung einnimmt. Er lässt sich auch nicht in das vorgegebene iobroker Schema pressen - deswegen werden auch Verzeichnisse in topics gewandelt usw.
Ein Shelly published nun mal mit originärem mqtt in
relay/0 - auch wenn es darunter noch ein command topic gibt. Aber wem erzähle ich das. :grin: :grin: :grin:
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@haus-automatisierung In der Regel gebe ich Dir Recht, aber diese Möglichkeit über eigene Datenpunkte was zu publishen, da habe ich hier lange für "gekämpft" und Diskussionen geführt und ich bin froh, dass es so funktioniert, wie es tut.
Man legt ja auch nicht Punkte in diesem Adapter an, um das als Datenspeicher zu nutzen - auch der alias Objektbaum hat eine bestimmte Funktion und muss published den Wert seiner Originaldatenpunkte. ;)
Deswegen würde ich dem Fall Deine Liste durchaus erweitern:
0_userdata.0 - zur Speicherung für eigene Daten jeglicher Art
alias.0 - für das Mappen und Veröffentlichen von bereits vorhandenen States unter "neutralem" Namen
mqtt - zum Publishen von mqtt topicsWie gesagt ich habe da lange Diskussionen geführt, dass der mqtt Adapter eine Sonderstellung einnimmt. Er lässt sich auch nicht in das vorgegebene iobroker Schema pressen - deswegen werden auch Verzeichnisse in topics gewandelt usw.
Ein Shelly published nun mal mit originärem mqtt in
relay/0 - auch wenn es darunter noch ein command topic gibt. Aber wem erzähle ich das. :grin: :grin: :grin:
@mickym sagte in MQTT Broker empfängt Daten, sendet aber nicht an Client:
dass der mqtt Adapter eine Sonderstellung einnimmt
Da hast Du Recht. Eventuell müsste man den Admin dann mal dahingehend ändern, dass man dort auch ohne den Expertenmodus Objekte anlegen kann. Zumal ich die Objekte dort ja auch bearbeite (read / write anpassen) nachdem sie angelegt wurden.
Es gibt ja keine "richtige" Struktur dort. Die legt man am Ende ja immer selbst an. Ob es über eigens definierte Topics ist oder manuell angelegte Objekte kommt ja auf das gleiche raus.
-
@bananajoe Dann liegt bei Dir was im Argen - der mqtt Adapter macht doch keinen Unterschied in welchem Ast er was published - bei mir geht das mit den Tasmota Punkten ebenfalls einwandfrei. Wenn man ein 1:1 Abbild macht - dann nutzt man auch gar KEIN Präfix - woher soll den Tasmota das kennen - der ganze Pfad stimmt ja dann nicht mehr. Man macht am Besten alle Haken raus und lässt den Adapter machen. Ein Präfix ist nur sinnvoll, wenn ich anderes States publishen möchte und das unter einem eigenen Präfix verwalten möchte.
Der Präfix MUSS in der Regel leer bleiben:
Du solltest lieber mal schauen, ob Du nicht zusätzlich Deinen ganzen tasmota topics unter /iobroker/cmnd nochmals angelegt hast. ;) Und das Tasmota nichts subscribed was mit einem topic iobroker/# losgeht, das dürfte ja für Dich als Tasmota Spezialist bekannt sein. ;) Natürlich nur, wenn Du es so eingetragen hast. Bei mir habe ich ja alle tasmotas mit Präfix Tasmota definiert und die Struktur umgedreht - deswegen habe ich eigene cmnd Aste für jedes Device und nicht für jedes Gerät einen Ast unter cmnd. ;)
@mickym sagte in MQTT Broker empfängt Daten, sendet aber nicht an Client:
Du solltest lieber mal schauen, ob Du nicht zusätzlich Deinen ganzen tasmota topics unter /iobroker/cmnd nochmals angelegt hast. ;)
Da ich bei solchen Sachen immer auf einem 3. Bildschirm den MQTT-Explorer mitlaufen habe: Nein, da passiert gar nichts, es wird nichts gesendet. Weshalb ich damals nach einer Lösung gesucht hatte, hier im Forum auch andere fand bei denen es nicht lief. Da ich mir es zur Gewohnheit gemacht habe auch mal die Anleitung eines Adapters zu lesen entdeckte ich dort die
sendTo-Methode die dann auch auf anhieb funktionierte.
Ich brauchte das vielfach zur Steuerung diverse Tasmota-Geräte und untercmndwird ja erst einmal nur dasPOWERangelegt. Und ich wollte die Datenpunkte im Skript anlegen, nicht mühsam von Hand.Ich bin jetzt noch kein so alter ioBroker-Hase, andererseits von den ioBroker + Adapterversionen doch schon ganz schön lange dabei. Keine Ahnung inwiefern sich das verhalten mit den Versionen geändert hat. Damals habe ich dann auch irgendwann beim Probieren wohl das
iobrokerim Adapter eingetragen.ioBroker@Ubuntu 24.04 LTS (VMware) für: >260 Geräte, 5 Switche, 7 AP, 9 IP-Cam, 1 NAS 42TB, 1 ESXi 15TB, 4 Proxmox 1TB, 1 Hyper-V 48TB, 14 x Echo, 5x FireTV, 5 x Tablett/Handy VIS || >=160 Tasmota/Shelly || >=95 ZigBee || PV 8.1kW / Akku 14kWh || 2x USV 750W kaskadiert || Creality CR-10 SE 3D-Drucker
-
@mickym sagte in MQTT Broker empfängt Daten, sendet aber nicht an Client:
Du solltest lieber mal schauen, ob Du nicht zusätzlich Deinen ganzen tasmota topics unter /iobroker/cmnd nochmals angelegt hast. ;)
Da ich bei solchen Sachen immer auf einem 3. Bildschirm den MQTT-Explorer mitlaufen habe: Nein, da passiert gar nichts, es wird nichts gesendet. Weshalb ich damals nach einer Lösung gesucht hatte, hier im Forum auch andere fand bei denen es nicht lief. Da ich mir es zur Gewohnheit gemacht habe auch mal die Anleitung eines Adapters zu lesen entdeckte ich dort die
sendTo-Methode die dann auch auf anhieb funktionierte.
Ich brauchte das vielfach zur Steuerung diverse Tasmota-Geräte und untercmndwird ja erst einmal nur dasPOWERangelegt. Und ich wollte die Datenpunkte im Skript anlegen, nicht mühsam von Hand.Ich bin jetzt noch kein so alter ioBroker-Hase, andererseits von den ioBroker + Adapterversionen doch schon ganz schön lange dabei. Keine Ahnung inwiefern sich das verhalten mit den Versionen geändert hat. Damals habe ich dann auch irgendwann beim Probieren wohl das
iobrokerim Adapter eingetragen.@bananajoe Wie gesagt ich lege die Punkte bei Bedarf manuell an - bzw. habe sich durch den Tasmota Device Manager anlegen lassen.
backlog habe ich selbst angelegt - da der Name nicht stimmt - muss ich gleich mal ändern. ;)
-
@bananajoe Wie gesagt ich lege die Punkte bei Bedarf manuell an - bzw. habe sich durch den Tasmota Device Manager anlegen lassen.
backlog habe ich selbst angelegt - da der Name nicht stimmt - muss ich gleich mal ändern. ;)
darf ich Euch nochmal bemühen. Die Übertragung funktioniert, aber immer nur sporadisch. Es kommt nur sehr selten ein neuer Wert an, obwohl in den Objekten der Wert schon längst geändert ist. Weiß jemand woran das liegt?
Lt. Log steht beides drin. hier ein Auszug. Es soll die aussentemp mit 31.8 übertragen werden. Leider stehen immer noch 34.4 von heute Vormittag drin. Beide Werte sehe ich hier im Log. Wird das vom IO-Broker Adapter falsch übertragen, oder sind die 34.4 die Rückmeldung vom Client an den Broker hier im IO Broker? Und der Client übernimmt einfach die 31.8 nicht.
2022-08-25 20:08:01.440 - info: mqtt.0 (23196) Client [] connected with secret 1661450881439_4253
2022-08-25 20:08:01.441 - debug: mqtt.0 (23196) Client [] with keepalive 60 set timeout to 90 seconds
2022-08-25 20:08:01.455 - debug: mqtt.0 (23196) Client [] received subscribe package {"cmd":"subscribe","retain":false,"qos":1,"dup":false,"length":29,"topic":null,"payload":null,"subscriptions":[{"topic":"solaranzeige/anzeige/1/#","qos":0}],"messageId":1}
2022-08-25 20:08:01.455 - debug: mqtt.0 (23196) Client [] Handle subscribe: {"topic":"solaranzeige/anzeige/1/#","qos":0}
2022-08-25 20:08:01.456 - info: mqtt.0 (23196) Client [] subscribes on "solaranzeige/anzeige/1/#" with regex /^solaranzeige.anzeige.1(..)?/
2022-08-25 20:08:01.456 - info: mqtt.0 (23196) Client [] subscribes on "solaranzeige/anzeige/1/#" with regex /^mqtt.0.solaranzeige.anzeige.1(..)?/
2022-08-25 20:08:01.457 - debug: mqtt.0 (23196) Client [] received subscribe package {"cmd":"subscribe","retain":false,"qos":1,"dup":false,"length":28,"topic":null,"payload":null,"subscriptions":[{"topic":"solaranzeige/befehl/1/#","qos":0}],"messageId":2}
2022-08-25 20:08:01.457 - debug: mqtt.0 (23196) Client [] Handle subscribe: {"topic":"solaranzeige/befehl/1/#","qos":0}
2022-08-25 20:08:01.457 - info: mqtt.0 (23196) Client [] subscribes on "solaranzeige/befehl/1/#" with regex /^solaranzeige.befehl.1(..)?/
2022-08-25 20:08:01.458 - info: mqtt.0 (23196) Client [] subscribes on "solaranzeige/befehl/1/#" with regex /^mqtt.0.solaranzeige.befehl.1(..)?/
2022-08-25 20:08:03.441 - debug: mqtt.0 (23196) Client [] send to this client "solaranzeige/anzeige/1/aussentemp": 34.4
2022-08-25 20:08:04.181 - debug: mqtt.0 (23196) Client [] received publish package {"cmd":"publish","retain":false,"qos":0,"dup":false,"length":38,"topic":"solaranzeige/1/i_heizung_warmwasser","payload":{"type":"Buffer","data":[48]}}
2022-08-25 20:08:04.181 - debug: mqtt.0 (23196) Server received "solaranzeige/1/i_heizung_warmwasser" (number): 0
2022-08-25 20:08:21.852 - error: modbus.0 (1180) Socket Error
2022-08-25 20:08:21.853 - error: modbus.0 (1180) Client in error state.
2022-08-25 20:08:21.853 - warn: modbus.0 (1180) On error: {"errno":"ETIMEDOUT","code":"ETIMEDOUT","syscall":"connect","address":"192.168.0.102","port":502}
2022-08-25 20:08:30.049 - silly: mqtt.0 (23196) States user redis pmessage mqtt.0.solaranzeige.anzeige.1./mqtt.0.solaranzeige.anzeige.1.aussentemp:{"val":31.3,ack":true,"ts":1661450910023,"q":0,"c":"script.js.Heizungssteuerung","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1661450430030}
2022-08-25 20:08:30.051 - debug: mqtt.0 (23196) stateChange mqtt.0.solaranzeige.anzeige.1.aussentemp: {"val":31.3,"ack":true,"ts":1661450910023,"q":0,"c":"script.js.Heizungssteuerung","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1661450430030}
mqtt.0.solaranzeige.anzeige.1./mqtt.0.solaranzeige.anzeige.1.aussentemp:{"val":31.3,"ack":true,"ts":1661450940066,"q":0,"c":"script.js.Heizungssteuerung","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1661450430030}
2022-08-25 20:09:00.078 - debug: mqtt.0 (23196) stateChange mqtt.0.solaranzeige.anzeige.1.aussentemp: {"val":31.3,"ack":true,"ts":1661450940066,"q":0,"c":"script.js.Heizungssteuerung","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1661450430030}
2022-08-25 20:09:00.255 - info: mqtt.0 (23196) Client [] connection closed: disconnected -
darf ich Euch nochmal bemühen. Die Übertragung funktioniert, aber immer nur sporadisch. Es kommt nur sehr selten ein neuer Wert an, obwohl in den Objekten der Wert schon längst geändert ist. Weiß jemand woran das liegt?
Lt. Log steht beides drin. hier ein Auszug. Es soll die aussentemp mit 31.8 übertragen werden. Leider stehen immer noch 34.4 von heute Vormittag drin. Beide Werte sehe ich hier im Log. Wird das vom IO-Broker Adapter falsch übertragen, oder sind die 34.4 die Rückmeldung vom Client an den Broker hier im IO Broker? Und der Client übernimmt einfach die 31.8 nicht.
2022-08-25 20:08:01.440 - info: mqtt.0 (23196) Client [] connected with secret 1661450881439_4253
2022-08-25 20:08:01.441 - debug: mqtt.0 (23196) Client [] with keepalive 60 set timeout to 90 seconds
2022-08-25 20:08:01.455 - debug: mqtt.0 (23196) Client [] received subscribe package {"cmd":"subscribe","retain":false,"qos":1,"dup":false,"length":29,"topic":null,"payload":null,"subscriptions":[{"topic":"solaranzeige/anzeige/1/#","qos":0}],"messageId":1}
2022-08-25 20:08:01.455 - debug: mqtt.0 (23196) Client [] Handle subscribe: {"topic":"solaranzeige/anzeige/1/#","qos":0}
2022-08-25 20:08:01.456 - info: mqtt.0 (23196) Client [] subscribes on "solaranzeige/anzeige/1/#" with regex /^solaranzeige.anzeige.1(..)?/
2022-08-25 20:08:01.456 - info: mqtt.0 (23196) Client [] subscribes on "solaranzeige/anzeige/1/#" with regex /^mqtt.0.solaranzeige.anzeige.1(..)?/
2022-08-25 20:08:01.457 - debug: mqtt.0 (23196) Client [] received subscribe package {"cmd":"subscribe","retain":false,"qos":1,"dup":false,"length":28,"topic":null,"payload":null,"subscriptions":[{"topic":"solaranzeige/befehl/1/#","qos":0}],"messageId":2}
2022-08-25 20:08:01.457 - debug: mqtt.0 (23196) Client [] Handle subscribe: {"topic":"solaranzeige/befehl/1/#","qos":0}
2022-08-25 20:08:01.457 - info: mqtt.0 (23196) Client [] subscribes on "solaranzeige/befehl/1/#" with regex /^solaranzeige.befehl.1(..)?/
2022-08-25 20:08:01.458 - info: mqtt.0 (23196) Client [] subscribes on "solaranzeige/befehl/1/#" with regex /^mqtt.0.solaranzeige.befehl.1(..)?/
2022-08-25 20:08:03.441 - debug: mqtt.0 (23196) Client [] send to this client "solaranzeige/anzeige/1/aussentemp": 34.4
2022-08-25 20:08:04.181 - debug: mqtt.0 (23196) Client [] received publish package {"cmd":"publish","retain":false,"qos":0,"dup":false,"length":38,"topic":"solaranzeige/1/i_heizung_warmwasser","payload":{"type":"Buffer","data":[48]}}
2022-08-25 20:08:04.181 - debug: mqtt.0 (23196) Server received "solaranzeige/1/i_heizung_warmwasser" (number): 0
2022-08-25 20:08:21.852 - error: modbus.0 (1180) Socket Error
2022-08-25 20:08:21.853 - error: modbus.0 (1180) Client in error state.
2022-08-25 20:08:21.853 - warn: modbus.0 (1180) On error: {"errno":"ETIMEDOUT","code":"ETIMEDOUT","syscall":"connect","address":"192.168.0.102","port":502}
2022-08-25 20:08:30.049 - silly: mqtt.0 (23196) States user redis pmessage mqtt.0.solaranzeige.anzeige.1./mqtt.0.solaranzeige.anzeige.1.aussentemp:{"val":31.3,ack":true,"ts":1661450910023,"q":0,"c":"script.js.Heizungssteuerung","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1661450430030}
2022-08-25 20:08:30.051 - debug: mqtt.0 (23196) stateChange mqtt.0.solaranzeige.anzeige.1.aussentemp: {"val":31.3,"ack":true,"ts":1661450910023,"q":0,"c":"script.js.Heizungssteuerung","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1661450430030}
mqtt.0.solaranzeige.anzeige.1./mqtt.0.solaranzeige.anzeige.1.aussentemp:{"val":31.3,"ack":true,"ts":1661450940066,"q":0,"c":"script.js.Heizungssteuerung","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1661450430030}
2022-08-25 20:09:00.078 - debug: mqtt.0 (23196) stateChange mqtt.0.solaranzeige.anzeige.1.aussentemp: {"val":31.3,"ack":true,"ts":1661450940066,"q":0,"c":"script.js.Heizungssteuerung","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1661450430030}
2022-08-25 20:09:00.255 - info: mqtt.0 (23196) Client [] connection closed: disconnected@gimichael Wäre super - wenn Du solche Log Auszüge in CodeTags packst - nur mal generell.
So ich habs aber nun auch geschafft - vom mqtt-Client auf den Broker der das dann wieder published auch wenn ACK=true ist und zurück.
Das sind die Broker Einstellungen:
Das sind die Client Einstellungen:
So hier mal - wie sich das gegenseitig aktualisiert. Wichtig ist, dass man bei Zuständen wirklich nur Änderungen publizieren darf, sonst ist die Endlosschleife vorprogrammiert.
Hier mal der Videobeweis:
mqtt.0 = Brokerinstanz
mqtt.1 = ClientinstanzFunktioniert auch mit bestätigten Werten ACK = true.
-
darf ich Euch nochmal bemühen. Die Übertragung funktioniert, aber immer nur sporadisch. Es kommt nur sehr selten ein neuer Wert an, obwohl in den Objekten der Wert schon längst geändert ist. Weiß jemand woran das liegt?
Lt. Log steht beides drin. hier ein Auszug. Es soll die aussentemp mit 31.8 übertragen werden. Leider stehen immer noch 34.4 von heute Vormittag drin. Beide Werte sehe ich hier im Log. Wird das vom IO-Broker Adapter falsch übertragen, oder sind die 34.4 die Rückmeldung vom Client an den Broker hier im IO Broker? Und der Client übernimmt einfach die 31.8 nicht.
2022-08-25 20:08:01.440 - info: mqtt.0 (23196) Client [] connected with secret 1661450881439_4253
2022-08-25 20:08:01.441 - debug: mqtt.0 (23196) Client [] with keepalive 60 set timeout to 90 seconds
2022-08-25 20:08:01.455 - debug: mqtt.0 (23196) Client [] received subscribe package {"cmd":"subscribe","retain":false,"qos":1,"dup":false,"length":29,"topic":null,"payload":null,"subscriptions":[{"topic":"solaranzeige/anzeige/1/#","qos":0}],"messageId":1}
2022-08-25 20:08:01.455 - debug: mqtt.0 (23196) Client [] Handle subscribe: {"topic":"solaranzeige/anzeige/1/#","qos":0}
2022-08-25 20:08:01.456 - info: mqtt.0 (23196) Client [] subscribes on "solaranzeige/anzeige/1/#" with regex /^solaranzeige.anzeige.1(..)?/
2022-08-25 20:08:01.456 - info: mqtt.0 (23196) Client [] subscribes on "solaranzeige/anzeige/1/#" with regex /^mqtt.0.solaranzeige.anzeige.1(..)?/
2022-08-25 20:08:01.457 - debug: mqtt.0 (23196) Client [] received subscribe package {"cmd":"subscribe","retain":false,"qos":1,"dup":false,"length":28,"topic":null,"payload":null,"subscriptions":[{"topic":"solaranzeige/befehl/1/#","qos":0}],"messageId":2}
2022-08-25 20:08:01.457 - debug: mqtt.0 (23196) Client [] Handle subscribe: {"topic":"solaranzeige/befehl/1/#","qos":0}
2022-08-25 20:08:01.457 - info: mqtt.0 (23196) Client [] subscribes on "solaranzeige/befehl/1/#" with regex /^solaranzeige.befehl.1(..)?/
2022-08-25 20:08:01.458 - info: mqtt.0 (23196) Client [] subscribes on "solaranzeige/befehl/1/#" with regex /^mqtt.0.solaranzeige.befehl.1(..)?/
2022-08-25 20:08:03.441 - debug: mqtt.0 (23196) Client [] send to this client "solaranzeige/anzeige/1/aussentemp": 34.4
2022-08-25 20:08:04.181 - debug: mqtt.0 (23196) Client [] received publish package {"cmd":"publish","retain":false,"qos":0,"dup":false,"length":38,"topic":"solaranzeige/1/i_heizung_warmwasser","payload":{"type":"Buffer","data":[48]}}
2022-08-25 20:08:04.181 - debug: mqtt.0 (23196) Server received "solaranzeige/1/i_heizung_warmwasser" (number): 0
2022-08-25 20:08:21.852 - error: modbus.0 (1180) Socket Error
2022-08-25 20:08:21.853 - error: modbus.0 (1180) Client in error state.
2022-08-25 20:08:21.853 - warn: modbus.0 (1180) On error: {"errno":"ETIMEDOUT","code":"ETIMEDOUT","syscall":"connect","address":"192.168.0.102","port":502}
2022-08-25 20:08:30.049 - silly: mqtt.0 (23196) States user redis pmessage mqtt.0.solaranzeige.anzeige.1./mqtt.0.solaranzeige.anzeige.1.aussentemp:{"val":31.3,ack":true,"ts":1661450910023,"q":0,"c":"script.js.Heizungssteuerung","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1661450430030}
2022-08-25 20:08:30.051 - debug: mqtt.0 (23196) stateChange mqtt.0.solaranzeige.anzeige.1.aussentemp: {"val":31.3,"ack":true,"ts":1661450910023,"q":0,"c":"script.js.Heizungssteuerung","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1661450430030}
mqtt.0.solaranzeige.anzeige.1./mqtt.0.solaranzeige.anzeige.1.aussentemp:{"val":31.3,"ack":true,"ts":1661450940066,"q":0,"c":"script.js.Heizungssteuerung","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1661450430030}
2022-08-25 20:09:00.078 - debug: mqtt.0 (23196) stateChange mqtt.0.solaranzeige.anzeige.1.aussentemp: {"val":31.3,"ack":true,"ts":1661450940066,"q":0,"c":"script.js.Heizungssteuerung","from":"system.adapter.javascript.0","user":"system.user.admin","lc":1661450430030}
2022-08-25 20:09:00.255 - info: mqtt.0 (23196) Client [] connection closed: disconnected@gimichael sagte in MQTT Broker empfängt Daten, sendet aber nicht an Client:
darf ich Euch nochmal bemühen. Die Übertragung funktioniert, aber immer nur sporadisch. Es kommt nur sehr selten ein neuer Wert an, obwohl in den Objekten der Wert schon längst geändert ist. Weiß jemand woran das liegt?
Völlig ins blaue geschossen, würde ich sagen, dass der Client nicht (mehr) verbunden ist. Das schaut in den Logs so aus. Insofern solltest Du Dir das hier nochmals ansehen:
Bin mir ziemlich sicher, dass hier der Client verbunden sein muss (alles grün), sonst kommen die "published" Nachrichten nicht an.
Ich an Deiner Stelle würde mit einem anderen MQTT-Client (siehe zweiter Post) gegentesten.
NUC10I3+Ubuntu+Docker+ioBroker+influxDB2+Node Red+EMQX+Grafana
Pi-hole, Traefik, Checkmk, Conbee II+Zigbee2MQTT, ESPSomfy-RTS, LoRaWAN, Arduino, KiCad
Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
@gimichael sagte in MQTT Broker empfängt Daten, sendet aber nicht an Client:
darf ich Euch nochmal bemühen. Die Übertragung funktioniert, aber immer nur sporadisch. Es kommt nur sehr selten ein neuer Wert an, obwohl in den Objekten der Wert schon längst geändert ist. Weiß jemand woran das liegt?
Völlig ins blaue geschossen, würde ich sagen, dass der Client nicht (mehr) verbunden ist. Das schaut in den Logs so aus. Insofern solltest Du Dir das hier nochmals ansehen:
Bin mir ziemlich sicher, dass hier der Client verbunden sein muss (alles grün), sonst kommen die "published" Nachrichten nicht an.
Ich an Deiner Stelle würde mit einem anderen MQTT-Client (siehe zweiter Post) gegentesten.
@marc-berg Ja das ist natürlich Voraussetzung - ich habe bei den mqtt Adapter untereinander festgestellt, dass die Verbindung auch nur zuverlässig klappt, wenn der Client eine eigene Client-ID benutzt. Standardmässig werden immer nur die Adapterinstanznamen genutzt - und die können auf unterschiedlichen Maschinen ja gleich sein.
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@marc-berg Ja das ist natürlich Voraussetzung - ich habe bei den mqtt Adapter untereinander festgestellt, dass die Verbindung auch nur zuverlässig klappt, wenn der Client eine eigene Client-ID benutzt. Standardmässig werden immer nur die Adapterinstanznamen genutzt - und die können auf unterschiedlichen Maschinen ja gleich sein.
@mickym sagte in MQTT Broker empfängt Daten, sendet aber nicht an Client:
@marc-berg Ja das ist natürlich Voraussetzung - ich habe bei den mqtt Adapter untereinander festgestellt, dass die Verbindung auch nur zuverlässig klappt, wenn der Client eine eigene Client-ID benutzt. Standardmässig werden immer nur die Adapterinstanznamen genutzt - und die können auf unterschiedlichen Maschinen ja gleich sein.
Habe etwas falsch zitiert, die Nachricht sollte natürlich an @GiMichael gehen. :-)
NUC10I3+Ubuntu+Docker+ioBroker+influxDB2+Node Red+EMQX+Grafana
Pi-hole, Traefik, Checkmk, Conbee II+Zigbee2MQTT, ESPSomfy-RTS, LoRaWAN, Arduino, KiCad
Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
@mickym sagte in MQTT Broker empfängt Daten, sendet aber nicht an Client:
@marc-berg Ja das ist natürlich Voraussetzung - ich habe bei den mqtt Adapter untereinander festgestellt, dass die Verbindung auch nur zuverlässig klappt, wenn der Client eine eigene Client-ID benutzt. Standardmässig werden immer nur die Adapterinstanznamen genutzt - und die können auf unterschiedlichen Maschinen ja gleich sein.
Habe etwas falsch zitiert, die Nachricht sollte natürlich an @GiMichael gehen. :-)
@marc-berg sagte in MQTT Broker empfängt Daten, sendet aber nicht an Client:
Habe etwas falsch zitiert, die Nachricht sollte natürlich an @GiMichael gehen.
Entschuldigung. :anguished:
-
@gimichael sagte in MQTT Broker empfängt Daten, sendet aber nicht an Client:
darf ich Euch nochmal bemühen. Die Übertragung funktioniert, aber immer nur sporadisch. Es kommt nur sehr selten ein neuer Wert an, obwohl in den Objekten der Wert schon längst geändert ist. Weiß jemand woran das liegt?
Völlig ins blaue geschossen, würde ich sagen, dass der Client nicht (mehr) verbunden ist. Das schaut in den Logs so aus. Insofern solltest Du Dir das hier nochmals ansehen:
Bin mir ziemlich sicher, dass hier der Client verbunden sein muss (alles grün), sonst kommen die "published" Nachrichten nicht an.
Ich an Deiner Stelle würde mit einem anderen MQTT-Client (siehe zweiter Post) gegentesten.
@marc-berg
Danke, scheint jetzt mit dem Senden von Zuständen auch zu laufen. Jede Änderung wird verwendet und vom Client auch empfangen. Ich teste aber weiter, ob es so funktioniert.Die Verbindung wird immer auf- und abgebaut. Scheint normal zu sein. Deshalb laufend X bei Verbindung.
das mit dem Code merke ich mir :-) -
@marc-berg Ja das ist natürlich Voraussetzung - ich habe bei den mqtt Adapter untereinander festgestellt, dass die Verbindung auch nur zuverlässig klappt, wenn der Client eine eigene Client-ID benutzt. Standardmässig werden immer nur die Adapterinstanznamen genutzt - und die können auf unterschiedlichen Maschinen ja gleich sein.
748
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge