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

[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

[liv-in-sky]

@fastfoot

es scheint im moment, dass ich jedes blockly mit einem neuen trigger versehen muss - irgendeinen - dann speichern und dann triggert das blockly wieder

shr seltsam

[fastfoot]

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

@fastfoot

es scheint im moment, dass ich jedes blockly mit einem neuen trigger versehen muss - irgendeinen - dann speichern und dann triggert das blockly wieder

shr seltsam

ich hätte ja auf einen Neustart des JS-Adapters getippt. Allerdings, wenn du dir den JS-Code eines geänderten Blockly anschaust, dann ist der ja weg. Bewegt man einen Block dann berechnet iobroker den Code neu. Evtll. liegt es auch daran. nach meiner Überzeugung braucht es diesen Code aber nicht zwingend. Evtl. braucht es aber dennoch eine Neucompilation.

Ansonsten hast du ja eine riesen Baustelle :-) Für die VIS hatten wir doch aber auch etwas?

[liv-in-sky]

@fastfoot die vis läuft - auch ein script von dir

nein -. ich muss einen neuen trigger-block einfügen - der muss einmal getriggert werden und danach funktioniert es
, iobroker neustart, instanz neustart - alles gemacht - die scripte sind auch im editor auf run eingestellt und auch unter script_enabeld

im moment muss ich jedes blockly aufrufen und das durchziehen - sondt geht nix mehr im haus

[fastfoot]

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

im moment muss ich jedes blockly aufrufen und das durchziehen - sondt geht nix mehr im haus

krass. ich habe keine Blocklys mehr, werde das aber mal testen

[liv-in-sky]

@fastfoot

habe alles direkt ins system geschrieben zeile 83 if(replaceInSystemsDB && changes > 0){

und const extChanged = '';

[fastfoot]

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

@fastfoot

habe alles direkt ins system geschrieben zeile 83 if(replaceInSystemsDB && changes > 0){

und const extChanged = '';

habe einen Fix. Der Code wird tatsächlich gebraucht.
ersetze in convertBlockly die erste Zeile(const BlocklyHeader....) durch

    let regex = new RegExp(oldNamespace, "g");
    //let blocklyHeader = '//Das Skript wurde programmatisch modifiziert. Um den JS code zurück zu erhalten, \n//einen der Blöcke etwas verschieben und abspeichern.\n//';
    let blocklyHeaderTmp = source.split('\n');
    blocklyHeaderTmp.pop();
    let blocklyHeader = blocklyHeaderTmp.join('\n').replace(regex, newNamespace) + '\n//';

Ein Zeitplan welcher nicht funktioniert hatte nach der Konvertierung läuft jetzt problemlos weiter