Beiträge von eiche

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.

Das müsste gehen.

Eine Action anlegen.

Wenn Schalter auf ein geändert wird, per URL Methode Script.Start verwenden. Angenommen die Id des Skripts ist 1.

http://localhost/rpc/script.start?id=1

Entsprechend, wenn der Schalter auf aus geändert wird, Skript anhalten.

http://localhost/rpc/script.stop?id=1

Bei Verwendung eines physikalischen Tasters ist ein zusätzliches Skript erforderlich, das bei Tastendruck den Skript 1 Zustand (running?) abfragt und diesen ändert. Das gelingt auch mit einer virtuellen Komponente.

Allerdings wirken die üblichen Taster in der Web-UI und der App/Clloud afaik unmittelbar auf den Ausgang. Wenn du diesen Ausgang brauchst, gelingt es mit einem solchen Taster nicht. Dann bleibt ab Generation 3 ein zusätzlicher virtueller Schalter (boolean) oder Taster(button).

Man könnte auch ein Temperatur gesteuertes Luftverteilungssystem einbauen. Ok, technisch vielleicht zu viel Aufwand, aber möglich könnte es sein.

1. im Inneren zwei Temperatur Messstellen und
2. ein kleiner Lüfter
3. außen ein Shelly, welcher alles (Kompressor, Lüfter) steuert

Am Shelly ein Add-On oder ein Plus UNI. Ich täte per Skript steuern, vermutlich gelingt es auch per Actions - aber keinesfalls per Cloud.

Alternativ könnte ein längerer Kühlkörper zwecks Temperaturausgleich dienen, oder ein langes Alu-Blech, damit es in den Schrank passt.

horkatz

Ja, deine Darlegung ist einleuchtend.

Dann stellt der Shelly per Messung fest, dass der Motor abgeschaltet wurde. Dies benötigt er ja auch zur Kalibrierung.

hemnes84

Ich verstehe dich so:

Der Magnetschalter (Endlagenschalter) hat nichts mit der bisherigen Torsteuerung zu tun?

Zitat von hemnes84

Wie die Torsteuerung weiss, wann der Motor aufhören soll zu arbeiten, kann ich nicht erkennen

Vermutlich so, wie der Shelly Plus 2 PM im Cover Modus es tut. Dieser misst die Last (Stromaufnahme). Wenn diese deutlich ansteigt, bringt der Motor gegen den Widerstand am Anschlag ein höheres Drehmoment auf. Dann wird abgeschaltet.

Deine Schaltung sollte passen. Ich sehe darin keinen Fehler.

Zitat von hemnes84

Leider ist es aber so, dass das Relais immer schaltet. Egal welchen Zustand der Magnetschalter hat.

Ja, das kann das Skript nicht verhindern, wenn der Shelly auf eine Sprachanweisung oder die virtuellen Buttons der App/Web UI reagiert. Das Skript beendet aber den Impuls umgehend, wenn das Tor auf Grund des Magnetschalterzustandes nicht fahren soll. Der vom externen Relais gegebene Impuls sollte so kurz sein, dass die Torelektrik nicht darauf reagiert. Entscheidend ist, ob das Tor bei einem sehr kurzen Impuls gefahren wird. Das musst du feststellen. Ich kann dafür das passende Skript (Version 0.1) beisteuern.

Die Dauer für einen wirksamen, längeren Impuls stellst du im Skript als Wert für die Variable "duration" ein. Für Testzwecke habe ich dort 2000 (ms) notiert. Diese Impulsdauer kommt nur dann zustande, wenn das Tor wirklich gefahren werden soll.

Den kurzen Impuls solltest du mit zwei oder vielleicht nur einem Klicken der Relais hören können. Danach muss das externe Relais auf Aus stehen.

Ist der Magnetschalter oben (bei offenem Tor geschlossen) oder unten (bei geschlossenem Tor geschlossen) montiert? Das Skript verwendet den unteren Montageort.

