Beiträge von eiche

Zitat von Jo_Be

LWT-Nachrichten sind Nachrichten, die sich der Broker merkt.

Was hat dieses mit deren Inhalt zu tun? Meine Antwort: Nichts

Btw., auch retained Nachrichten speichert der Broker.

Zitat von Jo_Be

Das trifft auf die LWT-Nachrichten nicht zu.

Seit wann?

Wenn ich die betreffende Firmware selbst programmiere, incl. MQTT Kommunikation, kann ich die LWT Nachricht selbst festlegen, d.h. deren Topic und deren Payload. Der Broker muss einzig wissen, dass es sich um die LWT Nachricht des Clients handelt, dessen MQTT Id der Broker registriert hat.

Den Inhalt der LWT Nachricht hat den Broker nichts anzugehen.

Andrey Yarizov (Ich war eine Weile hier nicht aktiv.)

MQTT etabliert folgendes Verhalten.

Ein MQTT Publisher sendet mit seiner Kontaktaufnahme zum Broker auch die LWT Nachricht. Die LWT ist also keine separate Nachricht.

Nach dieser Kontaktaufnahme muss sich der Publisher periodisch immer wieder mit einer Ping Nachricht beim Broker melden - üblicherweise spätestens alle 60s. Ist innerhalb dieser Zeit kein Ping eingetroffen, wertet dies der Broker als Nichtverfügbarkeit des Publishers. Grund unbekannt. Danach sendet er an alle Subscriber dieser Nachricht die LWT des nun nicht verfügbaren Publishers. Offenbar tut dies der Broker erst mit eine Latenzzeit von ca. der Hälfte der o.g. Periode. Jedenfalls tut das der von mir genutzte Mosquitto Broker.

Wenn du diese Zeit von ca. 90s verkürzen willst, dann musst du versuchen, tief in die beteiligten Systeme einzugreifen, damit die Periode verkürzt wird, bspw. auf 20s. Ich weiß weder beim Mosquitto und schon gar nicht bei den Shelly, wo/wie ein solcher Eingriff möglich ist. Letzteres kann bestenfalls derjenige wissen, welcher das Betriebssystem bzw. die MQTT Bibliothek für die Shelly zusammenstellt. Damit ist noch nicht klar, wo dies beim eingesetzten Broker gelingt, der ja vom Anwender, also dir, eingestellt wird.

Mir ist nicht bekannt, ob eine solche max. Periodendauer vom Broker an die Publisher übermittelt wird. Diese Frage sollten die Leute von HiveMQ beantworten können. Ich fand dazu auch in deren relativ guter Dokumentation nichts.

Fazit: Du hast schlechte Karten mit deinem Anliegen von bspw. 30s Reaktionszeit. Per Konfiguration oder Skript gibt es dafür keine (dokumentierte) Möglichkeit.

Warum soll diese Latenz von ca. 90s stark verkürzt werden? Willst du einen möglichst sofortigen Alarm als Diebstahlschutz nutzen? Dafür könntest du vor jeden Shelly ein anderes Gerät setzen, bspw. einen messenden Shelly. Letzterer kann leicht per Skript ein Event empfangen und zügig eine MQTT Nachricht veröffentlichen, oder selbst einen Signalgeber aktivieren, wenn die gemessene Stromaufnahme seines Verbrauchers auf ca. 0 sinkt. Es bleibt die Frage, wie fein ein Shelly die Stromaufnahme eines Verbrauchers messen kann. Ich habe dies bisher nicht geprüft. Dies täte jedoch deinen Installationsaufwand (Kosten) ca. verdoppeln. Du könntest prüfen, wie stark die Stromaufnahme eines Shelly i.d.R. schwankt und bspw. für je 5 Shelly einen messenden Shelly einsetzen. Dieser müsste hinreichend genau den Wegfall eines seiner "Klienten" erfassen können. Zudem müsste dessen Firmware eine solche relativ kleine Änderung als Event mitteilen.

So etwas weiß vielleicht thgoebel - trotz meiner späten Reaktion.

Zitat von Mar_Tec

Wird derselbe Taster nochmal gedrückt, stoppt die Rolllade.

Also, der "Taster" ist kein Taster sondern ein Schalter. Beide Schalter verriegeln sich mechanisch gegenseitig.

Normale Handhabung:
Man drückt bspw. den aufwärts Schalter. -> Der Rollladen wird aufwärts gefahren, bis zur Endposition, wenn sonst nichts betätigt wird.
Drückt man während der Fahrt den Schalter zurück in die Aus-Position, bleibt der Rollladen sofort stehen - kein Strom mehr.
Abwärts entsprechend.

Ohne Shelly muss der Antrieb so arbeiten. Tut er das nicht, ist der Doppelschalter oder der Rollladenantrieb oder eine Leitung defekt. Das hat zunächst mit einem Shelly nichts zu tun. Arbeitet die Anlage nun so oder nicht?

Zitat von Mar_Tec

Jedoch darf man in der jeweiligen Auf-/Abwärtsbewegung den Taster nicht erneut drücken, da sie ansonsten nach unten abrauscht.

Mir stellt sich ein Mysterium dar.

Du schreibst eindeutig von Taster. Ich las aber in der Produktbeschreibung nach deinem obigen Link "Kontrolltyp Schalter".

Angenommen, es sind Taster. Dann müsste im Rollladenantrieb eine Elektronik arbeiten, welche auf Impulse reagiert. Ein Impuls zum Hinauffahren -> der Motor fährt den Laden komplett hinauf. Entsprechend zum Hinunterfahren. Sollte dies tatsächlich so sein, dann sieht es nach defekter Elektronik im Rollladenantrieb aus.

Du schreibst in deinem Eröffnungsbeitrag hingegen eindeutig von Schalter. Nimm es mir bitte nicht übel, wenn ich feststelle, dass du dich zu einer wesentlichen Eigenschaft widersprüchlich äußerst!

Trotzdem ein Versuch zur Aufklärung. Habe ich dich recht verstanden?
Du "schaltest" den Rollladenantrieb auf bspw. aufwärts. Dann stellst du den "Schalter" zurück und schaltest erneut auf aufwärts? Dies hat zur Folge, dass der Rollladen wie von einer Bremse gelöst und ohne Motor nach unten "rauscht"?

Zitat von vaderabraham

mit 1 Sek. Schließ/Öffnungszeit

Beide? Hast du denn dann keinen Rechteckgenerator mit einer Frequenz von 0,5 Hz?

Zitat von vaderabraham

I/O-Button

Einen Output Button kenne ich noch nicht.

Vielleicht liegt es an meiner Szenenverweigerung, sorry ...

Mar_Tec

Mit Durchgangsprüfer die Funktion des abgeklemmten Schalters prüfen!

Zitat von Mar_Tec

Das gleiche passiert auch mit der Steuerung via iOS App: drücke ich auf den "Öffnen" Pfeil fährt die Rolllade wie erwartet hoch, jedoch rutscht sie nach unten durch, sobald ich auf "Pause " drücke.

Hast du den Shelly auch mal ohne angeschlossene Schalter genutzt, um zu sehen, ob die Schalter ein Problem sind?

(Fehlersuche ist offenbar nicht deine Stärke. )

Vermutlich ist der Rollladenantrieb defekt. Vielleicht hat der deinen alten Shelly zerstört.

Exilhamburger

Also ich täte die Sensoren weiter nutzen, da sie offenbar outdoor geeignet sind. Und die CCU/Homematic auch weiter nutzen.

Ich nutze weder CCU noch Homematic, weiß aber, dass damit ein Node-RED verfügbar ist, afaik RED-Matic genannt.

Ein adaptierender Node-RED Flow kann bestens passende Nachrichten an Shelly senden und auch von diesen empfangen, per URL (http), per MQTT und werweißwasnoch.

Du musst halt ein klein wenig programmieren, hauptsächlich grafisch zusammenschieben. Mit einem Smart Home Kumpel, der Homematic auf CCU nutzt, tat ich solches. Wenn du noch ein bisschen JavaScript kannst, stehen alle Wege und Implementationen offen.

Jo, genau so muss es sein. Dort, wo im Bild die Lampen zu sehen sind, kommen die Verbraucher (Lüfter, Heizmatte) hin.

Die Ausgänge schalten nach Ground.

Extrem einfach

Das Netzteil muss halt genügend Leistung liefern können, was vermutlich der Fall ist.

Mittlerweile dokumentiere ich diese Steuerung auf einer eigenen Website.

https://iotig.eichelsdoerfer.net/index.php/loes…r-andere-zwecke

Dort liegt ein vereinfachtes Skript vor, welches voraussetzt, dass ein sehr kurzer Impuls an der Steuerelektrik keine Wirkung hat. Wer diese Implementation nutzen will, sollte dieses Skript zuerst testen. Fährt die Steuerelektrik das Tor auch bei sehr kurzem Impuls, sollte stattdessen die Skriptversion 0.1 verwendet werden, die zwecks Korrektur einen zweiten Impuls nachreicht.

LuPe81

