Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[homecineplexx]

@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

[Codierknecht]

@homecineplexx sagte in Parse of � not possible:

weil ich nicht weiß welches Device das gerade war

Steht ja drin

DVES_655B31

[homecineplexx]

@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:

[crunchip]

@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

[homecineplexx]

@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

[crunchip]

@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

[PapaSpike]

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

[OliverIO]

@papaspike

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

daher 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

[Codierknecht]

@oliverio

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.

[PapaSpike]

@codierknecht Danke bin ich auch der Meinung.

[PapaSpike]

@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 ;-)