Beiträge von eiche

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.

Danke Michael.

Eine kleine Ergänzung, welche aber in Richtung Off Topic geht.

Es stellt sich selbstverständlich die Frage, ob dafür nicht besser ein anderes ESP32 Board genutzt werden sollte, bspw. mit Tasmota32.

Da der ESP32 über mehrere ADC (analog to digital converter) Eingänge verfügt, bräuchte man nur noch ein Netzteil und einen Opto Triac oder Optokoppler+Relais.

Ein ESP32 Entwicklungsboard ist leicht zu flashen und führt i.d.R. die meisten oder alle GPIO (general purpose input output) Pins des Mikrocontrollers nach außen zum anschließen externer Hardware.

Statt eines Shelly Skript wäre ein in Berry geschriebenes Programm und ggf. ein paar Rules zusammenzustellen.

Je nach Sensoren wären noch einfache Spannungsteiler erforderlich, eine Verstärkung der analogen Signale dürfte nicht notwendig sein.

Die Konfiguration könnte im nichtflüchtigen Speicher (Tasmota: 16 MEM Variable) abgelegt werden.

The second, inner function is never processed.

Warum sollte jemand eine Hand in eine Kreissäge stecken?

You can try with an URL and RPC method. At least with Generation 2, remote access should be possible.

In the callback function you can use the response in JSON format.

An example - untested

Shelly.call('http.get',{url:'http://<remote ip address>/rpc/switch.getstatus?id=0'},
    function(response) {
        let power = response.apower;
        //...
    }
);

To use a remote Gen. 1 Shelly, you should study its HTTP communication.

Das geht sehr einfach.

Du schaltest das Netzteil mit einem Shelly Ausgang.

Das Schalten wird per Zeitpläne (siehe Web UI -> Schedules) vorgenommen. In deinem Fall sind es 4 Schedule Jobs.

05:00 Uhr ein

09:00 Uhr aus

15:30 Uhr ein

20:00 Uhr aus

fertig

Mit einem Analog-Multiplexer (elektronische Ergänzung außerhalb des Shelly Angebotes) ginge so etwas. Für 4 analoge Signale wären allerdings 2 Bit für die Selektion erforderlich.

Und hier ist das Shelly Problem. Ein Plus 1 hat, auch mit AddOn nur einen digitalen (Relais) Ausgang.

Man kann unter Verwendung eines Skripts so etwas implementieren (theoretisch, praktisch zu testen).

Ein Zähler wird per Relais-Ausgang getaktet.

Bit 0 und Bit 1 des Zählers werden zur Selektion am Multiplexer angeschlossen.

Bit 2 des Zählers wird mit dem digitalen Eingang am AddOn verbunden.

So ließen sich zyklisch die analogen Signale nacheinander durchschalten.

Die Rückmeldung eines Zyklus gelänge mit Bit 2 an Digital In des AddOn, damit das Skript immer eindeutig "weiß", welcher Feuchtigkeitssensor seine Werte gerade einspeist.

Ich weiß nicht, ob du mit dieser Materie vertraut bist und ob du eine solche Erweiterung überhaupt aufbauen wolltest, aber es müsste so gelingen. Vermutlich wäre noch ein RC-Glied für den Takt zum entprellen zielführend.

Edit:

Mit einem zusätzlichen Plus Uni und dem Analog Multiplexer dürfte dies noch besser gelingen, weil der Uni zwei Ausgänge schalten kann. Hier wären die Ausgänge zur Selektion der 4 analogen Eingangssignale geeignet.

Das Skript kann auf dem Uni arbeiten und die kleine KI täte Befehle an den Plus 1 senden.