Beiträge von towiat

Hallo familieschaal ,

Ich habe mir das durch den Kopf gehen lassen und ich sehe keinen Sinn darin, das in diesem Script zu integrieren. Abgesehen von den Konsequenzen für die Programmierung (das Script müsste, abhängig von der Präsenz des Temperatursensors, unterschiedlich agieren) und für die Benutzerfreundlichkeit (die Konfiguration wäre ebenfalls unterschiedlich und komplexer) ist eine temperaturbezogene Steuerung auch einfach nicht der Zweck dieses Scriptes.

Das Script soll sich ausschließlich um die preisbasierte Steuerung kümmern - und die Wärmepumpe muss ja in irgendeiner Form sowieso temperaturbezogen agieren (und den Energiebedarf selbsttätig reduzieren, wenn kein Heizbedarf besteht).

Natürlich besteht immer die Möglichkeit das Script selbst anzupassen, aber in die von mir gepflegte "Standardversion" werde ich das nicht aufnehmen.

In der Diskussion im Thread FritzBox reconnect über Script hat ostfriese erwähnt, dass bereits öfters nach einem Script gefragt wurde, das eine FRITZ!Box rebooten kann. Nachdem ich gerade in der Materie drin war, habe ich noch ein bisschen recherchiert und in den folgenden Links Vorlagen gefunden, die ich für den Shelly adaptieren konnte:

https://www.media-techport.de/2023/08/fritzb…ipt-neustarten/

https://forum.heimnetz.de/threads/repeat…en-tr-064.1061/

Das folgende Script kann zumindest eine 6490 Cable erfolgreich rebooten:

let user = "";
let password = "";
let host = "fritz.box";
let port = 49000;

function reboot() {
 Shelly.call(
   "HTTP.Request",
   {
     method: "POST",
     url: "http://" + user + ":" + password + "@" + host + ":" + port.toString() + "/upnp/control/deviceconfig",
     headers: {
       "Content-Type": 'text/xml; charset="utf-8"',
       SoapAction: "urn:dslforum-org:service:DeviceConfig:1#Reboot",
     },
     body: [
       '<?xml version="1.0" encoding="utf-8"?>',
       '<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">',
       "  <s:Body>",
       '    <u:Reboot xmlns:u="urn:dslforum-org:service:DeviceConfig:1"></u:Reboot>',
       "  </s:Body>",
       "</s:Envelope>",
     ].join(""),
   },
   function (response, error_code, error_message) {
     if (error_code !== 0) {
       print("Call failed with error " + error_code + " (" + error_message + "). ");
     } else if (response.code !== 200) {
       print("Fritzbox responded with HTTP code " + response.code + " (" + response.message + "). ");
     } else {
       print("Fritzbox response: " + response.body);
     }
   },
 );
}

reboot();

Da der Reboot offenbar zwingend eine Autorisierung erfordert, müssen Benutzer und Passwort im Klartext im Script eingetragen werden - ob das klug ist, muss jeder selber wissen ;-).

Ich bitte um Feedback, falls das Ding auf anderen Modellen nicht funktionieren sollte - ich bin kein großer Fritzbox-Experte, aber ich werde mein Bestes tun ;).

Jep - hat bei 3 von 3 Versuchen funktioniert. Die Antwort der Fritzbox war jeweils ein freundliches Bestätigungs-XML:

Interessant - konnte es jetzt doch noch nachstellen und bei mir klappt es:

Ich kann das bei mir nicht testen, aber vielleicht gibt die Response einen Hinweis:

function sendReconnect(host, port) {
 Shelly.call(
   "HTTP.Request",
   
   {
     method: "POST",
     url: "http://" + host + ":" + port.toString() + "/igdupnp/control/WANIPConn1",
     headers: {
       "Content-Type": 'text/xml; charset="utf-8"',
       SoapAction: "urn:schemas-upnp-org:service:WANIPConnection:1#ForceTermination",
     },
     body: [
       '<?xml version="1.0" encoding="utf-8"?>',
       '<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">',
       "  <s:Body>",
       '    <u:ForceTermination xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"/>',
       "  </s:Body>",
       "</s:Envelope>",
     ].join(""),
   },
   
   function (response, error_code, error_message) {
     if (error_code !== 0) {
       print("Call failed with error " + error_code + " (" + error_message + "). ");
     } else if (response.code !== 200) {
       print("Fritzbox responded with HTTP code " + response.code + " (" + response.message + "). ");
     } else {
       print("Fritzbox response: " + response.body);
     }
   },
 );
}

sendReconnect("fritz.box", 49000);

