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

[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

[fastfoot]

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

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

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

[liv-in-sky]

@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

[liv-in-sky]

@fastfoot ich hoffe ich kapier das überhaupt alles richtig

theoretisch müßte man doch die scripte gleich in das object schreiben bzw überschreiben können - falls das nicht geht, wäre es möglich die "running" scripte nicht mit pfad im namen zu schreiben, sondern in eine verzeichnisstruktur, die dem mirror pfad entspricht - dann sollte man doch die file-struktur ins mirror kopieren können - ich weiß dann aber nicht, ob das running bleibt, wenn das script einfach in den mirror geschrieben wird

[fastfoot]

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

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

du kannst ja die isRunning condition(Zeile83) wegnehmen und auch Chg zu '' ändern(Zeile16 extChanded), das sind eig. alles nur Sicherheitsmassnahmen, das Skript ist ja auch für relativ Unbedarfte Leute gedacht. Ein Test zeigt dass der running Status beim Überschreiben erhalten bleibt und das Skript neu startet. Da das aber ein Rumgefummel am System ist, kann ich die Auswirkungen nicht wirklich einschätzen. So als Läie würde ich aber sagen dass das funktionieren müsste. Trau Dich!! :-) Meine Tests waren soweit sehr positiv

• das .chg als endung: könnten wir das auch ausschalten - ich hätte ja 750 scripte zu löschen

s.o.

Ich bin gerade dabei das Einlesen auf Mirrorpath umzustellen, es hakt nur noch an Kleinigkeiten, bei der Bestimmung der ObjektId sieht der Code grausig aus, ansonsten ist es aufgräumter und läuft auch schon ganz gut. Die Probleme mit dem Selektor haben mich total genervt

[fastfoot]

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

@fastfoot ich hoffe ich kapier das überhaupt alles richtig

theoretisch müßte man doch die scripte gleich in das object schreiben bzw überschreiben können - falls das nicht geht, wäre es möglich die "running" scripte nicht mit pfad im namen zu schreiben, sondern in eine verzeichnisstruktur, die dem mirror pfad entspricht - dann sollte man doch die file-struktur ins mirror kopieren können - ich weiß dann aber nicht, ob das running bleibt, wenn das script einfach in den mirror geschrieben wird

siehe den vorigen Post, überschreiben funktioniert eigentlich. Wie der Status eines 'neuen' Skript im Mirror ist weiss ich nicht, scheint mir aber von hinten durch die Brust ins Auge.

Wenn man zig Skripte konvertiert, dann werden die ja auch neu kompiliert, hier könnte ich mir eine race condition vorstellen. Speziell den global Ordner sollte man evtl. ausschliessen, da eine Änderung dort auch alle Skripte neu kompiliert

[liv-in-sky]

@fastfoot

habe jetzt umgestellt - habe aber ein problem

• objecte
• scripte - dank dir :-)
• iqontrol
• vis

was ich total vergessen habe,
sind alle meine tasker profiles - das sind einige - aber da geht auch was mit search und replace
und
ich habe viele scripte auf dem pc, die direct über simpleapi senden - die musss ich auch noch ändern :-)
und
und die linux scripte, die direct in linux laufen und auch simple api nutzen
und linux-control adapter

und
kann es sein, dass die trigger nicht mehr funktionieren ?

werde morgen wohl den ganzen tag in irgendwelchen log-dateien eintauchen müssen