Erste Schritte beim Scripten - Einsteigerfrage
-
Im Grunde genommen soll das Script dafür sorgen, dass die PV Anlage nicht in die 70% Abregelung kommt.
Wenn gutes Wetter ist (pvForecast > 20000 W), dann wird das wahrscheinlich passieren.
Im normalfall wird mit den ersten Sonnenstrahlen der Speicher geladen. Dieser ist um 10 Uhr voll und ab dann wird voll eingespeist.
Indem das Speicherladen verhindert und erst ab 11 Uhr freigegeben wird, umgeht man die 70% Abregelung. Alles über 70% geht dann in den Speicher und nicht ins Netz.@paul53
Klasse. Danke dir.
Das nehme ich gerne mit, sobald ich weiß was da genau passiert.@alle anderen.
Danke für eure Einsatz. -
Nicht das es immer stimmt, aber chatgpt kann man für das erklären von Code eigentlich ganz gut gebrauchen und dann mit den gewonnen Fachbegriffen suchen, ob es nicht mal wieder nur viel Worte gemacht hat.
-
Hallo,
das Script hat leider noch einen kleinen Fehler drin.
Nochmal eine kurze Funktionsbeschreibung:
Bei Sonnenaufgang wird gecheckt, wieviel Sonnenertrag die PV Anlage erwartet.
Liegt der Ertrag über 20000, wird die Ladeleistung für den Battereispeicher zu laden auf 10 gedrosselt, und die Variable reducedCharging auf true gesetzt.
Um 11 Uhr wird die Ladeleistung auf 2000 angehoben.
Wenn keine 20000 zu erwarten sind, bleibts beim Standartwert 10600.Das Problem ist, dass scheinbar immer um 11 Uhr auf 2000 gestellt wird. Und das, obwohl reducedCharging false ist.
Als Beispiel gestern und heute.
Ich bekam eine Telegram Nachricht, dass die 20000 nicht zu erwarten sind.
Um 11Uhr bekam ich dann die Nachricht, dass mit 2000 geladen wird.
Die Ladeleistung steht auch tatsächlich auf 2000 aber die Variable reducedCharging steht auf false.Hat jemand eine Idee, was da falsch läuft?
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('mqtt.0.evcc.site.prioritySoc'/*evcc/site/prioritySoc*/, 0); setState('telegram.0.communicate.response', forecast + "Wh Ertrag erwartet. Reduziere Ladeleistung auf 100W bis 11 Uhr"); setState('0_userdata.0.reducedCharging'/*reducedCharging*/, true); } else { setState('modbus.0.holdingRegisters.33046_Max_Charging_Power'/*Max Ladeleistung*/, 10600); //setState('mqtt.0.evcc.site.prioritySoc'/*evcc/site/prioritySoc*/, 30); setState('telegram.0.communicate.response', forecast + "Wh Ertrag erwartet. Lade Akku sofort mit voller Leistung"); setState('0_userdata.0.reducedCharging'/*reducedCharging*/, false); } 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 2 kW"); log("Set max_charge_power to 2kW"); setState('modbus.0.holdingRegisters.33046_Max_Charging_Power'/*Max Ladeleistung*/, 2000); //setState('mqtt.0.evcc.site.prioritySoc'/*evcc/site/prioritySoc*/, 30); } }); -
@doppellhelix sagte: Hat jemand eine Idee, was da falsch läuft?
Du schreibst zwar zum Sonnenaufgang den Datenpunkt "0_userdata.0.reducedCharging", setzt aber nicht die Variable
reducedCharging, die um 11:00 Uhr geprüft wird. Siehe Zeile 14 in meinem Vorschlag. -
@paul53 said in Erste Schritte beim Scripten - Einsteigerfrage:
@doppellhelix sagte: Hat jemand eine Idee, was da falsch läuft?
Du schreibst zwar zum Sonnenaufgang den Datenpunkt "0_userdata.0.reducedCharging", setzt aber nicht die Variable
reducedCharging, die um 11:00 Uhr geprüft wird.Wird das nicht in Zeile 11 gemacht?
setState('0_userdata.0.reducedCharging'/*reducedCharging*/, true); -
@doppellhelix sagte: Wird das nicht in Zeile 11 gemacht?
Nein, es wird nur der DP geschrieben, aber nicht die Variable gesetzt.
-
Wie schon erwähnt - Variable setzen Variable schreiben - nicht Variable setzen Wert schreiben.
-
@paul53 said in Erste Schritte beim Scripten - Einsteigerfrage:
@doppellhelix sagte: Wird das nicht in Zeile 11 gemacht?
Nein, es wird nur der DP geschrieben, aber nicht die Variable gesetzt.
Boah, ich werde kirre.....
Ist das nicht das Selbe?z.b. in Zeile 8, wird mit setState eine Variable auf den Wert 10 gesetzt.
Das funktioniert.
Warum funktioniert das nicht in der Zeile 11?Bitte erklärs mir.
-
@doppellhelix sagte in Erste Schritte beim Scripten - Einsteigerfrage:
Ist das nicht das Selbe?
nicht bei ioBroker
Datenpunkte enthalten "dauerhaft" gespeicherte Werte, die dem ganzen ioBroker Universum zur Verfügung stehen.
Variablen existieten nur in dem Skript, und das auch nur bis zum Neustart
-
Ok, das ist ein Hinweis, den ich mir aufschreiben sollte.
Ich denke Zeile 11 ist der Knackpunkt. Aber wie muss es dann richtig sein?
Ich habe u.a. hier eine Anleitung für den Syntax benutzt, aber da stehts so drin, wie ich es gemacht habe.
https://www.kreyenborg.koeln/wissensdatenbank/wert-in-datenpunkt-schreiben/ -
@doppellhelix sagte in Erste Schritte beim Scripten - Einsteigerfrage:
Boah, ich werde kirre.....
Ist das nicht das Selbe?z.b. in Zeile 8, wird mit setState eine Variable auf den Wert 10 gesetzt.
Das funktioniert.
Warum funktioniert das nicht in der Zeile 11?Bitte erklärs mir.
Du vermischt 2 unterschiedliche Dinge:
- Variablen (definiert via
letodervarim Skript (Z.Bsp. Zeile 1) sind Platzhalter die ausschliesslich innerhalb des Skriptes definiert sind. Sie haben einen (einfachen) Namen nur dann einen Wert wenn dieser nach Start des Skriptes auch 'gesetzt' wird. Diesen kann man einfach direkt einen Wert zuweisen, bzw. den Wert direkt abfragen (Bsp: Zeile 1 für eine Zuweisung, Zeile 10 für eine 'abfrage' - Datenpunkte (oder auch States) - Definiert als Objekte im Objektbaum. Um mit diesen zu Arbeiten musst du einen Aufruf an die Objekt-Datenbank machen (
getState) Sie haben verschiedene Eigenschaften:
-- die ID, die beigetState,setStateoderongenutzt wird
-- einen Wert (val) - Siehe Zeile 1, 5 oder 6.
-- ...
Das was du in Zeile 1 (oder 5,6) machst, ist den Wert eines Datenpunktes in einer Variablen zu speichern. Wohlgemerkt nur den Wert des Datenpunktes zu diesem Zeitpunkt. Es gibt keine verbindung zwischen Variable und Datenpunkt.
Was du in Zeile 11 machst ist einen Datenpunkt mit einem neuen Wert zu beschreiben. Dadurch bleibt aber die Variable reducedCharging unverändert. Willst Du diese auch verändern musst du das explizit tun - idealerweise bevor du den Datenpunkt aktualisierst.if (forecast > 20000) { setState('modbus.0.holdingRegisters.33046_Max_Charging_Power'/*Max Ladeleistung*/, 10); //setState('mqtt.0.evcc.site.prioritySoc'/*evcc/site/prioritySoc*/, 0); setState('telegram.0.communicate.response', forecast + "Wh Ertrag erwartet. Reduziere Ladeleistung auf 100W bis 11 Uhr"); reducedCharging = true; } else { setState('modbus.0.holdingRegisters.33046_Max_Charging_Power'/*Max Ladeleistung*/, 10600); //setState('mqtt.0.evcc.site.prioritySoc'/*evcc/site/prioritySoc*/, 30); setState('telegram.0.communicate.response', forecast + "Wh Ertrag erwartet. Lade Akku sofort mit voller Leistung"); reducedCharging = false } setState('0_userdata.0.reducedCharging'/*reducedCharging*/, reducedCharging);Zum Thema was nutz ich wann:
- Variablen:
- Variablen verbrauchen etwas Speicher, aber beim Zugriff fast keine Laufzeit.
- Variablen werden bei jedem Start es Skripts neu initialisiert. Wenn das Skript dieses nicht tut, dann mit dem Wert
undefined - Der code
let Testvar = 0; for (let I=1, I<100,i++) { const oldVal = Testvar Testvar = Math.random(); console.warn('values: ' + Testvar + ' ' + oldVal) }liefert 100 Zeilen mit jeweils 2 Zahlenpaaren - diese sind immer unterschiedlich.
- Datenpunkte
- Datenpunkte liegen in der Objekt-DB. Sie verbrauchen im Skript erst einmal keinen eigenen Speicher - der ist schon in der Objekt-DB enthalten
- Der Wert eines Datenpunktes b leibt über Skript- und ioBroker-Neustarts erhalten
- der Code
let rndVal = 0; for (let I=1; I<100;i++) { rndVal = Math.random(); setState('0_userdata.0.floatTest', rndVal ) console.warn('values: ' + getState('0_userdata.0.floatTest').val + ' ' + rndVal) }(Zum Probieren musst du einen Datenpunkt 0_userdata.0.floatTest als typ Numerisch anlegen.)
liefert 100 Zahlenpaare, wobei die Zahlen manchmal gleich und manchmal unterschiedlich sind! (Abhängig von Rechenleistung, Größe der Objektdatenbank, etc...)
A.
- Variablen (definiert via
-
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); -
@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? -
@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) -
@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. -
@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:
-
@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? -
@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.
-
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
Jetzt macht das alles einen Sinn. -
@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.
Fuzzy
