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.

    Das Skript läuft ausschließlich auf dem regelnden Shelly, was für die Autarkie auch erforderlich ist. Mit einer Cloud oder App hat dies nichts zu tun.

    Die vom Skript gelieferte Webseite wird von einem Web Browser dargestellt.

    Edit:
    Und sollte das WLAN ausfallen, erreicht man den Shelly und die Webseite über dessen AP Adresse 192.168.33.1, nachdem man das Endgerät (Smartphone, Tablet, ...) mit diesem AP verbunden hat.

    Edit 2:
    Neben dem C&P ist noch das einmalige Anlegen von bspw. 8 Schedule Jobs erforderlich, was mit einer meiner unterstützenden Webseiten relativ leicht möglich ist, allerdings nicht DAU sicher.

    oder gib ordentlich Geld aus und schreibe Scripte.

    Das ist nicht ganz stimmig. Ein Stellantrieb kostet ca. 15 €, eine Shelly Plus 1 liegt geschätzt bei 20 € (lange keinen mehr gekauft). Diese Kombination ist somit recht preisgünstig. Das Schreiben bzw. verstehen eines Skriptes ist wohl am aufwändigsten. Meines könntest du kostenfrei von mir erhalten. Ob dir die per Skript gelieferte Weboberfläche gefallen täte, ist eine offene Frage. Ich möchte sie tatsächlich noch verbessern, weiß aber nicht, wann ich genügend Antrieb dazu haben werde.

    Gruß Gerhard

    Afaik werden die TRV nicht mehr produziert.

    Ich bin auch nicht sehr zufrieden damit und habe einen Ersatz dafür mit einem Shelly Plus 1 und einem umfangreicheren Skript erstellt. Hierzu ist ein vom Shelly geschalteter Antrieb für das Stellventil (Stift) erforderlich. Diese Zusammenstellung arbeitet bei mir an einem Heizkörper sehr zuverlässig und insbesondere autark. Eine Spannungsversorgung ist dafür vor Ort notwendig. Ich habe bis zu 8 aktive Zeitpläne vorgesehen, deren Anzahl auf bis zu 16 erweitert werden könnte. Profile dazu habe ich nicht erstellt.

    Meine TRV werde ich sukzessive und nach Bedarf durch diese Kombination ersetzen. Mit den FRITZ! Thermostaten von avm habe ich keine Erfahrung.

    Flutschi und HighFive

    Ich kann nicht erkennen, wo der Beitrag #4 auch nur annähernd etwas konstruktives aufweist.

    Das ist wohl logisch.

    Das ist alles andere als "logisch" sondern ein Fakt, welcher aus zwar naheliegenden Gründen des Aufwandes aber nicht notwendigerweise so ist. Die Scheduler (Cron) Implementation wurde im Laufe von etlichen Jahren fortlaufend verbessert und wir können diese dankenswerterweise nutzen. Es ist aber durchaus möglich, auch nach einem Stromausfall eine zeitgesteuerte Aktion nachträglich noch ausführen zu lassen, bspw. per Skript oder einer sonstigen Implementation.

    Wo hast du jetzt etwas von Skripte geschrieben?

    Ich ging auf die Frage des TE ein und habe sie andeutungsweise beantwortet. Es liegt am TE, bei Bedarf genauer nachzufragen.

    leerraum

    Ich wollte dir eine PN zukommen lassen. Gelingt leider nicht mit dieser Fehlermeldung:

    Zitat

    Sie haben das zulässige Limit für Konversationen bereits erreicht und können keine neuen Konversationen starten.

    Wir sind derzeit zu dritt. ... ;)

    Eine reine Uhrzeit gesteuerte Funktion lässt sich zunächst mit Zeitplänen, sog. Schedule Jobs, realisieren. Diese können inzwischen per Web UI weitgehend flexibel angelegt und geändert werden.

    Der einzige Nachteil solcher Jobs liegt darin, dass sie ausschließlich zu den konfigurierten Zeiten triggern - also nicht nachträglich, falls zum Triggerzeitpunkt keine Stromversorgung vorliegt. Ich bin ein Fan solcher Schedule Jobs, weil der Scheduler bereits im Betriebssystem (Firmware) arbeitet.

    Ein solcher Job kann jegliche verfügbare Methode nutzen, also nicht etwa nur etwas ein- oder ausschalten. Allerdings unterstützt das Web UI nicht das Eintragen/Editieren beliebiger Methoden. Hierfür ist ein HTTP Request geeignet, welcher per Web Browser abgeschickt werden kann (Adresszeile). Dies ist alles in der API Dokumentation verteilt beschrieben.

    Ich habe u.a. eine Webseite erstellt, welche das Anlegen und Ändern von Schedule Jobs unterstützt, welche die Methode "Script.Eval" nutzen. Damit kann eine Skript interne Funktion aufgerufen werden, welche das Gewünschte sehr flexibel implementieren kann. Hiermit fügt sich die Flexibilität von Schedule Jobs und Skripten auf ideale Weise zusammen.

    Ein solcher Schedule Job kann auch mehrere Methoden triggern. Dann ist der Eintrag aber sehr komplex und man muss sich sehr genau mit der Syntax solcher Einträge beschäftigen.

    Die Verwendung solcher Jobs und/oder Skripten bietet den Vorteil der autarken Funktion eines Shelly, welche zumeist auch dann wirkt, wenn temporär kein WLAN verfügbar ist. Zu den Einschränkungen von Schedule Jobs bei fehlendem WLAN teile ich erst bei Interesse mehr mit, weil dies mehrere Aspekte umfasst.

    Ergänzung zu Skriptlösung mit Plus 2PM je Jalousie und einem i4 an Tastern

    • Je Plus 2PM ein Skript
    • i4 kann ggf. ohne Skript genutzt werden

    Skript mit EventHandler "evh()" und mindestens zwei Prozessfunktionen "close()", "light()" - Namen beispielhaft.

    close() schließt die Jalousie und stellt eine Variable "todo" auf eine leere Funktion "none()". light() schließt die Jalousie und stellt "todo" auf eine Funktion "aslant()".

    evh() reagiert auf den Status closed, indem die Funktion hinter "todo" aufgerufen wird. "aslant()" fährt die Jalousie kurz auf, damit die Lamellen quer gestellt werden und stellt "todo" auf "none()".

    Der i4 erhält Actions, deren URL die Methode "Script.Eval" nutzen und darüber eine der Funktionen "close()" oder "light()" aufgerufen wird.

    Code
    http://<IP Adresse des Plus 2PM>/rpc/script.eval?id=<Skript Id>&code="close()" bzw. "light()"

    Dies erlaubt den kürzest möglichen Prozess zum abschließenden querstellen der Lamellen, da das Skript praktisch unmittelbar auf das Ereignis "Jalousie geschlossen" reagiert. Das Skript ist relativ einfach und lässt weitere gewünschte Optionen zu.

    Genau diese maximale Zeit soll nicht ablaufen, das hat er so ja schon per Szene gelöst.

    Die maximale Dauer ist nur die Wartezeit, nach welcher kurz geöffnet wird und nicht etwa die Fahrdauer der Jalousie, deren Zielposition ja im URL festgelegt werden kann.

    Alternativ könnte der "Fahrzustand" der Jalousie im Sekundenabstand abgefragt werden, bis diese steht. Danach dann das kurze Öffnen der Lamellen.

    Entweder müsste ein Script auf jedem Rollladenaktor laufen ...

    Das dürfte nicht erforderlich sein, weil das i4 Skript dies kann.

    Edit:

    Gegen eine zusätzliche Unterstützung von lokal auf den Schalt-Shelly laufenden Skripten ist selbstverständlich nichts einzuwenden. Hierfür täte sich die Methode "Script.Eval" anbieten.

    Prinzip einer Skriptlösung auf einem Shelly i4

    Zunächst die maximale Dauer Tmax zum Fahren der Jalousie messen.

    1. EventHandler reagiert auf gewünschten Tastendruck, Reaktion s.u.
    2. Jalousie auf die gewünschte Position fahren lassen.
      Timer starten mit Tmax (oder geringfügig länger).
    3. Wenn Timer abgelaufen ist (callback Funktion) die geeignete Dauer (bspw. 2000 ms) lang öffnen lassen.
    4. Fahren lassen und kurz öffnen lassen per URL füt alle gewünschten Jalousien im selben Skript/EventHandler.

    Das sollte zum Ziel führen. Ggf. zu jeder Jalousie die zielführenden Zeiten separat im Skript verwenden.

    GuenterP

    Vielleicht gelingt dein Vorhaben mit Actions, auch Webhooks genannt.

    Mit einen Skript wird es in jedem Fall gelingen.

    Du wirst dafür zwei Temperatursensoren brauchen. Ändert sich ein Messwert, erzeugt die Firmware ein Ereignis und liefert dieses an registrierte EventHandler (eine Skriptfunktion). Dort können die Messwerte auf die Weise verarbeitet werden, wie du das haben willst. Das ist für den Anfang schon alles - relativ leicht zu implementieren.

    Etwas aufwändiger wird es dann, wenn Zeitpläne zum Zuge kommen sollen.

    Mir ist noch nicht klar, womit der Temperaturfühler gespeist wird - vermutlich von L1, also demselben Außenleiter wie die Shelly Versorgung.

    Dann wirkt nach Rappteller der Fühler als Freigabe für die beiden manuellen Schalter. So sehe ich kein Problem mit der Schaltung nach #14.
    Ich täte zwar die Anschlüsse an I und O vertauschen, bei potentialfreiem Schalten ist dies aber unerheblich.

    Funktioniert das auch ohne Cloud?

    Skripte werden immer ausschließlich lokal auf dem Shelly abgearbeitet, auf welchen sie angelegt (und gestartet) sind. Das hat weder mit übergeordneten Systemen noch mit Cloud zu tun. Deshalb kann mit Skripten ein Shelly weitestgehend autark arbeiten. "Weitestgehend" deshalb, weil bspw. die Firmware für die Nutzung von üblichen Zeitplänen die interne Uhrfunktion (keine Uhr, die ohne Spannungsversorgung weiterlaufen kann) nach einem Reboot (Stromausfall) mit einem Zeitserver synchronisieren muss.

    Da dein Anliegen (vermutlich) ohne einen Zeitplan auskommt, täte der Shelly mit Skript komplett autark, also auch ohne Internetzugang, arbeiten.

    Ich habe noch nicht komplett erfasst, was deine Ziele sind. Aber auf diese Fragen kann ich zumindest eingehen.

    Allerdings gelingt dies nur, wenn dein "Shelly 1" keiner der ersten Generation ist. Dies hast du nicht sorgfältig geklärt. Da du aber ein Skript verwendest, muss dieser Shelly zumindest der Generation 2 angehören ...

    Nur weiß ich nicht, wie ich abfragen kann, ob der Shelly 4 Taster oder die Cloud ausschaltung bedient wird. Falls es mit Cloud überhaupt geht.

    Der Shelly i4 kann per Action (oder per Skript) dem Shelly Plus 1 etwas per Methode "Script.Eval" oder per HTTPServer Endpoint (im Skript des Plus 1) mitteilen. Die Methode "Script.Eval" ist leichter in seiner Verwendung.

    Hierfür sendet der i4 an den Plus 1 eine Nachricht per folgendem URL.

    Code
    http://<IP Adresse des Plus 1>/rpc/script.eval?id=<Skript Id auf dem Plus 1>&code="<Funktionsname(optionale Parameter)>"

    Vielleicht ist diese Nachricht nicht ganz syntaxgerecht, dazu müsste ich ein wenig experimentieren - siehe API Dokumentation.

    In deinem Skript kannst du die Quelle des Schaltens per Event Handler herausfinden. Im event Parameter steckt auch die Information über die auslösende Quelle - per Cloud steht in der src Komponente der Wert "SHC".

    Mit welcher Spannung betreibst du den Shelly?

    Falls du diesen mit 230V AC betreibst, sollte 15V praktisch nichts bewirken. Über solche Werte wissen andere hier mehr. Da aber die Strommessung ausschließlich über eine Spannungsmessung erfolgt, ist hierfür im Stromkreis eine Messspannung erforderlich. Wie hoch diese sein kann, entzieht sich derzeit meiner Kenntnis.

    Ich weiß nicht, ob dein Anliegen per Actions gelingen kann - vielleicht ist dies möglich.

    Per Skript gelingt so etwas auf jeden Fall. Dies ist ein Grund, weshalb ich nicht versuche, die letzten Möglichkeiten von Actions auszureizen. Eine Implementation per Szenen (Cloud) kann ich eh nicht empfehlen, weil dann die Funktion Cloud abhängig ist und zudem wegen der Datenübertragung auch mehr Energie verbraucht.

    1. Eingang auf detached stellen. Damit werden Signaländerungen am Eingang erfasst, es erfolgt aber keine Reaktion am Ausgang. Diese Kopplung soll das Skript übernehmen.
    2. Das Skript braucht einen Event Handler, an welchen die Firmware das Ereignis "Eingangssignal geändert" o.ä. übermittelt.
    3. Das Skript nutzt eine boolesche Variable "Enable", um festzustellen, ob geschaltet werden darf oder nicht.
    4. Wenn Enable = true, schaltet der Event Handler den Ausgang, setzt Enable auf false und startet einen Timer, an dessen Ende Enable auf true gesetzt wird.
      Die Dauer des Timers legt fest, wie lang die Latenzzeit sein soll.

    Das ist nicht schwierig zu implementieren, braucht aber ein wenig Programmierkenntnisse, etwas Experimentierfreudigkeit und insbesondere das Studieren der Shelly API.

    Der Vorteil eines Skriptes gegenüber Actions ist, dass via Skript viel mehr Anwendungsorientierung implementierbar ist. Actions bieten nur einen eng begrenzten Rahmen von Anwendungen "von der Stange".

    Edit:

    Es dürfte auch möglich sein, hierfür HomeAssistant zu nutzen. Ich verwende kein fertiges übergeordnetes System, stattdessen Node-RED und, wie du an anderer Stelle schriebst, ebenfalls Influx und Grafana (neben Mosquitto). Der Shelly könnte vielleicht per Action HomeAssistant die Änderung am Eingang übermitteln, woraufhin HomeAssistant passend reagieren sollte.

    Dies hat allerdings den kleinen Nachteil, dass die gewünschte Funktion ausfällt, falls die Kommunikation zwischen deinem NUC und dem Shelly mal nicht gelingen sollte. Eine autarke Lösung auf dem Shelly ist in jedem Fall am sichersten.

    Brendianer

    Für Shelly Skripte stehen folgende hier zielführende Dinge zur Verfügung. Siehe hierzu die API Dokumentation.

    1. Timer verarbeiten Zeiten in Millisekunden. Damit lässt sich fast jegliche Dauer eines Impulses implementieren.
      1. Einschalten.
      2. Timer starten.
      3. Nach Timer Ende ausschalten.
    2. MQTT Subscriber bei Verwendung von MQTT. Damit lässt sich sowohl das Schalten als auch das Dimmen steuern.
    3. HTTPServer Endpoint zur Kommunikation per HTTP. Anwendung siehe 2.
    4. Variablen zur Speicherung der letzten Dimmtendenz (heller/dunkler). Damit lässt sich gezielt hoch- oder runterdimmen. War bspw. das letzte Dimmen hoch und es soll weiter hoch gedimmt werden, müssen zwei hinreichend lange Impulse ausgegeben werden, s. 1.

    Vermutlich täte ich ein Skript mit der gewünschten Funktionalität hinkriegen, wenn ich solches Equipment nutzen/besäßen täte. Da ich solches nicht habe, kann ich die Funktionalität nicht testen. Deshalb habe ich in den obigen Punkten die einsetzbaren Dinge aufgezeigt.

    Die Handhabung gelänge bspw. per HTTP (s. 3.). Der Anwender müsste ggf. dem Skript gelegentlich (vielleicht nur ein einziges Mal) mitteilen, wie beim letzten Mal per Skript gedimmt wurde, damit das Skript "weiß", welche Impulse es beim nächsten Mal ausgeben muss. Wesentlich hierfür ist zu wissen, wie sich die Lampe nach einem Stromausfall bzgl. des Dimmens verhält.

    Falls zusätzlich ein Taster verwendet werden soll, sollte dieser mit einem Eingang des eingesetzten Shelly verbunden werden. Somit kann per Skript die Tastdauer gemessen und geeignete Schlüsse daraus gezogen werden.