Beiträge von eiche

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.

Bei genügend Muße werde ich ein solches Skript mal zusammenstellen.

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.

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.

Zitat

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.

Zitat

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 T_max 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 T_max (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.

Also eher Alpha als Beta ...

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.

Zitat

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

Zitat

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.

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.

Zitat

Dann könnte "unser" 3326.12 als Taster agieren?

Falls der 3326.12 einen Impuls abgibt, könnte ein dazwischen geschalteter Shelly diesen weitergeben und den Impuls auswerten.

Ich kenne aber das durchgereichte Signal nicht. Von diesem wird es abhängen, ob der eingeschleifte Shelly funktionsgerecht nutzbar ist.

Zur App kann ich wenig sagen, weil ich das Ding schlicht extrem selten nutze.

Per Browser kann man aber leicht (Adresszeile/URL) verschiedene Kommandos an das Skript senden.

Ein Taster ist soweit ich es verstand doch bereits vorhanden, oder nicht? Mit einem solchen am Shelly lässt sich dessen ursprüngliche Nutzung weiterverwenden.

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.

Ich gelangte irgendwie hierher und möchte zu Michaels ( ostfriese) Skript etwas ergänzen, was auch bspw. das Anliegen von mhritter betrifft.

1. Die Abarbeitung von Einträgen in Datenfeldern kann durchaus über deren Stellen (Indexe) in den unterschiedlichen Datenfeldern erfolgen. Dies ist allerdings strukturell fehlerträchtig. Eine mittelflexible Lösung kann imho besser über eine (zunächst funktionslose) Datenstruktur erfolgen, siehe 2.
2. Eine geeignete Datenstruktur kann hierarchisch wie folgt aufgebaut werden.
   let device = [
   {"ipaddr":<IP Adresse>, "name":<user name>, "online":false, "online_action":[<list of URLs>], "offline_action":[<list of URLs>]},
   {"ipaddr":<IP Adresse>, "name":<user name>, "online":false, "online_action":[<list of URLs>], "offline_action":[<list of URLs>]},
   // ...
   ];
   Eine solche Struktur ermöglicht, jeder IP Adresse eine Liste an URLs im Online- bzw. im Offline-Fall zuzuordnen, bspw. auch die von mhritter gewünschten Aktivierungen/Deaktivierungen von Schedule Jobs. Auch kann jede dieser Listen leer sein. Eine geeignete Wiederholungsstruktur (Schleife) kann leicht die jeweilige Liste abarbeiten. Der Zusammenhalt aller Dinge in einem solchen Eintrag des Datenfeldes "device" ist bereits verankert, wozu es keinen korrespondierenden Index braucht. Der Zugriff gelingt über einen laufenden Index und den selektierenden primären Schlüssel <IP Adresse>.
3. Statt der Listen für Online- und Offline-Aktionen können zwei Funktionen eingebaut werden, was noch etwas mehr Flexibilität ermöglicht.
   let device = [
   {"ipaddr":<IP Adresse>, "name":<user name>, "online":false, "online_action":function (index){}, "offline_action":function (index){}},
   {"ipaddr":<IP Adresse>, "name":<user name>, "online":false, "online_action":function (index){}, "offline_action":function (index){}},
   // ...
   ];
   In dieser Lösung ist per Initialisierung den Funktionen für "online_action" und für "offline_action" die jeweils gewünschte (benannte) Funktion zuzuordnen. Dies unterstützt die Nutzung einzelner Funktionen für mehrere Geräte.

Mit einer Lösung gemäß 2 oder 3 gelänge es relativ leicht, das Anliegen von mhritter zu implementieren.

Solches ist einer der Gründe, weshalb ich einer Datenstruktur zu Beginn zumeist die höhere Priorität zuordne als der Ablaufstruktur, welche sich dann an der Datenstruktur orientieren muss.

Vielleicht helfen diese Anmerkungen für weitere Anliegen ähnlicher Art.

Ich sah mir soeben dein letztes Skript etwas genauer an. Ich schätze das Skript trotz seiner Kürze als relativ unübersichtlich ein, was eine Pflege erschweren wird.

Die derzeit gewollte Funktionalität des Skripts ist trotzdem vermutlich vorhanden.

Zitat

192.168.33.11

192.168.33.1

Dieser Zugriff funktioniert ausschließlich dann, wenn dein Endgerät (Smartphone, Tablet, Notebook, ...) mit dem aktiven Accesspoint des Shelly verbunden ist. Afaik ist erst ab Geräten der zweiten Generation zeitgleich eine WLAN-Einbindung und aktivem Accesspoint möglich. Das Web UI muss genauso über lokales WLAN wie über den Shelly Accesspoint erreichbar sein.

Dies kann aus naheliegenden Gründen nicht zugleich, also über das lokale WLAN und über den Shelly AP, gelingen.

Edit: Mit zwei Endgeräten sollte der zeitgleiche Zugriff über das WLAN und den Shelly AP bei Geräten ab zweiter Generation gelingen. Dann muss ein Endgerät mit dem WLAN und das andere mit dem Shelly AP gekoppelt sein.

Das könnte etwas für eine "smart home Tafel" sein - in Anlehnung an die übliche Tafel für Lebensmittel.

Für die Teilhabe an unterstützender Elektronik in verschiedenen Lebenslagen.