Bob2000

Option

Zusätzlich kann man den KVS (key value storage, nichtflüchtiger Speicher) zum Eintragen des Zählerstandes zum Beginn der Shelly Plus UNI Nutzung verwenden. Ein Skript kann diesen Wert lesen und die Pulse dazuzählen. Das ist relativ einfach.

Worüber der Shelly mit deinem übergeordneten System kommunizieren kann, musst du wissen. Möglicherweise fragt das System periodisch den Schelly nach dem Zählerstand. Ein Skript kann jedenfalls MQTT und HTTP. Ob man per Skript den Zählerstand manipulieren kann, weiß ich derzeit nicht.

Eine Skriptlösung hätte den Vorteil, dass es auch alleinstehend betrieben werden kann, incl. Webseite per Skript generiert. Mit der USV, bspw. die von thgoebel aufgezeigte, gelingt die Abfrage sogar während eines Stromausfalls per Smartphone.

Edit:

Maßnahme für Stromausfälle

Man kann auch einen herkömmlichen CMOS Zähler zur Impulszählung einsetzen, welcher irgendwie Energie gepuffert ist. Dieser kann vom Shelly mit jedem Impuls rückgesetzt werden. Bei Stromausfall zählt der CMOS Zähler, bei Stromwiedereintritt und Power On Reset des Shelly holt sich das Skript seriell den Zählerstand des externen Zählers und macht weiter. Diese Lösung sollte bei Stromausfall sehr wenig Leistung aufnehmen. Ggf. ist noch ein CMOS Schieberegister erforderlich, falls der Zähler keinen seriellen Ausgang besitzt.

Folgerichtig wäre es, wenn die Cloud-Nutzung auf reiner Kundenverantwortung beruhe.

Die Firmware solcher Shelly für Handwerkerinstallation und Gewährleistung müssten dem Handwerker ermöglichen, jedwede Konfigurationsänderung sowie ggf. Skriptänderung zu sperren. Afaik gibt es solche Shelly derzeit nicht.

Zusatzhinweis:

Die App wie auch das Web-UI des Shelly bieten ausschließlich virtuelle Tasterbedienung.

Die Einstellung Schalter vs. Taster und ggf. detached beziehen sich ausschließlich auf elektrisch angeschlossene Taster bzw. Schalter.

Verantwortlich für dieses Problem ist eindeutig der Akku-Hersteller. Das hat mit dem Shelly nichts zu tun.

Off Topic: Interessant finde ich, dass offenbar inzwischen auch Elektriker Shelly Geräte einbauen.

Inzwischen habe ich auf meiner o.a. Website dokumentiert, wie man folgendes erreichen kann.

Angenommen, man hat zwei per je einem Shelly Plus 2 PM (oder neuere Generation) gesteuerte Rollladenantriebe, typischerweise in einem Raum. Dann ist es möglich, beide per einer einzigen Zeitplanzusammenstellung (schedule job set) wie o.a. zu steuern. Das schedule job set besteht nach wie vor aus den aufgeführten Zeitplänen. In drei dieser Zeitpläne (id: 2, 4 und 5) kann man eine HTTP.GET Methode hinzufügen, welche den anderen Shelly beauftragen, dessen Rollladen zu öffnen oder zu schließen.

Nachteil: Die Zusammenstellung der URL Komponente im Parameter ist etwas komplex.
Mit meiner unterstützenden Webseite ist dies weniger schwierig.

Vorteil: Man braucht nur auf einem der beiden Shelly die Zeitpläne zu konfigurieren und bei Bedarf zu ändern, was eine höhere Servicefreundlichkeit mit sich bringt. Die Zeiteinstellungen der Schedule Jobs ist mit herkömmlichen Mitteln leicht zu bewerkstelligen.

