Nur zusätzlich zu den bisherigen Hinweisen.
Es fehlt die Angabe, wie du die Lampenanschlüsse verschaltet hast.
Welche Leitungen gehen vom Schalter zu den Lampen?
Bist du dazu bereit, bei Bedarf zusätzliche Leitungen zu verlegen?
Nur zusätzlich zu den bisherigen Hinweisen.
Es fehlt die Angabe, wie du die Lampenanschlüsse verschaltet hast.
Welche Leitungen gehen vom Schalter zu den Lampen?
Bist du dazu bereit, bei Bedarf zusätzliche Leitungen zu verlegen?
Trotz deines ( josefine ) Thread Schließens habe ich eine Nachfrage in die Runde.
Vermutlich ist das Cashen des eingesetzten Web Browsers für manche Irritation verantwortlich.
Kann dies bestätigt oder widerlegt werden?
Funktioniert ganz gut, die Farbtreue zwischen App und RGBW ist aber nicht optimal.
Das ist das alte Problem der unterschiedlichen Darstellungsgeräte.
Da hilft mit einfachen Mitteln nur eines: Trial & Error
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.
Versuche einfach mal folgendes!
Stelle Input Type auf Button und danach eine Action zu long push, die den Rollladen schließt.
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!
Eine Kombination könnte helfen.
Gruß an deine Frau - bei Gelegenheit.
Bevor es zur Trennung kommt, erstellen wir das Skript.
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.
Für Tests solltest du statt der 10800 (s) bspw. 30 (s) einstellen.
Dazu kannst du den Ausgangszustand in der Web UI beobachten.
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
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).
let Duration = 3*3600*1000; // 3 hours in ms
// etwas tun und nach 3h etwas anderes tun
function doThis(parameter) {
// do something
}
function doThat(parameter) {
// do something else
}
doThis(...);
Timer.set(Duration, false, doThat, parameter);
Alles anzeigen
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.
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?
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.
und wie macht man die Usernamen weiß auf schwarzen Grund?
So wie du es gerade getan hast. Ein "@" mit Nick direkt dahinter.
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
Mal sehen ...
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.
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.