Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[ticaki]

@schmakus sagte in Script Problems javascript Instanz:

BTW: Man legt grundsätzlich keine eigene Datenpunkte in irgendwelche Adapter Instanzen an.

Wird in der Doku aber mehr oder weniger empfohlen
https://github.com/ioBroker/ioBroker.javascript/blob/master/docs/en/javascript.md#best-practice

oder ist meine Nachschlaglink veraltet?

Insgesamt 13 Treffer vielleicht mal mit search/replace drüber gehen :)

// Create state "javascript.0.counter"
createState('counter', 0);
let mySubscription = on({ id: 'javascript.0.myState', change: 'any' }, function (data) {
on({ id: "javascript.0.myState1", change: 'ne' }, function (data) {
on({ id: 'javascript.0.myState1', change: 'any' }, function (data) {
// Delete state
deleteObject('javascript.0.createdState');
Create state and object in javascript space if it does not exist, e.g. javascript.0.mystate.

[paul53]

@ticaki sagte: Wird in der Doku aber mehr oder weniger empfohlen

Dort steht nichts von Datenpunkten, sondern nur, dass man eine produktive und eine Test-Instanz verwenden soll.
Wenn eine ID nicht mit "0_userdata.0." beginnt, werden mittels createState() die Datenpunkte unter "javascript.N" erstellt. Auch setState() und getState() greifen bei verkürzter ID (ohne Instanz) auf "javascript.N.id" zu.
Das Verzeichnis "0_userdata.0" für eigene Datenpunkte kam erst im Laufe der Zeit dazu.

[ticaki]

@paul53
Jetzt weiß ich wo der Verschreiber gelandet ist:

javascript.0.userdata.0.test.test

Wenn per default in javascript. Datenpunkte erstellt werden ist sowas wie:

Man legt grundsätzlich keine eigene Datenpunkte in irgendwelche Adapter Instanzen an.

nicht gerechtfertigt. Darauf hinzuweisen ist eines, aber wenn man das grundsätzlich nicht tut, ist das default Verhalten ein Fehler.

[paul53]

@ticaki sagte: ist das default Verhalten ein Fehler.

Das Verhalten ist historisch bedingt und für die Abwärtskompatibilität erforderlich.

[Schmakus]

@ticaki sagte in Script Problems javascript Instanz:

@paul53
Jetzt weiß ich wo der Verschreiber gelandet ist:

javascript.0.userdata.0.test.test

Wenn per default in javascript. Datenpunkte erstellt werden ist sowas wie:

Man legt grundsätzlich keine eigene Datenpunkte in irgendwelche Adapter Instanzen an.

nicht gerechtfertigt. Darauf hinzuweisen ist eines, aber wenn man das grundsätzlich nicht tut, ist das default Verhalten ein Fehler.

Nein ist es nicht. Ist ein normales Verhalten wie bei allen anderen Adaptern auch.
Bei einem Adapter macht createState() einen Datenpunkt im eigenen space.
Für einen anderen spaces nutzt man createForeignObject()
Der Javascript Adapter macht es ähnlich, wobei es für den User nur createState() gibt und wenn man keinen space angibt, legt er diese halt im eigenen space an. Beugt auch Fehler vor.

Solange die Datenpunkte per Scripte erstellt werden, sind diese bei jedem Neustart des Scripts wieder vorhanden, sofern diese gelöscht wurden. Leg man jedoch händisch Datenpunkte unter javascript an, läuft man Gefahr, dass langfristig - z.B. durch ein Javascript Update - diese nicht mehr vorhanden sind. Nutzt man diese jedoch z.B. in VIS, dann geht die Fehlersuche los. (Bis dato kam das zwar noch nicht vor, aber wer weiß, ob sich nicht irgendwann was am JS Adapter ändert oder es irgendwann generell unterbunden wird.)

Ich rate deshalb, alle Datenpunkte in userdata oder alias abzulegen. Auch der Übersichtshalber sind alle am selben Ort und durch irgendwelche Adapter Updates geschützt.

[ticaki]

@Schmakus
@paul53
akzeptiert

Würde aber zu einer Empfehlung in der Doku raten.

[Homoran]

@ticaki wieso??

as told before;

@homoran sagte in Script Problems javascript Instanz:

javascript.n ist ein zulässiger Ort für eigene Datenpunkte. Jedoch nicht unter script.enabled!

die Aussage von @Schmakus ist so nicht richtig!

@schmakus sagte in Script Problems javascript Instanz:

Leg man jedoch händisch Datenpunkte unter javascript an, läuft man Gefahr, dass langfristig - z.B. durch ein Javascript Update - diese nicht mehr vorhanden sind

das gilt nur für alle anderen Adapter

[Schmakus]

@homoran sagte in Script Problems javascript Instanz:

@ticaki wieso??

as told before;

@homoran sagte in Script Problems javascript Instanz:

javascript.n ist ein zulässiger Ort für eigene Datenpunkte. Jedoch nicht unter script.enabled!

die Aussage von @Schmakus ist so nicht richtig!

Dann korrigiere mich

[Homoran]

@schmakus sagte in Script Problems javascript Instanz:

Dann korrigiere mich

hab ich doch!

@homoran sagte in Script Problems javascript Instanz:

@schmakus sagte in Script Problems javascript Instanz:

@toki1973 ohne auf dein eigentliches Problem einzugehen, solltest mal anfangen, eigene Datenpunkte unter 0_userdata.0 oder alias.0 abzulegen und nicht in der Javascript Instanz.
BTW: Man legt grundsätzlich keine eigene Datenpunkte in irgendwelche Adapter Instanzen an.

warum?
javascript.n ist ein zulässiger Ort für eigene Datepunkte. Jedoch nicht unter script.enabled!

für "irgendwelche Adapter" mag die Aussage gelten (ausser MQTT)

[ticaki]

@toki1973 sagte in Script Problems javascript Instanz:

Wie kann man denn die Datenpunkte interpretieren die in den Objekten Script Problems beschrieben sind?
Hintergrund ist das sich bei mir der javascript Adapter aufhängt und gelegentlich unbemerkt Instanzen deaktivieren.

Poste das Script, dann kann man drüber schauen und findet wohl das Problem.

@Homoran
Hab das "man erstellt keine DP unter javascript" in letzter Zeit zu oft gelesen.

[Homoran]

@ticaki sagte in Script Problems javascript Instanz:

Hab das "man erstellt keine DP unter javascript" in letzter Zeit zu oft gelesen.

Vermutlich in Verbindung mit

@homoran sagte in Script Problems javascript Instanz:

nicht unter script.enabled!

da gilt das auch.

Ansonsten wird es durch häufige Wiederholung einer falschen Aussage nicht richtiger.

[paul53]

@homoran sagte: nicht unter script.enabled!

Nicht unter "scriptEnabled"
... und auch nicht unter "scriptProblem".

[ticaki]

@homoran sagte in Script Problems javascript Instanz:

Ansonsten wird es durch häufige Wiederholung einer falschen Aussage nicht richtiger.

Wenn die Leute so bunte Tags haben, überdenkt man seine Ansicht halt :) (oder paul heißen)

[paul53]

@ticaki sagte: Würde aber zu einer Empfehlung in der Doku raten.

PR auf Github ist erstellt.