Nun mag jemand versucht sein, anzumerken, dass er solches bereits mit Actions und dort eingetragenen URLs realisieren kann. Diese Annahme ist nicht treffend. Per Actions lassen sich bspw. beide Rollläden gleich steuern, was folgendes bedeutet.

Wird der "Master"-Rollladen geöffnet/geschlossen, tut dies dann immer auch der "Slave"-Rollladen. Die Flexibilität der getrennten Steuerung geht mit solchen Actions verloren.

Meine Zeitplansteuerung greift ausschließlich in den Zeitplänen auf beide Rollläden zugleich zu. Die individuelle Flexibilität der Rollladensteuerung bleibt erhalten.

In diesem Zusammenhang wäre folgende bisher nicht vorhandene RPC-Methode wünschenswert:

Name: "Schedule.AddMethod", Parameter: Id des Jobs, zusätzliche Methode

Die Wunschliste ließe sich fortsetzen, etwa so:

Methodenname: "Schedule.DeleteMethod", Parameter: Id des Jobs, Index des Eintrags in "call"

Methodenname: "Schedule.UpdateMethod", Parameter: Id des Jobs, Index des Eintrags in "call", {"method":<neue Methode>,"params":<Parameter>}

Na gut. Ich wollte nicht meckern, sondern darauf hinweisen, dass ich bei dieser Darstellung einen Optokoppler eher nicht empfehlen täte. Dein Hinweis ist ansonsten klar ok.

heyICE

Wie willst du den Shelly Plus 1 nutzen?

1. per App?
2. per Taster oder Schalter an den Eingängen?
3. per Sprachassistent?
4. etwas anderes?

Zitat von Guennesack

N > 230V
01 > Rolladenmotor rauf
02 > Rollademotor runter
L > 24V

Das liest sich aber bedenklich laienhaft.

hemnes84

Prima!

Das Skript Version 0.2 auf meiner Website empfehle ich zunächst. Vermutlich wird es das tun, was du willst.

Lasse von dir lesen!

Zusatzfragen:

1. Braucht die Torsteuerung nicht das Signal vom Endlagenschalter?
2. Hast du diesen Schalter parallel mit Torsteuerung und Shelly Add-On verbunden?

Du hast den von mir oben selbst zitierten Text verwendet, um dich auf etwas anderes zu beziehen?

Hast du den Zweck von Zitaten überhaupt verstanden? Das ist total daneben. Am besten ist es, wenn du schlicht dazu nichts schreibst. Ansonsten bist du ein Troll.

Jaaa, das erscheint mir plausibel.

tvbshelly

Von dort bezog ich die noch weitestgehenden Informationen. Was ein retained bei einer LWT bewirkt, weiß ich noch nicht genau. Dazu fand ich nichts. Ich kann somit nur vermuten, dass diese Nachricht bleibt, wenn sich der Client erneut mit dem Broker verbindet, ohne eine LWT mitzuteilen. Die LWT muss nativ bereits gespeichert sein, andernfalls täte dieser Mechanismus nicht funktionieren.

Zitat von eiche

Dem Broker sind die Inhalte von MQTT Nachrichten völlig wurscht, er muss nur "wissen", wann er eine LWT Nachricht an Subscriber senden soll/muss.

Leider muss ich mich hier mal selbst zitieren.

Zitat von Jo_Be

Das trifft auf die LWT-Nachrichten nicht zu.

Meine Aussage bezieht sich unmissverständlich auf die Inhalte.

Jo_Be Deine Aussage widerspricht diesem. Ich weiß nicht, warum du hier klugscheißt und absolut nichts Konstruktives an dieser Stelle beiträgst. Falls du in meinen Beiträgen nach Krümeln suchen solltest, empfehle ich dir, dies sein zu lassen.

Ich habe das oben Beschriebene nun auf einer eigenen Website (hoffentlich) sorgfältig dokumentiert.

https://iotig.eichelsdoerfer.net/index.php/loes…nicht-vor-6-uhr

Viel Freude damit!