Beiträge von eiche

    Shelly Script bzw. mJS ist eine Untermenge von JavaScript mit zusätzlichem API (Application Programming Interface).

    Die API beinhaltet die in der Shelly Dokumentation beschriebenen RPC Methoden (Remote Procedure Call), welche u.a. per HTTP und in einem Skript per Shelly.call(Methode, Parameter, callback) aufgerufen werden können.

    Zum erstellen oder anpassen eines Skript solltest du dich deshalb auch mit JavaScript beschäftigen.

    Eine brauchbare Quelle (Tutorial und Referenz zum Nachschlage) hierfür ist w3schools: https://www.w3schools.com/

    … aber wie selektiere ich nun den Inputs. wo, an welcher Stelle ergänze ich input:2 bzw. id:2

    Wenn du im Skript bspw. alle 4 Tasten unterschiedlich nutzen willst, kannst du eine Fallunterscheidung verwenden.

    Weil die Event Informationen redundant sind, brauchst du hier den Komponentennamen nicht, es genügt deren Id, wenn zuvor der Name auf "input" geprüft wird.

    Kleiner Hinweis:

    Ich nutze nicht selten bei englischsprachigen Begriffen und Abkürzungen mal dieses mal jenes Geschlecht.

    API mit I = Interface kann als das Interface oder als die Schnittstelle gedacht werden, entsprechend das API oder die API.

    Edit:

    Zur Sprache Shelly Script kenne ich kein Tutorial. Dasjenige in der Shelly Dokumentation ist ausschließlich zur Handhabung von Skripten geeignet, nicht zum kennenlernen der Sprache.

    Auch kenne ich keine JavaScript Einführung, die außerhalb von Webseiten angesiedelt ist.

    Da muss man halt durch, wobei die Kenntnis einer C ähnlichen Sprache nützlich ist.

    Abhängig von der Umgebung (Weglänge, Position des Blu Motion, übliche Laufwege), könnte vielleicht ein zusätzlicher (Blu) Motion in Verbindung mit einem Skript helfen.

    Der erste Motion sendet eine Nachricht an den Plus 1 bzw. Skript.

    Das Skript verzögert das Einschalten (Wartedauer).

    Wenn der zweite Motion innerhalb der Wartedauer eine Nachricht sendet, unterbleibt das Einschalten.

    Andernfalls schaltet das Skript nach Ablauf der Wartezeit ein, weil die Person sich vermutlich noch im Bereich des ersten Motion aufhält.

    Hierfür ist eine gute Abstimmung und Platzierung der Motion zielführend, was selbstverständlich nicht in jeder Umgebung möglich ist.

    Oder 89new experimentiert mit einem Motion ohne Blu. ;)

    Die Id steckt in event.info.

    Code
    Shelly.addEventHandler(
      function (event) {
        if(event.name==="input"){
          let id = event.info.id;
          // Nun kannst du die gewünschte id selektieren.
          // ...
        }
      }
    } 

    So etwas kannst du selbst herausfinden, indem du event per print() ausgeben lässt - weniger Zeilen umfassend per print(JSON.stringify(event)).

    Wenn du den Überblick hast und dich bspw. nur für das interessierst, was in event.info steckt, dann print(JSON.stringify(event.info)).

    ...

    Ich verstehe nicht, warum ich immer wieder diesen user_data als Parameter finde, obwohl nichts dafür oder null übergeben wird. Das ist absoluter Unsinn.

    Wenn du den Code leicht verbessern willst, nimm dieses stereotype, überflüssige Zeug heraus!

    Am Beispiel der Funktion toggleRGBW(ip) gezeigt:

    Code
    function toggleRGBW(ip) {
       Shelly.call(
           "http.get", {
               url: 'http://' + ip + '/light/0?turn=toggle'
           },
           function (response, error_code, error_message, ud) { // ud wird nicht gebraucht.
           }, // Komma weg!
           null // null bedeutet soviel wie "nichts" oder "ungültig", auch weg!
       );
    }

    Dann bliebe nur noch ein Skript auf dem Plus 1, welches abhängig von den Nachrichten des Blu Motion erst später schaltet.

    Ich kann wegen fehlendem Blu Motion nichts dazu beitragen, weil hierfür die Analyse der Nachrichten erforderlich ist.

    Außerdem hat offensichtlich die Blind Time eine andere Wirkung als die von mir angeführte Sleep Time eines Motion.

    Im Motion gibt es auch die Blind Time, welche der TE ostfriese mit seinem Beitrag ja in ihrer Wirkung beseitigte.

    walterli

    Mal unabhängig von deiner sonstigen Ausstattung.

    Du kannst eine Kombination aus Schedule Job und Skript einsetzen. Ich meine damit nicht, dass es keine andere Möglichkeit gibt.

    Die System integrierte MQTT Kommunikation ist aber etwas komplex, weil sie, jedenfalls in Shelly der zweiten Generation, eine Peer to Peer Kommunikation nachbildet.

    Das Skript braucht folgendes.

    1. Einen Eventhandler (callback Funktion) zum entgegennehmen der Messwerte. Diese sind in einer Variablen/Struktur zwischenzuspeichern.
      (Die callback Funktion kann stattdessen per Methode den Status des Shelly oder, was du brauchst, abfragen => noch eine callback Funktion in der ersten callback Funktion.)
    2. Eine Funktion, ich nenne sie mal send(), welche die zwischengespeicherten Werte per Aufruf von MQTT.publish(...) sendet. Das Topic kannst du im Rahmen der Syntax beliebig wählen.

    Der Schedule Job ruft in festgelegten Abständen die Funktion send() auf.

    Somit werden auch dann Werte, die zwischengespeicherten, gesendet, wenn keine neuen hereinkommen.

    Habe ich den Anliegen richtig verstanden?

    Wenn du weitere Hilfe dazu möchtest, melde dich!

    mrsample

    Ein Schedule Job ist erst einmal kein Shelly call.

    Da der Job aber etwas bewirken soll, ergibt er imho ohne eine Methode (im Skript als Shelly.call() nutzbar) keinen Sinn.

    Du kannst jede Methode verwenden, die dein Shelly bietet.

    Mit http://<IP Adresse>/rpc/Shelly.ListMethods kannst du alle Methoden auflisten lassen, die der Shelly bietet.

    Ein Schedule Job arbeitet unabhängig von Skripten, er kann per Methode "Script.Eval" aber eine Anweisung in einem laufenden Skript ausführen lassen.

    Zumeist dürfte es zielführend sein, per "Script.Eval" eine Funktion eines laufenden Skripts, ggf. mit Parameter, aufrufen zu lassen.

    Das Limit (derzeit 5) für Calls bezieht sich jeweils auf ein Skript und nicht etwa auf den Shelly. Seihe auch Ressource Limits

    Ein Call bzw. Methodenaufruf per Schedule Job fällt somit nicht darunter.

    Hast du mal die Periode zum Aufruf von checkWifiIP() deutlich verlängert?

    Wenn deine Vermutung der "Geister-Calls" auf Grund deren Anhäufung in einer Warteschlange zutreffen sollte, dann müssten diese ab einer genügend langen Periode wegbleiben - nur zwecks Fehleranalyse.

    Da der default Timeout-Wert 15s beträgt und du alle 2 Minuten eine Nachricht senden lassen willst, ist trotzdem nicht zu erwarten, dass diese Maßnahme weiterhilft.

    Ein Schedule Job, wie ich ihn oben angab, arbeitet eigenständig, weshalb du diesen einmal verwenden solltest, wenigstens zum testen.

    Weitere mögliche Schritte zur Fehlersuche

    1. Läuft noch irgend etwas anderes außer Skript auf deinem Shelly, vielleicht irgendwelche Actions? => Dann deaktiviere diese!
    2. Ist MQTT aktiviert? => Dann deaktiviere MQTT!
    3. Ist der Shelly in der Cloud eingebunden? => Dann nimm ihn dort heraus!
    4. Kommuniziert ein anderes Gerät per HTTP Request mit dem Shelly? => Verhindere dies!

    Weil es bisher keine Spur zur Fehlerursache gibt, will ich den Timer nicht ausschließen, auch wenn dies sehr unwahrscheinlich ist.

    Vielleicht verändert sich die Timerperiode, aus welchen Gründen auch immer. Angenommen, sie verkürzt sich. Dann könnten die periodisch aufgerufenen Calls irgendwann zu dicht aufeinander folgen.

    Hier kann ein Schedule Job Abhilfe schaffen.

    Edit:

    Man kann auch Ereignisse auslösen lassen. Damit lassen sich bspw. die Aktionen eines Skripts auf mehrere Skripte verteilen.

    Eine andere harte Alternative zum Reboot, besteht bspw. darin, das Skript die Funktion checkWifiIP() aufrufen zu lassen und sich nach 30s oder 60s selbst zu beenden. Oder das Skript beendet sich in der innersten callback Funktion, wenn also alles abgearbeitet wurde, was abzuarbeiten ist. Der Ort des Skript Stoppens wäre in deinem Skript die Funktion handleResponse(), selbstverständlich am Ende.

    Ein Schedule Job kann in regelmäßigen Abständen dein Skript per Methode "Script.Start" starten, bspw. alle 2 Minuten.

    Noch eine Idee:

    Du könntest den Shelly Plus 1 durch einen Plus 2 ersetzen.

    Dieser ist so (ohne Skript) per Action oder Leitung konfigurierbar, dass das zweite Relais den umgekehrten Zustand zum ersten einnimmt. Eine daran angeschlossene LED mit Vorwiderstand täte auch ohne Web UI den aktuellen Zustand anzeigen.

    12V Versorgung für den Plus 2 ? Hm ... mal nachsehen

    Edit: Schade, Plus 2PM geht nicht mit 12V.

    Mikelsaar

    Da dein Anliegen mit der Web UI nicht realisierbar ist, sehe ich derzeit eine einzige Möglichkeit, deinem Wunsch näher zu kommen.

    Ein Skript, welches eine interaktive Webseite zur Verfügung stellt, auf welches ziemlich alles, was an Symbolen gewünscht ist, implementierbar ist - auch die Darstellung "aktiv" bei ausgeschaltetem Relais.

    Falls du dich dafür interessierst und bereit bist, dich mit einem Skript (und etwas HTML) zu beschäftigen, liefere ich dir gerne den Anfang - bei Gelegenheit.

    Edit: Im WoMo einen zusätzlichen Shelly nur wegen eines Gimmicks zu installieren, halte ich für Energieverschwendung.

    Selbstverständlich ist es deine Entscheidung.

    Edit 2: Ich vergaß, darauf hinzuweisen, dass dafür ein Shelly der zweiten Generation oder höher erforderlich ist. Den hast du aber offensichtlich.

    Noch eine Kleinigkeit - aber nicht erheblich.

    Am Ende deines Skripts zu finden:

    Code
    var tH1 = 0;                   //Global Timer Handler
    
    checkWifiIP();
    if(!tH1) tH1 = Timer.set(interval, true, checkWifiIP);

    Da in deinem Skript nirgendwo der Timer mit dem Handle th1 beendet wird, läuft die Nutzung von th1 in's Leere. Auch die Anweisungsbedingung ist überflüssig. Es genügt - am Ende deines jetzigen Skripts:

    Code
    checkWifiIP();
    Timer.set(interval, true, checkWifiIP);

    mrsample

    Ich finde auch keine Ursache für das Skriptversagen in deinem Code.

    Ich vermute, ohne davon überzeugt zu sein, dass der Timer abgebrochen wurde.

    Grund: Wenn das Skript läuft, muss der Timer deine Funktion checkWiFiIP() aufrufen. Dann müsste zumindest hin und wieder etwas übertragen werden.

    Deshalb mein Vorschlag.

    Nimm den Timer heraus (auskommentieren) und verwende stattdessen einen Schedule Job, der bspw. alle 2 Minuten checkWiFiIP() aufruft.

    Das gelingt per URL wie folgt.

    Code
    http://<IP Adresse des Shelly>/rpc/schedule.create?timespec="0 */2 * * * *"&calls=[{"method":"script.eval","params":{"id":<Id deines Skripts>,"code":"checkWiFiIP()"}}]

    Zur Unterstützung beim Anlegen ... eines Schedule Jobs stelle ich eine Webseite zur Verfügung: Unterstützung beim anlegen, ändern und entfernen von Schedule Jobs (Zeitplänen)

    Damit kann wenigstens ermittelt werden, ob es am Timer liegt.

    Die Schedule Periode kannst du nach dem Anlegen des Jobs leicht per Web UI ändern, den Job kann man derzeit aber nicht per Web UI anlegen.

    Edit:

    Einen weiteren Schedule Job kannst du übrigens auch zum regelmäßigen starten deines Skripts verwenden.

    Und als Notfall Idee: Einen Job zum regelmäßigen Reboot des Shelly. Das muss gelingen, weil hierfür kein Skript verwendet werden muss.

    Edit 2:

    Zur Notfall Idee den passenden URL nachgereicht - ungetestet: Rebootet alle 2 Stunden

    Code
    http://<IP Adresse des Shelly>/rpc/schedule.create?timespec="0 0 */2 * * *"&calls=[{"method":"shelly.reboot"}]

    Aha, verständlich.

    Auch wenn deine bisherigen Taster-Handhabungen vermutlich so intuitiv geworden sind, dass du dich davon nicht lösen möchtest, kann ich dir folgendes als Option anbieten.

    Vorbemerkung:

    Unsere Rollladenantriebe steuern wir per je zwei Taster eines Shelly Wall Switch 4 an einem Shelly i4 und MQTT. Mit einem Switch 4 steuern wir somit zwei Rollläden oder einen Rollladen und bis zu zwei andere Schalt-Shelly.

    Die Switch 4 werden dafür nicht erforderlich sein, das müsste mit deinen Tastern genauso gehen. Auch MQTT ist unerheblich dafür.

    Mit dem oberen Taster für einen Rollladen starten wir dessen Fahrt nach oben, mit dem unteren nach unten - jeweils mit kurzem Drücken.

    Angehalten wird der Rollladen durch erneutes drücken auf denselben Taster. Fahrtrichtung geändert per Drücken auf den jeweils anderen Taster.

    Dies erscheint mir hinreichend intuitiv. Diese Funktionalität erreiche ich per Skript.

    Nun zu deinen Antrieben und Taster:

    Wenn du mein Skript, auf deinen Tasterbetrieb angepasst, verwenden tätest, wäre die beschriebene Handhabung aller Wahrscheinlichkeit nach bei dir die gleiche wie bei mir.

    Dazu wäre der "long push" als Ereignis im Skript hinzuzufügen.

    Vorteil:

    Per Skript gibt es fast beliebige Möglichkeiten, etwas gewünschtes zu triggern.

    Nachteil:

    Um ein Verhalten zu ändern, müsste eine Änderung im Skript vorgenommen werden, wozu das Skript wenigstens verstanden sein muss.

    Dieser Nachteil könnte per KVS Eintrag zum großen Teil ausgeglichen werden, wozu das Skript den entsprechenden KVS Eintrag verarbeiten müsste.

    Auch wenn ich viel im Konjunktiv schrieb, bin ich davon überzeugt, dass dies gelänge.

    Prinzip ist klar.

    Du wirst folgendes dazu brauchen.

    1. Timer
    2. Status-Struktur oder wenigstens eine Status-Variable
    3. einen EventHandler oder StatusHandler (einfach testend vergleichen), aber nicht beide
    4. Für die Aktivzeiten kannst du entweder das Skript durch zwei Schedule Jobs ergänzen oder im EventHandler die Uhrzeit abfragen und mit den beiden Zeitpunkten vergleichen.

    Vielleicht hilft dir diese Aufzählung zur Orientierung.

    Nein, nicht zwingend.

    Mit einem Stromausfall können aber auch Spannungsspitzen verbunden sein.

    Spannungsspitzen können in jedem Computer das Umkippen eines Bit (oder mehrerer) erzeugen.

    Wenn dies zufälligerweise im nichtflüchtigen Speicher dort geschieht, wo Konfiguration abgelegt ist ...

    Das ist wenig wahrscheinlich, aber möglich, abhängig von der Speichertechnologie.

    Wenn sich dies wiederholen sollte, halte ich eine solche Ursache allerdings für wenig wahrscheinlich.

    Um mehr darüber zu erfahren, müsstest du dich zu einem Nanowesen oder kleiner ;) transformieren, in den Chip eindringen und die Halbleiterpfade nach breiter "ausgetretenen" Pfaden, eigentlich per stärkerer Strömchen erwirkten Kristallumbildungen (Stromkanälen), absuchen.

    Ich mag die App für solche Zwecke nicht, weil ich damit nicht erkennen kann, was während des Einrichtens geschieht.

    Deshalb empfehle ich, die ursprüngliche Vorgehensweise ohne App zu verwenden.

    1. Mit AP des Shelly verbinden.
    2. per Web Browser und IP Adresse 192.168.33.1 die Web UI laden.
    3. Per Web UI konfigurieren, also zunächst in das WLAN einbinden.
    4. Die IP Adresse des Shelly ermitteln, wenn nicht unter 3. eine statische vergeben wurde.
    5. Im Browser per neuer IP Adresse die Web UI laden und damit weiterarbeiten.