Beiträge von eiche

Kurze Rückmeldung zur bisherigen Problemlösung

Ich habe das Skript umgeschrieben und bin damit zufrieden.

Auch nehme ich die Vermutung (vorläufig) zurück, dass die Firmware ursächlich für das Problem ist.

Jedenfalls lag die Stelle des Auftretens irgendwo im event handling.

Mein Skript nutzt nun den ursprünglichen schedule job und zwecks Erfassung des Schaltens das event handling.

Ich danke Devil und Seven of Nine für ihre Beteiligungen an diesem Thread.

Bei Interesse an diesem kleinen Projekt stelle ich meine Lösung gerne zur Verfügung.

Es soll dem Steuern von älteren elektrischen Nebenuhren dienen können.

Mir stellt sich die Firmware 0.14.1 als instabil dar.

Warum?

Folgende Konstellation:

Schedule Jobs:

{"jobs":[
{"id":1,"enable":false,"timespec":"0 * * * * *","calls":[{"method":"Script.Eval","params":{"id":1,"code":"clockTrigger(5000)"}}]},
{"id":2,"enable":true,"timespec":"0 * * * * *","calls":[{"method":"Switch.Set","params":{"id":0,"on":true}}]}
], "rev":6}

Ohne ein gestartetes Skript tut der Shelly seinen Job gemäß seines Schedule Job 2. Auch das konfigurierte automatische Abschalten nach 5s funktioniert.

Dann sperre ich wieder das automatische Abschalten und starte das folgende Skript:

 Shelly.addEventHandler(
  function (event) {
    //print(JSON.stringify(event));
    Timer.set(5000, false,
      function () {
        Shelly.call("Switch.Toggle", {"id":0},
          function (res) {
            //print(JSON.stringify(res));
          }
        );
      }
    );
  }
);

Nun ereignen sich in kürzeren Abständen, also deutlich unter 1 Minute Ein- und Ausschaltvorgänge - mehrmals hintereinander.

Ein und sofort danach wieder aus.

Die Ausgaben per print habe ich zur Sicherheit auskommentiert.

Zuvor zeigten sie die eintreffenden zu erwartenden Schaltereignisse.

Ich werde erneut andere typgleiche Shellies testen - mit unterschiedlichen Firmware Versionen.

Edit:

Das obige Skript ist nicht gut zusammengestellt. Der Timer sollte Event selektiv gestartet werden.

Allerdings sah ich ausschließlich die Schaltevents ...

Ich arbeite weiter daran.

So, ich habe soeben einen zweiten Schedule Job angelegt mit:

http://<ip-address>/rpc/Schedule.Create?enable=true&timespec="0 * * * * *"&calls=[{"method":"Switch.Set","params":{"id":0,"on":true}}]

Und prompt ereignet sich beim Einschalten der bereits geschilderte Skriptabbruch mit derselben Fehlermeldung.

Ein Eventhandling zum Einschalten habe ich noch nicht eingebaut.

Da bleibt mir nur noch der Schluss, dass hier ein Fehler in der Firmware vorliegt.

Mich würde nun noch interessieren, welche Konstellation dazu führt.

Ich habe ein anderes Projekt vorläufig erfolgreich abgeschlossen, welches einen Shelly Plus 1 mit Sensor Addon und einem Ventilantrieb als autarken Thermostat betreibt - ohne irgendeinen Skriptabbruch.

Und jenes Projekt ist deutlich komplexer als dieses hier mit dem von mir oben beschriebenen Skript.

Inzwischen habe ich den ersten Schedule Job disabled. Trotzdem derselbe Fehler.

Ich werde nun sukzessive und kleinschrittig ein neues Skript aufbauen, um zu sehen, wann sich dieser Fehler einstellt.

Ich hatte übrigens auch mal den Shelly gewechselt, also einen typgleichen eingesetzt.

Ich werde den Schedule Job so ändern, dass er die Methode Switch.Set mit {"id":0, "on":true} aufruft und im Eventhandler die Rückmeldung des Schaltens nutzen, um den Puls zu stoppen.

Meine bisherige Lösung gefällt mir aber besser, weil man so die Pulsdauer parametrieren kann, ohne das Skript zu manipulieren.

Wenn dies gelingt, kann ich ja noch Kommunikation einbauen, damit der Anwender die Pulsdauer darüber konfigurieren kann.

Das hatte ich zunächst so. Ich neige durchaus auch zu anonymen Funktionen.

