Parse of � not possible
-
https://en.wikipedia.org/wiki/Specials_(Unicode_block)
Da wird offenbar etwas verwendet, was sich nicht sauber darstellen bzw. per MQTT übertragen lässt.
Taucht sowas dann im JSON auf, lässt sich das (logischerweise) nicht mehr parsen.Was sind das für Geräte?
Beim zweiten vielleicht ein ESP für den Stromzähler? Wie sieht da das SML aus? -
@codierknecht sagte in Parse of � not possible:
was sich nicht sauber darstellen bzw. per MQTT übertragen lässt.
MQTT ist erstmal egal was übertragen wird. Das sind einfach nur Binärdaten für das Protokoll. Der Sonoff-Adapter macht aus allem UTF8:
Also muss das Problem eher bei Tasmota liegen. Wie sind denn da die Topics konfiguriert und welche Tasmota-Version läuft da? Selbst gebaut oder fertiges Image?
Hier wurde ein ähnliches Thema diskutiert: https://github.com/arendst/Tasmota/discussions/15970
-
@codierknecht also ja, das eine ist ein ESP32 der ESPAltherma drauf hat, für meine Wärmepumpe und das andere ist ein Sonoff Pow mit Tasmota.
Es kommt ja auch nicht immer...das kommt alle heiligen Zeiten Mal
Also das sind natürlich fertige Images. Welche ist jetzt die Frage, das lässt sich aus dem Log nicht sagen, weil ich nicht weiß welches Device das gerade war
-
Dann zeig mal, wie das in Tasmota aussieht.
@haus-automatisierung sagte in Parse of � not possible:
Wie sind denn da die Topics konfiguriert und welche Tasmota-Version läuft da?
-
@homecineplexx sagte in Parse of � not possible:
Es kommt ja auch nicht immer...das kommt alle heiligen Zeiten Mal
Laut Diskussion auf GitHub kann das passieren, wenn die Last auf den ESP8266 zu hoch wird. TasmoAdmin fragt z.B. wohl alle paar Sekunden den Status ab und das mögen die wohl nicht.
-
@Codierknecht
Übrigens so sieht das dann im Log direkt am ioBroker aus:2024-02-21 09:53:53.124 - ESC[33mwarnESC[39m: sonoff.0 (104658) Cannot parse data "SENSOR": _{"Time":"2024-02-21T09:53:31","ENERGY":{"TotalStartTime":"2020-12-27T18:58:12","Total":0.058,"Yesterday":0.000,"Today":0.000,"Period":0,"Power":0,"Apparent0<EF><BF><BD>^B^@^Vtele/DVES_655B31/STATE0<EF><BF><BD>^B^@^Vtele/DVES_655B31/STATE{"Time":"2024-02-2_ - SyntaxError: Unexpected token ^B in JSON at position 157 -
@homecineplexx sagte in Parse of � not possible:
weil ich nicht weiß welches Device das gerade war
Steht ja drin
DVES_655B31 -
@codierknecht sorry, vor lauter Fehlermeldung hab ich das nicht gesehen.
so schauen die Topics aus. Ist eigentlich standard, da ich nichts in die Richtung geändert habe:
-
@haus-automatisierung sagte in Parse of � not possible:
Also muss das Problem eher bei Tasmota liegen.
also ich habe das auch hin und wieder und das passiert wenn das Gerät nicht online/erreichbar ist
-
@crunchip said in Parse of � not possible:
ch hin und wieder und das passiert wenn das Gerät nicht online/erreichbar ist
das versteh ich nicht, denn wenns nicht Online ist, schickt es ja auch keine Daten
-
@homecineplexx hier ein Beispiel von mir
2024-02-18 10:58:30.941 - warn: sonoff.0 (1491007) Cannot parse data "SENSOR": _{"Time":"2024-02-18T10:58:14","ENERGY":{"TotalStartTime":"2023-12-21T23:19:40","Total":44.983,"Yesterday":0.000,"Today":0.000,"Period":0,"Power":0,"ApparentPowe0�tele/tasmota/STATE{"Time":"2024-02-18T10:58:24","Uptime":"58T13_ - SyntaxError: Unexpected token in JSON at position 162
da hat scheinbar das Gerät mal die Verbindung verloren
Gerät ist aber auch aktuell über den Winter gar nicht an -
Ich hatte das gleiche Problem und dazu im Git für den mqtt Adapter mal angefragt ob man das nicht filtern könnte, weil es mir auch das Log voll gemacht hat. Hatte dafür extra vom Sonoff zum mqtt gewechselt.
https://github.com/ioBroker/ioBroker.mqtt/issues/353
Lösung war: Stell sicher das der Client die richtigen Daten schickt
Da ich die Daten im JS Adapter weiterverarbeite, hab ich mich dazu entschieden den String danach abzuschneiden und lesbar wiederherzustellen. Seit dem hab ich nur noch den Fehler im MQTT...
if (typeof strStateValue === 'string') { // Findet die Position des ersten nicht druckbaren Zeichens const indexOfNonPrintable = strStateValue.search(/[^\x20-\x7E]/); // Findet das letzte Komma vor dem nicht druckbaren Zeichen, falls vorhanden const lastCommaIndex = indexOfNonPrintable >= 0 ? strStateValue.lastIndexOf(',', indexOfNonPrintable) : -1; // Entfernt den Teil des Strings nach dem nicht druckbaren Zeichen und stellt den JSON-String wieder her if (lastCommaIndex >= 0) { strStateValue = strStateValue.substring(0, lastCommaIndex) + '}'; }Geht bestimmt eleganter, war für ich aber die einfachste Lösung am Ende. Vlt hilft dir das ja.
Beste Grüße
-
das will message feld hat keine formatvorgabe.
daher würde ich da nur binär voraussetzen.
https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.htmldaher wäre es schon erlaubt da auch nicht druckbare zeichen zu senden.
wenn da von einem gerät nur ein bestimmtes format erwartet wird, dann muss das der eigene code abfangen, bevor da angefangen wird irgendwas zur parsen. alternativ eine try/catch klammer drum rum machen, mit einer entsprechenden protokollausgabe bei catch -
Das hat Matthias ja auch schon so geschrieben.
@haus-automatisierung sagte in Parse of � not possible:
Das sind einfach nur Binärdaten für das Protokoll
Ich würde dann auch eher dazu plädieren, das auf der ioBroker-Seite beim Parsen entsprechend zu berücksichtigen.
Wenn da außer JSON auch mal etwas anders kommen könnte, muss das entweder berücksichtigt oder durch eine geeignete Fehlerbehandlung abgefangen werden.Wenn Binärdaten da im Protokoll zulässig sind, darf man halt nicht einfach davon ausgehen, dass auch immer ein korrektes JSON kommt.
-
@codierknecht Danke bin ich auch der Meinung.
-
@oliverio Ich hab es am Ende ja auch bei mir berücksichtigt. Wäre dennoch eleganter aus meiner Sicht im MQTT Adapter zu sagen, verwerfe solche Nachrichten oder bearbeite solche Nachrichten aber dann ohne Fehlermeldung oder oder gibt ja mehre Möglichkeiten wie man mit sowas umgehen könnte.
Natürlich wäre es besser das der Absender es richtig macht, aber wo ist das halt garantiert
