Beiträge von eiche

    Dr.Zoidberg

    Ich gehe davon aus, das in der Garage 230V anliegen (Rolltor)

    Wenn vor Ort Netzversorgung (230V) nicht zur Verfügung steht, was ich hier vermute, dann stellt sich die Frage nach der Versorgung des Uni.

    Und damit beißt sich die sprichwörtliche Katze in den Schwanz.

    Warum vermute ich das Fehlen von 230V Netzversorgung?

    Weil zumindest ich bei Vorhandensein anders plante. Dann täte ich anstreben, den Repeater von Akku Versorgung auf 230V-Netzteil Versorgung umzuschalten. Dass hierfür eine dauerhafte Versorgung des Uni erforderlich ist, versteht sich von selbst - merkwürdigerweise ist dies noch nicht geklärt.

    Willst du dann per Powerbank die externe Anlage wieder zum "Leben", also arbeiten, erwecken?

    Die Rahmenbedingungen sind jedenfalls noch nicht hinreichend beschrieben.

    p0sti

    Versuche einfach mal folgendes!

    Stelle Input Type auf Button und danach eine Action zu long push, die den Rollladen schließt.

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Ich nutze derzeit keine direkt an meinen Rollladen-Shelly angeschlossenen Taster, weshalb ich nicht testen kann, ob es damit irgendwo hakt.

    Falls diese Lösung die sonstigen Funktionen stören, lasse dies uns wissen!

    Noch etwas:

    Sollte deine Frau etwas gegen diese Unterscheidung zwischen kurzem und langem (oder zweimal) Drücken haben, können wir hierfür ein Skript erstellen.

    Der Eingang ist dann auf detached einzustellen.

    Dieses Skript braucht einen EventHandler, der das Ereignis "Eingang geändertt" verarbeitet.

    In dieser Verarbeitung fragt das Skript den aktuellen Ausgangszustand ab und veranlasst auf Grund dessen das Beabsichtigte.

    Ein solches Skript wird deutlich einfacher sein als das bisher von dir eingesetzte. ;)

    Mit der Unterscheidung zwischen kurz Drücken und lang drücken (oder auch 2 mal drücken) ließe sich dein Ziel erreichen.

    Eine zusätzliche Bedingung in Action habe ich bisher nicht gefunden.

    Beispiel:

    Langes Drücken ==> für 3h einschalten

    Kurzes Drücken ==> ausschalten

    Ob deine Frau diese Unterscheidung des Drückens akzeptiert, wirst du herausfinden. ;)

    Sollte das Schalten auch remote gelingen, kann dies per RPC Aufruf erfolgen.

    http://<IP Adresse des Ziels>/rpc/switch.set?on=true bzw. false, optional: &toggle_after=10800

    Der Vollständigkeit halber: Bisher alles noch ohne Skript

    1. 3h lang einschalten gelingt mit einem RPC Aufruf - und vermutlich auch per Action (kein Skript erforderlich).
    2. Ausschalten per Taster soll immer gehen (kein Skript erforderlich).

    Ich komme besher zu dem Schluss, dass hier kein Skript gebraucht wird.

    Versuche mal folgendes.

    Erstelle eine Action, die per Taster den Ausgang einschaltet und nach 3h (3*3600 s) ausschaltet (toggle_after=10800)

    Diese Action ist dann retriggerbar, d.h. nach jedem Tastendruck beginnt die Zeit von vorne zu laufen.

    => manuelles Ausschalten ist nicht möglich.

    Ob per Action eine Zusatzbedingung eingebaut werden kann (ist off), weiß ich noch nicht, werde es prüfen.

    Mit einer solchen Zusatzbedingung (ist on) kann ohne Skript per zweiter Action auch manuell ausgeschaltet werden.

    Wenn obiges nicht gelingen sollte, kann dies per Skript implementiert werden.

    Du solltest es aber erst einmal ohne Skript versuchen!

    Ich denke, dass es genau zwei Aktoren gibt, einen Pro 3 und einen Pro 2.

    Jedenfalls lassen sich dann, wenn per Taster eingeschaltet wird, die Aktoren per Skript so einstellen, dass sie während der folgenden drei Stunden ausschließlich per Taster ausgeschaltet werden können.

    Vermutlich ist das die Absicht von Pit38 .

    Edit: Dass sie nach 3h automatisch ausschalten, ist eh sehr simpel zu realisieren, mit und ohne Skript.

    so wie ich es verstanden haben, möchte er verhindern, dass der zentrale PRO3EM die Aktoren schaltet, wenn an den Aktoren von Hand auf EIN geschaltet wurde. (der Aktor soll sich gegen Fernsteuerung für eine bestimmte Zeit sperren)

    Danke, das leuchtet mir funktional ein.

    Dann wäre auf jedem Aktor ein HTTP Endpoint zielführend, welcher für eine gewisse Dauer (bspw. 3h, was auch ein Parameter sein kann) schlicht nichts tut, außer evtl. eine passende Antwort wie "gesperrt" zu liefern.

    Zunächst einmal das einleitende Prinzip (alles ungetestet und genau so nicht lauffähig, weil parameter unbekannt).

    In der letzten Zeile wird ein mir noch unbekannter Parameter - in der Doku als userdata bezeichnet - als "parameter" an doThat() übergeben. Falls ein solcher Parameter nicht gebraucht wird, solltest du dafür kein null übergeben, sondern schlicht diese Parameter weglassen.

    Pit38

    Ich würde gerne einen Pro 3 und einen Pro 2 jeweils mit einem Skript für „http Get Befehle“ für 3 Stunden sperren.

    Hintergrund ist der, dass ich bei jedem Shelly einen Taster habe, der die Warmwasserspeicher für 3 Stunden manuell einschalten sollte.

    ...

    Das Skript auf dem 3em Pro aber die 2 Shellys immer nach ein paar Minuten mit einem Off Befehl ausschaltet, das würde ich gerne verhindern.

    Was soll "sperren" bedeuten?

    1. ausschalten oder
    2. nicht per Taster einschaltbar oder
    3. überhaupt nicht einschaltbar?

    Zum letzten Zitatsatz habe ich die gleichen Fragen wie Krauskopp . Das Skript als Antwort zu posten, ist wenig zielführend, weil dessen Analyse zu aufwändig ist.

    Wieso schalten die beiden ab. Woher stammt der Befehl?

    Dies scheint zunächst geklärt - vom Skript.

    Was du suchst ist nicht mit dem Skript, den ich mal als mein Projekt, der Stufenweise zu und weg schalten von Verbrauchern hier gezeigt habe nicht zu realisieren.

    Demzufolge sollte es besser sein, ein für dein Anliegen geeignetes Skript neu zu erstellen.

    Pit38

    Vielleicht werde ich mir das Skript gelegentlich genauer anschauen.

    Sorry, das ist gräßlicher Code mit einer viel zu langen und unübersichtlichen Funktion timerHandler().

    Damit möchte ich die Arbeit von User-64546 keinesfalls schmälern.

    Es gibt total Überflüssiges darin wie ungenutzte Parameter "userdata" und auskommentierte Zeilen.

    Solchen Code sollte man

    1. nicht verwenden sondern nur irgendwo ablegen, wo man ihn wiederfinden kann,
    2. von Überflüssigem befreien,
    3. hier nicht posten, weil schlecht verdaulich.

    Mal sehen ...

    Krauskopp

    Es wurden ja wohl nicht nur Skripte vorgeschlagen.

    Sorry Martin, es wurde nicht ein einziges Skript vorgeschlagen.

    Mein erstes "Code"-Stück zeigt ausschließlich die Struktur eines Schedule Jobs. Eine solche Struktur erhält man beim URL http://<IP Adresse>/rpc/schedule.list , mit dem man sich alle Schedule Jobs anzeigen lassen kann - auch solche, die in der Web UI nicht komplett angezeigt werden.

    Aber danke für deine Reaktion.

    Gunter Nerd

    Sorry, da hast du falsch interpretiert.

    Noch einmal ein Auszug meiner Reaktion:

    Du könntest (ohne Skript, mit Skript gelingt so etwas immer) den Eingang zwischen Sonnenauf- und Sonnenuntergang deaktivieren oder als detached einstellen.

    Das gelingt mit einem passenden Zeitplan (Schedule Job).

    Eine solche lokale Lösung ist verlässlicher als eine per Cloud. Und warum soll eine Cloud überhaupt etwas davon erfahren? Rhetorische Frage

    Schedule Jobs sind kein Skript. Sie können bspw. per Web UI angelegt werden. Nur solche Jobs für dein Anliegen gelingen derzeit nicht per Web UI.

    Wenn ich erwähne, dass dein Ziel immer mit Skript gelingt, so habe ich kein Skript angeboten, hier konkret im Gegenteil.

    Zudem habe ich auf die Problematik bei einer Implementation hingewiesen, die auf eine Cloud angewiesen ist.

    Ich finde es bedauerlich, dass du nicht mit einer kleinsten Frage oder Kommentar darauf eingegangen bist.

    Ich gewinne den Eindruck, dass dich eine argumentierte Alternative nicht interessiert.

    Dann frustrierst du zumindest mich, wo ich mich um eine konstruktive und weitgehend erklärte Antwort bemüht habe, die, nebenbei bemerkt, einiges meiner Zeit in Anspruch nahm.

    Klar, es gibt viele alternative Implementationen - auch umständliche, auch solche, die "man" auf Vertrautes zurückführen kann.

    Ich halte am meisten von Implementationen, die mit den wenigsten Geräten auskommen, flexibel nutzbar sind und die weitestgehend autark arbeiten können.

    Dabei lasse ich mich auch gerne auf Unvertrautes ein, nehme keinen schnellen Erfolg in Kauf und freue mich, wenn ich dabei dazulerne.

    Das kann ich selbstverständlich nicht (in ähnlichem Maße) von anderen erwarten.

    Das Ziel des TE Gunter Nerd ist mit einem einzigen Shelly Plus 1 ohne Cloud-Abhängigkeit und autark arbeitend erreichbar - vermutlich aber seinerseits nicht auf Vertrautes zurückführbar.

    Wenn er sich auf meinen Vorschlag in #2 einließe, bereit wäre zu experimentieren und zielstrebig das Ziel verfolgte, könnte er einiges dazulernen und sein Anfangsziel erreichen.

    Dass ich oder wir auf dabei auftretende Probleme einzugehen bereit wären, versteht sich hoffentlich von selbst.