Dann las ich während meiner Fehlersuche in den Dokus, dass es in der Tiefe von anonymen Funktionen Beschränkungen gibt und lagerte sie in benannte Funktionen aus.

Leider half auch das nicht.

Außerdem lasse ich das Skript laufen, ohne zu schalten. So läuft es seit Stunden ohne Unterbrechung durch, wie ich in den Datenbankaufzeichnungen sehen kann.

Mit den Callbacks von Shelly.call hatte ich dasselbe Problem.

Ja, mit großen Anfangsbuchstaben hatte ich begonnen.

Meiner Erfahrung nach sind die Methodennamen case unsensitiv.

In anderen Projekten funktioniert das Schalten fehlerfrei auch mit Kleinschreibung.

Btw, der Shelly schaltet mitunter (oder immer?) noch, bevor das Skript abbricht.

Somit ist es kaum möglich, dass der Methodenaufruf fehlerhaft ist.

Tja ...

Danke für die Reaktionen.

Devil

Das große S hat leider keine Besserung gebracht.

Seven of Nine

Oh ja, klar - mit http:// - ich war zu diesem Zeitpunkt schon etwas abgearbeitet.

Nun, mit Switch.toggle hatte ich bereits gearbeitet - leider das selbe Problem wie mit Switch.set.

Merkwürdig ist auch, dass beide Schaltaufrufe in einem anderen Projekt keinerlei Probleme bereiten. So etwas gehört ja auch zu den absoluten basics.

Ich versuchte es soeben mit http.get und komplettem URL. Leider genau dasselbe Problem, Skriptabbruch mit obiger Fehlermeldung.

Es sieht so aus, als ob der RPC-Methodenaufruf ein Problem darstellt, unabhängig vom Weg dorthin.

Hallo,

Ich entwickle eine Anwendung für Shellies der zweiten Generation mit per Scheduling ausgelöstem Schalten.

device: shelly plus 1

firmware: 0.14.1, alternativ getestet mit 0.13.0

Mein schedule job:

{"id":1,"enable":true,"timespec":"0 * * * * *","calls":[{"method":"Script.Eval","params":{"id":1,"code":"clockTrigger(5000)"}}]}

Dieser bewirkt zu jeder vollen Minute den Aufruf der Funktion clockTrigger mit 5000 (ms) als Parameter, welche das unten stehenden Skript enthält.

Und hier mein bisheriges Skript:

let debug = true; // set to false if no need for prints

let Config = {
  ClockEvent: "trigger",
  PubTopic: "develop/event"
};

let Status = {
  ScriptId: null, // the id of this script, using in schedule job
  PulseTs: null // last clock trigger timestamp, in development use ram instead of nvs
};

// script.eval function to trigger the clock pulse
function clockTrigger (duration) {
  Shelly.emitEvent("clock", {key:Config.ClockEvent, value:duration});
  return duration;
}

// get the stored timestamp of a clock event
function getPulseTs () {
  return Status.PulseTs; // in release get the timestamp from KVS
}

// put the new timestamp of a clock event
function putPulseTs (ts) {
  Status.PulseTs = ts; // in release put the timestamp into KVS
}

function pulseOut(duration) { // simulation
  if (debug) print("pulse on");
  //Shelly.call("switch.set", {"id":0, "on":true});
  //Shelly.call("http.get", {url: "127.0.0.1/rpc/switch.set?id=0&on=true"});
  MQTT.publish(Config.PubTopic, '{"pulse":true}');
  Timer.set(duration, false,
    function(){
      if (debug) print("pulse off");
      //Shelly.call("switch.set", {"id":0, "on":false});
      //Shelly.call("http.get", {url: "127.0.0.1/rpc/switch.toggle?id=0"});
      MQTT.publish(Config.PubTopic, '{"pulse":false}');
    }
  );
}

// the handler of a clock event
function clockEvent (data) { // send clock pulse
  if (debug) print("clock event: ", JSON.stringify(data));
  // get the time difference from last clock pulse to now
  let Last = getPulseTs();
  let dt = null;
  if (Last!==null) dt = data.ts - Last;
  if (dt!==null) {
    if (debug) print("dt: ", dt);
    // do something with the information in dt
    let missing = Math.round(dt/60) - 1;
    if (missing>0) {
      if (debug) print("missing pulses: ", missing);
      // send the missing pulses
      
    }
  }
  putPulseTs(data.ts);
  pulseOut(data.data.value);
}