Ich verstehe nicht, warum das nicht gehen sollte - das ist doch nur ein POST-Request mit ein paar Headern und einem String als Payload?

Das müsste in dieser Richtung funktionieren (komplett ungetestet und ohne jegliche Haftung ;)):

function sendReconnect(host, port) {
 Shelly.call("HTTP.Request", {
   method: "POST",
   url: "http://" + host + ":" + port.toString() + "/igdupnp/control/WANIPConn1",
   headers: {
     "Content-Type": 'text/xml; charset="utf-8"',
     SoapAction: "urn:schemas-upnp-org:service:WANIPConnection:1#ForceTermination",
   },
   body: [
     '<?xml version="1.0" encoding="utf-8"?>',
     '<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">',
     "  <s:Body>",
     '    <u:ForceTermination xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"/>',
     "  </s:Body>",
     "</s:Envelope>",
   ].join(""),
 });
}
sendReconnect("fritz.box", 49000);

Die charCodeAt() Methode gibt direkt den Wert eines Zeichens als Integer zurück. Kombiniert mit einer for...of Loop könnte man das dann z. B. so formulieren:

let testString="\x00190aZ\xFF";

for (let char of testString) { 
  print("Character: ", char, "Number: ", char.charCodeAt(0)); 
};

Das produziert den gleichen Output wie deine Version und ist etwas kürzer...

Hallo E-Mix142 ,

