Der neue Monatsrückblick für Mai und Juni 2026 ist online!

[Michael Schmitt]

@vowill werden dir den in der GUI die Scripte angezeigt ?

du kannst unten auf

• in Zwischenablage - kopiert den code der unten steht in die Zwischenablage
• Alle exportieren - hiermit werden alle gefundenen Scripte exportiert
• Ausgewählte exportieren - die Scripte die blau unterlegt sind werden exportiert

[vowill]

@michael-schmitt Danke für deine schnelle Rückmeldung. Vermutlich läuft bei mir das Programm nicht richtig: Es legt nur die schon genannte Datei 'temp_backup.tar' an, ohne dass sich ein Fenster öffnet. Vielleicht braucht das exe noch irgendwelche Zugriffsrechte ...

[Michael Schmitt]

du hast aber die zb "javascript_2026_08_09-03_37_10_backupiobroker.tar.gz" auf deinem PC. wenn die Dateien angelegt werden sollte das Programm auch laufen. Ist kein Symbol in der Taskleiste ?

[Shadowhunter23]

@Michael-Schmitt
Mit welcher KI baust du das Tool?

[Michael Schmitt]

Teilweise Gemini und ChatGPT

EDIT: es ist jeder Willkommen die Idee weiter zu spinnen und zu verbessern. Ich mach das nur aus Spaß an der Freude und aus der Not das ein oder andere mal ein Script zerschossen zu haben. Also Leute mit bezahlter Ki zaubern da sicher was besseres ;)

Für mich reichts

[vowill]

@Michael-Schmitt sagte:

du hast aber die zb "iobroker_2026_08_09-03_37_10_backupiobroker.tar.gz" auf deinem PC. wenn die Dateien angelegt werden sollte das Programm auch laufen. Ist kein Symbol in der Taskleiste ?

Ja, Backup-File ist auf dem PC im gleichen Directory. Beim Starten des .exe mosert erst Windows (11) wg. unbekannter App; nach dem Start öffnet sich das Fenster zur Dateiauswahl. Nach der Auswahl wird die o.g. Datei 'temp_backup.tar' angelegt und das Programm beendet sich. Die ganze Zeit erscheint kein Programmsymbol in der Taskleiste.

Nachtrag: Wenn ich das ps1 anlege und es in PowerShell öffne, kommt die Fehlermeldung

• CategoryInfo: Sicherheitsfehler: (:) [], PSSecurityException
• FullyQualifiedErrorId : UnauthorizedAccess

Noch ein Nachtrag: In PS musste ich die Ausführungsrichtlinie ändern (auf 'Bypass' oder 'Unrestricted'). Dann läuft das Skript los.
Allerdings findet er in meinem Backup-File keine Datei script.json (die habe ich nach dem Entpacken auch nicht gefunden). Meine Skripte liegen im Backup wohl alle in der Datei "opjects.jsonl"

[Nashra]

@michael-schmitt
habe die exe mal gestartet, funktioniert bei mir.
Gut gemacht

[Michael Schmitt]

Sry hab ich falsch geschrieben, du must die Backup Datei nehmen die mit Javascript beginnt

[Shadowhunter23]

@Michael-Schmitt sagte:

EDIT: es ist jeder Willkommen die Idee weiter zu spinnen und zu verbessern.

Ebenso ein Spaß Projekt:

Die exe Datei:
https://drive.google.com/file/d/1Jug1z98lpoxkRgWG7Jp-BQdsnhLoAw-F/view?usp=sharing

Und das Zip mit einzelnen Dateien:
https://drive.google.com/file/d/1EsFg0gmovrbbDVi_8BtJi7c6_r3tVMph/view?usp=sharing

Was es kann:

Spoiler

**Übersicht** — Backup-Datum, Objekt- und State-Zahlen, alle Adapter-Instanzen mit Version,
Aktivierungsstatus und Anzahl zugehöriger Objekte.

**Skripte** — alle Skripte mit Typ und Status. Suche wahlweise nach Name/Pfad oder **im
Code**, wobei auch das dekodierte Blockly-XML durchsucht wird. Genau damit beantwortet sich
die Ausgangsfrage: Man gibt eine Datenpunkt-ID ein und bekommt die Skripte, die sie
tatsächlich verwenden — auch die Blockly-Skripte, wo die ID im generierten JavaScript
teilweise anders aussieht. Export legt die ioBroker-Ordnerstruktur an, Blockly wird als
`.xml` **und** als bereinigtes `.js` geschrieben, deaktivierte Skripte landen in einem
eigenen Unterordner.

