Beiträge von eiche

thgoebel

Jetzt geht mir Spätzünder endlich ein Licht auf. Ja klar, die Skripte von _[Deleted]_ haben mich bereits des Öfteren beeindruckt. ...

Off Topic: Schade, dass einige kreative Köpfe hier nicht mehr dabei sind.

Dieses Faktum bringt das Thema "Nicht MQTT basierte Kommunikation" auf. Man kann von einem Shelly ausgehend auch andere Shelly per URL (http) und RPC beauftragen. Solches muss nicht zwingend über MQTT laufen und ist vermutlich zügig umsetzbar.

ich will nach eintreffen der Ware mal das BLE Skript genauer ansehen und testen.

Wow, dann können wir ja mal gespannt sein ... (hoffentlich).

Dass liest sich so, als ob die Firmware eine Historie - oder ggf. Protokolleinträge (?) - im Skript Memory Bereich speicherte. Ich kenne die Hintergründe nicht, täte solches aber als Entwurfsfehler einordnen. Ohne weitere Recherche- und Analysearbeiten kann ich nur feststellen, dass mir die Speicherverwaltung derzeit als wenig/nicht transparent erscheint.

So, weitere Erfahrungen mit der Firmware - und einem meiner Skripte.

Ich stellte inzwischen fest, dass in einem meiner Skripte ein zuvor offenbar tolerierter Fehler vorlag, den ich mittlerweile korrigierte. Es war ein Fehler im Gültigkeitsbereich einer Variablen. Diesen Fehler hat die Firmware V 1.5.1 nicht mehr toleriert, vermutlich, weil der Interpreter nun Variablendeklarationen fordert.

Diesen, von mir begangenen, Fehler fand ich in meinem Skript zur Regelung eines Heizkörpers mit ausgeweiteter, skriptbasierter Webseite. Letztere erfordert viel Pufferspeicher, welcher offenbar in der Firmware Version 1.6.0-beta1 nicht mehr hinreichend zur Verfügung steht, jedenfalls nicht in einem Shelly Plus 1 (Gen. 2).

Fazit

1. Der von mir oben angemerkte Fehler lag an mir. Der Interpreter in Firmware V 1.5.1 ist offenbar strenger als in den vorhergehenden Firmware Versionen.
2. Wer speicherintensive Skripte nutzen will, sollte (zunächst) nicht über die Firmware V 1.5.1 hinausgehen. Ob die in V 1.6.0-beta1 zusätzlichen Features zwecks Speichereinsparung deaktivierbar sind, weiß ich derzeit nicht.

haitauer

Ich habe im Zuge der Shelly Osteraktion (oder ist es Jubiläum ?) u.a. zwei BLU Shelly bestellt. Bei hinreichend Muße will ich damit experimentieren.

(Ich bin langsam auf der Weg der gesundheitlichen Genesung.)

In meiner IoT Anfangszeit (ca. 2018/19) habe ich u.a. gerne ein ESP 32 Entwicklungsboard per Arduino IDE und C++ ausgiebig programmiert. Darin verwendete ich auch die MQTT Bibliothek pubsubclient. Alles lief bestens, bis ich feststellte, dass immer nach 30 Minuten der µC neu startete. Ich fand den Fehler nicht. Dann stieg ich auf Tasmota (Theo Arends Sonoff MQTT over the air) um. Dieser Umstieg war erfolgreich. Später fand ich, dass mein MQTT Problem am zu kleinen Pufferspeicher für die MQTT Kommunikation liegen musste.

Mein Verdacht, welcher sich aus alter Erfahrung, aber noch ohne Shelly BLU Kenntnisse speist

Ich vermute, dass dein MQTT queue overflow die gleiche Ursache hat. Die Shelly MQTT Kommunikation per Firmware emuliert eine Peer to Peer Kommunikation over MQTT, was zusätzlichen Speicherbedarf bedeuten müsste, da so die Payload mit mehr Daten als notwendig gefüllt wird. Dazu werde ich das seitens Shelly vorliegende Transformationsskript noch analysieren müssen.

