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

[ticaki]

@doppellhelix

Deshalb war einer meiner ersten Vorschläge dass du die Variablen raus wirfst - das verwirrt nur am Anfang. Für die 4 mal am Tag oder so, wo du die brauchst, kannst du es auch direkt auf dem State lesen.

State sind hier vergleichbar mit Dateisystem und Variablen sind eben ungesicherte Daten.

Deshalb

// anlegen
var daten = true;
// oder das ist dann so als wenn du die Datei einmalig einlesen würdest. Danach können andere mit dem state 
// machen was sie wollen, du musst ihn erneut lesen wenn du wissen willst was passiert ist.
var daten = getState('meineId.daten', daten);

// beschreiben
daten = false;

// speichern
setState('meineId.daten', daten);

[Doppellhelix]

@ticaki
Ja hattest du, aber zu dem Zeitpunkt war ich ja 0 im Thema drinnen und wusste nicht, was du meinstest :-)

@Asgothian
Danke für die ausführliche Erklärung.
Warum unterscheidet man des denn so?
Aus der Historie, weil Speicher früher kostbar war? Oder weil Variablen einfach schneller "im Ablauf" sind?

[Asgothian]

@doppellhelix sagte in Erste Schritte beim Scripten - Einsteigerfrage:

Warum unterscheidet man des denn so?
Aus der Historie, weil Speicher früher kostbar war? Oder weil Variablen einfach schneller "im Ablauf" sind?

Es geht nicht um Schneller oder langsamer, sondern um das richtige Werkzeug für die richtige Anwendung.

Mit Variablen können viele Dinge getan werden die mit Datenpunkten unhandlich sind und/oder Zeit und Ressourcen kosten.

Was ich in dem Post oben nicht klar erwähnt habe:
Variablen brauchen primär Speicher als Ressource. Zugriff ist billig. Insbesondere wenn es darum geht Werte aus Datenpunkten in Skripten zu nutzen erhöht die Variable den Speicherbedarf, senkt aber im Gegenzug den Ressourcenverbrauch wenn sie geändert wird.

Stell dir das ganze so vor:

• Die Variable ist eine Kreidetafel. Willst du den Wert wissen schaust du drauf. Willst du den Ändern wischt du sie aus und schreibst den neuen Wert drauf
• Datenpunkte sind Karteikarten in einem Schober. Willst du den Wert wissen schickst Du jemanden mit der ID los die Karte zu holen. Willst du den Wert anpassen musst du jemanden mit einer neuen Karte losschicken um die Karteikarte im Schober auszutauschen
• Alles was du dauerhaft erhalten willst muss auf einer Karteikarte im Schober stehen. Nur dann bleibt es erhalten.

In deinem Skript ist die Verwendung der Variablen durchaus optional. Der Vorschlag von @ticaki ist nicht schlecht, da der 'gewinn' in deinem Beispiel sehr gering ist.

In einem anderen Beispiel sieht das aber dann anders aus:

• stell dir vor du hast einen Datenpunkt Energielimit. Damit steuerst du ab wie viel Energieüberschuss du das Auto laden willst.
• Jetzt machst du einen Trigger: - jedes mal wenn sich der Energieüberschuss ändert willst du wissen ob er über dem Limit liegt. Wenn du da das Limit jedes mal aus dem Datenpunkt holst ist das schon signifikant mehr Ressourcenverbrauch als das ganze einmal zu holen und in einer Variable abzulegen, mit die du den geänderten Energieüberschuss vergleichen kannst.

A.
(Ja, das Bild vereinfacht, hilft aber)

[Homoran]

@asgothian sagte in Erste Schritte beim Scripten - Einsteigerfrage:

Es geht nicht um Schneller oder langsamer,

naja, je nach Anwendungsfall schon.

@Doppellhelix
JS Scripte arbeiten asynchron, dh. sie warten nicht unbedingt auf die Abarbeitung des gerade ausgeführten Befehls, sondern führen direkt den nächsten aus.

Wenn jetzt der Bote mit der letzten Karteikarte noch unterwegs ist, hat der, der den Wert nachsehen will, u.U. noch den alten Wert.
Hier ist die Kreidetafel die bessere Methode, weil schneller.

[Asgothian]

@homoran sagte in Erste Schritte beim Scripten - Einsteigerfrage:

naja, je nach Anwendungsfall schon.

Den Anwendungsfall wo 3 oder 4 ms wichtig sind würde ich gerne kennenlernen.

Ironie aussen vor gelassen - das Problem mit dem Zeitverbrauch ist die Asynchronität - dafür gibt es inzwischen Lösungen im JS adapter. Ich gehe auch davon aus das die Laufzeit zum holen eines States inzwischen so kurz ist das der Effekt nur auf sehr langsamen Systemen sichtbar bleibt.

Bleibt die Ressourcenthematik.

A.
Nachtrag - Der test stammt aus einer älteren Version des JS Adapters - da war das noch so. Inzwischen hat der JS Adapter die Asynchronität über interne promises abgedeckt - der Test geht also schief. Um den OP nicht zu verwirren hier den Code nur hinterm Spoiler:

Spoiler

Hier klappt sind die Werte nicht gleich

let tmp = 0
for (let I=1; I<100;I++) {
   const rndVal = Math.random();
   setState('0_userdata.0.floatTest', rndVal);
   const state = getState('0_userdata.0.floatTest', (err, obj) => { 
       console.warn(`values: ${obj.val} ${rndVal} ${(rndVal ==  obj.val)}`) });
}

Hier sind sie es immer.

