Beiträge von eiche

Yes, and also in this post:

Beitrag

RE: Wegebeleuchtung für x Min zwischen Sonnenunter und aufgang.

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

Die Struktur eines solchen Jobs, der afaik so nicht per Web UI erstellt werden kann, dies jedoch per URL möglich ist:

(Quelltext, 14 Zeilen)

Dieser…

eiche

24. Februar 2024 um 15:05

Zitat von tomsta13

Standard URL motion detected: http://192.168.0.247/relay/0?turn=on

Standard URL end of motion detected: http://192.168.0.247/relay/0?turn=off

Ich habe deinen Betrieb so verstanden, dass der Shelly, auf welchem das Skript läuft, die Lampe schaltet. In diesem Fall sind beide obigen URL völlig obsolet.

Falls nicht der Skript-Shelly die Lampe schaltet, muss hierfür im Skript statt der Methode "Switch.Set" u.a. die Methode "HTTP.Get" mit URL verwendet werden.

Das ist zunächst zu klären.

Der Motion muss wie in #50 beschrieben den URL http://<IP Adresse des Schalt-Shelly>/script/<Skript Id>/on?<Dauer in Sekunden> in seiner Action zur Bewegungserkennung verwenden.

Das Skript retriggert nach Voreinstellung (Retrigger = true) - die Lampe bleibt an (nach der blind time), solange das Licht nicht per Taster am i4 eingeschaltet wird. Ist die Lampe bereits per Motion eingeschaltet, wird nur das Abschalten deaktiviert. So kann der Anwender das Dauerlicht per Taster einschalten und der Motion hat trotz seiner Nachrichten keine Wirkung, weil im Skript die vom Motion eintreffende Nachricht ausschließlich im ausgeschalteten Zustand zum Zuge kommt oder wenn das Einschalten per Motion erfolgte (Retriggerung).

Der i4 muss den URL http://<IP Adresse des Schalt-Shelly>/script/<Skript Id>/toggle wie in #50 beschrieben per dem Taster/Eingang zugeordneter Action verwenden.

Zum testen kannst du diesen URL aber auch in der Browser Adresszeile anwenden. Mit diesem URL schaltet das Skript die Lampe ein und/oder lässt vom Motion eintreffende Nachrichten http://<IP Adresse des Schalt-Shelly>/script/<Skript Id>/on?<Dauer in Sekunden> ignorieren, bis die Lampe per i4 Taster ausgeschaltet wird. Da du afaik nur einen Taster dafür verwenden willst, habe dafür die toggle Funktion genutzt, weshalb der URL am Ende auch "toggle" beinhaltet (nur als verständlichen Namen).

Da ich derzeit keinen Pro 3EM besitze, kann ich dir nun nicht weiterhelfen.

Protokollfehler sollten die Funktion des Shelly nicht beeinflussen, es ist halt "unschön".

Ich täte an einer solchen Stelle das Protokoll auf einen Arbeitscomputer herunterladen und mir etwas genauer ansehen.

Vielleicht wäre dabei etwas Auffälliges zu finden.

Zitat von Maunty

Bei dem lokalen Shelly (wo letztendlich die Aktion gestartet werden soll) muss ich im script die 127.0.0.1 einsetzen, da sich das Shelly nicht mit der eigenen IP ansprechen kann, oder ?

Und bei dem anderen (remote) shelly die IP Adresse des Shellys wo die Aktion gestartet werden soll.

Ja und ja.

Zitat von Maunty

Bei allen anderen die BT Gateway funktion einschalten habe ich gemacht aber ist dann auch notwendig bei allen das script aufzuspielen ?

Das ist zu vermuten. Dazu habe ich dir eine Vorgehensweise in #5 empfohlen.

Beispiel eines Protokolls auf einem Plus Plug S:

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

Klicke dazu auf "CLEAR LOG"!

Du kannst vorher das Protokoll auf einen Arbeitscomputer herunterladen.

Ach so und btw, App und Cloud sind für solche Zwecke total suboptimal.

Ein auf den ersten Blick überzeugendes Skript.

Ich nutze derzeit mit Shelly kein Bluetooth.

Soweit ich bisher verstand, stellt das Skript die Funktion des Gateway her.

Aus dem Skript: "This script lets you use your Gen2 device as a gateway ..."

Zitat von Maunty

Muss dieser script in allen Geräten installiert sein zu welchen der Button Zugriff hat

Ich empfehle dir folgende Vorgehensweise zum testen.

