NEWS
[Skript] Namespace für Datenpunkte in Skripten abändern
-
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
Die dritte Option wäre gewesen, eine Kopie der objects.json zu nutzen, aber da muss man das System vorher stoppen um die Kopie zu ziehen, läuft aber sehr sauber
hört sich für mich ganz gut an - eine sichere methode - ich stoppe auch gerne das system dafür
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
Probiere das doch mal mit Bereinigung dieser beiden Ordner
werd ich
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
Evtl. sollte man aber ein issue zum Selektor aufmachen
kannst du gerne machen - es gibt überhaupt keinen time-stress . ob das in ein paar tagen oder später funktioniert ist mir nicht wichtig - nur : das es funktioniert :-)
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
das setzt natürlich immer einen Header vorraus
ist das der header?

@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
ist das der header?
ja, für das JSON Widget braucht es natürlich nur den Zweck, aber ein Datum schadet nie und wenn ich es veröffentliche weiss jeder gleich an wen er sich wenden kann. Mittlerweile habe ich auch oft eine Zeile Forum.
-
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
ist das der header?
ja, für das JSON Widget braucht es natürlich nur den Zweck, aber ein Datum schadet nie und wenn ich es veröffentliche weiss jeder gleich an wen er sich wenden kann. Mittlerweile habe ich auch oft eine Zeile Forum.
die warnings sind jetzt weg - nach dem löschen der script-enabled
nur noch der bekannte error


-
die warnings sind jetzt weg - nach dem löschen der script-enabled
nur noch der bekannte error


@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
nur noch der bekannte error
na mir ist der nicht bekannt :-) Evtl. hat ein Skript da keinen source. müsste man prüfen indem man im Selektor auf einen Ordner begrenzt oder auf ein Skript und sich in Zeile 38 den Namen anzeigen lässt
log(obj.common.name); -
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
nur noch der bekannte error
na mir ist der nicht bekannt :-) Evtl. hat ein Skript da keinen source. müsste man prüfen indem man im Selektor auf einen Ordner begrenzt oder auf ein Skript und sich in Zeile 38 den Namen anzeigen lässt
log(obj.common.name);@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
log(obj.common.name);
meinst du so ?

das waren 2 leere scripte :-( :-) kannst/willst du das abfangen ?
-
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
nur noch der bekannte error
na mir ist der nicht bekannt :-) Evtl. hat ein Skript da keinen source. müsste man prüfen indem man im Selektor auf einen Ordner begrenzt oder auf ein Skript und sich in Zeile 38 den Namen anzeigen lässt
log(obj.common.name); -
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
log(obj.common.name);
meinst du so ?

das waren 2 leere scripte :-( :-) kannst/willst du das abfangen ?
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
das waren 2 leere scripte kannst/willst du das abfangen ?
ja natürlich! Gibt immer wieder Dinge welche man nicht im Traum dran denkt dass sie passieren könnten :-)
-
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
leere scripte gelöscht - jetzt läuft es durch
wow! ich komme gerade mal auf 255, incl. alter Versionen :-)
-
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
log(obj.common.name);
meinst du so ?