for (let I=1; I<100;I++) {
   const rndVal = Math.random();
   setState('0_userdata.0.floatTest', rndVal);
   const obj = getState('0_userdata.0.floatTest')
   console.warn(`values: ${obj.val} ${rndVal} ${(rndVal ==  obj.val)}`);
}

[Homoran]

@asgothian sagte in Erste Schritte beim Scripten - Einsteigerfrage:

Inzwischen hat der JS Adapter die Asynchronität über interne promises abgedeckt

again what learned ;-)
auch bei Blockly?

[ticaki]

@asgothian sagte in Erste Schritte beim Scripten - Einsteigerfrage:

@homoran sagte in Erste Schritte beim Scripten - Einsteigerfrage:

naja, je nach Anwendungsfall schon.

Den Anwendungsfall wo 3 oder 4 ms wichtig sind würde ich gerne kennenlernen.

Ironie aussen vor gelassen - das Problem mit dem Zeitverbrauch ist die Asynchronität - dafür gibt es inzwischen Lösungen im JS adapter. Ich gehe auch davon aus das die Laufzeit zum holen eines States inzwischen so kurz ist das der Effekt nur auf sehr langsamen Systemen sichtbar bleibt.

Der State wird meines wissens nach nicht aus der DB sondern aus dem Cache geholt, solange die Option dazu nicht abgeschaltet wird. Das sorgt nur für Probleme wenn du objekte löschst oder erstellst, da hilft dann ein sleep().

Nur um das in Zahlen zu packen:

128 µs

let b = 0;
for (let a = 0; a < 10000; a++) {
    b += a;
}

54 ms

// b wurde vor dem messen initialisiert
for (let a = 0; a < 10000; a++) {
    b = getState('0_userdata.0.testNumber').val;
    b += a;
    setState('0_userdata.0.testNumber', b)
}

Es ist egal, man schreibt es so das man es später auch nochmal lesen kann.

[Doppellhelix]

Jetzt ist es mir klarer.

Wie ich den Thread angefangen habe, war mir der Unterschied ja überhaupt nicht bewusst.
Deswegen stand ich wohl auch gewaltig auf dem Schlauch und hab mich mehrmals gefragt, was ihr da überhaupt redet :grin:
Jetzt macht das alles einen Sinn.

[fuzzy1955]

@paul53
Hallo Paul,

dein Vorschlag mit den CONST-Variablen der DP-Definition ist wirklich in vielen Skripten eine super Möglichkeit, um die Übersichtlichkeit zu gewährleisten! Bei Änderungen in Datenpunktnamen braucht man nur am Anfang des Skripts zu schauen.

:blush: Fuzzy

[Doppellhelix]

Guten Morgen,

durch einen kleinen Hardwarefehler, musste ich mit iobroker auf neue Hardware umziehen.
Dieses Script hier, habe ich einfach per Copy+Paste rüber kopiert.
Die 0_userdata.0.reducedCharging habe ich angelegt.

Dennoch läuft das Script nicht richtig:

var reducedCharging = getState('0_userdata.0.reducedCharging'/*reducedCharging*/).val; 
console.info('reduced charging is '+reducedCharging);

schedule({astro: "sunrise"}, function () {
    var msgText = "Akkustand bei Sonnenaufgang: " + getState('modbus.0.inputRegisters.13022_Battery_level_'/*Batteriekapazität*/).val + "%";
    var forecast = getState('pvforecast.0.summary.energy.today'/*Geschätzte Energie (heute)*/).val;
    if (forecast > 20000) {
        setState('modbus.0.holdingRegisters.33046_Max_Charging_Power'/*Max Ladeleistung*/, 10);
        setState('telegram.0.communicate.response', forecast + "Wh Ertrag erwartet. Reduziere Ladeleistung auf 10W bis 11 Uhr");
        reducedCharging = true;
    } else {
         setState('modbus.0.holdingRegisters.33046_Max_Charging_Power'/*Max Ladeleistung*/, 10600);
         setState('telegram.0.communicate.response', forecast + "Wh Ertrag erwartet. Lade Akku sofort mit voller Leistung");
         reducedCharging = false;
    }
    setState('0_userdata.0.reducedCharging'/*reducedCharging*/, reducedCharging);
    log(msgText);
    setState('telegram.0.communicate.response', msgText);
    });


schedule({hour: 11, minute: 0}, function () {
    if (reducedCharging) {
        setState('telegram.0.communicate.response', "Starte laden des Akkus mit 1 kW");
        log("Set max_charge_power to 1kW");
        setState('modbus.0.holdingRegisters.33046_Max_Charging_Power'/*Max Ladeleistung*/, 1000);
           }
});

Bei Sonnenaufgang wird alles gecheckt.
Heute morgen ist der erwartete Ertrag (pvforecast.0.sumary.energy.today bei 20083
Dennoch sagt das Script:

"Akkustand bei Sonnenaufgang: 66,3%"
"20083 Wh Ertrag erwartet. Lade Akku sofort mit voller Leistung."

Auch die reduced Charging wurde nicht gesetzt.

Ich habe auch @paul53 "optimiertes" Script 1zu1 eingefügt uns ausprobiert.
Auch dieses macht den gleichen "Fehler"

Könnt Ihr bitte noch einmal nachschauen, was hier gerade falsch läuft?

Vielen Dank.

[Doppellhelix]

@doppellhelix

Nach langer Sucherei habe ich es gefunden.
Ich hatte im Adapter pv.forecast nicht den Haken gesetzt bei: "Werte in W statt kW."

:face_palm: