js-controller 2 jetzt für alle im Stable

paul53

Mit deiner Frage stellst Du die komplette Idee des Alias in Frage ...

Nein, ich finde die Idee des Alias sehr nützlich: Bei Adapter-Datenpunkten, deren ID-Struktur nicht einheitlich ist bzw. sich beim Geräteaustausch verändern kann. Eigenen Datenpunkten verpasst man gleich ein sinnvolle ID-Struktur, die optimalerweise so aussieht wie die unter alias.0.

BBTown

@paul53 JETZT habe ich deinen Ansatz verstanden ... wieso sollte sich ein eigener Datenpunkt verändern?! .... ja, war ne ziemlich blöde Idee von mir :man-facepalming:

crunchip

@paul53 ich blick da langsam nimmer durch. was hat es dann mit dieser Option auf sich?

Durch die enormen Veränderungen, die mehr oder weniger alle auf einmal kamen, wie

Adapter devices.0
alias.0
0_userdata.0
komm ich da leider nicht mehr ganz mit,
wie, was angelegt wird, warum und weshalb.
Ich seh dadurch eher noch mehr Chaos bei mir im System, als das es vereinfacht werden würde
ich glaub, ich mach nen neuen thread dazu auf.
Denke, ich bin nicht der einzige der das nicht ganz versteht.

paul53

@crunchip sagte:

ich glaub, ich mach nen neuen thread dazu auf.

Das macht Sinn.

@crunchip sagte in js-controller 2 jetzt für alle im Stable:

Adapter devices.0

Der Adapter soll die Erstellung von Geräten und Datenpunkten unter alias.0 ermöglichen, ist allerdings noch in einem frühen Entwicklungsstadium. Ich komme (noch) nicht damit zurecht.

Detlev Rackow

@apollon77 Danke für die Rückmeldung. Nach einem weiteren Update läuft 2.1.1 jetzt ohne Probleme. Im ioBroker-Log zum Zeitpunkt der ersten Installation kann ich keinerlei Fehler oder Warnmeldungen finden, es wirkt so als wäre das System normal gelaufen - nur waren die Webseiten gar nicht und die SSH-Shell nur mit langer Wartezeit erreichbar.

Vor dem Upgrade hatte ich natürlich iobroker stop eingegeben und dabei keine Fehlermeldung bekommen.

Wenn es nur bei mir passierte, ist das Thema erledigt. Es mag sich um ein Problem im Betriebssystem gehandelt haben. Der Raspi 3B kommt ja schnell an Grenzen.

skokarl

Was gab es bei dem neuen Javascript Adapter und den Userdatenpunkten nochmal für eine Einschränkung ?
Man kann die nicht anlegen, oder nicht beschreiben ?

Versuche mit Javascript einen DP zu ändern, ( also zu füllen ) haut aber nicht hin ....

apollon77

@skokarl createState geht nicht. setState geht in jedem Fall

bahnuhr

@apollon77 sagte in js-controller 2 jetzt für alle im Stable:

@skokarl createState geht nicht. setState geht in jedem Fall

createState geht im javascript Ordner nicht mehr ?

Wie lege ich dann manuell Datenpunkte in dem javascript Ordner an ?

Bitte kurze Rückinfo.

apollon77

@bahnuhr createState geht in 0_userdata.0 nicht!!! Im JavaScript Ordner geht alles wie immer!!

bahnuhr

@apollon77 sagte in js-controller 2 jetzt für alle im Stable:

0_userdata.0

Danke für die Info.

Wenn ich das bisher richtig gelesen habe, soll aber doch der ..user.. der Bereich sein in dem man eigene Variablen ablegt.

Wie lege ich da denn per Script Objekte an ?

paul53

@bahnuhr sagte:

Wie lege ich da denn per Script Objekte an ?

So.