Ich täte - und will - versuchen, den MQTT Publisher auf Skriptbasis zu implementieren. Vermutlich wird damit weniger Warteschlangen-Pufferspeicher benötigt. Außerdem kann man in einem Skript die Ausnahmebehandlung (try - catch) verwenden, um entsprechende Fehler abzufangen und MQTT Nachrichten in eine eigene Queue zu schieben. Die sich damit ergebende Verzögerungen von Nachrichten werden vermutlich kaum spürbar.

Klar, das alles sollte den/die Firmware Entwickler nicht davon befreien, hier nach Verbesserungen zu streben. Aber vielleicht kann so dein Problem gelöst werden.

Ich weiß noch nicht, wann ich dazu komme, ich denke aber an dieses Problem - schon aus meiner eigenen leidvollen Ersterfahrungen.

P.S.:
Im vorvorgehenden Forum hat mal ein, längst hier leider nicht mehr mitwirkendes Mitglied ein ganzes Framework zur technischen Kommunikation per Skript(e) zusammengestellt und gepflegt (Nickname: dekat oder de_kat). Soweit ich erinnere, arbeitete es sowohl pre (profilaktisch) als auch post (Ausnahmebehandlung). Dieses erschien mir sehr ausgereift, allerdings nutzte ich es nicht. Ob es hier noch zu finden ist, weiß ich nicht.

Noch einmal meine Frage:

Wofür willst du diesen Transformator (ob im Stecker eingebaut oder nicht ist irrelevant) einsetzen? Welches Gerät willst du damit betreiben?

Hinweis: 24V AC ist eine Wechselspannung, mit welcher du deine Shelly NICHT betreiben kannst.

Zitat von eiche

Der von dir gekaufte Trafo ist vermutlich nicht für die Bewässerungsventile vorgesehen, oder?

Kannst du bitte diese Frage beantworten? Ein Shelly ist kein Bewässerungsventil.

AC = Alternate Current = Wechselstrom/-spannung (oder alternating ?)

DC = Direction Current = Gleichstrom/-spannung

Vermutlich solltest du dir vor Ort Hilfe bei jemandem holen, der sich wenigstens etwas mit Elektrotechnik auskennt.

Huckenin

Der Shelly Plus 2PM wird entweder mit Netzwechselspannung (230V), hier nicht(!), oder mit 24V Gleichspannung betrieben. Nicht mit 24V Wechselspannung. Du brauchst somit zur Versorgung der Shelly ein Netzteil, ein Trafo genügt nicht. Das ist im Schalplan von thgoebel unten erkennbar.

Der von dir gekaufte Trafo ist vermutlich nicht für die Bewässerungsventile vorgesehen, oder?

Huckenin

Wo du die Shelly bereits hast, dürfte die einfachste Lösung in zusätzlichen externen Relais bestehen. Solche gibt es u.a. als 8er Pack auf einer Platine (China Ware) und sollten bei 24V unbedenklich einsetzbar sein. Mitunter sind auch Optokoppler an deren Eingängen vorhanden. Damit hast du eine kostengünstige Lösung und bist auf der sicheren Seite. Zudem haben solche Relais zumeist Umschaltkontakte und sind somit vielseitig nutzbar.

Falls du diese Lösung nutzen willst, sind sicherheitshalber Freilaufdioden parallel zu den Magnetventilen zu empfehlen, falls solche nicht bereits vorliegen.

Edit:

Wenn du wieder mal Ähnliches vorhast, denke daran, dass PM Shelly nicht potentialfrei schalten!

hemnes84

Hier nun das Skript V 0.5, welches immer dann drei Impulse ausgibt, wenn das Tor bereits in Zielposition steht.

Es reagiert passend auf "öffnen" und "schließen", aber noch nicht auf "stop". Falls letzteres gewünscht ist, muss dieses Skript ausgebaut werden.

// von eiche
// Datum: 2025-04-20, Version 0.5

// Die folgenden Zeitspannen sind lang gewählt, damit die Funktion gut beobachtbar ist.
// Für den regulären Betrieb sollte sukzessive festgestellt werden, mit welchen Werten die Steuerung gerade noch funktioniert
// und dann etwa die doppelten Werte gewählt werden. Vermutlich können beide Werte gleich sein.
let duration = 1000, // Impulsdauer in ms
delay = 1000; // Verzögerung für den zweiten Impuls ab Ende des ersten Impuls

