Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Moppedman]

@capitaenz

Danke erst mal für die schnelle erste Antwort. Habe ich nicht mit gerechnet. Habe mir nun eine Sicherung erstellt und zusätzlich auch ein Image der SD Karte gemacht.

Bevor ich jetzt anfange zwei Verständisfragen.

Es gibt je eine "states.json.bak" bzw. "objects.jason.bak" in "iobroker-data" was meine Erachtens Sicherungsdateien sein sollten UND noch einen Unterordner "backup-objects" unter "iobroker-data" in dem noch weitere Kopien liegen. Kannst du mir erklären wie das ioBroker verwendet? Weist du aus welcher Datei er beim Start von mqtt seine objekte zieht? Habe Sorge das er ggf. die bak verwendet und von dort automatisch zurückspielt und die Arbeit umsonst wäre

Und die Zweite Frage

Ich habe kein zwei }} Klammer die einen Datensatz beenden. Würdest du zustimmen das der markierte Bereich einen Datensatz darstellt. Ich würde dann

1. mqtt im iobroker anhalten
2. Alle objekte im mqtt adapter löschen
3. iobroker in der shell stoppen
4. Datensatz in "objects.json" und parallel in "states.json" löschen
5. iobroker rebooten
6. schauen ob die datensätzen nun endlich weg sind.

Gruß Ralf

[capitaenz]

@Moppedman
Ich bin (auch nur) interessierter Anwender und kann leider keine weiteren technischen Infos liefern.
Aber ich würde auch annehmen, dass der von dir markierte Bereich gelöscht werden muss.
Schalte dich doch mit z.B. WinSCP drauf und lade dir die editierte Datei herunter, dann war die Arbeit nicht umsonst, wenn diese wiederhergestellt werden sollte.
Und denk dran, Backup, Backup, Backup!

[Moppedman]

@arteck

Darf ich dich mal bitten einen Blick auf meinen Fall zu werfen. Wie oben geschrieben habe ich durch mein Ausprobieren mit ESPEasy / Wemos D1 mini 8266 diverse Objekte als Restmüll in den MQTT Objekten stehen. Ich habe die beim Testen umbenannt und/oder die Daten die vom 8266 gepublished werden, geändert. Bei jeder Namesänderung z.B. wurde unter dem neuen Namen ein neues Objekt angelegt und nicht das alte Objekt überschrieben. Löschen hilft nicht, sie kommen wieder. Schaue ich in "states.json" und "objects.json" finde ich darin die alten und neuen Bezeichnungen. Gemeinsam haben die verschiedenen Namen die fest zugewiesene IP-Adresse vom Router.

Ich habe heute nun mal einen Sensor in beiden Dateien gelöscht der aber nach Starten des MQTT adapters wieder da war. Daher die Frage wie ioBroker mit den angelegten Datensicherungen "states.json.bak" und "objects.json.bak" umgeht. Bzw was ist mit den anderen Sicherungen in dem Ordner "/opt/iobroker/backup-objects". Welche Datei benutzt das System beim Start?

Ich habe folgendes gemacht.

1. mqtt im iobroker angehalten
2. Alle objekte im mqtt adapter gelöscht
3. iobroker in der shell gestoppt
4. Datensatz in "objects.json" und parallel in "states.json" gelöscht
5. iobroker reboot

Wie wäre die richtige Reihenfolge bzw. was fehlt das ich die Einträge endgültig gelöscht kriege.

Gruß und Dank

[apollon77]

DIe die diese Namensprobleme haben ... welche js.controller version ist im Einsatz?

[capitaenz]

@apollon77
Nutze Version 3.1.6

VG
Leif

[apollon77]

Ahhh ok, habs verstanden

[capitaenz]

@apollon77 Also den Fehler gefunden? Das würde mich echt freuen! :grinning:
Und übrigens: Danke, dass du dich dem Problem annimmst!

[apollon77]

@capitaenz Ne so wirklich gefunden wäre übertrieben ... aber am Ende ist klar was man ändern muss ... unerlaubte Zeichen müssen au den IDs raus ...

[hanss]

@apollon77
vielen Dank.
Ideal wäre natürlich, wenn solche unerwünschten Einträge erst gar nicht entstehen würden,
aber diese Ursache zu finden ist natürlich sehr schwierig.

[apollon77]

@hanss Zur Ursache: Wenn man es schafft das verhalten zu reproduzieren dann könnte man das mit einem Debug log dann mal dokumentieren

[capitaenz]

@apollon77 Wenn man jetzt genau wüsste, welches die unerlaubten Zeichen sind, dann könnte man doch veranlassen, z.B. ein Gerät mit Tasmota ein Objekt damit zu erstellen.
Was müsste dann genau geloggt werden? Den MQTT-Adapter auf Debug stellen würde reichen?

[hanss]

@capitaenz @apollon77
Ich meine, die Fehlervermeidung müsste weiter unten erfolgen, beim QOS, Prüfsumme, fehlerhafte MQTT Datenpakete erkennen usw..
Wenn MQTT mit fehlerhaften Datenpaketen weiter arbeitet, kann ja alles mögliche passieren, nicht nur diese unerwünschten Objekte.

Was bisher aufgefallen ist:
Diese verstümmelten Objekte hatten immer eine Ähnlichkeit mit bestehenden Objekten.
Evtl. auch Störungen im WLAN oder js.controller (hohe Auslastung, Speicher Überlauf etc.) als Ursache

[apollon77]

@hanss Es klingt auf jeden Fall danach das irgendwie "garbage" über die Leitung kommt ...

Ich würde also erstmal hingehen und versuchen solche IDs zu erkennen und zu ignorieren und das zu loggen. Dann sehen wir ob plötzlich was anderes nicht tut

[hanss]

@apollon77
Das sehe ich genauso, denn was ich bisher darüber gelesen habe, wird reproduzieren wahrscheinlich nicht möglich sein.

Ich habe gerade jetzt wieder einen Eintrag (in ein bestehendes MQTT Objekt) bemerkt, obwoh der
dafür zuständige Client nichts im Logbuch stehen hatte, daß er etwas weggeschrieben hätte.
Der Wert wurde wie üblich auch in der SQL Datenbank gespeichert und ist durchaus plausibel.
Dieses Mal ohne WiFi Störung, ohne JS Besonderheiten. im Client wurde ein Interrupt ausgelöst,
Eintrag war i.O.

[apollon77]

Naja am Ende müsste jemand der das Problem hat im texteditor mit so einem kaputten Objects File einfach mal schauen was das genau "Hex Code technisch" für ein zeichen ist :-)

[hanss]

mach ich gerne, wenn das wieder einmal auftritt.
In welcher Datei stehen denn die Zeichen, die Dich interessieren?

[apollon77]

@hanss In dem File was Du bearbeitestn kannst um es zu fixen ...

[capitaenz]

@apollon77 Also die "states.json" und "objects.json"?

[apollon77]

@capitaenz jupp

[capitaenz]

@apollon77 Da hatte ich ja bereits eine betroffene Stelle hochgeladen.