// Datenpunkt unter 0_userdata.0 erstellen
const idUser = 'Muell.gelbeTonne.Abholdatum';
const commonUser = { // nicht benötigte Attribute auskommentieren
    type: 'string', 
    read: true, 
    write: true, 
    name: 'Abholung gelbe Tonne',
//    desc: 'Laufzeit Rollo', 
    def: '22.11.2019',
//    min: 0,     // nur bei Zahlen
//    max: 30,   // nur bei Zahlen
//    unit: 'Tage',  // nur bei Zahlen
//    states: {  // nur bei Zahlen, Logikwerten
//        0: 'Aus',
//        1: 'Auto',
//        2: 'Ein'
//    },
    role: 'text'
};

function createDp(id, common) {
    if(getObject(id)) log('Datenpunkt ' + id + ' existiert bereits !', 'warn');
    else {
        var obj = {};
        obj.type = 'state';
        obj.common = common;
        setObject(id, obj, function (err) {
            if (err) log('Cannot write object: ' + err)
            else {
                var init = null;
                if(common.def === undefined) {
                    if(common.type === 'number') init = 0;
                    if(common.type === 'boolean') init = false;
                    if(common.type === 'string') init = '';
                } else init = common.def;
                setState(id, init, true);
            }
        });
    }
}

createDp('0_userdata.0.' + idUser, commonUser);

bahnuhr

Danke für die Info.

Ich habe ca. 700 selbst erstellte Objekte die in meinem Javascript Ordner sind.

Wenn ich das System neu aufsetze, dann lassen ich ein Script laufen, das per createState alle Objekte einmalig anlegt.

sieht dann so aus:

Dieses Script geht bis zur Zeile 693 !!

Wenn ich nun deinen Link nehme ist das ganze nicht mehr praktikabel.

Frage:
Wer und warum kommt auf diese sinnvolle Idee, dass create State nicht mehr geht.
Ist für mich derzeit nicht nachvollziehbar.

Dies spricht für mich (und auch die Einschränkung beim fs schreiben in ein Verzeichnis) absolut gegen das Update auf js2.0.

Kann natürlich auch sein, dass ich wieder einmal den Sinn dahinter nicht verstehe.

mfg

paul53

@bahnuhr sagte:

dass create State nicht mehr geht.

Wie kommst Du darauf ? Eigene Datenpunkte können weiterhin unter javascript.0 erstellt werden. 0_userdata.0 ist nur eine zusätzliche Option für eigene Datenpunkte.

bahnuhr

@paul53 sagte in js-controller 2 jetzt für alle im Stable:

@bahnuhr sagte:

dass create State nicht mehr geht.

Wie kommst Du darauf ? Eigene Datenpunkte können weiterhin unter javascript.0 erstellt werden. 0_userdata.0 für eigene Datenpunkte ist nur eine zusätzliche Option.

Ok, aber stand nicht irgendwo, dass ..user.. der Ordner zukünftig sein soll, der man für eigene Objekte nehmen soll.

paul53

@bahnuhr sagte:

..user.. der Ordner zukünftig sein soll, der man für eigene Objekte nehmen soll.

Nein, das ist nur ein Vorschlag für diejenigen, die mit eigenen Datenpunkten unter javscript.0 nicht zurecht kommen und ohnehin eigene Ordner erstellen würden.

bahnuhr

Im thread3 von apollon steht das aber anders:

Zitat:
Ja ist es. Wir möchten 0_userdata.0 gern als neuen Standardplatz forcieren und haben uns dazu entschieden.

für mich klingt das so, dass ...user... der Platz ist der eigentlich genommen werden soll.

Aber nochmal:
Warum kann man da nicht mit create State etwas anlegen.
Wenn es doch der Standard werden soll ?

paul53

@bahnuhr sagte:

Wir möchten 0_userdata.0 gern als neuen Standardplatz forcieren

Das gilt für Einsteiger in ioBroker, nicht für bestehende Installationen.

@bahnuhr sagte in js-controller 2 jetzt für alle im Stable:

Warum kann man da nicht mit create State etwas anlegen.

Ist in Planung.

bahnuhr

@paul53 sagte in js-controller 2 jetzt für alle im Stable:

Ist in Planung.

Danke, diese Antwort ist gut und zielführend.
Stellt sich für mich nur die Frage warum man dies nicht gleich macht. Denn gerade Einsteiger brauchen doch einen einfachen Befehl.