1. Installiere das Skript auf mindestens zwei relativ weit voneinander entfernten Shelly Plus!
2. Passe beide Skripte in der Konfiguration (oben im Skript) für deinen Test an!
3. Begib dich mit dem Blu Button mal nahe zu dem einen Shelly (weit weg vom anderen) und prüfe, ob das Gewünschte bei Tastendruck geschieht.
4. Wiederhole das Gleiche mit dem anderen Plus Shelly!
5. Halte auch erst das eine und dann das andere Skript an und teste, was bei Tastendruck - nicht - geschieht!

Um ganz sicher zu sein, kannst du auch jeweils einen der beiden Skript Shelly von der Versorgung nehmen.

Das Skript verwendet verständlicherweise die Methode "HTTP.Get", weshalb in der Konfiguration ausschließlich URL greifen.

Soweit mir bekannt ist, verwendet ein Blu Button das am nächsten verfügbare Gateway. Dass hierfür auf allen betreffenden Plus Geräten die Gateway Funktion zu aktivieren ist, weißt du sicher bereits.

Vor einem Eintrag in die CONFIG Struktur solltest du auch per Browser den gewünschten URL testen.

Zitat von Kraftwerkbetreiber

Firmwareprotokoll..... mhh wo finde ich das?

Damit meinte ich das bereits von der Firmware bereitgestellte Protokoll.

Dazu solltest du statt App und Cloud einen Web Browser mit der Shelly IP Adresse verwenden.

Dort sollte das Protokoll erreichbar sein.

Hier ein solches von einem Plus Plug S:

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

Zu Szenen können Andere wesentlich mehr beitragen als ich.

Erst wenn eine Sicherheitseinrichtung greift, weiß man sicher, wofür sie da ist.

Bei Internet- oder nur Cloudausfall ist deine Steuerung wirkungslos.

Wenn ich sicher sein will, dass etwas auf die gewünschte Weise funktioniert, dann implementiere ich dies

1. lokal, auch ohne Cloudverfügbarkeit und möglichst autark auf einem Gerät
2. per Skript, welches erheblich bessere Testmöglichkeiten bietet als Szenen

Dass man per Skript und ... wesentlich mehr erreichen kann, will ich nur beiläufig erwähnen.

Selbstverständlich ist es Ok, wenn du bei Cloud-Szenen bleiben willst.

Um das tatsächliche Verhalten zu protokollieren, kannst du erst einmal im Firmware-Protokoll nachsehen. Vielleicht kannst du dort fündig werden.

Für ein selektives Protokoll kann man ein Skript einsetzen, welches dafür sehr gezielt zusammenstellbar ist.

Gegen eine hier oftmals vorzufindende Skript-Phobie bin ich machtlos. Verständlich ist aber, dass man vor Skript zurückschreckt, wenn man keinerlei Ahnung vom Programmieren hat.

Ich kann derzeit keinen Blu Button nutzen.

Ich täte erst einmal prüfen, ob ein Gateway Shelly eine Nachricht per Action weitersenden kann.

Das lokale Auslösen auf einem Shelly der zweiten Generation täte ich nicht mit der localhost IP Adresse implementieren, obwohl das auch funktionieren sollte.

Dafür gibt es die RPC Methoden, welche in einem Skript per Shelly.call() lokal nutzbar sind.

Da du das Skript weder direkt noch per Link zur Verfügung stellst, kann ich zum Skript selbst nicht sagen.

Zitat von Maunty

Doppelklick auf einen Shelly 1 Mini

Wenn ich auf einen Shelly klicke, reagiert der auch nie.

@66er

Auto Off gelingt afaik nur per Sekunden-Auflösung und nicht per Millisekunden.

Ich nehme gerne wieder mal etwas ...

Szenen sind mir nur per Cloud bekannt.

1. Du willst wirklich so etwas per Cloud lösen?
2. Welchen Shelly setzt du gegenwärtig dafür ein oder willst du einsetzen?

Mit einem Shelly der zweiten Generation und Skriptfähigkeit gelingt so etwas locker.

Über Messwerte kann ich mangels solchem Gerätes leider nichts sagen.

Dann beschreibe bitte mal möglichst genau, was du damit tun willst!

Soll die Einschaltdauer parametrierbar sein?

...

higgy

Ich kenne insbesondere die Zeitpläne (= Schedule Jobs) von Shelly der zweiten Generation - mit dem Plus im Namen.

Diese Schedule Jobs arbeiten nach meinen Erfahrungen sehr verlässlich und sie sind sehr flexibel nutzbar.

