Seite 1 von 2
MQTT Protokoll hält sich nicht an Standard.
Verfasst: Mo Feb 28, 2022 1:18 pm
von JB_Sullivan
Ich hatte es in einem anderen Thread ja schonmal angemerkt, das dass übertragene MQTT Protokoll sich scheinbar nicht an den Standard hält.
------------ Hier nochmal der Beitrag, der möglicherweise untergegangen ist, da dieser dem falschen Topic zugeordnet war ----------------------
Ich lasse mir die Datenpunkte von openWB via MQTT an ioBroker übergeben. In ioBroker sorgt dieses über den dortigen MQTT Adapter aber regemäßig für massenhaft Fehlermeldungen. Funktionieren tut aber trotzdem alles.
Die ioBroker Entwickler sind der Meinung, das es daran liegt, wie die Daten rein kommen - also von openWB gesendet werden.
Ist das etwas was auf openWB Seite heilbar ist?
Antwort eines ioB ENtwickler:
Aahhh es geht um die Typ-Warnungen? Ja, die kommen vor, wenn die gegenstelle keinen einheitlichen Datentyp sendet
Hier kommen scheinbar mal Strings und mal Zahlen und damit entsteht ein chaos
Hier mal ein kleiner Beispiel Ausschnitt.
Code: Alles auswählen
mqtt.2 | 2022-02-25 10:11:34.102 | info | State value to set for "mqtt.2.openWB.set.evu.faultState" has to be type "number" but received type "string"
mqtt.2 | 2022-02-25 10:11:32.900 | info | State value to set for "mqtt.2.openWB.set.houseBattery.faultState" has to be type "string" but received type "number"
mqtt.2 | 2022-02-25 10:11:32.801 | info | State value to set for "mqtt.2.openWB.set.pv.1.faultState" has to be type "string" but received type "number"
mqtt.2 | 2022-02-25 10:11:14.477 | info | State value to set for "mqtt.2.openWB.set.lp.1.socFaultState" has to be type "string" but received type "number"
mqtt.2 | 2022-02-25 10:11:14.395 | info | State value to set for "mqtt.2.openWB.set.evu.faultState" has to be type "number" but received type "string"
mqtt.2 | 2022-02-25 10:11:13.340 | info | State value to set for "mqtt.2.openWB.set.houseBattery.faultState" has to be type "string" but received type "number"
mqtt.2 | 2022-02-25 10:11:13.184 | info | State value to set for "mqtt.2.openWB.set.pv.1.faultState" has to be type "string" but received type "number"
mqtt.2 | 2022-02-25 10:10:54.409 | info | State value to set for "mqtt.2.openWB.set.lp.1.socFaultState" has to be type "string" but received type "number"
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Mit einem DEBUG Log in ioBroker konnte der Entwickler des dortigen MQTT Adapter dieses nun bestätigen.
Ja seht mal sehr schön das sich das gerät nicht einig ist was es senden will ... wtf
Code: Alles auswählen
2022-02-28 11:16:04.182 - [34mdebug[39m: mqtt.2 (8416) stateChange mqtt.2.openWB.set.houseBattery.faultState: {"val":0,"ack":true,"ts":1646043364179,"q":0,"from":"system.adapter.mqtt.2","user":"system.user.admin","lc":1646043364179}
2022-02-28 11:16:04.226 - [34mdebug[39m: mqtt.2 (8416) stateChange mqtt.2.openWB.set.houseBattery.faultState: {"val":"","ack":true,"ts":1646043364223,"q":0,"from":"system.adapter.mqtt.2","user":"system.user.admin","lc":1646043364223}
Innerhalb von 24ms zwei Datentypen ... heul ...
Darum noch einmal die Frage - ist das etwas was auf Seite von openWB abgestellt werden kann, oder muss ich mit dem Ergebnis auf ioBroker Seite damit leben?
Re: MQTT Protokoll hält sich nicht an Standard.
Verfasst: Mo Feb 28, 2022 1:31 pm
von openWB
Hallo,
Werte kommen als Zahl (number), ebenso Fehler states (analog zu Exit Codes).
Hingegen kommen "Meldungen" natürlich als string.
Es ist also weniger ein Chaos sondern eher je nach Typ entsprechend.
Re: MQTT Protokoll hält sich nicht an Standard.
Verfasst: Mo Feb 28, 2022 2:44 pm
von d-dl
Ist mir auch schon aufgefallen, wobei ich das in meinem Setup beim "socFaultState" habe.
Hier der Input, der von der openwb geschickt wird - beides mal der selbe Datenpunkt openWB.set.lp.1.socFaultState.
Einmal value 0 (number), dann value "" (string):
Code: Alles auswählen
mqtt.2.openWB.set.lp.1.socFaultState: {"val":0,"ack":true,"ts":1646059195160,"q":0,"from":"system.adapter.mqtt.2","user":"system.user.admin","lc":1646059195160}
mqtt.2.openWB.set.lp.1.socFaultState: {"val":"","ack":true,"ts":1646059195180,"q":0,"from":"system.adapter.mqtt.2","user":"system.user.admin","lc":1646059195180}
Re: MQTT Protokoll hält sich nicht an Standard.
Verfasst: Mo Feb 28, 2022 2:55 pm
von Andi
openWB hat geschrieben: ↑Mo Feb 28, 2022 1:31 pm
Werte kommen als Zahl (number), ebenso Fehler states (analog zu Exit Codes).
Hingegen kommen "Meldungen" natürlich als string.
Es ist also weniger ein Chaos sondern eher je nach Typ entsprechend.
Puh, das finde ich aber auch schräg... In jeder Programmiersprache wird zw. String und Integer Datentypen sauber unterschieden und sauber definiert...
Dann gehören hier m.E. wirklich zwei MQTT Botschaften definiert, für jeden "Typ" eine... Wie soll man denn auf der Gegenseite da sonst raten was grad als nächstes kommt?
Re: MQTT Protokoll hält sich nicht an Standard.
Verfasst: Mo Feb 28, 2022 3:46 pm
von openWB
Fault State / faultMsg sind doch getrennte Topics!?
Re: MQTT Protokoll hält sich nicht an Standard.
Verfasst: Mo Feb 28, 2022 3:55 pm
von derNeueDet
Ok, aber wenn du dir den Ausschnitt oben anschaust, liefert das Topic soCFaultState einmal einen leeren String und einmal die Zahl 0.
Re: MQTT Protokoll hält sich nicht an Standard.
Verfasst: Mo Feb 28, 2022 4:09 pm
von derNeueDet
d-dl hat geschrieben: ↑Mo Feb 28, 2022 2:44 pm
Ist mir auch schon aufgefallen, wobei ich das in meinem Setup beim "socFaultState" habe.
Hier der Input, der von der openwb geschickt wird - beides mal der selbe Datenpunkt openWB.set.lp.1.socFaultState.
Einmal value 0 (number), dann value "" (string):
Code: Alles auswählen
mqtt.2.openWB.set.lp.1.socFaultState: {"val":0,"ack":true,"ts":1646059195160,"q":0,"from":"system.adapter.mqtt.2","user":"system.user.admin","lc":1646059195160}
mqtt.2.openWB.set.lp.1.socFaultState: {"val":"","ack":true,"ts":1646059195180,"q":0,"from":"system.adapter.mqtt.2","user":"system.user.admin","lc":1646059195180}
Welches SoC Modul verwendest du denn bei dem LP1?
VG
Det
Re: MQTT Protokoll hält sich nicht an Standard.
Verfasst: Mo Feb 28, 2022 4:18 pm
von d-dl
derNeueDet hat geschrieben: ↑Mo Feb 28, 2022 4:09 pm
d-dl hat geschrieben: ↑Mo Feb 28, 2022 2:44 pm
Code: Alles auswählen
mqtt.2.openWB.set.lp.1.socFaultState: {"val":0,"ack":true,"ts":1646059195160,"q":0,"from":"system.adapter.mqtt.2","user":"system.user.admin","lc":1646059195160}
mqtt.2.openWB.set.lp.1.socFaultState: {"val":"","ack":true,"ts":1646059195180,"q":0,"from":"system.adapter.mqtt.2","user":"system.user.admin","lc":1646059195180}
Welches SoC Modul verwendest du denn bei dem LP1?
MQTT, der SoC wird über "openWB/set/lp/1/%Soc" gepusht. Das MQTT Log sagt
Code: Alles auswählen
2022-02-28 16:49:45 Topic: openWB/set/lp/1/socFaultStr Message: Kein Fehler
2022-02-28 16:49:45 Topic: openWB/set/lp/1/socFaultState Message: 0
Re: MQTT Protokoll hält sich nicht an Standard.
Verfasst: Mo Feb 28, 2022 4:32 pm
von derNeueDet
JB_Sullivan hat geschrieben: ↑Mo Feb 28, 2022 1:18 pm
Ich hatte es in einem anderen Thread ja schonmal angemerkt, das dass übertragene MQTT Protokoll sich scheinbar nicht an den Standard hält.
------------ Hier nochmal der Beitrag, der möglicherweise untergegangen ist, da dieser dem falschen Topic zugeordnet war ----------------------
Ich lasse mir die Datenpunkte von openWB via MQTT an ioBroker übergeben. In ioBroker sorgt dieses über den dortigen MQTT Adapter aber regemäßig für massenhaft Fehlermeldungen. Funktionieren tut aber trotzdem alles.
Die ioBroker Entwickler sind der Meinung, das es daran liegt, wie die Daten rein kommen - also von openWB gesendet werden.
Ist das etwas was auf openWB Seite heilbar ist?
Antwort eines ioB ENtwickler:
Aahhh es geht um die Typ-Warnungen? Ja, die kommen vor, wenn die gegenstelle keinen einheitlichen Datentyp sendet
Hier kommen scheinbar mal Strings und mal Zahlen und damit entsteht ein chaos
Hier mal ein kleiner Beispiel Ausschnitt.
Code: Alles auswählen
mqtt.2 | 2022-02-25 10:11:34.102 | info | State value to set for "mqtt.2.openWB.set.evu.faultState" has to be type "number" but received type "string"
mqtt.2 | 2022-02-25 10:11:32.900 | info | State value to set for "mqtt.2.openWB.set.houseBattery.faultState" has to be type "string" but received type "number"
mqtt.2 | 2022-02-25 10:11:32.801 | info | State value to set for "mqtt.2.openWB.set.pv.1.faultState" has to be type "string" but received type "number"
mqtt.2 | 2022-02-25 10:11:14.477 | info | State value to set for "mqtt.2.openWB.set.lp.1.socFaultState" has to be type "string" but received type "number"
mqtt.2 | 2022-02-25 10:11:14.395 | info | State value to set for "mqtt.2.openWB.set.evu.faultState" has to be type "number" but received type "string"
mqtt.2 | 2022-02-25 10:11:13.340 | info | State value to set for "mqtt.2.openWB.set.houseBattery.faultState" has to be type "string" but received type "number"
mqtt.2 | 2022-02-25 10:11:13.184 | info | State value to set for "mqtt.2.openWB.set.pv.1.faultState" has to be type "string" but received type "number"
mqtt.2 | 2022-02-25 10:10:54.409 | info | State value to set for "mqtt.2.openWB.set.lp.1.socFaultState" has to be type "string" but received type "number"
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Mit einem DEBUG Log in ioBroker konnte der Entwickler des dortigen MQTT Adapter dieses nun bestätigen.
Ja seht mal sehr schön das sich das gerät nicht einig ist was es senden will ... wtf
Code: Alles auswählen
2022-02-28 11:16:04.182 - [34mdebug[39m: mqtt.2 (8416) stateChange mqtt.2.openWB.set.houseBattery.faultState: {"val":0,"ack":true,"ts":1646043364179,"q":0,"from":"system.adapter.mqtt.2","user":"system.user.admin","lc":1646043364179}
2022-02-28 11:16:04.226 - [34mdebug[39m: mqtt.2 (8416) stateChange mqtt.2.openWB.set.houseBattery.faultState: {"val":"","ack":true,"ts":1646043364223,"q":0,"from":"system.adapter.mqtt.2","user":"system.user.admin","lc":1646043364223}
Innerhalb von 24ms zwei Datentypen ... heul ...
Darum noch einmal die Frage - ist das etwas was auf Seite von openWB abgestellt werden kann, oder muss ich mit dem Ergebnis auf ioBroker Seite damit leben?
Bringst du deine Werte die Probleme machen auch per MQTT in die openWB?
Ich hab vorher mal mit MQTT Explorer den soCFaultState meines EQ Soc Moduls beobachtet. Da ist in der History nur der Wert 0 drin, sonst nix.
VG
Det
Re: MQTT Protokoll hält sich nicht an Standard.
Verfasst: Mo Feb 28, 2022 5:58 pm
von LutzB
Der leere String wird bei allen Set-Topics genutzt, um die als retained gesendete Nachricht zu löschen. So kann es schon sein, dass einmal eine Zahl und danach das "Nichts" als String interpretiert werden kann.
Das noch in 1.9 anders zu handhaben, verursacht reichlich Nebenwirkungen und Inkonsistenzen. In 2.0 werden alle Topics mit JSON Daten gesendet, sodass das Problem dort nicht auftreten sollte.