Beiträge von eiche

Ohne hier in Einzelheiten des betreffenden Skripts gehen zu wollen, fand ich ausschließlich eine Iteration über die Keys in einer definierten Map.

for(key of Object.keys(topicMap)) {
	// ...
	MQTT.publish(topic, value, mqttQOS);
	// ...
}

Diese Schleife alleine lässt zunächst kein Problem erwarten. Es bleibt noch zu prüfen, ob es gut ist, zu jedem definierten Key eine MQTT Nachricht zu senden. Ich kann das Skript leider immer noch nicht testen - kein Shelly BLU.

Meine vorläufige Strategie: Anwendungsorientierung
Das Skript ist eine Art "Eier legende Wollmilchsau". Es sollte je nach Anwendungsfall auf die erforderlichen Nachrichten (Map verkleinern) reduziert werden.

Zusätzlich ist zu prüfen, ob wenige (bis hin zu einer) MQTT Nachricht mit (je) einer JSON Payload geeignet ist und ggf. die Subscriber das Gebrauchte selektieren.

Auch wenn eine Wiederholungsstruktur in einer Ereignis gesteuerten Umgebung nicht grundsätzlich "verboten" ist, so ist sie doch mit skeptischen Blicken zu betrachten. Stattdessen lässt sich eine Kombination aus Timer und Status nutzen, welcher in der Timer callback Funktion geprüft wird ...

Hoffentlich kommen meine bestellten Teile bald an, damit ich das Skript mal selbst testen und zielführend analysieren kann.

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.