Beiträge von eiche

Es mag für diesen Thread nicht relevant sein, was ich nicht einschätzen kann, da ich keine passende Konstellation nutze. Also bitte nur als ergänzenden Hinweis zu MQTT und Tasmota auffassen!

Nach meiner weiter zurückliegenden Erfahrung sendet Tasmota(32) ständig MQTT Nachrichten, auch dann wenn das regelmäßige Protokollieren ausgeschaltet ist. Außerdem kann es bei Verwendung von retained Nachrichten zu Phantom-Schaltvorgängen kommen. Deshalb sollte im Zweifelsfalle retained vermieden werden.

Da dies nichts mit einem IP Adressen Scan zu tun hat, glaube ich nicht an retained als Ursache. Ich verwende gelegentlich zum Scannen den "Angry IP Scanner". Es wäre interessant, ob solche unerwünschten Schaltvorgänge auch bei diesem Scanner auftreten.

Du kannst beide URL in einem Web Browser testen. Du wirst dann als Antwort "erledigt" oder "nicht erledigt" erhalten, abhängig davon, ob dein Wollen zum Öffnungszustand passt.

Ich habe ein möglichst einfach verwendbares Skript erstellt. Dieses stellt zwei sog. HTTP Endpoints zur Verfügung.

1. Zum öffnen des Tors per Impulsausgabe, wenn der "Geschlossen-Sensor" dies signalisiert.
2. Zum schließen des Tors per Impulsausgabe, wenn der "Offen-Sensor" dies signalisiert.