let impulse = ["Cover.Open", "Cover.Close"], // Damit nicht immer dasselbe Relais schalten muss. ;-)
index = 0,
opened = false; // Zustand des Torsensors, true = geschlossen, false = geöffnet

function next_index() {
  index = (index + 1) % 2;
}

function stop() { // Schaltet das eingeschaltete Relais aus.
  Shelly.call("Cover.Stop", {id:0});
}

function impulse_end() { // Beendet den Impuls nach delay ms.
  Timer.set(duration, false, stop);
}

function impulse_out() { // Gibt einen Impuls aus.
  Shelly.call(impulse[index], {id:0},
    function(res, errc, errm) {
      if(errc) {print(errc, errm);}
      impulse_end();
    }
  );
  next_index();
}

function delayed_impulses() { // Gibt zwei Impuls verzögert aus.
  Timer.set(duration + delay, false, impulse_out);
  Timer.set(2*(duration + delay), false, impulse_out);
}

function process(ev) {
  //print(JSON.stringify(ev));
  let e = ev.info
  //print(e.component);
  if(ev.component==="input:100" && e.event==="toggle") {
   opened = e.state;
    return;
  }
  if(ev.component==="cover:0") {
    //print(e);
    if(e.event!==undefined) {
      // Bei opening und closing ist der Sensor abzufragen.
      // Es ist zu erwarten, dass der Impuls am Ausgang das Tor bewegt.
      // Soll dies nicht geschehen, werden zwei zusätzliche Impulse ausgegeben, welche das Tor wieder zurückstellen.
      switch(e.event) {
        case "opening":
          print("wird geöffnet");
          if(e.source!==undefined && e.source!=="loopback") {
            impulse_end();
            // Wenn das Tor offen ist, zwei zusätzliche Impulse ausgeben, damit es offen bleibt.
            if(opened) delayed_impulses();
          }
          next_index();
          break;
        case "closing":
          print("wird geschlossen");
          if(e.source!==undefined && e.source!=="loopback") {
            impulse_end();
            // Wenn das Tor geschlossen ist, zwei zusätzliche Impulse ausgeben, damit es geschlossen bleibt.
            if(!opened) delayed_impulses();
          }
          next_index();
          break;
        case "stopped":
          print("angehalten");
          break;
        //default: print(e.event);
      }
    }
    if(e.source!==undefined) {
      let src = "Quelle: ";
      switch(e.source) {
        case "button": src += "Taster"; break;
        case "switch": src += "Schalter"; break;
        case "loopback": src += "Skript"; break;
        case "SHC": src += "Sprachassistent -> Cloud"; break;
        default: src += e.source;
      }
      print(src);
    }
  }
}

Shelly.call("Input.GetStatus", {id:100},
  function(res, errc, errm) {
    if(errc) {print(errc, errm); return;}
    //print(res);
    opened = res.state;
    Shelly.addEventHandler(process);
  }
);

Zitat von hemnes84

das Tor schließt weil auch ein kurzer Impuls ausreicht

Dann solltest du die Zeitspannen für duration und delay deutlich reduzieren können, vielleicht auch je 100. Evtl. muss delay etwas größer sein.

Das kann ich einbauen.

hemnes84

Nach einer genaueren Analyse deines Fotos in #18 erkannte ich auch deinen offenbar zusätzlich montierten Magnetschalter rechts.

Ich bin zuversichtlich, dass beide Skripte wie gewünscht funktionieren.

Diese Übersetzung von "Run on startup" ist nicht wirklich treffend.

Es bedeutet, dass das Skript gestartet wird, wenn das kleine System hochfährt.

haitauer

Ich habe deinen Text gelesen und will noch darauf eingehen. Allerdings ging es mir heute schlecht, weshalb meine Reaktion dauern wird.

Ok. Ich habe noch nie mit den Shelly MQTT Probleme gehabt. Deshalb die Frage nach deiner Umgebung.

Bitte noch einmal alles!

