Beiträge von towiat

Genau - für mich als elektrotechnisch Ahnungslosen: nach Einfügen dieser Zeile steht der Switch mit diesem Setup für vier Stunden auf OFF und für den Rest der Zeit auf ON.

Hallo Coloschni ,

Freut mich, dass es nützlich ist.

Um die Schalterlogik umzudrehen, müsste man exakt eine Zeile ins Script einfügen und zwar in der Funktion set:

function set(val) {
  val = !val;  // <---- Diese Zeile muss eingefügt werden
  if (Shelly.getComponentStatus("switch", switchID).output === val) return; 
  let msg = val ? "ON." : "OFF.";
  let flag = val ? sendPowerOn : sendPowerOff;
  Shelly.call("Switch.Set", { id: switchID, on: val }, function (res, errc) {
    if (errc === 0) {
      log("Switch " + switchID + " has been turned " + msg, flag);
    } else {
      log("ERROR: Switch " + switchID + " could not be turned " + msg, flag);
    }
  });
}

Damit wird EIN auf AUS umgedreht und umgekehrt. In allen anderen Aspekten verhält sich das Script genauso wie vorher.

Ist das das was du wolltest oder habe ich dich falsch verstanden?

Ich habe Version 3.0 des Scriptes mit einigen signifikanten Änderungen und Verbesserungen veröffentlicht. Hier ist das Changelog:

• Neu: Verbessertes Rebootverhalten
  Nach einem Neustart des Shelly wird der Start des Scriptes nun so lange verzögert, bis der Shelly die erste Synchronisation der Systemzeit erfolgreich abgeschlossen hat.
• Neu: Verbessertes Verhalten beim ersten Start
  Wenn das Script nach 15:00 Uhr gestartet wird, beginnt es nun sofort mit dem ersten Berechnungslauf und wartet nicht mehr bis zum nächsten Tag.
• Geändert: Preisdatenabruf
  Es werden nun immer die Preisdaten für den gesamten Kalendertag abgerufen, nicht nur für das definierte Zeitfenster.
• Geändert: Definition von Zeitfenstern
  Es ist nicht mehr möglich, Zeitfenster zu definieren, die über Mitternacht hinausgehen. Zeitfenster müssen nun immer am selben Kalendertag beginnen und enden.
• Neu: Fallback
  Wie bisher startet das Script den ersten Abruf für die Preise des nächsten Tages um ca. 15:00. Sollte der Abruf scheitern (Preisdaten noch nicht verfügbar, Internet/Netzwerk Störung oder technische Probleme des API-Servers), wird er in Abständen von 20 Minuten so lange wiederholt, bis er erfolgreich ist.
  
  Wenn um ca. 23:45 noch immer kein Abruf erfolgreich war, stoppt das Script die Abrufversuche und greift (wenn aktiviert) auf fix hinterlegte statistische Preise zurück, die aus den Marktdaten des Jahres 2024 für die deutschen und österreichischen Märkte errechnet wurden.
  
  Das soll sicherstellen, dass der angeschlossene Verbraucher auch bei fehlenden Preisdaten mit Strom versorgt wird. Weitere Details sind in der Beschreibung der neuen Konfigurationsvariable `useFallback` zu finden.
• Geändert: Anzeige der nächsten Updatezeitpunktes
  Der Zeitpunkt des nächsten geplanten Updates wird nun in einer separaten Statusleiste im Web UI des Scriptes angezeigt.
• Neu: Anzeige von Anzahl und Durchschnittspreis
  Die Anzahl und der durchschnittliche Preis der aktivierten Stunden werden nun in der Statusleiste des Web UI angezeigt.
• Neu: Farbcodierung
  Die Einträge in der Stundentabelle des Web UI sind nun - abhängig von der Höhe des Stundenpreises - auf einer Grün-Gelb-Rot-Skala eingefärbt.
• Neu: Manuelle Bearbeitung
  Die vom Script berechneten aktivierten Stunden können nun im Web UI geändert werden. Jeder Eintrag in der Stundentabelle ist mit einem Schalter versehen, mit dem die Stromabgabe für die entsprechende Stunde nach Belieben (de)aktiviert werden kann.

Das Web UI des Scriptes sieht nun so aus:

Das Script ist wie immer auf GitHub zu finden: https://github.com/towiat/spotelly

Für Wünsche, Fragen und Anregungen stehe ich wie immer zur Verfügung...

Du kannst HTTP.GET nicht direkt aufrufen - Aufrufe von RPCs müssen über Shelly.call durchgeführt werden. Mit diesem Code sollte es klappen:

Shelly.call("HTTP.GET", { url: WEBHOOK_URL }, function (res, err) {
 if (err) {
   print("Fehler beim Senden des Requests: ", err);
 } else {
   print("Webhook gesendet, Antwortcode: ", res.code);
 }
});

