Beiträge von eiche

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 von mastro736

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 von Hangkuro

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 von Brendianer

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 von hjbucher

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.

AlexSchmitz

Es wird gerne zwischen "feste" und "statische" IP Adresse unterschieden.

Eine feste IP Adresse ist eine, welche der DHCP Server (bspw. eine FRITZ!Box) an Hand der MAC Adresse des Client diesem Client immer wieder zuweist. Diese liegt somit im DHCP IP Adressbereich des Servers.

Eine statische IP Adresse hat nichts mit DHCP zu tun und darf, wie Captain_Byte andeutete, nicht im IP Adressbereich des DHCP Servers liegen. Bei Verwendung einer statischen IP Adresse, was ich bevorzuge, musst du somit den Adressbereich des DHCP Servers kennen, um sicher keine IP Adresse aus diesem Bereich zu vergeben.

Zitat von seseis

Leider gibt's derzeit nur den frame für 3 Einsätze.

Vielleicht für alte Shelly i3 (Name?) ...

https://www.shelly.com/de/products/sh…-switch-4-white

Solche habe ich mit Shelly i4 im Einsatz. Leider ist der Abdeckrahmen etwas zu groß, was bei Einzeldosen kein Problem darstellt.

Dieser URL ist rückwärtskompatibel zu Shelly Geräten der ersten Generation.

Versuche es auch mal mit dem originären URL für einen Plus Plug S (zweite Generation) - am besten per Web Browser Adresszeile, um die Reaktion des Plus Plug S zu testen!

http://<IP Adresse des Plus Plug S>/rpc/switch.set?id=0&on=true

Zum Ausschalten am Ende ...&on=false.

Wenn der Plus Plug S sich wie gewünscht verhält, kannst du diesen URL im Button 1 eintragen und entsprechend testen. Danach sollte feststehen, welches der beiden Geräte ggf. nicht funktioniert.

Zum Dimmer siehe die Dokumentation.

Edit: API Dokumentation zum schalten von Shelly Geräten ab Generation 2. Hier spielt die Component Switch die entscheidende Rolle.

Zunächst ein paar Hinweise und eine Frage zu deinem Skript/Anliegen.

1. Ich sehe keinen triftigen Grund, die Berechnungsfunktion (calculateDewPoint) lokal in loop zu definieren. Man kann so etwas tun, es macht den Code aber unübersichtlicher.
2. Solange ich kein Skriptproblem wegen Abbruchs vorfinde, lasse ich Ausnahmebehandlungen (try, catch) weg. Das ist zwar Ermessenssache, nach meiner Kenntnis aus C++ brauchen Ausnahmebehandlungen aber Ressourcen, weshalb ich solches nicht ohne Not einsetze, zumal dein Skript recht kurz ist.
3. Für eine explizite, zyklische Abfrage der Messwerte sehe ich keinen Grund. Hier täte ich einen EventHandler einsetzen, welcher sofort auf das von der Firmware gelieferte Event reagiert.
4. Konstanten sollten nur dort definiert werden, wo sie gebraucht werden. Dies kann durchaus global sein, in deinem Skript werden a und b nur in der Berechnungsfunktion gebraucht und sollten dort lokal definiert werden. Du kannst diese auch global definieren, dann aber mit aussagekräftigen Namen statt a und b.
5. Auf Grund welchen Ereignisses soll der Shelly einschalten und wie soll dieses Einschalten erfolgen - manuell oder automatisiert? Im zweiten Fall wären zwei Referenzwerte für eine Hysterese zielführend.

Wie eine Nachricht (an die Shelly App) gesendet werden kann, weiß ich nicht. Aber die Stelle, an welcher dies erfolgen kann, steht fest. Ich täte dazu MQTT einsetzen, andere vermutlich ein übergeordnetes System. Wie der Ausgang eines Shelly ab zweiter Generation geschaltet werden kann, ist in der API Dokumentation zu finden.

Auf der Grundlage deines Skripts gelänge dies wie folgt.

let RefDewPoint = ...; // Hier setzt du den von dir gewünschten Wert ein!

// Das MQTT Topic ist ausschließlich für das Senden einer MQTT Nachricht erforderlich.
// Ich setzte hier in der Shelly Konfiguration den Eintrag eines öffentlichen MQTT Brokers voraus, wie test.mosquitto.org.
// Dafür ist das Topic insbesondere bei Verwendung des öffentlichen Brokers geeignet anzupassen.
let MqttTopic = "crypticPreTopic/deviceDewPoint/belowReference"; 