Es gibt derzeit keine Konfigurationsmöglichkeit für den anzusteuernden Switch, aber du kannst das gewünschte Resultat erzielen, indem du die Zeile 48 im Script von

  Shelly.call("Switch.Set", { id: 0, on: value }, function (result, error_code) {

auf

  Shelly.call("Switch.Set", { id: 1, on: value }, function (result, error_code) {

änderst.

Ich werde in einer der nächsten Versionen eine entsprechende Konfigurationsvariable einbauen.

Viel Erfolg!

markus.guertler

Sehr mysteriös - nur zur Sicherheit zwei Grundsatzfragen:

1. Ist die Firmware des Shelly aktuell (sollte 1.4.4. sein)?
2. Ist die Systemzeit des Shelly korrekt?

Beides wird in der letzten Zeile des WebUI angezeigt. Wenn die Antwort auf beide Fragen ja ist, bräuchte ich die Logeinträge des Shelly zum Abfragezeitpunkt. Die findest du unterhalb des Scriptes (bitte die Checkbox "ONLY SCRIPT LOGS" deaktivieren):

Die Einträge werden bei der planmäßigen Abfage um 15:00 geschrieben und nachdem das Log eine begrenzte Kapazität hat wäre es am besten, wenn du es genau zu diesem Zeitpunkt abfragst.

markus.guertler

Das Datum 01.01.1970 und der Preis Infinity deuten tatsächlich darauf hin, dass das Script keine Preisdaten vom API bekommen hat. Das könnte am Timing der Abfrage liegen - könntest du mir dein Setup (also alle Konfigurationsvariablen) hier reinkopieren?

Dass das API die Preise in EUR/MWh liefert ist dem Script bekannt und kein Problem.

akreienbring

Nachdem sich mein Script ausführlich mit Datums- und Zeitproblemen beschäftigt und ich hier zufällig reingestolpert bin:

Eigentlich sollte es reichen, wenn du die Zeile

const nCurrentDateTime = (Shelly.getComponentStatus("sys").unixtime + 2 * 3600) * 1000;

durch die Zeile

const nCurrentDateTime = Date.now();

ersetzt.

Date.now() liefert den UNIX-Zeitstempel der Systemzeit. Über den Konstruktor new Date() kann ein Zeitstempel direkt in ein Datumsobjekt in der lokalen Zeitzone umgewandelt werden. Und von diesem Datumsobjekt kann man über den Aufruf der getTime() Methode wiederum den UNIX-Zeitstempel extrahieren. Als Beispiel:

let nowTimestamp = Date.now();                    // UNIX-Timestamp der Systemzeit
let nowDatetime = new Date(nowTimestamp);         // Datum in der lokalen Zeitzone
let nowDatetimeTimestamp = nowDatetime.getTime(); // UNIX-Timestamp des Datums
print(nowTimestamp === nowDatetimeTimestamp);     // true

Stromopa

Danke für das Feedback - freut mich, dass es nützlich ist.

Ich werke gerade an einer neuen Version und das von dir gewünschte Feature ist dabei im Plan. Es wird einen alternativen Berechnungsmodus geben, bei dem das Script die Stromzufuhr zu den günstigsten x Stunden des Zeitfensters einschaltet (auch wenn sie nicht zusammenhängen), womit dann automatisch die teuersten Stunden ignoriert werden.

Ich kann noch nicht sagen, wann die neue Version herauskommt - wenn es so weit ist, werde ich das natürlich hier bekannt geben.

beeMitch - danke für das Feedback!

Ich würde das verwendete API tatsächlich gerne auf energy-charts.info umstellen, weil das Script dann europaweit verwendbar wäre und nicht nur in Deutschland und Österreich. Rein von der Programmierung her wäre der API-Wechsel in zehn Minuten erledigt - leider gibt es dabei ein praktisches Problem:

Laut meinen Tests ist das energy-charts API sehr unzuverlässig. API-Aufrufe enden immer wieder in Timeouts und auch der Zeitpunkt, an dem die Preise für den nächsten Tag verfügbar sind, ändert sich jeden Tag - im Gegensatz zum Awattar-API, das offenbar steinstabil läuft und verlässlich um 15:00 die Preisdaten hat.

Das Script in seiner derzeitigen Form kann mit dieser Unsicherheit aus strukturellen und technischen Gründen nicht umgehen - die praktische Konsequenz eines einfachen API-Wechsels wäre, dass es an einer signifikanten Anzahl von Tagen einfach nicht funktionieren würde.

Ich arbeite an einer neuen Version, die konzeptionell völlig anders aufgezogen und in vielen Belangen resilienter ist (und es mir auch erlaubt, ein paar neue Features einzubauen). Ich kann aber derzeit nicht sagen, wann diese Version das Licht der Welt erblickt...

TomPu31

Ein User in einem anderen Forum hat ein ähnliches Problem gemeldet (sein Shelly stolpert über eine Codezeile, die auf meinem Shelly problemlos läuft).

Ich habe das Script so abgeändert, dass dieses konkrete Problem nicht mehr auftreten kann - bitte versuch es noch einmal mit der aktuellen Version.

HighFive

Zitat

Was spricht dagegen, wenn beispielhaft kein KVS vorhanden d.h. beim ersten Start einmal diesen Aufruf automatisch auszuführen?

Zwei Dinge sprechen dagegen:

Zum einen könnte das dazu führen, dass das Shelly-Limit von 5 Timern pro Script gerissen wird:

• der Aufruf von calculate() analysiert das nächste Zeitfenster und setzt zwei Timer
• dann kommt der planmäßige Aufruf via Schedule, der (abhängig vom Installationszeitpunkt) noch einmal dasselbe Zeitfenster beackert und nochmals zwei Timer (für dieselben Zeitpunkte) setzt
• und diese vier Timer können (abhängig von den Berechnungsergebnissen) noch immer aktiv sein, wenn am Folgetag der nächste planmäßige Aufruf zwei weitere Timer hinzufügt

Das derzeitige Design des Scriptes stellt implizit sicher, dass maximal vier Timer gleichzeitig aktiv sein können.

Das zweite Problem ist, dass beim Aufruf von calculate() die Preisdaten für das nächste Zeitfenster möglicherweise noch gar nicht existieren. Wenn du das Script vor 14:00 installierst, gibt es die Preise für den nächsten Tag noch nicht und dementsprechend würde die Preisanalyse dann scheitern (und die Benutzer wären erst recht verwirrt).

Ich habe versucht, das Verhalten nach der Installation in der Doku zu erklären - mehr wird es wohl nicht werden, weil es ein ziemlicher Aufwand wäre, die obigen Spezialkonstellationen algorithmisch abzufangen und den Benutzern verständlich zu machen.

Aber das Problem von TomPu31 ist ja, dass das Script mysteriöserweise stoppt und das ist ja eine andere Baustelle...

TomPu31

Ein sofortiger Abbruch des Scriptes passiert normalerweise, wenn ein schwerer und offensichtlicher Programmierfehler im Script vorliegt. Das würde dann aber bei jedem Start des Scriptes bei allen Anwendern passieren - also auch bei meinen Tests (wo das natürlich nicht aufgetreten ist).

Eine mögliche Ursache wäre, dass beim Kopieren des Scriptes auf deinen Shelly etwas schiefgegangen ist - hast du den alten Code komplett entfernt, bevor du die neue Version reinkopiert hast? Bzw. könntest du das noch einmal versuchen?

Falls das Problem weiter auftreten sollte, könntest du direkt nach dem Start auf den Diagnostics Tab gehen und schauen, ob du da einen Fehler siehst? Der könnte z. B. so ausschauen:

Hallo TomPu31 ,

Na das ging ja schnell . Wenn du im Script Fenster auf 'Start' drückst, solltest du im darunter liegenden 'Console' Fenster eventuelle Fehlermeldungen sehen können. Siehst du da etwas?

Das Script ist umgezogen!

Ich habe das Script vom bestehenden Github Gist in ein vollwertiges Github Repository überführt.

In diesem Zuge habe ich die Dokumentation aus dem Script herausgenommen und in die README Datei überführt. Damit ist sie jetzt umfangreicher und (hoffentlich) besser strukturiert. Außerdem ist ein vollwerrtiges Repo für mich als Entwickler praktischer, weil ich diverse Konfigurations- und Tooleinstellungen inkludieren kann.

Im Zuge des Umzugs habe ich auch den Code überarbeitet und restrukturiert. An der bestehenden Funktionalität hat sich dadurch (hoffentlich ) nichts geändert und laut meinen Tests funktioniert alles wie gehabt.

Neues Feature: Preislimit

Es gibt eine neue Konfigurationsvariable namens priceLimit. Damit kann man einen Maximalpreis definieren (z. B. 10 cent/kWh). Wenn der günstigste berechnete Durchschnittspreis höher ist als dieses Limit, wird die Stromzufuhr für das aktuelle Zeitfenster nicht eingeschaltet (und die Nachrichten im KVS bzw. über Telegram informieren den Benutzer auch darüber).

In der Grundeinstellung ist das Preislimit nicht aktiv.

Der neue Link zum Script ist hier:

https://github.com/towiat/spotelly

Der alte Link bleibt aktiv, enthält aber nur noch einen Verweis auf den neuen Standort.

Ich bitte um Rückmeldung, falls die neue Version unerwarteterweise Probleme machen sollte...

Viel Spaß!

TomPu31

Hallo Thomas,

Grundsätzlich bearbeitet das Script nur ein Zeitfenster und teilt die Einschaltzeiten nicht auf. Wenn du die Einschaltdauer (switchOnDuration) auf z. B. drei Stunden setzt, schaltet es stur den günstigsten Dreistundenblock innerhalb des definierten Zeitfensters.

Du kannst aber auf dem Shelly bis zu fünf Scripte gleichzeitig laufen lassen und es hindert dich nichts daran, zwei Versionen dieses Scriptes mit unterschiedlichen Einstellungen zu.betreiben.

Wenn du z. B. die günstigsten vier Stunden während des Tages und die günstigsten drei Stunden während der Nacht nutzen willst, könntest du das Script einmal mit den diesen Einstellungen installieren:

// finde den günstigsten Vierstundenblock im Zeitraum von 6:00 bis 18:00
let switchOnDuration = 4;
let timeWindowStartHour = 6; 
let timeWindowEndHour = 18;

Dann installierst du das Script ein zweites Mal mit den folgenden Einstellungen:

// finde den günstigsten Dreistundenblock im Zeitraum von 18:00 bis 6:00
let switchOnDuration = 3;
let timeWindowStartHour = 18; 
let timeWindowEndHour = 6;

Damit kümmert sich Script 1 um die Tages- und Script 2 um die Nachtzeiten.

Ich habe so ein Setup eine Zeit lang bei mir laufen lassen und das funktionierte problemlos. Du solltest nur darauf achten, dass sich die Zeitfenster der beiden Instanzen nicht überschneiden, weil sich sonst die berechneten Ein- und Ausschaltzeiten überschneiden könnten.

Für weitere Fragen stehe ich natürlich zur Verfügung...

Turbinendriver

Freut mich, dass das Script nützlich ist!

Wenn das Script erfolgreich einen Zeitplan berechnet, sollte das Ein- und Ausschalten der Stromzufuhr eigentlich problemlos funktionieren. Ein möglicher Grund für das Unterbleiben der Schaltung wäre, wenn der Shelly selbst kurzzeitig von der Stromversorgung getrennt oder aus einem anderen Grund neu gestartet wurde. Dann würden die vom Script gesetzten Timer verloren gehen und die Schaltung würde erst nach dem nächsten planmäßigen Scriptdurchlauf wieder funktionieren.

Wenn du Telegram aktiviert hast und die Variablen sendPowerOn und sendPowerOff auf true stehen, solltest du zu den berechneten Schaltzeiten Nachrichten erhalten, die dir sagen, dass die Stromzufuhr ein-/ausgeschaltet wurde.

Bezüglich Anleitung und Fehlersuche habe ich ein paar Ideen, um das besser und verständlicher zu gestalten - sobald es etwas zu berichten gibt, werde ich das hier tun.