**VIS-Datenpunkte** — alle in der Visualisierung verwendeten Datenpunkte, getrennt nach
VIS 1 und VIS 2, mit View, Widget-ID, Widget-Typ und dem Feld, in dem der Datenpunkt steckt
(`oid` = angezeigter Wert, `visibility-oid` = Sichtbarkeit usw.). Aliasse werden mit ihrem
Ziel aufgelöst. Ein eigener Filter zeigt **tote Widgets**: Datenpunkte, die im Backup gar
nicht mehr existieren, auf die eine View aber weiterhin zeigt.

**Verwaiste Datenpunkte** — drei Analysen:

- *A: Objekt-Leichen* — Objekte, deren Adapter-Instanz im Backup fehlt.
- *B: unbenutzte User-Datenpunkte* — geprüft werden Vorkommen in Skripten, Vorkommen in
 VIS-Views, Alias-Ziel und aktives Logging. Zusätzlich wird die letzte Wertänderung aus
 der `states.jsonl` angezeigt.
- *C: States* — fünf Sichten auf die States-Datenbank: Werte ohne Objekt, Objekte ohne
 Wert, älteste Datenpunkte, Störungen (Qualitätscode) und nicht quittierte Befehle.

**Vergleich zweier Backups** — die Antwort auf „gestern lief es noch". Zeigt geänderte
Adapter-Versionen (Downgrades werden hervorgehoben), neu angelegte und gelöschte Objekte
nach Namensraum, geänderte VIS-Views und vor allem **inhaltlich geänderte Skripte mit
zeilengenauem Vergleich** — bei Blockly wird das XML verglichen, nicht das daraus erzeugte
JavaScript. Zusätzlich wird geprüft, ob beide Backups überhaupt aus derselben Installation
stammen (dazu unten mehr).

---

## Was ich beim Bauen über das Backup-Format gelernt habe

Das ist vermutlich der für die Allgemeinheit interessantere Teil.

**1. Es gibt keine `backup.json` mehr.** Aktuelles Backitup schreibt `objects.jsonl` und
`states.jsonl` im JSON-Lines-Format — eine Zeile pro Datensatz, kein umschließendes
JSON-Objekt. Die Objekt-ID steht dabei im Feld `_id` innerhalb der Zeile, nicht als
Schlüssel. Nebeneffekt: Man kann die Datei zeilenweise lesen, der Speicherbedarf ist von
der Dateigröße unabhängig. Ein Voll-Backup mit rund 25 MB `objects.jsonl` ist bei mir in
gut einer Sekunde ausgewertet.

**2. Blockly-XML braucht zwingend eine URL-Dekodierung.** Das XML hängt als Base64-Kommentar
am Ende des `source`-Strings. Base64 dekodieren allein reicht nicht — das Ergebnis ist
zusätzlich URL-kodiert. Erst danach beginnt es mit `<xml`. Ich habe das gegen einen echten
Export aus dem Admin geprüft: nach Normalisierung zeichengenau identisch.

**3. `states.jsonl` ist die einzige Stelle, die etwas über die tatsächliche Nutzung sagt.**
Alles andere im Backup sagt nur, dass ein Datenpunkt *existiert*. In der `states.jsonl`
steht dagegen pro Wert der Zeitpunkt der letzten echten Wertänderung (`lc`), wer geschrieben
hat (`from`), der Qualitätscode und das Ack-Flag. Der Wert selbst (`val`) ist unbrauchbar
und sollte gar nicht erst geladen werden — bei mir steckt in einem Datenpunkt ein komplettes
Kamera-JPEG als String.

Das hat den größten praktischen Effekt gehabt: Meine Verwaisten-Analyse meldete 18
Kandidaten. Mit den Zeitstempeln bleibt davon genau **einer** als wirklich toter Datenpunkt
übrig — die anderen 17 hatten sich am Backup-Tag noch geändert. Es waren Datenpunkte, deren
IDs ein Skript zur Laufzeit zusammensetzt, weshalb keine Textsuche der Welt sie findet. Wer
also anhand von „kommt in keinem Skript vor" aufräumt, löscht munter lebende Datenpunkte.

**4. ioBroker-IDs sind case-sensitiv — und das ist praxisrelevant.** In meinem Bestand gibt
es drei ID-Paare, die sich ausschließlich in der Groß-/Kleinschreibung unterscheiden; für
ioBroker sind das verschiedene Objekte, in Wahrheit sind es Tippfehler-Dubletten.