Ich konnte mangels zweier Sensoren nicht alles testen. Es sollte aber wie gewünscht funktionieren, wenn ich die Wirkung der Impulsausgabe richtig interpretierte (s. #5).

Wenn du das Skript bei geöffnetem Editierfenster startest, erhältst du zwei Sekunden danach im Protokollfenster zwei Ausgaben, etwa so:

open URL: http://172.16.8.1/script/1/open
close URL: http://172.16.8.1/script/1/close

Deine IP Adressen sind anders zu erwarten und die Skript Id (hier 1) kann anders sein, wenn du noch andere Skripte auf dem Shelly Plus 1 gespeichert hast.

Hier das Skript. Kopiere es per Kopier-Symbol oben rechts und nicht etwa per markieren ...!

let Response = {
  did  : "erledigt",
  didnt: "nicht erledigt"
},
Component = { // Components zu beiden Magnetschaltern 
  opened: "input:100",
  closed: "input:101"
},
Duration = 0.5; // Impulsdauer in Sekunden

function impulseOut(dur) {
  Shelly.call("Switch.Set", {id:0, on:true, toggle_after: dur});
}

function sendResponse(response, body) {
  response.code = 200;
  response.headers = [["Content-Type", "text/html"]];
  response.body = body;
  response.send();
}

function openGate(request,response) {
  let closed = Shelly.getComponentStatus(Component.closed);
  let doit = closed!==null && closed.state;
  if(doit) impulseOut(Duration);
  sendResponse(response, (doit ? Response.did : Response.didnt));
}

function closeGate(request,response) {
  let opened = Shelly.getComponentStatus(Component.opened);
  let doit = opened!==null && opened.state;
  if(doit) impulseOut(Duration);
  sendResponse(response, (doit ? Response.did : Response.didnt));
}

let openUrl = null, closeUrl = null,
localIP = Shelly.getComponentStatus('wifi').sta_ip;

Timer.set(2000,false,
  function(){
    openUrl = 'http://'+localIP + HTTPServer.registerEndpoint('open', openGate);
    closeUrl = 'http://'+localIP + HTTPServer.registerEndpoint('close', closeGate);
    print("open URL: " + openUrl);
    print("close URL: " + closeUrl);
  }
);

Bei Fragen stehe ich selbstverständlich zur Verfügung.

Edit:
Per open URL kannst du das Tor öffnen lassen wollen, per close URL schließen lassen wollen. Es wird aber nur dann geöffnet, wenn es geschlossen ist und umgekehrt.

Ergänzung

Nach deinem Beitrag #1 reagiert der Torantrieb auf einen Impuls jeweils mit der gegenteiligen Aktion zur vorherigen. Tor schließt wenn zuvor geöffnet und umgekehrt. Stimmt das?

Dann sehe ich keinen Anlass, den Impuls nur unter einer erfüllten Bedingung ausgeben zu lassen. Entscheidend wäre vielmehr, den Öffnungszustand als Anwender zu erkennen.

Aber vielleicht habe ich die erforderliche Beschaltung und deren Signalgebung noch nicht verstanden ...

Edit:
Ich habe nachträglich erkannt, dass du zwei Auslöser möchtest und jede der beiden Auslösungen nur bedingt wirken sollen. Ok soweit. Ich schaue mal, ob ich auf die Schnelle ein kleines Skript baue.

1. Weil Cloud nicht erforderlich ist, nur etwas einfacher.
2. Weil ich für Sicherheit relevante Einrichtungen nur lokal implementieren würde. Was nicht raus geht, kann weniger ausspioniert werden.
3. Weil es nicht funktioniert, wenn auf die Cloud nicht zugegriffen werden kann.

Genügen diese Gründe? Dies schließt allerdings afaik "Nachricht an Alexa" aus.

Also kann ich erst einmal den Versuch mit Actions (=Webhooks) empfehlen, weil diese rein lokal arbeiten können. Damit kannst du einfach mal versuchen, dein Ziel zu erreichen.
Ich bin in Actions nur teilfit, weil ich oftmals Skripte mit deren höchstmöglichen Flexibilität bevorzuge.

Edit:
Für dein Anliegen sollte es genügen, irgendetwas Optisches wie Signalleuchte, Leuchtring an einem Shelly (Plus) Plug S, Symbol in einem Dashboard ... genügen. Was hierfür auf relativ einfache Weise implementierbar ist, hängt von deiner bisherigen Ausstattung ab.

Maybe you have that activated? Sorry, I use the german UI.

Du willst ein Tor remote steuern, ohne dessen Umgebung einsehen zu können?

Hast du dafür eine Versicherungsgesellschaft gefunden, die solches versichert?

Dies mal unabhängig davon, wie es implementierbar ist. Und wenn du das nun noch immer willst, dann doch bitte ohne eine Notwendigkeit einer Internetverbindung, also ohne Cloud und möglichst mit weiteren Sicherheitseinrichtungen. Solches ist erst einmal möglich - wenn nicht per Actions, dann jedenfalls per Skript.

Ich hoffe, dass meine Warnhinweise verständlich sind.

Alles gut Thomas. Solche Hinweise können durchaus nützlich sein. Ich denke, dass wir beide die beiden Endpunkte einer Implementations-Skala aufgezeigt haben und nun der TE am Zuge ist.

Edit: Vielleicht ist "Skala" schlecht gewählt und die Implementationsmenge hat eher eine zweidimensionale Gestalt.

Zitat von thgoebel

Was erreicht man aber mit dem Ersatz des einen Wechselschalters durch einen (per Software-Regel konstruierten) Umschaltkontakt? Nichts, meine ich.

Das weiß ich nicht, aber die vom TE genutzte Tasmota Rule tut solches. Deshalb unterstelle ich einfach mal, dass er weiß, was er damit erreichen will. Ich muss nicht alle Situationen kennen, in welchen "ungewöhnliche" Konstellationen verständlich werden.

Btw, in einem anderen Thread hat mir ein anderes Mitglied per PM plausibel mitgeteilt, warum er etwas erreichen will, dessen Sinnhaftigkeit angezweifelt wurde. Wegen PM will ich dies nicht öffentlich darlegen.

SeeHome2024 meint nicht den Einbau eines Shelly in eine Wechselschaltung, sondern eine automatische Umschaltung zwischen den beiden Ausgängen - ähnlich einer Rollladensteuerung.

Solange diese Tasmota Rule arbeitet, ist immer einer der beiden Ausgänge eingeschaltet und der andere ausgeschaltet, wobei Power1 der Master ist.
In Shelly Notation sind Power1 "switch:0" und Power2 "switch:1".

So etwas sollte bereits mit Actions (=Webhooks) lösbar sein. Schaue einfach mal unter Actions nach und analysiere deren Konfigurierbarkeit!

Sollte dies nicht gelingen, kann dafür ein kleines Skript eingesetzt werden.

Zitat von Schubbie

Nachteil wäre, dass man keine Benachrichtigung bekommt, wenn das Wasser alle ist, aber das könnte man dann immer noch über den Verbrauch ermitteln

Kriegst du solches per Action hin? Wenn nicht per Szene, also wieder Cloud? Eine solche Mitteilung dürfte ja nur dann erfolgen, wenn trotz eingeschaltet Seins die Leistung 0 ist.

Ratzebaer

Es ist dir hoffentlich klar, dass deine Vögelversorgung nur dann automatisiert arbeitet, wenn der Shelly Plus 1 eine Verbindung zum Internet hat. Ohne diese fällt deine Automatisierung aus. Das Ganze lässt sich auch autark arbeitend lösen - ohne Alexa-Erfordernis. Und zusätzlich so, dass die Pumpe bei Niedrigwasserstand nicht einmal kurz eingeschaltet wird. Dabei kann die Cloud, Szene und Alexa zusätzlich genutzt werden, falls Bedarf daran besteht.

Wie?

Das beantworte ich erst bei Interesse daran.

Ohne selbst ein solches Problem gehabt zu haben, täte ich

1. die betreffenden Geräte aus der Cloud entfernen,
2. sicherheitshalber eine Weile warten - 1h bis 1Tag,
3. falls dies das Problem noch nicht löst, ein Factory Reset.

Vermutlich kann dieses Vorgehen das Problem lösen. Mehr als eine Vermutung kann ich allerdings nicht beisteuern.

peterpaul1

Wie von apreick empfohlen, gelingt dies mit einem übergeordneten System. Dies empfiehlt sich besonders dann, wenn du bereits ein solches nutzt.

Es ist aber auch möglich, all dies mit einem Shelly Plus Plug S und einem darauf laufenden Skript zu implementieren. Allerdings erfordert solches entweder auf die Anwendung genau zugeschnittenes Skript oder ein gut durchdachtes Skript, welches per Konfiguration auf die gewünschte Anwendung anpassbar ist. Das Zweite ist erheblich aufwändiger zu erstellen, aber flexibler nutzbar. Damit wäre dein Vorhaben ohne zusätzliche Investition in Hardware implementierbar.

Ob per übergeordnetem System oder per Skript - ohne Zeitinvestition gelingt eh nichts.

Da du an deinen beiden Küchengeräten jeweils einen skriptfähigen Shelly nutzt, ließen sich beide per Skripte "intelligenter" machen, als sie ohne Skript sind - incl. Priorisierung und gegenseitigem Sperren. Dass dafür WLAN zwingend erforderlich ist, wird dir sicher bekannt sein. Das "intelligenter" Machen der beiden Plus Plug S ist die ausfallsicherste Lösung, weil diese auch untereinander ohne zusätzliches System kommunizieren können. Eine Cloud basierte Lösung ist technisch immer die schlechteste, aber mitunter die bequemste.

Wenn du keine Programmierkenntnisse hast, sind Skripte nicht zu empfehlen. Allenfalls könnte dann jemand mit genügend Zeitreserve für dich geeignete Skripte erstellen.

Edit:
Die Einwände seitens DIYROLLY sind sehr ernst zu nehmen und sicherheitshalber Tests durchzuführen. Die angegebenen maximalen schaltbaren Stromstärken sind mit großer Vorsicht zu genießen und für reguläre Einsätze auf ca. die Hälfte zu reduzieren - als grobe Richtlinie.

Verständlich.

Zitat von rmsiegler

Sonnenauf-/Untergangsschaltung wäre bei Aktionen noch nützlich bezüglich dem Zeitfenster für die Aktionen.

Ich weiß es auch nicht und brauche es bisher nicht. Ich weiß aber, dass ich so etwas mit einem Plus Plug S und einem Skript implementieren könnte.

I would try the following.

Equipment

1. one Shelly Pro 4 PM or
2. two Shelly Plus 2 PM

I would code a script that ensures that only one of the four outputs is switched on at a time. As soon as you want to switch, all outputs can be switched off for safety reasons and then the desired output can be switched on.

I don't know if this can be imlemented without a script.

Edit: After a reboot, all outputs must be configured to “off”.

Edit 2:
I mistakenly saw the 80V connection being used. Of course, three outputs are sufficient.
Compared to the electrically safe series connection of relay outputs ( thgoebel), my script solution uses slightly less energy...

Das Prinzip gefällt mir. Ich habe dein Skript nur überflogen, nicht analysiert. Dazu nur ein kleiner Hinweis.

Du kannst mit einem Skript auskommen, indem du zwei HTTPServer Endpoints in diesem Skript nutzt. Der Rest ist eine Frage der Parametrierungen. Auch ein zusätzlicher HTTP GET Parameter könnte genutzt werden ...

Wenn die Beschriftungen/Beschreibungen im UI sorgfältig und richtig sind ...

Zitat von rmsiegler

Bedeutet das jetzt, dass er alle 30 Minuten die Aktion erneut auslöst, wenn die Bedingungen noch erfüllt sind?

ist dies zu erwarten.

Zitat von rmsiegler

wie verhält es sich wenn der H&T am Vortag geschalten hat und die Luftfeuchtigkeit über Nacht nicht auf <50% Luftfeuchtigkeit fällt und der Plug S bei Sonnenuntergang abschaltet. Schaltet der H&T dann am Folgetag ab 0900 Uhr die Aktion erneut ein? Wenn nicht, wie lässt sich das programmieren, dass er das tut?

und auch dies zu erwarten.

Frage: Warum testest du solches nicht selbst, was nicht wirklich schwierig ist und nur etwas Zeit kostet?
Dazu kannst du den Entfeuchter für den Test abklemmen und stattdessen eine Lampe oder ähnliches als Signalgeber anschließen. Dann kannst du das Schaltverhalten beobachten. Mit einem übergeordneten System kannst du auch des Schaltverhalten registrieren und vermutlich speichern lassen. Ich täte solches per Node-RED.

Ich nutze zwei Taster in einer anderen Anwendung am Plus AddOn. Ein Taster am digitalen Eingang, den anderen am analogen Eingang. Allerdings nutze ich zur Auswertung ein Skript, welches den analogen Eingang binär interpretiert. Es sollte aber auch ohne Skript gelingen, wobei der analoge Eingang bspw. auf unter U_ref/2 bzw. über U_ref/2 zu prüfen wäre -> Action.

Dafür ist ein zusätzliches RC-Glied erforderlich, siehe bspw. meine "Autarke Heizkreisregelung per Shelly Skript" unter "Mikrotaster am AddOn. Die vom TE genutzten Magnetsensoren sind vermutlich Reed-Schalter, die genauso nutzbar sind wie Taster.

Selbstverständlich kann der Plus Plug S nur das messen, was über seinen Ausgang strömt. Das gelingt mit einem angeschlossenen Verbraucher.

Ob dies auch in der anderen Richtung gelingen kann, also das BKW über den Plus Plug S in dein Netz einspeist, weiß ich nicht. Ich vermute, dass dies gelingt. In jedem Fall muss etwas an den Plus Plug S angeschlossen werden.

Wie sieht denn deine Schaltung aus? Schaltskizze wäre hilfreich.