Beiträge von eiche

VPN/Proxy erkannt

Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.

    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.

    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 ..."

    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.

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

    Doppelklick auf einen Shelly 1 Mini

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

    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.

    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.

    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:

    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.

    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.

    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!

    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.

    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. 8)

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

    Es ließ mir keine Ruhe. Hier die verbesserte Version des Skripts.

    Was habe ich verbessert?

    1. Das Skript ist besser strukturiert.
    2. Die Methode Script.Eval habe ich durch einen zweiten HTTP Endpoint ersetzt.
      Solange in den remote Geräten solche Endpoints verwendet werden - und kein Script.Eval - wird das Skript nicht abgebrochen, auch wenn der Endpoint Name nicht passen sollte.
    3. Die Protokollausgaben sind verständlicher und lassen den Ablauf leichter verfolgen.
    4. Der Ausgang, also dessen Id, kann per Variable out festgelegt werden.

    Was bleibt wie es war?

    Der Action URL in den Bewegungsmeldern, also nicht ändern! Endpoint Name lautet "on".
    http://<IP Adresse des Schalt-Shelly>/script/<Skript Id>/on?<Dauer in Sekunden>

    Was muss geändert werden?

    Der Action URL in den Geräten, die remote umschalten, also ändern! Endpoint Name lautet "toggle".

    http://<IP Adresse des Schalt-Shelly>/script/<Skript Id>/toggle

    Beide Informationen werden bei Skriptstart im Protokollfenster mit aktuellen Werten ausgegeben.

    Das gleiche Skript mit der nach ostfriese kleiner Änderung für die anwenderfreundliche Ausgabe nach Skriptstart.

    Dafür ist nichts an den anderen Geräten zu ändern.