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

[SBorg]

Korrekt. Dafür gibt es beim Javascript-Adapter einen Issue, damit man auch außerhalb von javascript.x States anlegen kann :)

[Blackmike]

grmmpf... also tipporgien... ich freu mich.

mal schauen ob ichs wenigstens so hinkriege, dass die nur anlege und den rest über extendObject per Script mache. (mein Wrapper hatte 205 States, da fallen mir sonst die Finger ab)

[paul53]

@Blackmike sagte:

wie ist da der lösungsansatz?

Siehe hier.

[dslraser]

@paul53 sagte in Anlegen von States über script in alias.0:

@Blackmike sagte:

wie ist da der lösungsansatz?

Siehe hier.

Ich hatte mal das von Dir, funktioniert auch, aber das verlinkte scheint noch "feiner"

anlegen

const id = 'Test.0.Testordner.Testdatenpunkt';

const obj = {
 "type": "state",
   "common": {
   "name": "Testdatenpunkt",
   "role": "switch",
   "type": "boolean",
   "read": true,
   "write": true,
   "def": false,
   }};

setObject(id, obj, function() {
   setState(id, obj.common.def, true); // Initialisierung
});

oder das zum kopieren von vorhandenen Datenpunkten

vorhandenen Datenpunkt kopieren

//vorhandener zu kopierender Datenpunkt
const idSrc = "javascript.0.Eigene_Datenpunkte.05Temperaturen.01Schlafzimmer"/*Temperatur Schlafzimmer*/;

//neue Ordnerstruktur/Ordner mit kopiertem Datenpunkt
const idDst = "datenpunkte.0.Alexa2Adapter.Ansagen.Temperatur.Temperaturansage";

function copyObject() {
   var obj = getObject(idSrc);
   setObject(idDst, obj, function() {
       if(obj.type === 'state') {
           var init = null;
           if(obj.common.def !== undefined) {
               if(obj.common.type === 'number') init = 0;
               if(obj.common.type === 'boolean') init = false;
               if(obj.common.type === 'string') init = '';
           } else init = obj.common.def;
           setState(idDst, init, true); 
       }
   });
}

copyObject();

[Blackmike]

danke, werde ich nun einbauen

[Blackmike]

Wobei ich grade über eine Sache falle:
Ich habe ja grade eine Geklonte VM meines Produktivsystems mit einmal JScontroller 1.5.x und einmal eine VM mit Controller 2.1

ExtendObject: mit 1.5.x "mischte" das die vorhandenen Einstellungen zu den neuen, heisst
ich habe ein common bei den Objects
ich will nun ein {common: {"Black":"reiner test"}} dem common hinzufügen.

bei der controller Version 1.5.x wird das Black : reiner Test zu den vorhandenen Einträgen der common Gruppe hinzugefügt

bei der Version 2.1 enthält der common dann nur den Eintrag Black: reiner Test, Name, min, max und so sind weg. common wird also ersetzt, nicht gemerged.
womit ich grade auch den Grund gefunden habe, warum mein Wrapper Script nur Shice macht, das setzte darauf nämlich auf.

Bin ich mit dem Effekt alleine, ist das ein feature oder ein Bug ?

Thnx, Black

[paul53]

@Blackmike sagte:

werde ich nun einbauen

Besser so:

// Original-Datenpunkt
const idOrigin = 'sonoff.0.Kontakt-Haustuere.POWER'/*Kontakt-Haustuere POWER*/
 
// Alias-Datenpunkt
const idAlias = 'Haus.Tuer.Kontakt';
const typeNew = null; // 'string', 'boolean', 'number', keine Typwandlung: null
 
function createAlias(idSrc, idDst, typeAlias) {
   if(!getObject('alias.0.' + idDst)) {
      var obj = {};
      obj.type = 'state';
      obj.common = getObject(idSrc).common;
      if(typeAlias) obj.common.type = typeAlias;
      obj.common.alias = {};
      obj.common.alias.id = idSrc;
      setObject('alias.0.' + idDst, obj);
   } else log ('Alias schon vorhanden !', 'warn'); 
}
 
createAlias(idOrigin, idAlias, typeNew);