// the event handler of this script
Shelly.addEventHandler(
  function (event) {
    if (event.info.data.key===Config.ClockEvent) {
      clockEvent(event.info);
      return;
    }
    if (debug) print(JSON.stringify(event));
    
  }
);

// get the id of this script for extensions in future
Status.ScriptId = Shelly.getCurrentScriptId();

Der Abbruch des Skript ereignet sich in der Funktion pulseOut, wenn geschaltet wird - Zeilen 31 und Zeilen 37.

Das Skript arbeitet einwandfrei, wenn die Schaltmethodenaufrufe auskommentiert sind.

Die Methoden http.get habe ich nur zwecks Fehlersuche eingesetzt. Sie sind also nur alternativ zu switch.set bzw. switch.toggle zu verstehen.

Wenn ich die Schaltmethoden einbaue, bspw. per switch.set, gibt es den Skriptabbruch mit der Fehlermeldung:

"onEvent callback error: type error"

Ich kann keinen Typfehler finden. Dieser müsste sich in den Shelly.call Aufrufen zum schalten befinden, da ohne diese Aufrufe das Skript fehlerfrei abgearbeitet wird.

Manchmal erscheint diese Meldung beim Einschalten, spätestens nach dem Ausschalten - verlässlich reproduzierbar.

Mir fällt nichts mehr ein, was ich noch tun kann, um diesen Fehler zu beseitigen oder mich der Ursache zu nähern.

Da ich über keine solcher Uhren verfüge, kann ich selbstverständlich nur simulieren.

Sobald deine vorläufige Entscheidung für eine Shelly-Implementation feststeht, lasse mich das bitte wissen!

Ich möchte meine Zeitinvestition ungerne für die Tonne leisten, auch wenn dies letztlich nicht total ausgeschlossen werden kann.

Hierfür wird die Firmware aller Wahrscheinlichkeit nach ein "shifting" einsetzen. Dies sorgt dafür, dass ein solcher KVS-Eintrag nach und nach an verschiedenen Stellen im NVS geschrieben wird. Bei geringer NVS Auslastung kannst du somit mal eben einen Faktor 1000 oder mehr einsetzen.

Nachgereicht:

Vielleicht würde ich für dich bei Muße ein solches Skript erstellen.

horkatz

Wenn ich es richtig verstand, dann werden die Nebenuhren ohne eigenes "Zeitgerät" von der Masteruhr gesteuert.

Hier eine SPS einzusetzen, halte ich für sehr übertrieben - um es vorsichtig auszudrücken.

Mit jeweils einem Shelly könnten die Nebenuhren auch relativ autonom betrieben werden.

Ein Shelly kann leicht, auch ohne Programmierung (s.a. Projekt von Th. Goebel) sehr präzise jede Minute - oder auch bspw. jede Sekunde - einen Schaltvorgang auslösen/durchführen.

Zur Umstellung zwischen "Sommerzeit" und physikalischer Zeit kann ein Skript erstellt werden - von wem auch immer.

Dieses Skript kann zu bekannten Umstellzeiten die Nebenuhr vorstellen oder für eine Stunde anhalten.

Ob diese Umstellzeiten gleich bleiben, weiß ich derzeit nicht, vermute es aber.

Wie du die Zeitsynchronisation per Zeitserver realisierst, bleibt dir überlassen.

Prinzipiell wäre es auch möglich, hierfür die Impulse der Masteruhr einzusetzen, was jedoch ziemlich retrospektiv wäre.

Um die Dauer eines Stromausfalls zu erfassen - und die Nebenuhr nachzustellen, wäre in den Shellies immer der letzte Unix-Zeitstempel zu einem Nebenuhr-Schaltimpuls im nichtflüchtigen Speicher (nvs = non volatile storage) abzulegen. Auch dies wäre prinzipiell noch ohne Skriptprogrammierung möglich. Hierfür sind aber Kenntnisse zu den RPC (remote procedure calls) erforderlich, welche von der Firmware bereitgestellt sind.

In der Firmware von Allterco wird statt nvs die Bezeichnung KVS verwendet - key value storage. key value bezeichnet allerdings eine Datenstruktur, auf deren Elemente (Werte) per key zugegriffen wird.

Nachteil: Der nvs verträgt deutlich weniger Schreibzugriffe als der flüchtige Speicher, auch als RAM geläufig.

Dieser kleine Nachteil ist aber vermutlich nicht entscheidend.