das waren 2 leere scripte :-( :-) kannst/willst du das abfangen ?
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
kannst/willst du das abfangen ?
ändere in Zeile 36 zu
if(obj && obj.type === 'script' && obj.common.source){Der neue JS-Adapter erzeugt auch bei leeren Skripten einen obj.common.source, so dass mir das nicht aufgefallen ist. Erinnerst du dich was im Objekt gefehlt hatte? Ich habe zum Testen das source Attribut entfernt, bekam aber eine andere Fehlermeldung als du, so dass icht ganz sicher bin ob der Fehler gefixt ist, evtl. hat auch das kmpl. common bei dir gefehlt
-
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
leere scripte gelöscht - jetzt läuft es durch
wow! ich komme gerade mal auf 255, incl. alter Versionen :-)
@fastfoot
du willst die genaue zahl - dann hättest du das widget nicht limitieren sollen - es sind 746- da sind aber einige sonder-scripts für andere user
- und viele scripte, mit allen versionen bei der entwicklung
- viele still-gelegte
gehört wohl mal aufgeräumt :-)
-
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
kannst/willst du das abfangen ?
ändere in Zeile 36 zu
if(obj && obj.type === 'script' && obj.common.source){Der neue JS-Adapter erzeugt auch bei leeren Skripten einen obj.common.source, so dass mir das nicht aufgefallen ist. Erinnerst du dich was im Objekt gefehlt hatte? Ich habe zum Testen das source Attribut entfernt, bekam aber eine andere Fehlermeldung als du, so dass icht ganz sicher bin ob der Fehler gefixt ist, evtl. hat auch das kmpl. common bei dir gefehlt
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
Der neue JS-Adapter erzeugt auch bei leeren Skripten einen obj.common.source, so dass mir das nicht aufgefallen ist. Erinnerst du dich was im Objekt gefehlt hatte? Ich habe zum Testen das source Attribut entfernt, bekam aber eine andere Fehlermeldung als du, so dass icht ganz sicher bin ob der Fehler gefixt ist, evtl. hat auch das kmpl. common bei dir gefehlt
weiß ich leider nicht - habe das log angesehen, dass script gecheckt, welches als letztes angezeigt wurde und das "leere" gelöscht
noch ne frage - habe die beiden scripte (im log), die leer waren gelöscht - alle js-instanzen neugestartet und bekomme nun dieses warning

das problem dabei, in script_enabled werden die datenpunkte nicht gelöscht. nur in der eigentlichen instanz wird der dp gelöscht - in den anderen beiden bleibt dieser dp enthalten - man sollte also auf jeden fall alle script_enabled-ordner aller instanzen löschen bovor das script läuft - evtl in der anleitung als pflicht angeben ?
-
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
kannst/willst du das abfangen ?
ändere in Zeile 36 zu
if(obj && obj.type === 'script' && obj.common.source){Der neue JS-Adapter erzeugt auch bei leeren Skripten einen obj.common.source, so dass mir das nicht aufgefallen ist. Erinnerst du dich was im Objekt gefehlt hatte? Ich habe zum Testen das source Attribut entfernt, bekam aber eine andere Fehlermeldung als du, so dass icht ganz sicher bin ob der Fehler gefixt ist, evtl. hat auch das kmpl. common bei dir gefehlt
@fastfoot
und noch ne frage - zur sicherheit - wenn ich "scriptIds" so auswähle, dass ich nur ein script "erwische", wird doch nur ein script ins system geschrieben und der rest bleibt oder ist der rest gefährdet (natürlich mit proxmox backup !)irgendwie muss ich ja mal richtig testen - möchte aber nicht alles auf einmal ändern - ist zuviel
-
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
Der neue JS-Adapter erzeugt auch bei leeren Skripten einen obj.common.source, so dass mir das nicht aufgefallen ist. Erinnerst du dich was im Objekt gefehlt hatte? Ich habe zum Testen das source Attribut entfernt, bekam aber eine andere Fehlermeldung als du, so dass icht ganz sicher bin ob der Fehler gefixt ist, evtl. hat auch das kmpl. common bei dir gefehlt
weiß ich leider nicht - habe das log angesehen, dass script gecheckt, welches als letztes angezeigt wurde und das "leere" gelöscht
noch ne frage - habe die beiden scripte (im log), die leer waren gelöscht - alle js-instanzen neugestartet und bekomme nun dieses warning

das problem dabei, in script_enabled werden die datenpunkte nicht gelöscht. nur in der eigentlichen instanz wird der dp gelöscht - in den anderen beiden bleibt dieser dp enthalten - man sollte also auf jeden fall alle script_enabled-ordner aller instanzen löschen bovor das script läuft - evtl in der anleitung als pflicht angeben ?
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
das problem dabei, in script_enabled werden die datenpunkte nicht gelöscht. nur in der eigentlichen instanz wird der dp gelöscht - in den anderen beiden bleibt dieser dp enthalten - man sollte also auf jeden fall alle script_enabled-ordner aller instanzen löschen bovor das script läuft - evtl in der anleitung als pflicht angeben ?
eigentlich sollte der Fehler nicht auftauchen, da in Zeile 32 auf die Existenz des Objekts geprüft wird. Zusätzlich wird, falls existent, auch die Instanz der scriptID mit der tatsächlichen verglichen und nur bei Gleichheit weitergemacht. Theoretisch sollte also egal sein was in scriptEnabled steht. DA hilft nur die beiden Skripte zu prüfen,
-
@fastfoot
und noch ne frage - zur sicherheit - wenn ich "scriptIds" so auswähle, dass ich nur ein script "erwische", wird doch nur ein script ins system geschrieben und der rest bleibt oder ist der rest gefährdet (natürlich mit proxmox backup !)irgendwie muss ich ja mal richtig testen - möchte aber nicht alles auf einmal ändern - ist zuviel
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
@fastfoot
und noch ne frage - zur sicherheit - wenn ich "scriptIds" so auswähle, dass ich nur ein script "erwische", wird doch nur ein script ins system geschrieben und der rest bleibt oder ist der rest gefährdet (natürlich mit proxmox backup !)irgendwie muss ich ja mal richtig testen - möchte aber nicht alles auf einmal ändern - ist zuviel
das ist richtig, du kannst aber auch die Datei im Filesystem nutzen und erstmal von Hand importieren, es werden nur Dateien geschrieben welche auch eine Änderung haben(also oldNamespace beinhalten). Müsstest du im Pfad von pathToRestore finden, vorher löschen damit nur diese Datei drinne ist. Für ein Schreiben ins System empfehle ich mit Endung Chg, dann wird ein neues Skript angelegt und das alte bleibt erhalten!
-
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
das problem dabei, in script_enabled werden die datenpunkte nicht gelöscht. nur in der eigentlichen instanz wird der dp gelöscht - in den anderen beiden bleibt dieser dp enthalten - man sollte also auf jeden fall alle script_enabled-ordner aller instanzen löschen bovor das script läuft - evtl in der anleitung als pflicht angeben ?
eigentlich sollte der Fehler nicht auftauchen, da in Zeile 32 auf die Existenz des Objekts geprüft wird. Zusätzlich wird, falls existent, auch die Instanz der scriptID mit der tatsächlichen verglichen und nur bei Gleichheit weitergemacht. Theoretisch sollte also egal sein was in scriptEnabled steht. DA hilft nur die beiden Skripte zu prüfen,
da kann ich nix prüfen - die scripte sind gelöscht - habe die dp aus script_enabled von hand gelöscht - dann sind warnungen weg
habe mal ein "großes" blockly konvertiert und ins filesystem geschrieben - kann man ohne fehler importieren :-)
-
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
@fastfoot
und noch ne frage - zur sicherheit - wenn ich "scriptIds" so auswähle, dass ich nur ein script "erwische", wird doch nur ein script ins system geschrieben und der rest bleibt oder ist der rest gefährdet (natürlich mit proxmox backup !)irgendwie muss ich ja mal richtig testen - möchte aber nicht alles auf einmal ändern - ist zuviel
das ist richtig, du kannst aber auch die Datei im Filesystem nutzen und erstmal von Hand importieren, es werden nur Dateien geschrieben welche auch eine Änderung haben(also oldNamespace beinhalten). Müsstest du im Pfad von pathToRestore finden, vorher löschen damit nur diese Datei drinne ist. Für ein Schreiben ins System empfehle ich mit Endung Chg, dann wird ein neues Skript angelegt und das alte bleibt erhalten!
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
@fastfoot
und noch ne frage - zur sicherheit - wenn ich "scriptIds" so auswähle, dass ich nur ein script "erwische", wird doch nur ein script ins system geschrieben und der rest bleibt oder ist der rest gefährdet (natürlich mit proxmox backup !)irgendwie muss ich ja mal richtig testen - möchte aber nicht alles auf einmal ändern - ist zuviel
das ist richtig, du kannst aber auch die Datei im Filesystem nutzen und erstmal von Hand importieren, es werden nur Dateien geschrieben welche auch eine Änderung haben(also oldNamespace beinhalten). Müsstest du im Pfad von pathToRestore finden, vorher löschen damit nur diese Datei drinne ist. Für ein Schreiben ins System empfehle ich mit Endung Chg, dann wird ein neues Skript angelegt und das alte bleibt erhalten!
bedeutet: ich hätte dann 1500 scripte - statt 750
-
da kann ich nix prüfen - die scripte sind gelöscht - habe die dp aus script_enabled von hand gelöscht - dann sind warnungen weg
habe mal ein "großes" blockly konvertiert und ins filesystem geschrieben - kann man ohne fehler importieren :-)
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
da kann ich nix prüfen - die scripte sind gelöscht - habe die dp aus script_enabled von hand gelöscht - dann sind warnungen weg
aber genau das dürfte nicht passieren, da ja auf die Existenz eines Objektes zuerst geprüft wird. Evtl. habe ich da einen Denkfehler. Die Id ist xxxx.scriptEnabled.DeletedScript. Daraus wird script.js.DeletedScript und dann wird auf existsObject('script.js.DeletedScript') geprüft.
Ich versuche das mal nachzustellen, evtl. spielt da auch der Buffer von iobroker einen Streich
-
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
@fastfoot
und noch ne frage - zur sicherheit - wenn ich "scriptIds" so auswähle, dass ich nur ein script "erwische", wird doch nur ein script ins system geschrieben und der rest bleibt oder ist der rest gefährdet (natürlich mit proxmox backup !)irgendwie muss ich ja mal richtig testen - möchte aber nicht alles auf einmal ändern - ist zuviel
das ist richtig, du kannst aber auch die Datei im Filesystem nutzen und erstmal von Hand importieren, es werden nur Dateien geschrieben welche auch eine Änderung haben(also oldNamespace beinhalten). Müsstest du im Pfad von pathToRestore finden, vorher löschen damit nur diese Datei drinne ist. Für ein Schreiben ins System empfehle ich mit Endung Chg, dann wird ein neues Skript angelegt und das alte bleibt erhalten!
bedeutet: ich hätte dann 1500 scripte - statt 750
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
bedeutet: ich hätte dann 1500 scripte - statt 750
jein, wenn du erstmal zum Test auf ein einziges Skript beschränkst, sind es nur 751 :-)
-
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
da kann ich nix prüfen - die scripte sind gelöscht - habe die dp aus script_enabled von hand gelöscht - dann sind warnungen weg
aber genau das dürfte nicht passieren, da ja auf die Existenz eines Objektes zuerst geprüft wird. Evtl. habe ich da einen Denkfehler. Die Id ist xxxx.scriptEnabled.DeletedScript. Daraus wird script.js.DeletedScript und dann wird auf existsObject('script.js.DeletedScript') geprüft.
Ich versuche das mal nachzustellen, evtl. spielt da auch der Buffer von iobroker einen Streich
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
Ich versuche das mal nachzustellen, evtl. spielt da auch der Buffer von iobroker einen Streich
daher habe ich js-instanzen neugestartet
-
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
Ich versuche das mal nachzustellen, evtl. spielt da auch der Buffer von iobroker einen Streich
daher habe ich js-instanzen neugestartet
@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
Ich versuche das mal nachzustellen, evtl. spielt da auch der Buffer von iobroker einen Streich
daher habe ich js-instanzen neugestartet
ich kann es nicht nachvollziehen. in ScriptEnabled noch vorhanden aber tatsächlich gelöscht. Das Skript arbeitet da bei mir sauber.
Vlt stelle ich doch noch auf Mirrorpfad um :-)
-
Schon länger sind User angehalten, für ihre eigenen Datenpunkte den Namespace 0_userdata.0 zu verwenden. Mit Einführung von Admin 5 wird das auch mehr forciert und es wird so langsam Zeit 'umzuziehen', sprich, wer eigene Datenpunkte z.B. unter MeineDatenpunkte.0 angelegt hat sollte diese nun unter 0_userdata.0 anlegen. Da sich evtl. viele Skripte angesammelt haben, welche auf die alten DP Bezug nehmen und es sehr mühsam ist alle Skripte händisch anzupassen ist dieses Skript entstanden. Auch wer nicht konvertieren will oder muss kann so eine komplette Übersicht über seine Skripte erhalten.
Was kann das Skript?- Auflistung aller Skripte mit Name und Pfad, Beschreibung(wenn Header gepflegt wird), Instanz, Typ, Anzahl der erforderlichen Änderungen, Status(läuft/läuft nicht)
- Die Darstellung erfolgt durch einen mit JSON Daten gefüllten DP und einem JSON Widget von inventwo. Der dazu notwendige DP muss händisch angelegt werden!
- Schreiben von notwendigen Änderungen als Datei in das Dateisystem, bei Blockly-Skripten als xml-Export. Unterstützt werden Javascript, Blockly und Typescript.
- Diese Option ist einstellbar über writeToFileSystem (Default = true) und pathToRestore (Default = /opt/iobroker/switched)
- Direktes Ändern der Skripte im System.
- Auf Wunsch (und aus Sicherheitsgründen enpfohlen!!!) wird an den Skriptnamen die Endung Chg angehängt, hierbei wird dann eine Kopie erstellt und das Original bleibt erhalten. Ist die Endung auf '' gesetzt, wird das Original überschrieben.
- Aktive Skripte werden nicht ins System übernommen.
- Diese Option ist einstellbar über replaceInSystemsDB (Default = false) und extChanged (Default = Chg)
- Einstellungen für das Verhalten des Skriptes erfolgen in den Zeilen 11-15
Was das Skript nicht kann:
- Notwendige Änderungen in der VIS müssen händisch erfolgen.
- Die neuen Datenpunkte unter 0_userdata.0 sollten/müssen vor dem Neustart der Skripte natürlich schon vorhanden sein(Export Objekstruktur => Ersetzen alter Namespace mit neuem Namespace => Import unter 0_userdata.0)
Unzulänglichkeiten:
- Skripte, welche javascript.x.scriptEnabled zum Ein- und Auschalten von Skripten verwenden, werden evtl. nicht richtig/vollständig konvertiert
- Skripte welche setState(myDP, wert) ohne Namespace verwenden(d.h. der State wird automatisch in javascript.instance.myDP geschrieben) werden nicht korrekt konvertiert
Ich hoffe dass das Skript bei einer anstehenden Konvertierung hilfreich sein wird. Evtl. Korrekturen und Verbesserungen werden in diesem Beitrag gepostet
@fastfoot sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:
Direktes Ändern der Skripte im System.
Auf Wunsch (und aus Sicherheitsgründen enpfohlen!!!) wird an den Skriptnamen die Endung Chg angehängt, hierbei wird dann eine Kopie erstellt und das Original bleibt erhalten. Ist die Endung auf '' gesetzt, wird das Original überschrieben.
Aktive Skripte werden nicht ins System übernommen.
Diese Option ist einstellbar über replaceInSystemsDB (Default = false) und extChanged (Default = Chg)moin @fastfoot
hätte noch ein paar fragen
bitte bedenke die große anzahl meiner scripte
- wie kann ich aktiv laufende scripte konvertieren - was gibt es da für ein problem? könnten wir evtl über eine eigene javascript-instanz für das script nehmen und die anderen instanzen deaktivieren - es ist einfach zu viel, alle aktiven scripte "von hand" zu importieren
- das .chg als endung: könnten wir das auch ausschalten - ich hätte ja 750 scripte zu löschen
da ich proxmox habe ist das mit dem backup und restore ziemlich schnell erledigt - ich wollte jetzt einfach mal dein script auf alles anwenden und mich überraschen lassen. so wie es momentan ist, ist die nacharbeit zu viel
- Auflistung aller Skripte mit Name und Pfad, Beschreibung(wenn Header gepflegt wird), Instanz, Typ, Anzahl der erforderlichen Änderungen, Status(läuft/läuft nicht)
