Beiträge von eiche

Hier gibt es ein gut dokumentiertes und relativ leicht anpassbares Beispiel: https://shelly-api-docs.shelly.cloud/gen2/Component…rvices/Schedule

mal hierher kopiert:

{
     "id": 1,
     "enable": true,
     "timespec": "0 34 17 * * SUN,MON,TUE,WED,THU,FRI,SAT",
     "calls": [{
         "method": "Switch.Set",
         "params": {
           "id": 0,
           "on": false
         }
       }
     ]
}

"id" und Wert (hier 1) wird nur bei Änderung des Schedule Jobs gebraucht.

"timespec" ist sehr flexibel nutzbar, hier für alle Wochentage, stattdessen täte es auch ein schlichtes Asterisk (*).

Um 17:34 Uhr wird Ausgang 0 ausgeschaltet.

In "timespec" kann man auch sunrise, sunset oder von - bis nutzen.

Nun kann man als Methode "Switch.SetConfig" einsetzen und die entsprechenden Parameter dazu.

Ich kreiere dies mal noch ohne Test:

{
     "timespec": "0 0 22 * * SUN,MON,TUE,WED,THU,FRI,SAT",
     "calls": [{
         "method": "Switch.SetConfig",
         "params": {
           "id": 0,
           "in_mode": "detached",
           "initial_state" : "off"
         }
       }
     ]
}

Die id und enable des Schedule Jobs habe ich weggelassen. Damit sollte täglich um 22:00 Uhr der Schalter/Taster jeden Einfluss auf den Schaltausgang verlieren.

Die gegenteilige Aktion wäre entsprechend zu gestalten - in einem weiteren Schedule Job.

Wichtig! Das sollte ohne irgendein Skript funktionieren.

Per http gelingt das Deaktivieren/Sperren des Schalters/Tasters folgendermaßen:

http://192.168.33.1/rpc/switch.setconfig?id=0&config={"in_mode":"detached","initial_state":"off"}

Das Gegenstück wird auch kein Problem sein.

Wie ich dies in einen Schedule Job einbauen kann, weiß ich noch nicht.

Ergänzung zum Skript-Wissen

(an dieser Stelle eher nicht off topic)

Diese Skripte arbeiten ausschließlich Ereignis gesteuert. Wer etwas anderes versucht, wird Schiffbruch erleiden.

Falls kein geeignetes Ereignis eintreten sollte, kann man solche mit einem periodisch arbeitenden Timer nachbilden.

Hierfür ist nach meinen Erfahrungen in den meisten Fällen ein Schedule Job besser geeignet, welcher allerdings anzulegen ist. Damit dies relativ einfach gelingen kann, habe ich dazu eine Webseite erstellt: tools.eichelsdoerfer.net/schedjob.html

Solche Schedule Jobs können durchaus den per Web UI angelegten hinzugefügt werden, allerdings (noch) nicht per Web UI.

Per aktivem Schedule Job wird schlicht eine Funktion im (laufenden) Skript aufgerufen, ggf. mit Parameter. Diese Skript-Funktion muss im Schedule Eintrag eingebaut werden, was nicht schwierig ist.

Hier kann jede Skript Funktion oder eine Anweisung eingetragen werden. Entscheidend ist, dass das Skript mit der einzutragenden Id läuft (running).

Auch das Eintragen bzw. Austragen eines Eventhandlers ist möglich.

Zum von ostfriese angestrebten Prinzip:

Erstelle im Skript zwei Funktionen "enableEventHandler()" und "disableEventHandler()", welche das tun, was ostfriese in #91 darlegte! Dann erstelle zwei Schedule Jobs, welche ebendiese Funktionen zu gewünschten Zeiten aufrufen ...

Edit: (für etwas Fortgeschrittene)

Wer mag, kann in einem Schedule Job auch das Auslösen eines Ereignisses per Shelly.emitEvent(...) implementieren. Dann kann ein beliebiges, vom Anwender/Entwickler bevorzugtes Ereignis ausgelöst und per Eventhandler, auch in mehreren Skripten auf demselben Shelly, verarbeitet werden. Das ist sozusagen das High End der zeitgesteuerten Verarbeitung.

Edit 2: (unmittelbar zum angestrebten Ziel des TE)

Vermutlich können sogar ohne Skript zwei Schedule Jobs das Ziel erreichen. Allerdings wären solche Einträge nicht simpel. Sie müssten die RPC Methode Switch.SetConfig nutzen. Vielleicht werde ich das mal testen. Und wenn mich der Affe beißt, könnte ich sogar eine Webseite speziell dafür erstellen ... mhh ...

Eine Zeit auf Gleichheit zu testen, halte ich für problematisch. Der Vergleich sollte eine Ordnungsrelation (<, >) beinhalten, damit er robust funktioniert.

Auch hier täten locker zwei Schedule Jobs greifen, welche solche Zeiten bzw. sunrise und sunset nutzen.

Edit: Nach meinen Erfahrungen arbeiten die Schedule Jobs verlässlicher als jedes Skript.

Möglicherweise ist eine Implementation, welche Schedule Jobs nutzt, doch zu bevorzugen.

siehe bspw. meine Postings #46, #47

Zitat von ostfriese

"script:1":{"id":1,"running":false,"mem_free":25200,"errors":["error"]}

Dies interpretiere ich als einen Fehler, der im Skriptablauf auftrat, zu welchem aber keine genaueren Informationen vorliegen.

Ich täte nun im Skript eine, oder mehrere, Ausnahmebehandlung(en) einbauen - Stichworte: try und catch

Zitat von ostfriese

"wifi":{"sta_ip":"192.168.0.22","status":"got ip","ssid":"nicht verbunden!","rssi":-75}

Korrektur: Die SSID lautet "nicht verbunden!", was nicht heißt, dass der Shelly nicht mit dem AP verbunden ist.

Nach einem kurzen Test sollte hier bei verlorener Verbindung zum AP stehen:

    "wifi": {
        "sta_ip": null,
        "status": "connecting",
        "ssid": null,
        "rssi": 0
    },

Überprüft mit einem Shelly Plus 1 und meinem Smartphone Hotspot, Firmware 1.2.0-beta1

Aber nur dann, wenn der Gen 2 mit einem Auge zwinkern kann.

leicht off topic, zur Begriffsklärung

Ein Server ist grundlegend Software, bspw. auch ein Skript.

Eine Aussage wie "Der Server steht dort.", womit zunächst Hardware gemeint ist, ist nicht ganz falsch, wenn die Hauptaufgabe des Computers ist, Server (Dienste) bereitzustellen.

Grundlegend ist sie aber falsch, weil Server, wie angemerkt, Software ist.

Vor diesem Hintergrund ist das Skript von ostfriese ein Server, welcher als Hardware einen Shelly der zweiten Generation braucht. Auf diesem Shelly läuft also der Server (Skript), welcher anderen Shellies, auch der ersten Generation zur Verfügung steht.

Ich hoffe, damit nicht noch mehr verwirrt zu haben.

Ergänzung:

Wenn du per Browser den URL http://<IP-Adresse Shelly>/rpc/shelly.getstatus eingibst, kannst du unter "script:<id>" ggf. eine Fehlerursache ablesen.

horkatz

Kläre mich bitte mal auf, wie das mit Signal gelingt. Bisher nutze ich solche Mitteilungen von Shellies nicht.

DIYROLLY: Ich habe deine Hinweise in meine Doku eingebaut.

Die Dimensionierungen habe ich als "geschätzt" und überprüfungswürdig beschrieben, weil ich derzeit nicht die Muße habe, dies genauer zu testen.

Wenn du nachliest, kannst du prüfen, ob die Schaltskizzen und die Schätzwerte deiner Meinung nach passen.

Der 100µF Kondensator ist vermutlich eh überdimensioniert. Er tat es halt und ich war froh, dass dieses Prinzip funktioniert.

Dann legte ich meine Priorität auf die Verbesserungen des Skript.

Ich werde in Kürze deine Hinweise in meine Doku einbauen.

Brauchst du nicht aufzuzeichnen. Ich bin mit Elektronik hinreichend vertraut und habe deine Alternative verstanden.

Danke DIYROLLY, die schlagartige Entladung sagte mir auch nicht zu und ich dachte ebenso über einen Entladungswiderstand nach.

Ich werde deine Hinweise gerne verarbeiten und zumindest teilweise testen.

Bisher funktioniert alles wie gewünscht, allerdings nur in selten genutztem Laboraufbau.

Deine Hinweise sind jedenfalls angemessen und verständlich.

Edit:

Ich nutze das Projekt im praktischen Einsatz, nur bisher ohne die Taster.

Dort bewährt es sich bestens.

In einem parallelen Testaufbau stecken die Taster.

Ja klar, gerne.

Ich finde es nicht auf die Schnelle hier im Forum.

Deshalb hier der Link zu einer meiner Websites, auf welcher ich das Projekt beschreibe, noch ohne herunterladbarem Skript.

Autarke Heizkreisregelung per Shelly Script

Bei deutlichem Interesse am Skriptcode werden ich voraussichtlich diesen zum Herunterladen bereitstellen.

Ich bitte dann um eine entsprechende Mitteilung.

Falsch: Das Skript ist längst herunterladbar, hatte ich vergessen.

Edit: An der Verbesserung der vom Skript gelieferten Webseite werde ich noch arbeiten. Es gibt dazu neue Erkenntnisse und Ideen.

ostfriese

Ich kann hierfür mein laufendes Projekt zur Temperaturregelung einzelner Heizkreise auf der Basis von Skripten empfehlen.

Dieses ist