tvbshelly Ah, thanks for clearing that up - now I can stop worrying about having hallucinations...

Is this about the image in entry #2? Because it displays fine for me:

Zitat von eiche

Wenn das "muss" durch ein "kann" ersetzt wird, passt es.

Nein, die Request ID ist zwingend erforderlich:

Ich glaube, die Verwirrung bei den IDs entsteht dadurch, dass das von thgoebel gepostete curl-Beispiel das JSON-RPC Protokoll verwendet.

In diesem Protokoll muss jedem Request eine (frei vergebbare) ID mitgegeben werden, mit der man - wenn nötig - den Request an den Shelly mit dessen Response abgleichen kann. Diese ID hat aber nichts mit der ID des abgefragten Objekts zu tun. Siehe dazu auch das GetConfig Beispiel aus der JSON-RPC Dokumentation:

{
   "jsonrpc":"2.0",
   "id": 1,  // Das ist die (frei vergebbare) ID des Requests
   "src":"user_1",
   "method":"Switch.GetConfig",
   "params": {
      "id":2  // Das ist die ID des abgefragten Switches
   }
}

Bei HTTP GET requests und auch bei direkten Shelly.Call Abrufen gibt es diese ID natürlich nicht und daher sieht das dort dann auch anders aus...

Zitat von tvbshelly

Ich mache hier routinemäßig immer Anführungszeichen drum, dann muss man nicht nachdenken, ob der Key erlaubt ist oder ggf. nicht

Ich hab's mir eh gedacht, aber der Pedant wollte unbedingt raus . Ich überlasse das Anführungszeichenthema der Entwicklungsumgebung - die kümmert sich gern darum...

Zitat von tvbshelly

Bei Shelly.call gibt es auch noch eine Kleinigkeit, der Key id muss in Anführungszeichen:

<Pedantenmodus EIN>

Anführungszeichen sind hier nicht nötig. Bei Attributnamen werden Anführungszeichen nur dann benötigt, wenn der Name nicht den JavaScript-Konventionen für Variablennamen entspricht (z. B. weil er Leerzeichen oder Bindestriche enthält).

<Pedantenmodus AUS>

jwka61

Zusätzlich zu den geteilten Dokumentationen kannst du einen Shelly mit http://ipdesshelly/rpc/Shelly.ListMethods auch direkt nach den RPCs fragen, die dieses konkrete Gerät unterstützt.

Für eine generalisierte Lösung die alle Möglichkeiten abdecken soll, wäre es vielleicht eine gute Idee, generell das JSON-RPC Protokoll zu verwenden, so wie es in der Dokumentation beschrieben ist: https://shelly-api-docs.shelly.cloud/gen2/General/RPCProtocol.

MandiNice

Ich habe eh nichts Schlechtes über UDP gesagt . Aber ich scheine dich falsch verstanden zu haben - mein Eindruck war, dass du eine direkte Antwort auf das UDP Datagram erwartet hast. Aber wie ich sehe, hat sich das Problem eh schon erledigt...

Zitat von MandiNice

Warum kommt dann per UDP nix zurück ?

Weil UDP ein verbindungsloses Protokoll ist. UDP-Pakete werden "auf gut Glück" losgeschickt und der Zielrechner kann gar nicht antworten, weil das im Protokoll einfach nicht vorgesehen ist - dass dabei Pakete sang- und klanglos verschwinden können, wird bei UDP bewusst in Kauf genommen.

Der entsprechende WIkipedia Artikel sagt das noch deutlicher:

Zitat

UDP ist ein verbindungsloses, nicht-zuverlässiges und ungesichertes wie auch ungeschütztes Übertragungsprotokoll. Das bedeutet, es gibt keine Garantie, dass ein einmal gesendetes Paket auch ankommt, dass Pakete in der gleichen Reihenfolge ankommen, in der sie gesendet wurden, oder dass ein Paket nur einmal beim Empfänger eintrifft. Es gibt auch keine Gewähr dafür, dass die Daten unverfälscht oder unzugänglich für Dritte beim Empfänger eintreffen. Eine Anwendung, die UDP nutzt, muss daher gegenüber verlorengegangenen und unsortierten Paketen unempfindlich sein oder selbst entsprechende Korrekturmaßnahmen und ggf. auch Sicherungsmaßnahmen vorsehen.

Wie AlexAn schon gesagt hat: Wenn du eine gesicherte und verifizierbare Kommunikation brauchst, kannst du UDP nicht verwenden, weil das buchstäblich der Idee von UDP widerspricht.

Zitat von eiche

Und an euch beide: 10 s sind 10000 ms und nicht etwa 6000 ms.

Ich habe keine Ahnung, warum du mir das sagst - ich habe den 6000er Timer aus dem Originalscript übernommen und weder angenommen noch behauptet, dass das zehn Sekunden sind.