1. Welche Shelly Geräte nutzt du?
2. Woraus besteht dein übergeordnetes System?
3. Warum Ist MQTT für deine Zwecke erforderlich?
4. Wie hast du auf den Shelly MQTT konfiguriert?
5. Welche MQTT Kommunikation nutzt du?
   Firmware eigene oder aus einem Skript
6. Hast du auch mal einen MQTT Shell Client verwendet, wie mosquitto_pub oder mosquitto_sub (Bei diesen Namen bin ich mir nicht ganz sicher.)
7. Was hast du ansonsten bisher getan, um die Quelle des Problems herauszufinden?

Edit:

Ich nutze keine Shelly Bluetooth (BLU) Geräte. Können diese überhaupt alle MQTT?

Zitat von SiloBau

Ich werde dem Kollegen eine Anweisung schreiben, dass er nach einem Netzausfall

den Status wieder On setzen muss.

Das ist nicht erforderlich. Die Konfiguration "Run on startup" bleibt auch bei Stromausfall erhalten. Der Shelly hat auch einen nichtflüchtigen Speicher, u.a. für solche Zwecke.

Zitat von SiloBau

Das von Eiche funzt nicht, da kommt Fehlermeldung in der Diagnose.

Etwas genauer bitte! Dass solches nicht funktioniert, ist so gut wie ausgeschlossen. Diese URL sind sehr schlicht.

Vielleicht klappt "localhost" nicht. Dann nimmt man halt die IP-Adresse 127.0.0.1. Ob das Skript läuft oder nicht, sieht man leicht in der von tvbshelly erwähnten Skript-Übersicht.

haitauer

Your nickname sounds German or Austrian. If you speak German, I would prefer the German language to go into details.

Zitat von hemnes84

Der Magnetschalter ist bei offenem Tor geschlossen.

Eine schlichte, aber wesentliche Information, welche ich bisher nicht hatte. Ich nahm einfach an, das er bei geschlossenem Tor geschlossen sei.

Beide Versionen musste ich anpassen. Da hilft auch keine ältere Skript Version.

Zuerst das zu bevorzugende Skript (Version 0.4). Dieses schaltet den Ausgabeimpuls sofort ab, wenn das Tor den Zielzustand bereits hat. Andernfalls dauert dieser Impuls so lange, wie der Wert von duration festlegt.

// von eiche
// Datum: 2025-04-15 Version 0.4

// Die Dauer eines Impulses (duration) ist lang gewählt, damit die Funktion gut beobachtbar ist.
// Für den regulären Betrieb sind vermutlich 500 ms geignet.
let duration = 2000, // Impulsdauer in ms
opened = false; // Zustand des Torsensors, true = geschlossen, false = geöffnet

function stop() { // Schaltet das eingeschaltete Relais aus.
  Shelly.call("Cover.Stop", {id:0});
}

function impulse_end() { // Beendet den Impuls nach duration ms.
  Timer.set(duration, false, stop);
}

function process(ev) {
  //print(JSON.stringify(ev));
  let e = ev.info
  if(ev.component==="input:100" && e.event==="toggle") {
    opened = e.state;
    return;
  }
  if(ev.component==="cover:0") {
    if(e.event!==undefined) {
      // Bei opening und closing ist der Sensor abzufragen.
      // Es ist zu erwarten, dass ein sehr kurzer Impuls am Ausgang wirkungslos ist.
      switch(e.event) {
        case "opening":
          if(e.source!==undefined && e.source!=="loopback") {
            if(opened) stop();
            else {
              impulse_end();
              print("wird geöffnet");             
            }
          }
          break;
        case "closing":
          if(e.source!==undefined && e.source!=="loopback") {
            if(opened) {
              impulse_end();
              print("wird geschlossen");
            }
            else stop();
          }
          break;
        case "stopped":
          print("angehalten");
          break;
        //default: print(e.event);
      }
    }
    if(e.source!==undefined) {
      let src = "Quelle: ";
      switch(e.source) {
        case "button": src += "Taster"; break;
        case "switch": src += "Schalter"; break;
        case "loopback": src += "Skript"; break;
        case "SHC": src += "Sprachassistent -> Cloud"; break;
        default: src += e.source;
      }
      print(src);
    }
  }
}