1. anpassbar
2. pflegbar
3. bisher robust am laufen
4. relativ ausfallsicher, s.a. Webserver im Skript
5. weitgehend unabhängig von Herstellerfehlern - Firmware ausgenommen
6. bereits mit Shelly Plus 1, AddOn und Temperatursensor arbeitsfähig
7. per zusätzlicher Taster und Elko am AddOn, also Niedrigspannung, leicht für Laien bedienbar.

Einschränkungen:

• Stromversorgung erforderlich, dafür aber auch kein Laden eines Akku notwendig
• Keine Anzeige, dafür aber der im Skript implementierte kleine Webserver, der eine Website liefert, welche von jedem halbwegs aktuellen Browser dargestellt werden kann
  (Diese Website ist auch dann per Shelly eigenem AP nutzbar, wenn das WLAN ausgefallen sein sollte. Auch eine LAN-Verbindung durch portieren auf einen Pro ist selbstverständlich möglich.)
• Ich kann selbstverständlich keine Gewährleistung übernehmen, halte aber die Qualität dieser Implementation für relativ hoch - zumindest verlässlicher als die TRV.

Außerdem entwickle ich daran weiter, wenn es mich packt.

Da du Skripten eher zugeneigt bist, könntest du dieses Projekt, quasi als Fork, selbst weiterpflegen.

LockeR56

Ich las diesen Thread erstmalig.

Hattest du auch mal den Shelly spannungsfrei geschaltet - Sicherungsautomat zu diesem Stromkreis aus?

Nach dem erneuten Einschalten und dem Booten des Shelly, hätte der Betrieb evtl. wieder funktioniert.

Aus gegebenem Anlass - eine von mir versehentlich weggelöschte E-Mail Anfrage

Ich erhielt kürzlich eine E-Mail, vermutlich von hier ausgehend weitergeleitet, welche ich leider nicht sorgfältig betrachtend zügig als Spam weglöschte.

In dieser E-Mail fragte mich der Absender, ob ich ihm für 70€ "eine solche Uhr" herstellen könne.

Im Nachhinein erfasste ich, dass er sich auf meine Implementation einer "Hauptuhr" in einem Shelly Plus 2 per Skript bezogen haben dürfte.

Falls der Absender dies hier liest, möge er sich bitte noch einmal dbzgl. an mich wenden, damit ich ihm antworten bzw. die Rahmenbedingungen erfragen kann.

Hier noch einmal die Links zur Beschreibung:

Emulation einer Hauptuhr per Shelly Plus 2

Hauptuhr-Emulation per Shelly - Installationsanleitung

Optionaler Tönezusatz

Zusätzlich lasse ich per altem Raspberry Pi mit Node-RED Flow und angeschlossenem Lautsprecher beliebige Töne alle Viertelstunde und zu jeder vollen Stunde (unterschiedlich) wiedergeben, selbstverständlich nur zu festgelegter Zeitspanne tagsüber.

Diese Töne sind beliebige Sounddateien, welche auf dem Raspberry abgelegt und dort nach Wunsch per kurzen JSON-Textdateien zu konfigurieren sind. Die zugeordneten Konfigurationsnamen (Dateinamen) werden auf dem Shelly im KVS abgelegt und sind entsprechend änderbar.

Aktuell werden in meiner Installation eine Abwandlung des Westminster Abbey Gong zu voller Stunde und eine Kuckuckruf zu jeder Viertelstunde (ein-, zwei- und dreimal) wiedergegeben.
Für mehr siehe Hauptuhr per Shelly Plus 2 - Audio Erweiterung und mehr

Eine solche Uhr läuft übrigens längst sehr zuverlässig mit automatischen Zeitumstellungen an meiner Schuppen-Außenwand - bisher verlässlicher als jede Funkuhr.

Diese Nebenuhr wurde mir dankenswerterweise von thgoebel geschenkt, da er, so darf ich behaupten, mit meiner Implementation sehr zufrieden ist.

Btw, das Hauptproblem beim "Herstellen" einer solchen Uhr ist die Beschaffung solcher alten Nebenuhren, wie sie bspw. in der Abbilddung gezeigt ist.

Solche Uhren ohne eigenen Taktgenerator (Uhrwerk) können auch andere Bauformen haben, wie bspw. eine Klappzahlenuhr mit zyklisch herunterklappenden Zahlenschildern.

Den Rest mit Shelly Plus 2 und Skript sowie einrichten der Hauptuhr (Shelly Plus 2 + Polwenderelais) kann ich beisteuern.

Thomas arbeitet vermutlich noch gelegentlich am Einbau eines SSR (Solid State Relais) inkl. Polwende in den Shelly als Ersatz für die beiden "Klick-Klack Relais", wodurch das externe Polwenderelais obsolet würde.

Ich hoffe, darüber bei unserem nächsten Treffen mehr zu erfahren.

Nordlicht_2023

Ich denke, dass du wenigstens einen Teil meiner Projektlösung brauchen kannst.

Wie ich weiter oben bereits mitteilte, kannst du weiteres dazu hier finden:

https://iotig.eichelsdoerfer.net/index.php/loes…r-shelly-script