Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Javascript Datenpunkte (states und values) sichern #1179

Closed
ntfrnd opened this issue Oct 29, 2024 · 14 comments
Closed

Javascript Datenpunkte (states und values) sichern #1179

ntfrnd opened this issue Oct 29, 2024 · 14 comments

Comments

@ntfrnd
Copy link

ntfrnd commented Oct 29, 2024

Im Backitup-Adapter 3.0.25 gibt es die Sicherungs-Option "Javascript". Offenbar werden damit die Skripte gesichert, aber nicht die in den Skripten erstellten Datenpunkt. Diese liegen standardmäßig unter Javascript.0.xxx
Die darin enthaltenen States samt deren Values werden nicht gesichert. Damit ist nach einem Backup alles weg.
Besonders bei errechneten Werten (z.B. Verbrauchswerte) wäre es sehr hilfreich, diese ebenfalls zu sichern.
In der iobroker-Objektansicht kann man den Objektbaum als json-Datei speichern. Importiert man diesen wieder, so sind alle States und Values wieder da. Das hätte ich von einem Backup auch erwartet.
Besteht die Möglichkeit, dies in das Javascript-Backup mit aufzunehmen?

Copy link

Thanks for reporting a new issue @ntfrnd!

  1. Please make sure your topic is not covered in the German documentation or English documentation
  2. Please attach all necessary log files (in debug mode!), screenshots and other information to reproduce this issue
  3. Search for the issue topic in other/closed issues to avoid duplicates!
  4. Ensure that you use the latest available beta version of this adapter (not the current stable version): 3.0.26

Otherwise this issue will be closed.

@simatec
Copy link
Owner

simatec commented Oct 29, 2024

Alle States werden im iobroker Backup gesichert.
Allerdings wird dringend abgeraten, in javascript.x eigene states anzulegen. Dafür gibt es den Bereich userData

@simatec simatec closed this as completed Nov 1, 2024
@ntfrnd
Copy link
Author

ntfrnd commented Nov 1, 2024

@simatec Danke für den Hinweis, habe die Skripte nun in 0_userdata abgelegt. Anfangs war wohl beim Anlegen von Datenpunkten mittels Blockly der Pfad auf javascript.0. hinterlegt - wenn man nur einen Namen eingibt. Aktuell ist dort "0_userdata.0.example" hinterlegt, damit wird es deutlich.
Allerdings behebt das mein Problem noch nicht - oder ich verstehe es einfach nciht.
Wenn ich in Backitup als Backup "ioBroker" und "JavaSkript" anhake, erhalte ich zwei Backup-Files: javascripts_xxxx und iobroker_xxx.
Im javascript-File ist ein script.json enthalten, im iobroker gibt es ein sehr großes Backup.json und eine Ordnerstruktur, die die Verzeichnisstruktur abbildet...vis...web.0...admin...0_userdata...usw. Allerdings sind die Ordner leer.
Wo sollten die 0_userdata-States gesichert sein?

@simatec
Copy link
Owner

simatec commented Nov 1, 2024

In der Backup.json sind alle States.
Auch alle Skripte befinden sich darin.
Die zusätzliche Option des Backups von Skripten dient nur zur schnellen Wiederherstellung von Skripten, wenn man mal was versehentlich gelöscht hat oder einen Skript vermurkst hat

@ntfrnd
Copy link
Author

ntfrnd commented Nov 2, 2024

Vielen Dank für die gute Erklärung.
Besteht die Möglichkeit in einer zukünftigen Version die States auch in einer separaten Datei zur Verfügung zu stellen? Damit wäre auch ein schnelles Wiederherstellen möglich.

@simatec
Copy link
Owner

simatec commented Nov 3, 2024

Ein schnelles wiederherstellen ist doch möglich... Nochmal kurz erklärt... Die Option für "Javascript" sichert die Skripte, wo oft viel Zeit und Arbeit drin stecken.
Das ioBroker Backup sichert unter anderem alle States.

Wenn du nun spezielle States mit in deinen Skripten nutzt und diese dafür erzeugst, dann mache dass doch auch in Javascript oder Blockly. Wenn dann ein State wirklich mal fehlen sollte, was für mich eigentlich nicht möglich sein sollte ohne ein händisches löschen, dann wird dieser beim Start des Skriptes automatisch erzeugt.

Also dein Issue ergibt was States angeht leider keinen Sinn und es wir hierzu auch keine Änderungen am Backup geben

@mcm1957
Copy link
Contributor

