MQTT Protokoll hält sich nicht an Standard.

[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?

[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.

[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}

[Andi]

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?

[openWB]

Fault State / faultMsg sind doch getrennte Topics!?

[derNeueDet]

Ok, aber wenn du dir den Ausschnitt oben anschaust, liefert das Topic soCFaultState einmal einen leeren String und einmal die Zahl 0.

[derNeueDet]

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

[d-dl]

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

[derNeueDet]

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

[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.