Shelly.call("Input.GetStatus", {id:100},
  function(res, errc, errm) {
    if(errc) {print(errc, errm); return;} // Ohne Endlagenschalter Abbruch
    opened = res.state;
    Shelly.addEventHandler(process);
  }
);

Fall das obige Skript nicht den gewünschten Effekt hat, bleibt die Alternative in Version 0.3. Hier wird ein zweiter Impuls nachgeschoben, wenn das Tor bereits den Zielzustand hat. Der zweite Impuls fährt das Tor wieder zurück.

// von eiche
// Datum: 2025-04-15, Version 0.3

// Die folgenden Zeitspannen sind lang gewählt, damit die Funktion gut beobachtbar ist.
// Für den regulären Betrieb sollte sukzessive festgestellt werden, mit welchen Werten die Steuerung gerade noch funktioniert
// und dann etwa die doppelten Werte gewählt werden. Vermutlich können beide Werte gleich sein.
let duration = 2000, // Impulsdauer in ms
delay = 2000; // Verzögerung für den zweiten Impuls ab Ende des ersten Impuls

let impulse = ["Cover.Open", "Cover.Close"], // Damit nicht immer dasselbe Relais schalten muss. ;-)
index = 0,
opened = false; // Zustand des Torsensors, true = geschlossen, false = geöffnet

function next_index() {
  index = (index + 1) % 2;
}

function stop() { // Schaltet das eingeschaltete Relais aus.
  Shelly.call("Cover.Stop", {id:0});
}

function impulse_end() { // Beendet den Impuls nach delay ms.
  Timer.set(duration, false, stop);
}

function impulse_out() { // Gibt einen Impuls aus.
  Shelly.call(impulse[index], {id:0},
    function(res, errc, errm) {
      if(errc) {print(errc, errm);}
      impulse_end();
    }
  );
  next_index();
}

function delayed_impulse() { // Gibt einen Impuls verzögert aus.
  Timer.set(duration + delay, false, impulse_out);
}

function process(ev) {
  //print(JSON.stringify(ev));
  let e = ev.info
  //print(e.component);
  if(ev.component==="input:100" && e.event==="toggle") {
   opened = e.state;
    return;
  }
  if(ev.component==="cover:0") {
    //print(e);
    if(e.event!==undefined) {
      // Bei opening und closing ist der Sensor abzufragen.
      // Es ist zu erwarten, dass der Impuls am Ausgang das Tor bewegt.
      // Soll dies nicht geschehen, wird ein zweiter Impuls ausgegeben, welcher das Tor wieder zurückstellt.
      switch(e.event) {
        case "opening":
          print("wird geöffnet");
          if(e.source!==undefined && e.source!=="loopback") {
            impulse_end();
            // Wenn das Tor offen ist, einen zweiten Impuls ausgeben, damit es offen bleibt.
            if(opened) delayed_impulse();
          }
          next_index();
          break;
        case "closing":
          print("wird geschlossen");
          if(e.source!==undefined && e.source!=="loopback") {
            impulse_end();
            // Wenn das Tor geschlossen ist, einen zweiten Impuls ausgeben, damit es geschlossen bleibt.
            if(!opened) delayed_impulse();
          }
          next_index();
          break;
        case "stopped":
          print("angehalten");
          break;
        //default: print(e.event);
      }
    }
    if(e.source!==undefined) {
      let src = "Quelle: ";
      switch(e.source) {
        case "button": src += "Taster"; break;
        case "switch": src += "Schalter"; break;
        case "loopback": src += "Skript"; break;
        case "SHC": src += "Sprachassistent -> Cloud"; break;
        default: src += e.source;
      }
      print(src);
    }
  }
}

Shelly.call("Input.GetStatus", {id:100},
  function(res, errc, errm) {
    if(errc) {print(errc, errm); return;}
    //print(res);
    opened = res.state;
    Shelly.addEventHandler(process);
  }
);

Für beide Skripte gilt: Da nur ein Endlagenschalter vorliegt, können die Skripte nur feststellen, ob das Tor ganz geöffnet ist oder nicht. Ist es teilweise geöffnet, wird dies als geschlossen gewertet. Dies lässt sich mit der gegebenen Ausstattung nicht ändern.