mcm1957 commented Nov 3, 2024

Ich bin nicht sicher ob es dem OP um die States oder um die Values der States geht. Immerhins chreibt er:

Die darin enthaltenen States samt deren Values werden nicht gesichert. Damit ist nach einem Backup alles weg.

Mit Backup kann eigentlich nur ein Backup Restore gemeint sein. Und da sollte ioBroker Backup ja die States wieder herstellen. Ob das ioBroker Backup auch die WERTE (values) sichert weiß ich nicht. Das wäre dann aber ein Fall für ein Issue beim js-controller.

@simatec
Copy link
Owner

simatec commented Nov 3, 2024

Das Backup von iobroker sichert auch die Werte der States

@mcm1957
Copy link
Contributor

mcm1957 commented Nov 3, 2024

OK - dann sollte alles passen. Oder es liegt ein Bug vor.

@ntfrnd
Copy link
Author

ntfrnd commented Nov 5, 2024

Mir ging es tatsächlich um die States und Values in 0_userdata.
Wenn diese im kompletten Backup enthalten ist, passt ja alles.

Mir ging es darum -ähnlich wie bei der separaten script.json- auch eine separate userdata.json zu erzeugen. Damit könnte man sehr schnell diese wiederherzustellen ohne das große Backup drüberzubügeln.
Vor allem wenn man beim Erstellen der Skripte einen Fehler macht oder nicht alles auf Anhieb funktioniert, kann es schnell vorkommen, dass in den 0_userdata etwas verhunzt wird.
Und da wäre ein separates userdata.json - Backup sehr hilfreich.
Das waren meine Gedanken....

@ntfrnd
Copy link
Author

ntfrnd commented Nov 13, 2024

Das Backup von iobroker sichert auch die Werte der States

Ich habe mir nun einen Datenpunkt gesucht, von dem ich gerne den Wert hätte. Abgesehen davon, dass es schon schwierig ist, ein 14 MB großes json-File zu öffnen, da die meisten Programme dabei abschmieren, sehe ich kein "val"-Tag und auch keinen Wert:

` {
"id": "0_userdata.0.Verbrauch.Wasserzähler_Zählerstand",
"value": {
"common": {
"type": "number",
"unit": "l",
"custom": {
"influxdb.0": {
"enabled": true,
"aliasId": "Wasserzaehler_Zaehlerstand",
"changesOnly": true,
"changesRelogInterval": 3600
}
},
"name": "0_userdata.0.Verbrauch.Wasserzähler_Zählerstand",
"role": "state"
},
"native": {

    },
    "type": "state",
    "from": "system.adapter.javascript.0",
    "user": "system.user.admin",
    "ts": 1730463819040,
    "_id": "0_userdata.0.Verbrauch.Wasserzähler_Zählerstand",
    "acl": {
      "object": 1636,
      "state": 1636,
      "owner": "system.user.admin",
      "ownerGroup": "system.group.administrator"
    }
  }
},`

Exportiere ich nun diese Variable direkt im ioBroker-Objektbaum, erhalte ich dieses json:

{ "0_userdata.0.Verbrauch.Wasserzähler_Zählerstand": { "common": { "type": "number", "unit": "l", "custom": { "influxdb.0": { "enabled": true, "aliasId": "Wasserzaehler_Zaehlerstand", "changesOnly": true, "changesRelogInterval": 3600 } }, "name": "0_userdata.0.Verbrauch.Wasserzähler_Zählerstand", "role": "state" }, "native": {}, "type": "state", "from": "system.adapter.javascript.0", "user": "system.user.admin", "ts": 1730463819040, "_id": "0_userdata.0.Verbrauch.Wasserzähler_Zählerstand", "acl": { "object": 1636, "state": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" }, "val": 8250, "ack": false } }

Mir scheint, der Wert geht irgendwo verloren.

P.S. Ich hatte json in Code-Tags gesetzt, scheint aber nicht zu klappen. Ich hoffe, es ist trotzdem lesbar.

@simatec
Copy link
Owner

simatec commented Nov 13, 2024

Du musst bei einem State nicht in dem Backup suchen... Sollte da wirklich etwas verloren gehen, führe einen Restore vom ioBroker durch.

@ntfrnd
Copy link
Author

ntfrnd commented Nov 13, 2024

Und woher sollte der Restore den Wert nehmen? Soweit ich verstanden habe, aus dem Backup, oder?

@simatec
Copy link
Owner

simatec commented Nov 13, 2024

richtig...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants