UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[liv-in-sky]

@fastfoot thema script enabled

durch meine 3 instanzen kam es da schon immer zu einem extremen wildwuchs (script-enabled) - vorallem, wenn man scripte verschiebt

ich hatte mich nie getraut, script eabled zu löschen - aber du sagst, die legen sich neu an - verstehe ich das richtig ?

ein anderer weg für die scripte - dachte anfangs, dass du das darüber machen wirst:
ich habe mal ein script gemacht um mir alle scripte anzusehen - da nutzte ich die scripte-spiegel function vom js-adapter und ging auch durch das directory - ich glaube das nutzen auch einige, die mit einem anderen/externen script editor arbeiten

sieht so aus:

[liv-in-sky]

@fastfoot

habe gerade gesehen, dass du ja ein script hast, welches über diesen mirror-ordner geht ( Extrahiert XML Datei aus Blockly.js im Mirror-Pfad)

warum nutzt du diesen weg nicht ? ist das wegen den blockly scripte ?

[fastfoot]

@liv-in-sky sagte in [Skript] Namespace für Datenpunkte in Skripten abändern:

verstehe ich das richtig ?

ja tust du, die beiden Ordner werden beim Neustart der jeweiligen Instanz sofort wieder aufgebaut(dennoch: Backup!). Ich habe das schon oft gemacht und nie(!) Probleme damit gehabt.

Über den Mirrorpfad zu gehen wäre auch eine Option gewesen, eines meiner älteren Skripte nutzt das um aus Blocklys XML Dateien zu erzeugen. ich wollte es aber bewusst so machen. 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. Das hatte ich ja auch mal gepostet, hatte aber das Namespace Switching nicht mit drin.

Evtl. sollte man aber ein issue zum Selektor aufmachen, das sollte eig. auch mal sauber laufen. Da wollte ich aber noch mehr belastbare Daten haben, damit die Entwicklerdas nachvollziehen können. Vieles ist auf meiner Seite Spekulation. Allerdings wirft das Skript unmittelbar die Fehler unmittelbar nach der Definition des Selektors und anschliessendem Durchlaufen, ohne dass man die Chance hätte etwas falsch zu programmieren

Probiere das doch mal mit Bereinigung dieser beiden Ordner, das geht sehr schnell. Für mich ein Hauptgrund für dieses Skript ist eigentlich die Auflistung mainer Skripte incl. ihres Zweckes, das setzt natürlich immer einen Header vorraus, den du mittlerweile in fast allen meinen Skripten sehen kannst. Ist etwas Arbeit aber für mich hat es sich schon gelohnt :-)

[liv-in-sky]

@fastfoot

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

[fastfoot]

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

@fastfoot

die warnings sind jetzt weg - nach dem löschen der script-enabled

nur noch der bekannte error

[fastfoot]

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

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

@fastfoot

leere scripte gelöscht - jetzt läuft es durch

[fastfoot]

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

[fastfoot]

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

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

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

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

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

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

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

@fastfoot

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]

@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

[fastfoot]

@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