Wenn ich darf, noch ne Frage:
Warum beschränkt man die fs Befehle auf den ..data.. Ordner.?
Was ist, wenn man eine Datei im lokalen Netzwerk speichern möchte ?
Warum geht der copy Befehl nicht mehr (Lösung ist ja read und write); aber warum beschränkt man dies?

Gibt für mich (aus meiner Logik) auch keinen Sinn für diese Einschränkung.

mfg
Dieter

apollon77

@bahnuhr Wie paul geschrieben hat oder nach einem kommenden JavaScript Update

apollon77

@bahnuhr Jetzt bitte mal gaaaaaaaanz langsam ...

Zu 0_userdata.0: Zitat aus Post #3 dieses Threads mit den Infos zum Feature:

Wichtig Wer seine States bisher in javascript.X ablegt und das für die eigenen Bedürfnisse ausreicht, kann dies weiterhin ohne Probleme tun. Wer jedoch seine Skripte auf mehrere JavaScript-Instanzen verteilt möchte ggf. einen besseren Platz, wie 0_userdata.0, nutzen Ebenso eigene Ordner auf oberster Ebene (z.B. MeineObjekte.0.x) können weiterhin genutzt werden - so lange halt bis ein Adapter mit diesem Namen kommt ...

Also niemand zwingt irgend jemanden das zu nutzen!

Es ist korrekt das der JavaScript Adapter bisher noch kein Update bekommen hat dies auch vollständig zu unterstützen. Ein Schritt nach dem anderen Bitte. Es wird kommen. Wir versuchen alles um Sinnvolle Pakete für Euch zu schnüren, aber auch wir haben nur begrenzte Zeit zur Verfügung!

Stimmt doch im zugehörigen GitHub Issue ab und Zeit so das es Euch unter den Nägeln brennt das Feature zu haben ... hat aktuell nur 3 Stimmen ... https://github.com/ioBroker/ioBroker.javascript/issues/429

Weiterhin: NIEMAND beschränkt "fs-Befehle" auf den data Ordner. Das können wir gar nicht weil die "fs" Library von nodejs auf das Filesystem zugreift. Da hast Du was komplett falsch verstanden.
Die Beschränkung gilt nur für Daten die im iobroker-data/files Ordner gespeichert sind - diese dürfen nicht mehr per direkten Filesystemzugriffen manipuliert werden. Das das früher ging war keine Absicht und eigentlich schon damals "am System vorbei".

Für "copy" (bzw "rename" um was es bisher ging) gibt es die Funktion im js-controller, sie ist aber im JavaScript Adapter noch nicht eingebaut weil Sie bisher wohl niemand gebraucht hat. Issue dazu was gern Eure Stimmen nimmt: https://github.com/ioBroker/ioBroker.javascript/issues/451 . Falls "copy" gebraucht wird wäre das ein ein js-controller Request.

Der Grund für die Limitierung sind einerseits Sicherheitsüberlegungen und das ist wie immer ein Trade-Off zwischen "Einfachheit" und "Sicherheit". Alles was im ioBroker-Store Liegt ist generell per web/vis/admin u.ä. Adapter direkt abrufbar. Es gibt leider einige Installationen die frei im Internet erreichbar sind.
Wir wollen sicherstellen das es eine bewusste Entscheidung ist welche Daten hier verfügbar sind und das auch hier das ioBroker-User- und Rechtesystem vollständig greift und genutzt werden kann. Das geht allerdings nur wenn alle Dateien sauber "offiziell" hochgeladen wurden.

Ein weiterer Grund ist das bei der Nutzung von Redis als Objects/File Store das Filesystem irrelevant ist und damit nur die Daten abgerufen werden können die auch im Redis hochgeladen wurden. Das heisst hier würden auch sämtliche Skripte die mit den nodejs-Filesystem-Funktionen arbeiten nicht mehr funktionieren. Da uns aber für alle Funktionen die Einheitlichkeit wichtig ist und, wie oben erwähnt, an den offiziellen Funktionen vorbei zu arbeiten niemals offiziell unterstützt war, haben wir uns dafür entschieden.