Jedenfalls kann der Shelly per Skript zu jedem erfassten Unix-Zeitstempel die ausgefallenen Minutentakte an die Nebenuhr ermitteln und diese quasi nachreichen.

Versuch eines relativ simplen Lösungsentwurfs:

Lichtschranke, durch welche das Pendel "läuft" oder Reflektionslichtschranke.

Die Impulse (von Lichtschranke) werden im Shelly (oder anderem Mikrocontroller) gezählt.

Der Zählerstand wird mit der vergangenen Zeit verglichen und gelegentlich bzw. bei zu großer Abweichung das Pendel temporär angehalten.

Für diesen Zweck sollte die Uhr also ein klein wenig schneller laufen.

Ich möchte das Prinzip "inkrementale Regelung" nennen - ohne Kenntnis davon, ob es so etwas im Sprachgebrauch gibt.

thgoebel

Kann eine solche Uhr ihre eigene Zeit irgendwie elektronisch mitteilen oder sie entsprechend ergänzt werden, um eine solche Mitteilung zu erhalten?

Dann sollte es mit deiner Steuerung eine Lösungsmöglichkeit geben.

Btw, ich kenne solche, von dir erwähnten, Pendel leider nicht.

horkatz

Ich kenne die "Innenleben"/Beschaltung solcher Uhren nicht. Vielleicht fiele mir eine Lösung ein, wenn du diese Uhren genauer beschreibst. Insbesondere, was an Funktionalitäten darin steckt, wäre hierfür wichtig zu wissen.

@dekat win

Vielen Dank für deine Reaktion. Stimmt, ich könnte versuchen, das selbst zu ermitteln. Allerdings könnte ich so nur die Phänomene erkennen und müsste interpretieren.

Ok, das ist wohl ein etwas ungewöhnliches Thema.

Mein Projekt:

Nutzen eines Shelly Plus 1 mit Addon und DHT 22 zwecks autarker, lokaler Temperaturregelung (Heizkörper/Raum).

Hierfür werde ich KVS und insbesondere den Scheduler nutzen. Letzterer kann ja mehr als nur Wochenpläne, auch wenn die für Anwender genügen.

Ich entwickle daran, bis schon soweit fertig - außer Komfortfunktionen.

Der wichtige Nebeneffekt daran ist, dass ich während der Implementation und Verbesserungen die Firmware genauer kennenlernen muss(te).

Mir gefällt sie immer besser. Ich möchte selbstverständlich auch eine sehr hohe Funktionssicherheit erreichen.

Dann können solche Shellies locker die TRV ablösen.

Meine Projektlösung wird stabiler arbeiten, immer erreichbar sein, zügig reagieren und erweiterbar sein.

Ok, ein angepasstes Webinterface fehlt. Hierfür habe ich ein Node-RED Dashboard erstellt.

Ob es möglich ist, per Skript ein solches Webinterface zu implementieren, weiß ich derzeit nicht.

Btw, ich nutze teilweise noch Shellies der 1. Gen. mit Addon. Die Regelung findet per Node-RED Flows statt. Das ist nicht ganz gut, weil die Autarkie der Shellies fehlt.

Ok, wegen des repeat=true Parameters. Einverstanden

thgoebel

Ganz wie du willst. Trotzdem könntest du mal folgendes testen:

http://<ip-address>/rpc/Schedule.Create?timespec="0 * * * * *"&calls=[{"method":"Switch.Set", "params":{"id":0,"on":true,"toggle_after":10}}]

Dies erstellt auf deinem Shelly einen Schedule-Eintrag. Dieser Eintrag bewirkt zu jedem Sekundenstand von 0, also jede abgelaufene Minute, das Auslösen der Methode Switch.Set mit den angegebenen Parametern.

Der Default-Wert von enable ist true, könnte aber auch zwischen dem timespec- und dem calls-Teil eingefügt werden. Das ist eher interessant, wenn man testen will, ob Schedule.Create erfolgreich abgearbeitet wurde, ohne den Eintrag zu aktivieren.

http://<ip-address>/rpc/Schedule.Create?timespec="0 * * * * *"&enable="false"&calls=[{"method":"Switch.Set", "params":{"id":0,"on":true,"toggle_after":10}}]

Das zusätzlich Interessante daran ist, dass es verlässlich funktioniert und du kein Skript hierfür benötigst.

Die Einschaltdauer von 10s ist selbstverständlich für den Test gedacht. Hier wirst du für den Betrieb bspw. eher 1 einsetzen.