Falls du zur Steuerung auch einen Sprachassistenten (App auf Smartphone) nutzen möchtest, habe ich eine Lösung mit einem Shelly Plus 2PM + externes Relais oder Shelly (Plus) 1 für dich. Bei Interesse bitte melden.

Es ist durchaus möglich, dass sich das Tor nicht bewegt, wenn der Impuls sehr kurz ist. Dann sollte das Skript nach Erkennen der ansteigenden Flanke den Impuls sofort beenden. Damit würde das Skript noch einfacher und technisch besser. Das kann ich aber nicht testen.

Ich habe in einem anderen Thread eine Lösung dargelegt. Diese unterstützt die Steuerung per Sprachassistent und arbeitet mit einem Skript.

Hier: Shelly Plus 1 + Addon Garagentor per Sprachsteuerung öffnen/schließen

Das Thema passt nicht mehr genau, da statt des Shelly Plus 1 ein Shelly Plus 2 verwendet werden muss.

In Seite 2 sind die Rahmenbedingungen beschrieben und das vorläufige Skript zu finden.

Danke Thomas. Nun habe ich mir doch noch die Arbeit gemacht und die komplette Schaltung auf der Basis des Plans von hemnes84 bearbeitet.

In rot die Beschaltung der Shelly Ausgänge mit dem zusätzlichen externen Relais.

In grün die Relaiskontakte parallel zum vorhandenen Taster. Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Hinweise:

1. Das Tor lässt sich so bspw. per Smartphone mit Sprachassistent-App auch von fern und aus dem Auto, Moped ... steuern. Jedenfalls gelingt dies mit meiner "Alexa App".
2. An SW1 und SW2 (an meinem Shelly ist S1, S2 aufgedruckt) kann man zusätzlich Taster oder Schalter zum bedienen anschließen. Dies ist aber rein optional und vermutlich letztlich uninteressant, weil bereits ein Taster vorliegt.
3. Ich weiß ich nicht, wo der Magnetschalter noch angeschlossen ist. Das hat der TE nicht erklärt. Evtl. kann man das Add-On weglassen und den Magnetschalter an einen der beiden Eingänge legen. Dazu wären die Eingänge auf detached zu konfigurieren und das Skript anzupassen.

Hallo Thomas ( thgoebel ). Danke für die Korrektur.

Könntest du mal schnell mit deinem Tablet die Schaltung für hemnes84 skizzieren? Bei mir ist das ein relativ großer Aufwand.

Zumal wir nicht zu Hause sind - im Norden bei Schwiegermama.

hemnes84

Die Schaltung ist relativ einfach. Allerdings habe ich keine Garage ...
Du verwendest das, was du in #24 skizziert hast. Der Plus 2 besitzt allerdings keine potentialfreie Ausgänge, d.h. er schaltet die 24 V Versorgungsspannung bei "Ein" durch.

1. Du nimmst deine bisherige Schaltung, incl. Add-On und daran angeschlossenem Magnetschalter als Zustandssensor des Tors.
2. Du ersetzt den Shelly Plus 1 durch einen Shelly Plus 2.
3. Die beiden Ausgänge des Plus 2 verbindest du, wodurch bei beiden Kommandos "öffnen" und "schließen" jeweils einen Impuls schalten - so wie dein Taster auch.
4. Nun wird es etwas schwieriger. Ich kenne die Spannung am Taster zur Torsteuerung nicht. Vielleicht können die 24V des Shelly Plus 2 an einen der beiden Tasterklemmen gelegt werden. Dazu solltest du einen Elektriker fragen oder jemanden, der sich mit el. Spannungen und Potentialen auskennt.
   Ganz sicher funktioniert die Schaltung, wenn du mit den parallel geschalteten Ausgängen des Shelly ein 24V Relais ansteuerst. Die Schaltkontakte dieses Relais werden genau so verdrahtet, wie I und O des Shelly Plus 1, also beide Relais-Schaltkontakte mit den Tasteranschlüssen verbunden.
5. Alternativ kannst du auch die Ausgänge des Plus 2 an den Eingang eines Shelly 1 (mit oder ohne Plus, also Generation 1 genügt bereits) anschließen. Der Shelly (Plus) 1 wird dann mit seinen Ausgängen genau so verdrahtet wie in deiner bisherigen Schaltung. Diese Lösung ist nur dann interessant, wenn du dir kein 24V Relais beschaffen und ggf. löten willst.

Ich werde an Hand deiner Skizze die Schaltung mit dem zusätzlichen Relais nachreichen.

