Beiträge von eiche

    Hmm, liest sich so wie "von hinten durch die Brust in's Auge". ;)

    Es geht mit ziemlich viel Aufwand sicher auch das, was dir vorschwebt. Ich täte solches nicht weiter verfolgen.

    Hast du mal darüber nachgedacht, deine bisherige Funkanlage durch Shelly zu ersetzen, möglichst ab Generation 2? Vielleicht gelingt dies auch parallel zur bestehenden Funkanlage. Dazu kann ich leider nicht viel mitteilen, da meine neuen Rollladenantriebe mit einfachen Motoren und drei Anschlüssen ausgestattet sind und bestens an Shelly 2.5 sowie Shelly Plus 2PM arbeiten.

    Du könntest aber für den Anfang mit einem Rollladen experimentieren, was auch bereits per altem Shelly 2.5 gelingt. Jedenfalls brauchst du dann zu jedem Rollladen einen einzelnen Shelly, was du ja bereits feststelltest.

    Zielführend für ein solches Vorhaben wären genauere Angaben zu deinem Rollladenantrieb - Motoren, Motoranschlüsse, ...
    An Hand solcher Informationen können Andere hier voraussichtlich fachgerechte Hinweise geben.

    Hojo7871

    Was mir in deinem Skript unmittelbar auffällt ...

    Zeile 12:

    Code
    urlSource = "http://" & urlSourceIP & "/light/0?/getstatus"

    Der Operator & dient dem bitweisen UND verknüpfen von Operanden. Was du damit willst, ist eine String-Verkettung, wozu der Operator + geeignet ist.

    Deine Zeilen 22 bis 27:

    Code
       if (boolOnOff === true) {
         strOnOff = "on"
       }
       if (boolOnOff === false) {
         strOnOff = "off"
       }

    Umständlicher geht es kaum. Dazu zwei Alternativen:

    Code
    if(boolOnOff) strOnOff = "on"; else strOnOff = "off";

    oder noch kürzer: (gefällt nicht jedem)

    Code
    strOnOff = boolOnOff ? "on" : "off";

    Auch ist es keine gute Idee, Konstanten, wie bspw. IP Adressen, irgendwo im Code zu platzieren. Dies gehört in einen Konfigurationsbereich, möglichst Nähe Skriptanfang. Dies ist dir aber vermutlich klar, sorry.

    Die Funktion deines Skripts habe ich nicht analysiert. Mache bitte weiter! ;)

    Noch etwas mehr ...

    Prüfe bitte gelegentlich die Verwendung der Methode "Script.Eval"! Diese ist sehr leicht verwendbar und besitzt gegenüber dem Starten und Anhalten eines Skripts folgende Vorteile.

    1. Das Skript kann durchlaufen, wenn per "Script.Eval" einfach eine spezifizierte Funktion im Skript aufgerufen wird.
    2. Die aufgerufene Skriptfunktion kann Parameter importieren.
    3. Per RPC ist eine Skriptfunktion leicht aufrufbar.
      http://<IP Adresse des Skript Shelly>/rpc/script.eval?id=<Skript Id>?code="<Anweisung>"
      Als Anweisung ist fast immer ein Funktionsaufruf, bei Bedarf mit Parameter, zielführend - mit derselben Syntax wie im Skript auch.

    Allerdings wird das Skript von der Firmware abgebrochen, falls im RPC ein Fehler vorliegt, bspw. der Skriptname falsch notiert ist.

    Um einen solchen Abbruch zu vermeiden, allerdings bei Fehler ohne gewünschten Effekt, ist ein HTTPServer Endpont zielführend, was etwas mehr Code-Aufwand nach sich zieht.

    Eine Lösung per Action fällt mir dazu nicht ein. Da sind andere erfahrener als ich. Ich bevorzuge halt Skripte, die immer erfolgversprechend sind.

    Dein Anliegen habe ich verstanden und kann folgendes aufzeigen, per Skript.

    Die Pumpe wird eingeschaltet, was das Skript registriert.

    30 Minuten später kann das Skript den aktuellen Verbrauch ermitteln und auf Grund dessen die Pumpe weiterlaufen lassen oder ausschalten. abhängig von deinem Schwellenwert.

    Wenn die Pumpe weiterläuft, muss das Skript in kurzen Abständen oder per sog. StatusHandler den aktuellen Verbrauch prüfen, um bei Unterschreitung deines vorgegebenen Schwellenwertes abzuschalten.


    Edit:
    Es geht aber auch einfacher. Das Skript erfasst jederzeit die aktuelle Pumpenleistung und schaltet sicherheitstechnisch ab, wenn die Leistung den vorgegebenen Schwellenwert unterschreitet. Das sollte auch per Action gelingen.


    Edit 2:
    Dazu wären für deinen Einsatz schlicht zwei unterschiedliche Nachrichten zu verwenden.

    1. Einschalten und nach 30 min aus.
    2. Einschalten ohne Zeitbegrenzung.

    Diese Liste kannst du nach deinem Bedarf erweitern.

    In jedem Fall brauchst du einen Shelly, der die vom Verbraucher gezogene Leistung messen kann. Dazu genügt ein Shelly Plus 1 (ohne PM) nicht.

    Danke für die Erklärung.

    Welche Erklärung meinst du? Die von mir zur MQTT Kommunikation? Dies ist für mich u.U. bedeutsam.

    Ich suche jetzt schon mehrere Tsge die Seite, wo Befehle aufgeführt waren.

    Welche "Befehle"? Wenn es um MQTT geht, gibt es keine "Befehle", aber Nachrichten. Wie diese umgesetzt werden, liegt am Emfänger. Im Empfänger können "Befehle" wirken.

    Zielführende Informationen sind nur möglich, wenn deine Aussagen hinreichend verständlich (differenziert) sind.

    Edit:
    Es ist für einen Anfragenden, ich sage mal Klienten, sicher immer klar, was er meint und wie seine Umgebung gestaltet ist. Für jemanden wie mich, der versucht, das alles zu verarbeiten, ist es zumeist sehr hilfreich, wenn der Klient für ihn redundante Infos an einen Helfenden wiederholt. ;)

    der macht die Beleuchtungen aus.

    In aller Freundschaft:

    Nicht der Button macht in diesem Fall das Licht aus, sondern Amazon Software über den Internetzugriff und die Shelly Cloud. Ohne diese gelänge es nicht.

    Dies hat nicht annähernd die Funktionssicherheit einer lokalen Lösung, da kannst du oder könnt ihr soviel schreiben, wie ihr wollt. Ich bitte schlicht nur darum, diese Perspektive nicht zu ignorieren.

    Thomas63 Sei bei elektrischen Installationen sehr vorsichtig!

    Bleibe aber beim experimentieren nicht so extrem vorsichtig!

    Zumindest ich, wie sicher auch viele andere, habe meine Erfahrungen durch Experimente, Lesen, Fehler machen und reflektierendes Verarbeiten (Verstehen) von Zusammenhängen gesammelt. Das ist oft nicht unmittelbar befriedigend. Nach erfolgreicher Bewältigung in Verbindung mit dem Verstehen der Zusammenhänge stellt sich aber eine tiefere Befriedigung geistiger Art ein. ;)

    Fazit: Sei nicht so "ängstlich" - no risk no fun. ;)

    Zu deiner Frage: Ja, so sollte der URL lauten!

    Kann man das in den Einstellungen so hinterlegen das dieser Zwischenschritt nicht nötig ist?

    Ein Shelly kann ausschließlich auf Taster oder Schalter und bei Schalter in verschiedene Betriebsarten (Modi) konfiguriert werden. Dies wird auch nie mit einem binären (zumeist digital genannt) Eingang anders möglich sein. Abhängig von den eingesetzten Schaltern oder Tastern, ggf. mit mechanischen Verriegelungen/Freigaben, können solche Handhabungs-Unannehmlichkeiten auftreten, was per Firmware nicht vermeidbar ist. Ob hier ein Skript helfen könnte, weiß ich derzeit nicht, weil ich solche "altdeutschen" ;) Schalter bewusst nicht einsetze. Solche Schalter/Taster ... entsprechen halt den Kenntnissen deutscher Mechanik-Fachkräfte, die die Flexibilität von Software auf Mikrocontroller nicht erkennen wollen oder können. :rolleyes:

    Es gibt hierfür nichts flexibleres als schlichte Taster in Verbindung mit einem Skript. Damit lassen sich (vermutlich) alle Bedienungswünsche erfüllen. Nur eine Gesichtserkennung für unterschiedliche, individuelle Bedienungswünsche wären damit nicht erreichbar. :S

    Nun bleiben dir folgende Möglichkeiten.

    1. Ihr unterwerft euch den vorgesehenen Bedienungen.
    2. Du experimentierst mit der Konfiguration, um schließlich eine akzeptable Lösung zu finden oder deren Grenzen zu erkennen.
    3. Du verwendest schlichte Taster und experimentierst mit der Konfiguration - ggf. ohne den gewünschten Erfolg.
    4. Du findest einen Weg zur Skriptnutzung und tauschst, falls erforderlich deine Schalter gegen schlichte Taster aus.

    Deinen Königsweg musst du selbst finden, wenn es einen solchen überhaupt gibt. Ich habe meinen per Taster und Skript gefunden.;)

    thdoerr

    Ich dachte noch einmal über das Skript nach und favorisiere folgende relativ einfache Implementation. Dabei setze ich voraus, dass die Durchführung auf den Gruppenmitgliedern gerne auch um jeweils bspw. 1s versetzt erfolgen darf.

    Das Skript kann mit wenig Aufwand noch vielseitiger verwendbar gestaltet werden. Hier ist die Anzahl an Gruppenmitgliedern bereits nur durch die interne Speicherkapazität begrenzt. Das Ganze ohne Warteschlange, aber robust, weil die Aktionen zeitversetzt genutzt werden. Ungetestet, aber wegen Einfachheit vermutlich so lauffähig.

    Wenn in einer Button 1 Action ein Namensfehler, bspw. statt "to_all" als Funktionsname "toall" eingetragen ist, wird das Skript leider gestoppt. Das liegt nicht am Skript sondern an der Firmware bzw. der verwendeten Methode "Script.Eval". Es ginge auch robuster ohne Skriptstop, im Fehlerfall nur mit Nichtausführung des Gewünschten, das macht aber das Skript etwas komplexer.

    Wenn mit dem Period Wert experimentiert werden will, dann nur soweit verkleinern, bis das Skript mit Fehlermeldung abbricht. Danach vorsichtshalber den letzten Period Wert verdoppeln - fertig.

    Die im Button 1 zu jedem spezifischen Tastendruck einzutragende Actions:
    (Hier mit vorausgesetzter Skript ID von 1, was mit dem ersten Skript immer der Fall ist.)

    zum öffnen

    Code
    http://<IP Adresse des Skript Shelly>/rpc/script.eval?id=1&code="to_all(cover.open)"

    zum schließen

    Code
    http://<IP Adresse des Skript Shelly>/rpc/script.eval?id=1&code="to_all(cover.close)"

    zum anhalten

    Code
    http://<IP Adresse des Skript Shelly>/rpc/script.eval?id=1&code="to_all(cover.stop)"

    Zum fahren auf eine Position müsste das Skript ein wenig umgestaltet werden.

    Falls du es einsetzt, viel Erfolg damit und Freude daran! ;)

    Die Skript-Lösung kann leicht per Konfiguration vielseitig gestaltet werden. Diese Konfiguration kann im Skript selbst vorliegen oder im KVS - für solche, die lieber kein Skript öffnen. ;)

    Ungetestet: Der Parameter doThis ist schlicht die zu verteilende Methode. Hier habe ich die Component Id mit 0 fest verankert.

    Problem: Die Methodenaufrufe sind in ihrer Anzahl begrenzt nutzbar.
    Abhilfe wäre die Nutzung einer FiFo-Struktur (Warteschlange, Queue), in die alle Aufträge eingeschrieben und in Abständen von ca 1 bis 3s abgearbeitet werden.

    Eine entsprechende Action im Button 1: Das obige Skript möge die Id 1 besitzen.

    Code
    http://<IP Adresse des Skript Shelly>/rpc/script.eval?id=1&code="to_all(cover.open)"

    zum öffnen der Rollläden. Die anderen Actions zum schließen, anhalten, ... entsprechend.

    Du kannst selbstverständlich das Skript auch auf die Component "Cover" bereits festlegen und nur noch als Parameter die Cover-Methode übergeben.

    Oder in Members Objekte (JSON) unterbringen mit der jeweiligen IP Adresse und der Component Id, was das Skript noch ein wenig flexibler macht ...

    Den Aufruf eine Cloudszene praktiziere ich nicht, es mag aber durchaus möglich sein und ich las etwas dieser Art, so glaube ich, hier bereits.

    Versuche einfach mal, zu jedem Shelly Plus 2PM im Button 1 eine Action anzulgen und teste dies!
    Ich kann derzeit solches nicht testen.

    Sollte dies nicht gelingen, bleibt noch ein Skript, welches auf einem dieser Plus 2PM läuft. Dieses Skript ist sehr einfach. Per einfachster Implementation braucht es nur eine Funktion, ich nenne sie mal "to_all(doThis)". Diese Funktion wird per Button 1 Action und der Methode "Script.Eval" aufgerufen. Sie ruft seinerseits die RPC Methoden aller anderen Gruppenmitglieder mit dem jeweils passenden URL auf und erledigt dies auf dem eigenen Shelly selbst.

    Falls du weitere Hilfe dazu brauchst, kann ich mehr dazu schreiben.

    Edit:
    Du kannst selbstverständlich auch auf bspw. zwei der Plus 2PM jeweils Actions anlegen, die die jeweilige Action an weitere Plus 2PM senden und so eine Art Verteilung statt "Broadcast" einzusetzen. Dann braucht der Button 1 nur zwei oder 3 Actions zu jedem verwendeten Tastendruck. Die Skriptvariante läge mir näher, weil dazu auf dem Button nur jeweils eine Action pro spezifischen Tastendrucks erforderlich und die Verteilung leichter pflegbar ist.

    Ich erwarte die Lieferung eines Wall Display, habe aber noch keines.

    Ich kann dir somit nur empfehlen, die Dokumentation zu Shelly Duo zu lesen und damit bspw. zunächst per Web Browser und URL zu experimentieren. Wenn die zielführenden URL bekannt sind, kannst du damit versuchen, dein Ziel zu erreichen.

    Dazu täte ich auf dem Wall Dislay

    1. die Möglichkeiten von Actions untersuchen,
    2. falls dies nicht genügt, ein Skript erstellen und damit experimentieren.

    Bisher fand ich leider noch kein API zum Wall Display. :(
    Deshalb hänge ich mich an deinen Thread an mit der Frage: "Wo ist die Beschreibung einer API zum Display selbst zu finden?"

    thdoerr

    Vergiss erst einmal die Cloud und/oder Alexa! Dahin kannst du immer noch wandeln. ;) Dies kann für dich bedeutsam sein, muss es aber nicht in allen Fällen.

    Btw, nicht jeder Sprachassistent hört auf Alexa. Nicht jedes Papiertaschentuch ist ein Tempo-Taschentuch. Nicht jeder Suchdienst ist ein "Google". X(

    1. Wie viele Geräte sind in deiner Gruppe?
    2. Hast du vor, diese Gruppe so erweitern zu können, dass du am Button 1 nichts ändern musst?
    3. Nutzt du ein übergeordnetes System wie ioBroker, HomeAssistant, HomeMatic, Node-RED, ... ?
    4. Nutzt du andere Shelly ab Generation 2? Vielleicht hat ein solcher noch einen ungenutzten Ausgang.

    Bedenke, dass Cloud erst einmal eher schlecht ist. Ich bin es müde, die Gründe dafür immer wieder aufzuzählen. Nimm stattdessen einfach meine Signatur!

    Es kann durchaus nützlich sein, eine Cloud-Gruppe anzusprechen.