Titty-Twister Ah, ok - hab noch mal geschaut und da ist ein kleines Hoppala drin. Ich hab versehentlich den Timer auf 60000 gesetzt - damit würde das Script nur in Abständen von einer Minute laufen. Wenn du willst, kannst du das korrigieren, in dem du Timer.set(60000, true, processTimer); auf Timer.set(6000, true, processTimer); änderst.

Titty-Twister Mein Script wäre als kompletter Ersatz für deine Version gedacht gewesen. Aber wenn das Script von eiche deine Anforderungen erfüllt passt das schon so und ich halte mich raus, um den Thread nicht weiter zu verkomplizieren (ich verstehe aus dem Gesprächsverlauf heraus schon nicht, wie wir jetzt bei boolescher Algebra gelandet sind...).

Ich habe das Script umformuliert, weil deine Version mit hoher Wahrscheinlichkeit nicht das tut, was du erwartest.

Das Problem ist (und darüber stolpern viele Neulinge), dass JavaScript nicht wartet, während du die Abfragen an den Pro2 schickst - statt dessen läuft das Script in der Zwischenzeit einfach weiter. Für dein Script bedeutet das:

function startControl() {
  // Setze eine Funktion zur regelmäßigen Überprüfung alle 10 Sekunden
  Timer.set(6000, true, function() {
    updateSwitchStatus(); // Frage Switch 0 vom Pro2 ab
    updateSwitchStatus2(); // Frage Switch 1 from Pro2 ab
    // Die folgenden beiden Zeilen werden ausgeführt, bevor der PRO2 geantwortet hat
    print("Das Netz wurde", switch_status ? "auf Netzbetrieb" : "auf Akkubetrieb", "umgeschaltet");
    setRelayState(switch_status && switch_status2); // Aktualisiere den gewünschten Relaiszustand
  });
}

Das bedeutet, dass dein Script nicht auf den aktuellen Stand des Pro2 reagiert, sondern auf den Stand vom letzten Durchlauf (also sechs Sekunden früher).

Wenn du das vermeiden willst, musst du die Statusabfrage im Callback der Abfrage verarbeiten (was die Hauptänderung in meiner geposteten Version ist). Wenn dich diese Verzögerung nicht stört, kannst du natürlich auch damit leben...

Der folgende Code sollte funktionieren und (auf etwas einfachere Art) exakt das tun, was deine derzeitige Version macht (machen sollte).

Allerdings sagst du, dass du den Pro 1 einschalten willst, wenn beide INPUTS des Pro2 AUS sind - derzeit fragst du aber ab, ob die OUTPUTS EIN sind. Ist das Absicht oder missverstehe ich da etwas?

const shelly2_ip = "192.168.120.161";

function processTimer() {
 Shelly.call(
   "HTTP.GET",
   
   { url: "http://" + shelly2_ip + "/rpc/Shelly.GetStatus" },
   
   function (res1, error_code1, error_message1) {
     if (error_code1 !== 0) {
       print("Fehler beim Call:", error_code1, "-", error_message1);
       return;
     }
     
     let response = JSON.parse(res1.body);
     
     let switch_status = response["switch:0"].output;
     print("Netzspannung1:", switch_status ? "Eingeschaltet" : "Ausgeschaltet");
     
     let switch_status2 = response["switch:1"].output;
     print("Netzspannung2:", switch_status2 ? "Eingeschaltet" : "Ausgeschaltet");
     
     // ergibt diese Meldung Sinn?
     print( "Das Netz wurde", switch_status ? "auf Netzbetrieb" : "auf Akkubetrieb", "umgeschaltet");
     
     let state = switch_status && switch_status2;
     
     Shelly.call("Switch.Set", { id: 0, on: state }, function (res2, error_code2, error_message2) {
       if (error_code2 !== 0) {
         print("Fehler beim Schalten des Relais Starkstrom:", error_message2);
       } else {
         print("Starkstrom:", state ? "Eingeschaltet" : "Ausgeschaltet");
       }
     });
   },
 );
}

// Setze eine Funktion zur regelmäßigen Überprüfung alle 10 Sekunden
Timer.set(60000, true, processTimer);

Hallo Pit38 ,

Das Script sollte funktionieren - die Meldung "Call may not work as expected" ist eine Macke in der Firmware ohne reale Auswirkung. Das kannst du überprüfen, indem du schaust, ob der Output zu den angegebenen Zeiten ein- und ausgeschaltet wird. Falls dem nicht so ein sollte, melde dich bitte!

Kurzer Hinweis für alle österreichischen Benutzer des Scriptes:

Derzeit funktioniert die Kalkulation in der aktuellen Version des Scriptes nicht, weil das API keine Preisdaten für Österreich (und einige andere Länder) liefert. Für Benutzer in Deutschland tritt das Problem nicht auf.

Ich werde das weiter beobachten...