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

[Codierknecht]

@homecineplexx

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?

[haus-automatisierung]

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

https://github.com/ioBroker/ioBroker.sonoff/blob/1dca3ee4f916e372d4617766c46d623577a11bbe/lib/server.js#L1164-L1165

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

[homecineplexx]

@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

[Codierknecht]

@homecineplexx

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?

[haus-automatisierung]

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

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