[Blackmike]

@paul53 sagte in Anlegen von States über script in alias.0:

@Blackmike sagte:

werde ich nun einbauen

Besser so:

// Original-Datenpunkt
const idOrigin = 'sonoff.0.Kontakt-Haustuere.POWER'/*Kontakt-Haustuere POWER*/
 
// Alias-Datenpunkt
const idAlias = 'Haus.Tuer';
 
function createAlias(idSrc, idDst, typeAlias) {
   if(!getObject('alias.0.' + idDst)) {
      var obj = {};
      obj.type = 'state';
      obj.common = getObject(idSrc).common;
      if(typeAlias) obj.common.type = typeAlias;
      obj.common.alias = {};
      obj.common.alias.id = idSrc;
      setObject('alias.0.' + idDst, obj);
   } else log ('Alias schon vorhanden !', 'warn'); 
}
 
createAlias(idOrigin, idAlias);

ich bin da schon dran, in dem Else Pfad muss ich ein Object merge machen, aber da bin ich wie in meinem Post über deinem über tewas bei extendObject gefallen. es schein sol, als ob da intern irgendwo ein result = Object.assign({}, obj1, obj2) fehlt... (bei js2.1 gegenüber js v1.5.x)

[paul53]

@Blackmike sagte:

ich will nun ein {common: {"Black":"reiner test"}} dem common hinzufügen.

common.Black = 'reiner test';

[Blackmike]

@paul53 sagte in Anlegen von States über script in alias.0:

@Blackmike sagte:

ich will nun ein {common: {"Black":"reiner test"}} dem common hinzufügen.

common.Black = 'reiner test';

@paul53 , danke aber de allgemeine JSON Syntax war mir schon klar. Ich meine explizit diese Diskrepanz:

in js 1.5.x:
ein beispielhaftes Object
"common": {
"name": "State",
"role": "",
"type": "number",
"read": true,
"write": true,
"desc": "Manuell erzeugt",
"def": false}
da führe ich aus extendObject (oID,{common:{min:0,max:2}})

ergibt:
"common": {
"name": "State",
"role": "",
"type": "number",
"read": true,
"write": true,
"desc": "Manuell erzeugt",
"def": false,
"min": 0,
"max":2} also wird das ineinander gemerged

in dem neuen Controller ergibt das

"common": {
"min": 0,
"max":2}

und das halte ich für buggy.
extendObject
extendObject(id, obj, callback);
It is almost the same as setObject, but first it reads the object and tries to merge all settings together.
Use it like this:
// Stop instance
extendObject('system.adapter.sayit.0', {common: {enabled: false}});

im 2.1 wird das Object nicht gemergt, sondern ersetzt

Black

[paul53]

@Blackmike
Gerade getestet und Du hast recht: extendObject(id, obj) funktioniert nicht mehr wie beschrieben.
js-controller 2.1.0
javascript 4.3.1

[Blackmike]

@paul53 sagte in Anlegen von States über script in alias.0:

@Blackmike
Gerade getestet und Du hast recht: extendObject(id, obj) funktioniert nicht mehr wie beschrieben.
js-controller 2.1.0
javascript 4.3.1

gut, oder auch nicht... stellt du das issue ?
als workaround habe ich mal das probiert:

var extCom= {};
extCom.common= Object.assign (oID.common,{wrapper: wpath+sWrapID});
extendObject (oID._id, extCom,function () {....;}

kann aber nicht die generelle Lösung sein.
aber kannst dir mein gesicht vorstellen , als bei Start damit binnen Sekenden alle meine States am Ar... waren und das log logischerweise von Zugriffsfehlern überlief. Zum Glück gibts bei proxmox die Snapshoots, ich hatte da keinen sinnigen fehler gefunden, da produktivsystem muss laufen, also rollback und die VM geklont, jontroller upgrade, und spurensuche...
ich hab jetzt das Wrapperscript mit meinem Workaround angepasst und werd nun nochmal ein Upgrade des hauptsystems probieren (An den Snapshot hab ich auch gedacht)

Danke für deine Mühe, Black

[paul53]

@Blackmike sagte:

stellt du das issue ?

Ja, erledigt.

[Blackmike]

ok, so als zwischenmeldung, nach dem anpassen des wrapperscriptes auf den Workaround, snapshot und controllerupdate startete das produktivsystem sauber durch.

Nicht destotrotz werd ich an der geschichte mit den aliases nun weitermachen, ist aber etwas der durck raus nun da fehelr gefunden. Im Enszustand soll dann aliases den part des wrappers übernehmen.

Black

[apollon77]

Sehr interessant. Auf reinem js-Controller Level gibt es sogar Tests für extendObject. Die hab ich jetzt noch erweitert. Da klappt das extend wie es soll ... hhhmmmmmm ......

[Blackmike]

@apollon77 sagte in Anlegen von States über script in alias.0:

Sehr interessant. Auf reinem js-Controller Level gibt es sogar Tests für extendObject. Die hab ich jetzt noch erweitert. Da klappt das extend wie es soll ... hhhmmmmmm ......

kann ich dir mit irgendwelchen Angaben weiterhelfen ?
paul53 konnte dies ja auch nachstellen.

Black

[apollon77]

Mal frech gefragt: Eure Tests ... haben die mit controller 1.5 und 2.1 mit der gleichen javascript Adapter version stattgefunden? Wenn ja mit welcher?

Also wir sind gerade an folgendem Punkt: Scheinbar ändert "Vm2" (was die Sandbox ist in der die Skripte laufen) hier das Objekt etwas und daher wird es nicht mehr als ein Objekt erkannt an der Stelle wo die Daten gemerged werden.
Wenn das so ist, dann sollte dieses Problem aber seit javascript 3.7 oder so existieren (oder wann auch immer vm2 offiziell für alle an war ...)

[Blackmike]

@apollon77
javascriptadapter war immer der gleiche, der war schon vor dem controllerUpgrade auf 4.3.3

Stand war:
vor dem Upgrade lief js 1.5.14 mit jenigmn javascript adapter, ohne probleme (das war auch das Produktivsystem)

nach dem Upgrade auf 2.1.0 hats mir alle States zerschlagen, die der Wrapper angefasst hat, also eine ganze menge

(Ich habe mir angewöhnt schon seit längerem, immer zuerst den JS-Controller uozugraden, system beobachten udn erst dann evtl weitere Adapter nachzuziehen)

[apollon77]

Seeeehr Strange ... wir überlegen wie wir die Ursache fixen.

[apollon77]

Hey All, der war echt nice ;-)

Also was passiert ist, ist das Objekte die in Javascript Skripten erzeugt werden quasi noch so ein bissl der "Sandbox" in der sie ausgeführt werden mit sich rumtragen.
Das war schon immer so. Die ganze "Objekt-Logik" (auch das echte "extendObject") hat im js-controller (und nur da) stattgefunden. Das Objekt wurde serialisiert und zum controller übertragen. Dadurch ist der "komische Teil" quasi abgeschüttelt worden. Deswegen hatte das keine Auswirkung.

Seit js-controller 2.0 übernimmt die Logik eine Library die vom Adapter direk genutzt wird und die "Datenbank" macht quasi nur noch "get" und "set". Das extend wird also quasi vom Adapter-Prozess gemacht und hier stolpert die "extend"-Funktion jetzt über den Sandbox-Teil im Objekt und arbeitet dadurch anders weil es kein echtes Objekt mehr ist sondern was komisches halt :-)

Wir haben jetzt einen Fix dafür. Am Ende sind es aktuell zwei Stellen wo wir etwas geändert haben dafür, es sollte aber reichen wenn Ihr EINE davon nutzt!

1.) Es gibt eine neue Version der genannten Objects-Library. Jeder der den controller 2.1.0 nach heute 13:30 Uhr installiert hat sollte diese schon haben. Ansonsten kann diese aktualisiert werden: cd /opt/iobroker/node_modules/iobroker.js-controller dann dort npm update iobroker.objects-redis sollte die 1.2.7 der Library installieren. Danach mindesterns den javascript adapter neu starten (am besten gesamten controller)

2.) Installiert JavaScript vom GitHub. Kommt dann da in die nächste Version rein.

Ingo