Willst du diese Dauer oder andere Dinge im selben Schedule-Eintrag ändern, brauchst du dessen id dazu. Diese erhältst du mit

http://<ip-address>/rpc/Schedule.List

Angenommen, diese id ist 1, dann änderst du obige Einschaltdauer auf 1s mit

http://<ip-address>/rpc/Schedule.Update?id=1&timespec="0 * * * * *"&calls=[{"method":"Switch.Set",%20"params":{"id":0,"on":true,"toggle_after":1}}]

Die kürzere Variante lautet:

http://<ip-address>/rpc/Schedule.Update?id=1&calls=[{"method":"Switch.Set",%20"params":{"id":0,"on":true,"toggle_after":1}}]

Es muss nur das angegeben werden, was im Schedule-Eintrag zu ändern ist. In diesem Fall muss es der gesamte calls-Teil sein.

Das Ganze lässt sich auch per MQTT und RPC gestalten, ebenfalls ohne Skript.

Ich betone noch einmal, dass für diesen Zweck Timer.set suboptimal ist.

Hinweis: Der Scheduler ist Teil des Betriebssystems mongoose und entspricht dem von Unixen, also bspw, Linux.

Gruß aus Rheinland-Pfalz

Ich würde dafür den Scheduler einsetzen, der zu jeder Sekunde 0 (oder bspw. 59) die Script.Eval Methode aufruft und die entsprechende Funktion im Skript dazu schreiben. Es geht selbstverständlich auch ohne Script.Eval, wenn eine passende andere Methode greift. Der Scheduler bekäme dann folgenden timespec: 0 * * * * * - oder statt der 0 die 59, wenn du eine Sekunde Reserve einbauen willst.

Die RPC Methode heißt Schedule.Create oder Schedule.Update, falls der Zeitplan bereits existiert.

Wenn du direkt mit dem Schelly 2. Gen. schalten willst, geht selbstverständlich auch die Methode Swich.Set ...

Die RPC Schedule Methoden sind unter https://shelly-api-docs.shelly.cloud/gen2/Component…vices/Schedule/ recht gut beschrieben.

Ein Timer.set würde ich dafür nicht einsetzen, weil es vermutlich sukzessive zu Verzögerungen käme. Der Scheduler ist dafür bestens geeignet.

Btw. ich implementiere gegenwärtig ein Thermostat auf Basis eines Shelly Plus 1 mit Sensor AddOn, dem Scheduling für Zeitpläne und zwei Skripten, welche die Funktion der Initialisierung und Temperaturregelung sowie deren Parametrierung realisieren. Ich priorisiere MQTT, es geht aber auch all das per HTTP. Alles funktioniert bereits bestens - auf dem Labortisch (hier eine Fensterbank ;-)). Die Mensch-Maschinen-Schnittstelle ist auch fertig (per Node-RED Dashboard, von meiner Frau akzeptiert). Ich werde aber noch überarbeiten und Komfortfunktionen einbauen. Deshalb habe ich mich eingehend mit RPC, KVS, Scheduling, Script.Eval und der Skriptfunktion Shelly.emitEvent() beschäftigt.

Falls du genaueres bzw. fertig nutzbares von mir haben möchtest, muss ich den genauen Kontext kennen.

daniel b

Unter settings -> "Movement time limits"

Ich habe so etwas bisher nicht gebraucht, da meine Rollladenantriebe hinreichend kompatibel zur Shelly Firmware sind.

Ich weiß also nicht, ob du damit weiterkommen kannst. Ich würde es damit versuchen.

Vermutlich könntest du mit diesen Einstellungen allenfalls komplett öffnen und schließen - ungetestet.

daniel b

Zitat

Aus deinem Log: "data": "shelly_notification:161 Status change of cover:0: {\"id\":0,\"errors\":[\"cal_abort:implausible_power_consumption_in_close_dir\"],\"state\":\"closed\"}\n"

Vermutlich hat die Firmware ein Problem mit einer Nichtrollladenanlage wie in deinem Fall. Hast du mal mit "Reverse Direction" experimentiert? Dein Kettenantrieb ergibt im Lastmoment vermutlich kaum Unterschiede zwischen öffnen und schließen. Die Firmware kann evtl. deshalb nicht erkennen, ob das Fenster geöffnet oder geschlossen wird. Vielleicht kannst du ohne Kalibrierung auskommen und die reinen Bewegungsdauern händisch eintragen.