MQTT Protokoll hält sich nicht an Standard.

[SkodaEnyaq]

Ich habe das gleiche Problem. Mein IO Broker Log ist komplett zu, sobald ich das Loglevel auf Info stelle.
Hat jemand einen Work araond gefunden?
Die Nightly FW wird hierzu nichts bringen, oder?

LG, Tim

[hhoefling]

Die Überschrift verwirrt.
Es gibt keinen Standart der den Type des MQTT-Payload definieren würde.
Der Inhalt des Payload wird nur durch die publishende Application festgelegt.
In diesem Falle betrachte einfach alle Topics als String und wandle nötigenfalls Str->Int um.

[schrej]

In 2.0 werden alle Topics mit JSON Daten gesendet, sodass das Problem dort nicht auftreten sollte.

Ob das im JSON kommt oder nicht, spielt keine Rolle.
Wenn du im JSON einmal "0" und einmal "" sendest, bekommst du den gleichen Fehler, wenn du das Payload Item als " Number" definierst. Das sollte also auch im JSON nicht passieren.
Jörg

[hominidae]

...ich finde die Diskussion hier nicht zielführend.
Das "Problem" im Titel ist keines von mqtt.
Der Umstiieg auf JSON in openWB 2.0 ändert da auch nix dran.
Auch der IOBroker hält sich da mMn nicht an Standards...nur an eine andere Konvention als openWB.

Aber Standards sind nicht immer dazu da, es allen Recht zu machen. Standards-Arbeit ist Lobby Arbeit und kostet viel Zeit=Geld.
In der Regel "gewinnt" Derjenige, der als Erster sein Produkt erfolgreich an den Markt bringt...man kann froh sein, wenn es überhaupt eine Beschreibung der Konventionen gibt.

mqtt ist also eine Sache, die Andere eben die Konvention, wie Daten über ein Transport-Protokoll hinweg in der Applikation beim Austausch normiert werden.
Dafür gibt es in der Tat Standards, zB https://homieiot.github.io/specification/
Woanders ist es IEC-61850 in der Elektotechnik....https://iec61850.dvl.iec.ch/

Ob in 1.9 oder 2.0, geht openWB da einen eigenen, pragmatischen Weg und das ist auch gut so.
IOBroker, als - wie der Name schon suggeriert - Integrator sollte da nicht als Standardskonvention interpretiert werden., sondern offen für unterschiedliche "Standardkonventionen" sein. Wenn es da zu "Problemen" kommt oder einen die Logs stören, dann ist es mMn dort zu fixen und nicht in der openWB.....wie gesagt, schon gar kein Problem von mqtt.

...my 2 cents.

[schrej]

Sorry,
Aber wenn ein Wert einmal als Number und einmal als String kommt ist das schon ein Problem der Implementierung in der OpenWB. Zu argumentieren, man solle danach halt bei sich Routinen implentieren, die das abfangen, ist nicht zielführend.
Jörg

[hhoefling]

Ok.
Dann definiere mal "Nichts" als Zahl.

[Gero]

Ok.
Dann definiere mal "Nichts" als Zahl.

Bei SQL-Datenbanken gibt es den Wert NULL. Der hat die Eigenschaft ungleich alles anderen zu sein. Da muss man immer explizit auf "is NULL" abfragen. Oder auch Excel's "N/A", was man auch explizit mit isna() abfragen muss. Eine Zahl die mal als "" kommt verhält sich da genauso.

[hhoefling]

@Gero, ist schon klar. ging eher an Schrej
PS:
der Parameter "payload" ist übrigens immer ein String, auch wenn der String aus Ziffern besteht und eine Zahl darstellt.

[Gero]

@Gero, ist schon klar. ging eher an Schrej

Schon klar, ich wollte nur anmerken, dass es in anderen Programmierumgebungen in der IT durchaus das Konzept eines zulässigen Variablenwerts gibt, der in sonst üblichen Operationen zu "Fehlern" führt. Eigentlich sind das ja keine, wenn man das Konzept verstanden hat. Genauso würde ich den leeren String an Stelle einer Zahl sehen: Ist halt kein Wert vorhanden. Muss man explizit abfragen, wenn man das wissen will und nicht einfach mit dem Wert drauflosrechnen, weil man davon ausgeht, dass der immer numerisch ist.

PS: Das mit dem Prüfen auf einen erwarteten Inhalt vor der Verarbeitung sollte sowieso gängige Praxis des Programmierens sein. Dann wären uns die allermeisten der heutzutage doch so gängigen Buffer-Overflows oder Remote Code Excecutions wohl erspart geblieben.

[schrej]

der Parameter "payload" ist übrigens immer ein String, auch wenn der String aus Ziffern besteht und eine Zahl darstellt.

Das ist absolut richtig. Aber mit der Argumentation müsste man jede Payload in MQTT nur als String auslesen.
Bei MQTT Announcements wird aber in der Regel z.B. der Typ und wenn vorhanden auch die Einheit mitgegeben.
Und eine Zahl ist nun mal eine Zahl. Und eine Zahl kennt keinen leeren Wert.
Ich muss also jetzt jeden Wert der OpenWB als String übernehmen und dann mit z.B. JavaScript analysieren, ob da ein leerer Wert kommt.
Das kann es doch wirklich nicht sein.

Jörg