Deutlicher noch bei den Werte-Leichen: Der alexa2-Adapter hat irgendwann von
`echo-devices` auf `Echo-Devices` umgestellt. In meiner States-Datenbank liegen dadurch bis
heute 110 Werte unter der alten Schreibweise — Objekte gibt es dazu null, Werte aber
weiterhin, mit Zeitstempeln von 2018. Insgesamt sind bei mir **994 Werte ohne zugehöriges
Objekt** in der Datenbank, überwiegend von Adaptern, die ich längst nicht mehr betreibe.
Im Admin sieht man davon nichts, weil dort der Objektbaum angezeigt wird — und ein Objekt
existiert ja gerade nicht.

**5. Jedes Voll-Backup trägt eine eindeutige Installations-ID.** In `system.meta.uuid`
steht eine UUID, die bei der Erstinstallation vergeben wird — meine stammt von 2018 und ist
seither unverändert. Damit lässt sich hart prüfen, ob zwei Backups überhaupt zusammengehören.
Der Hostname taugt dafür nur bedingt: Backitup ersetzt ihn im Backup durch
`$$__hostname__$$`; der echte Name steckt dann nur noch im `from`-Feld des Host-Objekts.

**6. VIS-Views liegen als ganz normales JSON im Voll-Backup**
(`files/vis*/main/vis-views.json`). Die Datenpunkte stecken in den `data`-Objekten der
Widgets, und zwar in jedem Feld, dessen Name `oid` enthält, plus in Bindings der Form
`{id;format}` in beliebigen Textfeldern. Wichtig dabei: Ein Binding kann statt des Werts ein
Zustandsattribut lesen — `{irgendeine.id.ts;date(hh:mm)}` greift auf den Zeitstempel von
`irgendeine.id` zu. Wer das `.ts` naiv als Teil der ID nimmt, meldet einen nicht
existierenden Datenpunkt.

---

## Kennzahlen aus der Praxis

Damit man eine Vorstellung von der Größenordnung bekommt — mein System:
16.689 Objekte, 14.603 States, 64 Adapter-Instanzen, 193 Skripte (159 Blockly, 34
JavaScript). Ein Voll-Backup mit 17,7 MB gepackt ist in gut einer Sekunde vollständig
eingelesen und ausgewertet.

---

## Grenzen, ganz offen

- Die Verwaisten-Analysen sind **Prüflisten, keine Löschlisten**. Nutzung durch externe
 Systeme (MQTT-Clients, Grafana, Apps) ist in einem Backup grundsätzlich nicht erkennbar,
 und zur Laufzeit zusammengesetzte IDs nur eingeschränkt.
- Redis-, InfluxDB- und Zigbee-Teilbackups werden nicht ausgewertet.
- Adapter-Konfigurationen (`native`) werden bewusst nirgends angezeigt — da stehen
 Zugangsdaten drin.
- Getestet ist es bisher gegen meine eigenen Backups. Andere Backitup-Versionen und
 ältere Formate sind zwar berücksichtigt, aber nicht mit echten Daten geprüft.

---

## Technisches

C# / .NET 8, WinForms, keine Fremdbibliotheken. Läuft als portable Anwendung ohne
installiertes .NET.

Drei Hinweise, bevor jemand loslegt

Löscht nichts allein aufgrund einer Liste. Das Werkzeug liest nur und kann an eurem System nichts kaputtmachen — gefährlich wird erst, was man mit den Ergebnissen anstellt. Eine Analyse, die sagt „kommt in keinem Skript und keiner View vor", beweist nicht, dass ein Datenpunkt unbenutzt ist. Bei mir waren 17 von 18 solcher Kandidaten quicklebendig, weil ein Skript ihre IDs zur Laufzeit zusammensetzt. Im laufenden System gegenprüfen, und im Zweifel den Datenpunkt erst mal ein paar Wochen beobachten statt löschen.

Ein ioBroker-Backup enthält Zugangsdaten. Im Klartext, in den native-Abschnitten der Adapter-Instanzen: MQTT-Passwörter, API-Schlüssel, Cloud-Logins, dazu der Schlüssel, mit dem ioBroker gespeicherte Passwörter verschlüsselt. Schickt euer Backup also nicht zum „schau doch mal drüber" durch die Gegend und ladet es nirgends hoch. Aus demselben Grund lohnt vor einem Screenshot ein Blick darauf, was gerade in der Tabelle steht.

Es ist ein privat gebautes Werkzeug, keine geprüfte Software. Ich gebe es ohne Gewährleistung weiter und übernehme keine Haftung für Schäden, die aus seiner Nutzung entstehen. Fehler meldet ihr am besten hier im Thread — mit der Backitup-Version und der Stelle, an der es hakt.

Version aktuell: 1.2.4

[Michael Schmitt]

Nice, muss ich mir gleich nach der Arbeit anschauen. @shadowhunter23 .....