Zu Zeitplänen der ersten Generation kann ich derzeit leider wenig mitteilen.

Wenn dir diese Funktionalität wichtig ist, könntest du über einen Wechsel zu einem Plus 1 PM nachdenken.

Ich besitze keinen solchen Shelly.

Die Fehlermeldung ist sehr allgemein formuliert.

Hast du mal versucht, das Protokoll zu löschen?

Eine andere Ursache könnten (theoretisch) zu dicht aufeinanderfolgende Ereignisse sein.

Zitat von Train18

Was muss oder kann ich ändern?

Auf bessere Firmware warten

Vielleicht sind die Schwankungen in erster Linie auf das Relais zurückzuführen.

Hast du das Gleiche mal mit einem SSR geprüft?

Damit sollte auch das Prellen entfallen.

Das sind 500ms bis 2000ms und gelingt per Timer in einem Skript. Somit gelingt dies mit skriptfähigen Shelly.

Ein sog. HTTP Endpoint ist ein Name, welcher einer Funktion zugeordnet ist.

Aufruf: http://<IP Adresse des Schalt-Shelly>/script/<Skript Id>/<selbst gewählter Name>?<optionale Parameterliste>

Bsp: http://<IP Adresse des Schalt-Shelly>/script/1/ein?700

Der Skriptcode:

function send_response(response, body) {
  response.code = 200;
  response.body = body;
  response.send();
}

HTTPServer.registerEndpoint('ein',
  function (request, response) {
    send_response(response, "OK");
    let dur = 0;
    if(request.query.length > 0) dur = JSON.parse(request.query);
    if(!isNaN(dur) && dur>=500) {
        if(dur>2000) dur = 2000;
        Shelly.call("Switch.Set", {id:0, on:true});
        Timer.set(Math.floor(dur), false, function() {Shelly.call("Switch.Set", {id:0, on:false});}
    }
  }
);

Du kannst vermutlich erkennen, dass die Dauer parametrierbar ist und evtl. dass die Dauer auf 2s begrenzt ist.

Nachgereicht:

Ich habe die Dauer auch nach unten, zu kleineren Werten, begrenzt.

Zitat von Lacoste

Ich habe das über Action gelöst.

Was hast du über solche Actions gelöst?

Hast du den Thread gelesen?

Hier ist erheblich mehr gewünscht als das, was du per Actions lösen könntest.

Mit diesen URL wird das Gewünschte jedenfalls (noch) nicht gelingen.

Wenn solches gelesen und nicht geprüft wird, stellen sich völlig falsche Vorstellungen ein.

Ich lasse mich gerne überraschen.

tomsta13

Btw, ich denke mit thgoebel eine gute Referenz zu haben. Für ihn habe ich eine Shelly-Hauptuhr per Skript implementiert und solange nicht aufgehört, bis diese zuverlässiger arbeitete als eine Funkuhr ...

Daran kannst du vielleicht ermessen, dass hier nicht aufgegeben wird.

Das Skript sollte so arbeiten und tut dies bei mir auch.

Wenn der Motion das Licht einschalten lässt und während der Einschaltdauer die zugeordnete Taste am i4 gedrückt wird, wird der Timer zum ausschalten gelöscht.

Damit bleibt das Licht solange an, bis es von einem nicht Motion Gerät, also bspw. dem i4 per Taste, ausgeschaltet wird.

Überprüfe das Bitte!

Das gelingt selbstverständlich nur dann, wenn der URL stimmt und die Taste gedrückt wird, die diesem URL zugeordnet ist (Action ...).

Falls dies nicht gelingen sollte, experimentiere bitte mit den Einstellung am Eingang des i4 zu dieser Taste!

Zitat von tomsta13

egal ob Bewegung erkannt wird

Das könnte an den Einstellungen am Motion liegen. Wenn im Skript Retrigger auf true steht, dann muss mit jeder Nachricht vom Motion die Einschaltdauer von vorne beginnen, weil dann der Timer neu gestartet wird.

Zitat von tomsta13

ich habe eure Geduld genug strapaziert

Nein! Ich bin davon überzeugt, dass alles genau so funktioniert, wie ich es beschrieb und dies afaik von dir gewünscht ist.

Ich gebe nicht eher Ruhe, bis es gelingt.

... ähm ... oder es dich zu sehr nervt.

Falsch.

Du hast mich auch in unserer Konversation unterstützt.

Ohne diese hätte ich vermutlich diese letzte Version nicht erstellt.

Herr Shelly-Meister