function calculateDewPoint(t, rh) {
	let a = 17.27;  // Konstante für die Magnus-Formel
	let b = 237.7;  // Temperaturkonstante in der Magnus-Formel
    // Berechnung des Sättigungsdampfdrucks
    let gamma = (a * t) / (b + t) + Math.log(rh / 100.0);
    // Berechnung des Taupunkts basierend auf dem Sättigungsdampfdruck
    let dp = (b * gamma) / (a - gamma);
    return dp;
}

function Loop(){
  try{

	let temp= Shelly.getComponentStatus('Temperature', 100).tC;
	let humidity= Shelly.getComponentStatus('Humidity', 100).rh;

	let dewPoint = calculateDewPoint(temp, humidity);

	print("Temperatur: ", temp, "°C");
	print("Luftfeuchtigkeit: ", humidity, "%");
	print("Taupunkt: ", dewPoint.toFixed(2), "°C");
	
	//Verarbeiten des berechneten Taupunktes	
	if(dewPoint < RefDewPoint) {
		// Nachricht senden, was ich hier ausschließlich per MQTT andeute.
		MQTT.publish(MqttTopic, true);	
		//Ausschalten des Shelly-Ausgangs.
		Shelly.call("switch.set", {id:0, on:false});
	}
	// Bei Berücksichtigung einer Hysterese ist ein weiterer Vergleich mit einem zweiten Referenzwert
	// ähnlich wie oben ggf. mit automatisiertem Einschalten zielführend.
	// else if(dewPoint > ... ) {
	// 		// Anweisungen
	// }
  }catch(e){print(e);}
}

Timer.set(2000,true,Loop);

Ich habe dein Skript weitgehend so belassen. Den Einsatz eines EventHandlers magst du selbst prüfen. Bei Bedarf kann ich eine solche Alternative gerne ergänzen. Informationen dazu in der API-Dokumentation.

Frage: Wie hast du denn ein solches Skript per trial and error zustande gebracht - ohne Programmierkenntnisse? Solches erscheint mir recht abenteuerlich.

Zitat von nurmaso

Ich suche aber nach einer Möglichkeit, dass man nicht zyklisch überwachen muss, sondern der i4 das sofort mitkriegt, wenn eine Lampe eingeschaltet wird.

Ich habe nur eine Shelly Duo zum testen und tat dies für ein Forumsmitglied auch bereits.

Dazu kannst du in der Shelly Leuchte eine Action anlegen, welche bspw. auf das Einschalten reagiert. Im Skript des i4 verwendest du im einfachsten Fall eine Funktion oder etwas besser einen HTTPServer Endpoint. Die Action auf der Leuchte lautet bspw. so.

http://172.16.8.1/rpc/script.eval?id=1&code="sync()"
allg.
http://<IP Adresse des Zielgerätes (i4)>/rpc/script.eval?id=<Skript Id>&code="sync()"

Im Skript muss die Funktion, welche auf die Action reagieren soll, in diesem Beispiel sync() lauten und das abarbeiten, was du erreichen willst.

Auf diese Weise meldet die Leuchte das Einschalten oder das, was sie melden soll, bspw. auch das Ausschalten. Ohne die Leuchte per polling abzufragen, da die Leuchte selbst das Ereignis der Änderung mitteilt. Das Abfragen der Leuchtenzustandsparameter musst du selbstverständlich in sync() noch selbst coden, bspw. so wie der Link von ThomasHRO zeigt. Allerdings täte ich darin ein Array aus IP-Adressen verwenden und zum synchronisieren eine Schleife abarbeiten lassen.

Edit:
Nicht alle Änderungen einer Shelly Leuchte können in einer Action verwendet werden.
Wäre eine solche Leuchte mit einem ESP32 ausgestattet, wäre sie vermutlich skriptfähig. Dann könnte jegliche Änderung per Skript mitgeteilt werden.

Das ist hier relativ ausführlich beschrieben:

https://github.com/mongoose-os-libs/cron

Zitat

• @sunset-1h30m 1 * * : Run 1.5 hours before the sunset every 1th day of month;

Für deinen Zweck lautet der timespec Wert also:

@sunset-2h * * *

Dies lässt sich auch per Web UI einstellen, solange man keine spezifischen Methoden wie "Script.Eval" einsetzen will.