Es ist durchaus möglich, alles in Halbleitertechnik auszuführen. Aber dazu braucht es jemanden mit hinreichenden Elektronik-Kenntnissen.

hemnes84

Ich lege hiermit das Skript in der ersten Fassung vor. Ich habe es mit einem Shelly Plus 2 PM + AddOn entworfen und getestet.

Kurze Zusammenfassung:

1. Wenn bspw. per Sprachassistent das Tor geöffnet werden soll und der Sensor signalisiert "Tor geschlossen", dann wird ein Impuls geschaltet -> Die Torsteuerung öffnet das Tor.
   
2. Ist hingegen das Tor offen, werden zwei Impulse geschaltet. Der zweite Impuls soll das Tor wieder zurück in die Offen-Position bringen. Ich erwarte dann zwei sehr kurze Anläufe - runter und wieder hoch. Das Schalten (=Impulsanfang) lässt sich nicht vermeiden, weil ein Skript erst aufgrund dessen erkennen kann, dass ein Trigger eingetroffen ist. Deshalb sind zwei Impulse erforderlich.

Entsprechend verhält sich der Shelly beim Schließen des Tors.

Das Skript gibt noch einige Informationen im Console Fenster aus, die später entfallen können. Das Skript reagiert auf verschiedene Ereignisse, u.a. Sprachanweisung (Weg über die Shelly Cloud).

Ich habe einen kleinen Lastenausgleich für die Relais eingebaut, damit für die ggf. zweiten Impulse die Relais gewechselt werden und dafür nicht immer dasselbe Relais schalten muss. Die Ausgaben könnten etwas verwirren. Ich habe sie aber aus guten Gründen so genutzt, wie sie die Firmware als Ereignis an das Skript überträgt.

// von eiche
// Datum: 2025-04-07, Version 0.1
// für hemnes84

// 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,
closed = 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") {
    closed = 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(!closed) 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(closed) delayed_impulse(); // Dieser Aufruf muss dann erfolgen, wenn das Tor nicht bewegt werden sollte.
          }
          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);
    closed = res.state;
    Shelly.addEventHandler(process);
  }
);

Am Ende des Skripts (nach einem Reset, mit dem Start des Skripts, nach Stromausfall) wird der digitale Eingang abgefragt und nur dann der Eventhandler registriert, wenn diese Abfrage erfolgreich ist. Dies ist ein kleines Sicherheitsverhalten. Ich setze voraus, dass der Schaltersensor bei geschlossenem Tor geschlossen ist. Sollte dies umgekehrt sein, muss die Logik dazu geringfügig angepasst werden.

Ich arbeite erst daran weiter, wenn hemnes84 sich hierzu meldet.

He, da ist ja der Code. Besten Dank tvbshelly ! Danach suchte ich und sah diese Weiterführung nicht.

Wird umgehend kopiert.

hemnes84

Ich habe experimentiert und bin noch dran. Die Nutzung eines Sprachassistenten hat höchste Priorität. Dies gelingt nicht mit einem Shelly Plus 1.

Eingesetztes Gerät: Shelly Plus 2 PM

Die Ausgänge werden parallel geschaltet, weil der Torantrieb ausschließlich auf einen Impuls reagiert. Somit erhält die Torsteuerung sowohl mit der Sprachanweisung "Garage öffnen" als auch mit "Garage schließen" den Beginn des Einschaltimpulses.

1. Das Gerät muss im Modus Cover betrieben werden, weil andernfalls die Sprachanweisungen "öffnen" und "schließen" nicht wirken.
2. Deshalb greifen die Timer-Einstellungen in der Ausgangskonfiguration nicht.
3. Um einen Impuls auszugeben, muss das Skript nach dem Einschalten die Anweisung "stop" beauftragen.
4. Sollte das Tor nicht bewegt werden, weil es bereits den beauftragten Zustand besitzt (öffnen eines geöffneten Tors führt wegen Impuls zum schließen und umgekehrt), muss ein zweiter Impuls vom Skript ausgegeben werden, um das Tor wieder zurückzustellen.
5. Das Skript muss somit die Component "Cover" nutzen, um zu stoppen und um einen zusätzlichen Impuls auszugeben.

Das ist zwar etwas tricky, wird aber per Skript implementierbar sein. Ich arbeite daran ...

Zitat

Aber ich nehme an, das Skript von ostfriese ist sicher eine verbesserter Version davon.

Er hat dazu eine sehr übersichtliche Webseite per Skript erstellt. Leider fand ich das Skript noch nicht.

Prinzipiell tue ich so etwas auch, habe aber derzeit dazu keinen Antrieb.