Beiträge von eiche

Dr.Zoidberg

Zitat von tom-tsi

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.

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.

1. Die von funkenwerner vorgeschlagene Überbrückung.
2. Eine Action, die den Ausgang sofort wieder einschaltet, wenn er ausgeschaltet wird. (s. Abb.)

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

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.

Zitat von User-64546

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);

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.

let Duration = 3*3600*1000; // 3 hours in ms

// etwas tun und nach 3h etwas anderes tun
function doThis(parameter) {
    // do something
}

function doThat() {
    // do something else
}

doThis(...);
Timer.set(Duration, false,  doThat);

Pit38

Zitat von 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.

Zitat von Krauskopp

Wieso schalten die beiden ab. Woher stammt der Befehl?

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

Zitat von User-64546

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.

Zitat von Pit38

und wie macht man die Usernamen weiß auf schwarzen Grund?

So wie du es gerade getan hast. Ein "@" mit Nick direkt dahinter.

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

Zitat von 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:

Zitat von eiche

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.

Wer dem Zauber einer Cloud hinterher hechelt, wird sich von deinem oder meinem Zeug nicht beeindrucken lassen.

Flutschi interessante Einwände

Im Rahmen dieses Thread und physikalischer Gegebenheiten ist tatsächlich nur die Zeitspanne zwischen Sonnenauf- und Sonnenuntergang relevant - in welcher die Bedingung false werden muss, sonst true.

Zitat von Flutschi

Zuerst

Ist die aktuelle Uhrzeit vor Sonnenaufgang

Danach

Ist die aktuelle Uhrzeit nach Sonnenuntergang.

Es gibt keine Uhrzeit die beide Bedingungen erfüllt.

Das muss sie, die Uhrzeit, auch nicht. Es genügt, wenn sie eine dieser Bedingungen erfüllt, also ist eine ODER Verknüpfung zu verwenden - die selbstverständlich in eine UND Verknüpfung transformiert werden kann.

Zitat von eiche

(b) wenn t <= e ODER t > b dann enable, sonst disable

Das = in <= ist hier irrelevant.

Angenommen b = Sonnenuntergang = 21:00, e = Sonnenaufgang = 06:00

Die ursprüngliche (gedankliche) Formulierung "t liegt zwischen Sonnenaufgang und Sonnenuntergang" ist zu transformieren/umzuinterpretieren zu "t >Sonnenaufgang UND t<Sonnenuntergang", was äquivalent ist zu "nicht (t<=Sonnenaufgang ODER t>=Sonnenuntergang)"

Die Uhrzeit t = 10:00 erfüllt die Bedingung "t >Sonnenaufgang UND t<Sonnenuntergang" => enable = false

Die Uhrzeit t = 23:00 erfüllt die Bedingung "t >Sonnenaufgang UND t<Sonnenuntergang" nicht => enable = true

Bei Verwendung der ODER Verknüpfung:

Die Uhrzeit t = 10:00 erfüllt die Bedingung nicht("t <=Sonnenaufgang ODER t>=Sonnenuntergang") => enable = false

Die Uhrzeit t = 23:00 erfüllt die Bedingung "t <=Sonnenaufgang ODER t>=Sonnenuntergang" => enable = true

Zitat von Flutschi

Alles falsch, es geht nicht über Szenen. Bei Szenen wird nur zum Zeitpunkt des Sonnenuntergang/Sonnenaufgang geprüft.

Ich kenne mich mit Szenen nur sehr wenig aus und verlasse mich auf deine Aussage. Dies entspricht dann den Schedule Jobs, die ausschließlich zu dem timespec Muster passenden Zeitpunkten Aktionen auslösen können.
Dann verbleibt aber als einziges, und schwaches, Argument für die Cloud-Verwendung, dass deren Implementationen leichter per Klicks und so zu erstellen sind.

Alle anderen Argumente - verlässlichere Funktionalität, meine Steuerung verbleibt in meinem lokalen Bereich, Funktion auch bei Ausfall des Internetzugangs ... - sprechen gegen die Cloud-Verwendung.

Wenn man sich dann noch mit Skripten beschäftigt, kann man erkennen, dass diese zusätzliche Verbesserungen zulassen. Dies ist aber für die ursprüngliche Absicht des TE nicht zwingend erforderlich.

Flutschi und Krauskopp

Zitat von Flutschi

Aber vor Sonnenaufgang und nach Sonnenuntergang ist immer false

Prinzipiell ist "vor Sonnenaufgang UND nach Sonnenuntergang" nicht immer false, sondern während der zeitlich festgelegten Dunkelphase true.

Die Bedingung ist vermutlich so formuliert verständlicher: "nach Sonnenuntergang UND vor Sonnenaufgang"

Ob dies in der Cloud auch so implementiert ist, ist eine andere Frage - die ich nicht beantworten kann.

Dahinter liegende Vergleiche werden sich auf Tageszeiten beziehen müssen.

Beispiel allg. formuliert:

t = aktuelle Zeit, b = Begin der Aktivität (Freigabe, enable), e = Ende der Aktivität (Sperren, disable) - alle drei Werte als Tages-Uhrzeit

Bedingung: e < b, was bei e = Sonnenaufgang und b = Sonnenuntergang erfüllt ist

t <= e (inkludiert t < b) => enable

t > e UND t < b => disable

t > b => enable

Zusammengefasst: (a), (b) und (c) sind alternative Darstellungen derselben Funktion

(a) wenn t > e UND t < b dann disable, sonst enable

(b) wenn t <= e ODER t > b dann enable, sonst disable

(c) enable = t <= e ODER t > b (boolescher Ausdruck, dessen Wahrheitswert enable zugeordnet wird)

Statt <= kann selbstverständlich auch < genutzt werden. Das erscheint vor dem Hintergrund der Anwendung unerheblich.

Mir erscheint eine solche Cloud Lösung suboptimal, weil das Auslösen geeigneter Aktionen per Schedule Job (zu Zeitpunkten) eindeutig ist und insbesondere lokal funktioniert.

Einziger Nachteil eines Schedule Jobs:

Wenn zum Zeitpunkt seines Triggers die Stromversorgung weg ist, kann er afaik die gewünschte Aktion nicht auslösen.

Dies könnte per Skript, einem minütlich auslösendem Schedule Job, zweier Konfigurationseinträge im KVS auch nachträglich (nach Stromausfall) zielführend verarbeitet werden.

Ich täte mich jedenfalls dabei mehr auf ein Skript verlassen, dessen Funktion analysiert, getestet und überarbeitet werden kann, als auf die Implementation in einer, nicht immer verlässlich erreichbaren Cloud, deren Implementationen mir verborgen sind.