Beiträge von eiche

Kannst du mal genau angeben, wo der entsprechende Passus in der von dir angegebenen Quelle zu finden ist oder diesen hier zitieren.

Ich fand nichts dergleichen, habe auch nach "target temperture" gesucht, ohne Erfolg.

Die Schwelle der Temperaturänderung, ab welcher der H&T seinen neuen Messwert mitteilt, ist keine Zieltemperatur.

Per zweier Actions, auf dem H&T eingetragen, kann dieser aber Aktionen auf einem anderen Shelly per URL auslösen, bspw. ein- oder ausschalten des Ausgangs im empfangenden Shelly. Dazu braucht es tatsächlich kein Skript. Eine geeignete Action zum einschalten des Ausgangs eines Shelly Plus 1 wäre bspw.

http://<IP Zieladresse>/rpc/switch.set?id=0&on=true

Die Bedingung dieser Action wäre die Unterschreitung eines Temperaturwertes. Dazu kannst du auch das aktive Zeitintervall einstellen.

Somit ist es relativ leicht möglich, über einen Tag verteilt, unterschiedliche Temperaturschwellen fest einzustellen, welche solche Actions auslösen. Dieses Einstellen ist etwas aufwändig und nicht wirklich dazu geeignet, mal schnell eine Zieltemperatur zu ändern. Solches gelänge erst mit Hilfe eines Zusatztools, welches auch aus einer Webseite bestehen kann, die geeignet strukturiert ist und die passenden Links mit den URL zum Umkonfigurieren bereit hält. Eine Alternative wäre ein übergeordnetes System, welches solche Umkonfigurierungen bereit stellt. Ich täte dafür ein Node-RED Dashboard oder eine MQTT App einsetzen.

Ich setze nun voraus, dass es keine Zieltemperatur auf dem H&T gibt. Dann gelingt etwas ähnliches nur über zwei Schwelltemperaturen mit Hysterese, deren Unter- bzw. Überschreitungen Actions auslösen. Das wäre eine Nachbildung einer Zieltemperatur für eine Zweipunktregelung.

Der H&T kann aber auch in Actions seine Temperatur-Messwerte per ${ev.tC} übertragen, eingebettet in den URL. Damit kann ein Skript auf dem empfangenden Shelly die Temperaturregelung übernehmen, weil es die Messwerte vom H&T empfängt. Dies gelingt ohne übergeordnetes System. Die Änderung der gewünschten Zieltemperatur ist dann dem Skript mitzuteilen. Dies gelingt auf unterschiedlichen Wegen, abhängig von deiner smart home Umgebung. Notfalls kann dazu das KVS genutzt werden, wo solche Daten per Web UI des regelnden Shelly eingetragen werden können. Auch können relativ viele Schedule Jobs auf dem regelnden Shelly dafür genutzt werden, solche Zieltemperaturen in Zeitintervallen dem Skript mitzuteilen, auch Wochentags abhängig und mehr.

Du erkennst hoffentlich, dass die Shelly sehr unterschiedliche Möglichkeiten bieten, die vielleicht nicht leicht zu erfassen, aber je nach smart home Umgebung sehr flexibel nutzbar sind.

Sobald ich deine genaue smart home Umgebung kenne, kann ich dir ggf. auf diese Umgebung zugeschnittene Empfehlungen geben. Entscheidend ist weniger die Regelung selbst, diese ist per Skript möglich, sondern die einfache Handhabung von Zieltemperaturänderungen. Dies gelänge bspw. per MQTT und einer App relativ leicht. Ich nutze dafür die Android App MQTT Dash sehr gerne, die aber nicht auf iOS verfügbar ist. Da ich kein iPhone nutze, kenne ich keine dafür geeignete App. Die Alternative wäre bspw. ein vom Skript bereitgestellte interaktive, per Browser nutzbare Webseite, über welche die Zieltemperatur und ggf. anderes ad hoc auf dem regelnden Shelly einstellbar wäre. Dies zu programmieren erfordert aber einigen Aufwand. Ich habe etwas ähnliches für eine Heizkreisregelung per Shelly Plus 1 mit Plus AddOn erstellt. Dies ist aber noch nicht komfortabel genug. ostfriese erstellt etwas ähnliches für ein Forumsmitglied. Wenn ich dazu den Link finde, reiche ich ihn nach. Bestechend daran ist, dass dies alles ohne zusätzliche Ausstattung ginge, nur WLAN ist erforderlich.

Zitat von steffda

Aufgrund des Sleep-Mode könnte es auch sein, dass der Shelly H&T sich während einer Wachphase die Paramter selber aktiv holen muß

Ich wüsste nicht, wie der H&T dies bewerkstelligen könnte, da auf diesem kein Skript nutzbar ist.

Zitat von Klaatu

Ich habe echt NULL-Ahnung wie es funktionieren soll, den 2PM ohne die "Shelly Smart Control"-App (Version 3.71.36) einzurichten

Zuerst verbindest du dein Handhabungsgerät (Notebook, Tablet, Smartphone) mit dem Access Point des Shelly.

Dann ganz schlicht per Web Browser und http://192.168.33.1'.

Nach der Einbindung in dein LAN geht es am besten weiter per Browser mit http://<IP Adresse des Shelly im WLAN>.

Ist das nirgendwo auf dem Beipackzettel notiert?

Edit: Dieses bevormundende automatische Einstellen als Link ist grässlich. Sorry, ich konnte den ersten URL nicht "delinken".

Zitat von thgoebel

Wählt man Rm mit 10kΩ, so kann Vref als Spannung genutzt werden.

Auch wenn ein 10kΩ Widerstand ein "Klacks" ist, vielleicht ginge sogar der DMS an Vref + interner Widerstand.

Per Skript geht dann so gut wie alles.

Zitat von eiche

Hast du mal daran gedacht, den Scanner "Script.Eval" Methoden nutzen zu lassen? Damit ließen sich statt verschiedener Events auszulösen verschiedene Skript-Funktionen aufrufen.

Damit täte ein anderer Shelly sofort Parameter verarbeiten, ohne das KVS abzufragen. Das KVS liegt im nichtflüchtigen Speicher, der weniger Schreibzugriffe aushält als ein flüchtiger Speicher (RAM), Ob das bedeutungsvoll ist, hängt von der Anwendung ab. Per "Script.Eval" wäre die Reaktionszeit kürzer.

Sorry, there was a mistake in my variant 2 above which now I have corrected.

Unfortunately I don't have any Shelly Pro 3, but Shelly pro 2 and of corse Shelly Plus 1 ... So I can't test such a script. But it will works.

My first variant above just shows the principle.

But the incoming event has an input state which is a boolean value (true or false). Therefore my variant 2 works if you store the state of input:0 to variable in1, of input:1 to variable in2, of input:2 to variable in3.

Ok, I understood, you need a complete script. Maybe I'll program a little script for you today or tomorrow ...

Alles klar.

In meinem WoMo täte ich gerne gelegentlich die Heizung digital regeln. Vermutlich wäre hierfür der Ruuvi auch geeignet, zusammen mit einem Shelly Plus Uni. Ich weiß derzeit aber nicht, wie ich den Uni in die vorliegende analoge Heizungsregelung (Truma Combi 6) integrieren könnte. Das sollte ich gelegentlich in einem anderen Thread mal thematisieren.

Im WoMo könnte der Plus Uni mit Sensor(en) per 12V betrieben werden, ohne den Ruuvi. Nur zur Temperaturregelung sollte ein angeschlossener DS18B20 genügen, mit vielleicht etwas längerer Zuleitung.

Gibt es zu meinen Gedanken Einwände oder Ergänzungen?

Zitat von PS5500

kann man einen Unterputz Buschjäger Taster mit 240V (Phase und Null) ohne einen Draht zur Lampe bzw zum Relais in der Unterverteilung als Aktor 1 mittels Shelly 1 nutzen und via Szene den Aktor 2 zum schalten der Lampe konfigurieren

1. Die naheliegendste Lösung ist als Shelly am Taster einen ohne Relais zu nehmen, da dieser ja nichts schalten kann, wegen fehlender Leitung zur Lampe. Dann ist das aber kein Aktor sondern ein (intelligenter) Sensor.
2. Oder du kannst, vielleicht in einer Abzweigdose oder einer Leerdose daneben, einen Shelly mit Relais als Aktor zwischen Taster und Lampe so platzieren, dass die Leitung vom Taster zum Eingang des Shelly führt und dessen Ausgang zur Lampe.

Zu 1.
Dazu ist ein Shelly i4 prädestiniert, allerdings bei nur einem Taster auch etwas überdimensioniert mit seinen 4 Eingängen. Jedenfalls muss dann der Sensor Shelly an den Aktor eine Nachricht senden, wenn der Anwender auf den Taster drückt, was sehr leicht per Action möglich ist, wie kingof7eleven bereits mitteilte. Der Sensor kann auch long push oder double push unterschiedlichen Actions zuordnen. Szenen sind wegen Cloud Abhängigkeit nicht empfehlenswert. Ein i4 ist dann besonders interessant, wenn dieser mit 4fach Tastern betrieben wird. Dann kannst du jedem Taster eine andere Funktion zuordnen, bspw. andere Verbraucher schalten oder Rollladen hoch- runterfahren. Diese Konstellation mit zwei oder mehr Shelly braucht aber ein funktionierendes WLAN, was bei 2. nicht erforderlich ist.

Insbesondere zum dimmen wären mindestens zwei Taster zielführend, einer für heller, der andere für dunkler - vielleicht ein dritter zum ein-/ausschalten, was aber bspw. auch per long push auf einen von zwei oder beiden Tastern gelänge. Prinzipiell gelingt so etwas auch mit einem einzigen Taster, wenn alle Nutzer bereit sind, sich an push, long push und double push zu gewöhnen.

Zitat von Programmieraffe

Das belastet nicht (!) deinen potentialfreien Schaltkontakt, weil damit nicht die Ladungspumpe angetrieben wird sondern nur ein Relais im 1 PM betätigt wird.

Stimmt so nicht ganz.

Über die Stromstärke (nicht Stromhöhe ) eines Shelly Plus 1PM Eingangs weiß bspw. thgoebel sehr genau bescheid. Dieser über den Eingang fließende Strom ist aber relativ schwach und wenn potentialfrei geschaltet wird, sollte das keine Rolle spielen. Somit ist der erste Teil weitgehend ok.

Der zweite Teil ist aber falsch. Der Strom eines Shelly Eingangs treibt kein Ausgangsrelais an. Das Relais wird von einem Ausgang des Mikrocontrollers, ggf. über einen externen Schalttransistor betrieben.

In jedem Fall ist zu erwarten, dass die ausschließliche Verwendung eines Shelly Plus 1 keinerlei Probleme darstellt. Ein RC Snubber ist aber evtl. empfehlenswert. Dieser kann an den geschalteten Verbraucher oder zwischen die Ausgangsklemmen des Shelly geschaltet werden und dämpft Störimpulse durch Ausschalten von induktiven Verbrauchern.

Bevor die "Richtigen" sich mitteilen, schon mal eine Vorab-Information von mir.

Es handelt sich offensichtlich um einen Dehnungsmessstreifen, was ein resistiver Sensor ist. Die weiteren Beschaltungserfordernisse hängen von dessen Wert und Empfindlichkeit ab.

Du kannst dazu erst einmal den Widerstandswert ohne und mit anwendungsnaher Verformung messen. Dann lässt sich zumindest abschätzen, ob er ohne oder mit zusätzlichen Bauteilen wie Widerstande und Verstärker an einem AddOn nutzbar ist - vermutlich nur mit Verstärker ...

Zusätzlich ist es nützlich zu erfahren, welches AddOn du nutzen willst, ein AddOn der ersten Generation oder ein Plus AddOn (zweite Gen.).

This may be implemented by an event handler in a script at device y. This handler receives any change of an input, store the status (off vs. on) in a variable and checks the three values like this:

if(in1===off && in2===off && in3===off) Shelly.call("HTTP.Get", {url:"http://<IP address of device x>/rpc/Switch.Set?id=0&on=false"});

respectively

if(!in1 && !in2 && !in3) Shellly.call("HTTP.Get", {url:"http://<IP address of device x>/rpc/Switch.Set?id=0&on=false"});
In the second variant the values of in1, in2, in3 must be of type boolean.

Zitat von steffda

Dafür will ich nicht unbedingt am H&T rumorgenln, sondern auf den Shelly Plus 1 gehen, der an der Gastherme hängt und das dort ändern. Beim nächsten Wachzyklus des H&T kriegt der dann diese neuen Werte mitgeteilt.

Genau so kann es gelingen. Dann braucht der Plus 1 die Solltemperatur, die er mit der vom H&T gelieferten vergleicht und auf Grund des Resultats, einer Differenz zwischen Soll- und Ist-Temperatur (vom H&T) die Therme steuert. Wenn du das ohne übergeordnetes System realisieren willst - ohne Cloud am besten sowieso , dann bleibt nur ein Skript auf dem Plus 1. Dabei kann dir geholfen werden. Das Skript kann die Ist-Temperatur vom H&T auf mindestens drei verschiedenen Wegen empfangen.

1. Per MQTT, wozu ein Server, der MQTT Broker, erforderlich ist.
2. Per RPC Methode "Script.Eval" zum Aufruf einer Skript-Funktion mit der Temperatur als Parameter.
3. Per HTTP Endpoint, wobei der H&T einen von dir/uns teilweise festgelegten URL nutzt.

Bei 2. und 3. kommuniziert der H&T unmittelbar mit dem Plus 1 über das WLAN, ohne Zwischenstation. Hierfür ist erforderlich, dass im H&T eine Action (=Webhook) erstellt werden kann, was ich stark vermute, aber aus verschiedenen Gründen derzeit nicht testen kann. Ich kann 3. empfehlen, weil dies am robustesten ist. 2. ist etwas leichter zu implementieren. Da hierfür eh ein Skript erforderlich ist, kann zwar ein gewünschtes MQTT Topic bzw. ein gewünschter URL vereinbart werden, die eigentliche Steuerung bzw., an Hand der Soll-Temperatur, Regelung muss aber eh das Skript übernehmen, wobei eine simple Zweipunktregelung genügen sollte. Dies ist sehr leicht implementierbar.

Zwei Schaltschwellen dTu, dTo mit Hysterese
dT = Temperaturdifferenz Istwert - Sollwert
dT < dTu => einschalten
dt > dTo => ausschalten

Da jedes Relais "klackt", kann dir nur eine Halbleiterlösung (SSR oder Opto-TRIAC) weiterhelfen und ein Shelly ohne Relaisausgang wie der Plus Uni. Zur Anpassung der Schaltspannung deiner (Reflektions-)Lichtschranke an die digitalen Eingänge eines Plus Uni können andere mehr sagen. Die beiden Ausgänge des Uni müssen die SSR der so steuern.

Zitat von steffda

Ich würde den H&T gerne so einrichten, dass er in einer Wachphase die aktuellen Werte, falls sie die ensprechenden Abweichungen haben, an eine anderen Shelly schickt und mit neuen Parametern versorgt wird.

Dazu sind die RPC Methoden geeignet. Diese können bspw. per HTTP oder per MQTT genutzt werden. Deren Syntax ist zwar für alle Shelly Generation 2+ sehr ähnlich, aber nicht für alle Typen genau gleich. Insbesondere, wenn ein Ziel-Shelly Skripte nutzen kann, gibt es sehr anwendungsorientierte URL. Sobald klar ist, welcher Shelly Typ die Messwerte mitgeteilt bekommen soll, könnte ich etwas konkretere Auskunft geben.

Nachfrage:

Afaik ist ein H&T (ich besitze nur Gen 1 und Gen 2) ausschließlich für Messungen geeignet. Was kann denn ein H&T Gen 3 mit einer "Solltemperatur" anfangen?

Andere Dinge sind Gegenstand der Konfiguration. Hierfür täte ich mit den RPC Methoden "Sys.GetConfig" und "Sys.SetConfig" experimentieren.

'http://<IP Adresse des H&T>/rpc/sys.getconfig' liefert dir alle Konfigurationsparameter. Viele, wenn nicht alle, von diesen lassen sich per "Sys.SetConfig" ändern. Dazu sind Kenntnisse der Syntax, inbesondere der Parameterstruktur erforderlich. Dies ist in der Shelly API Dokumentation relativ gut beschrieben.

In jedem Fall kann es nicht schaden, während solcher Versuche den H&T über USB zu versorgen.

Edit:
Die Web Browser Edge und Firefox stellen die Antworten des Shelly (im JSON Format) übersichtlich dar, vermutlich noch andere Browser, aber nicht alle.

Klaatu

Ich nutze die Shelly smart control App sehr selten und schon gar nicht zum Einrichten eines Shelly. Die Web UI sind recht verlässlich dafür. Alle meine Plus 2PM laufen ohne Probleme, sowohl mit optionaler Cloud als auch ohne. Auf Grund solcher Erfahrungen empfehle ich dir, zunächst die Cloud auszusperren und den Plus 2PM zu testen, ggf. neu einzurichten - ohne App.

Alternativ kannst du einfach mal einen Tag lang warten. Vielleicht hat die Cloud dann deinen Shelly aufgenommen. Aber wozu willst du die Cloud verwenden? Um die Leinwand per Sprachassistent zu fahren? Dazu nutze auch ich die Cloud, aber ausschließlich optional. (siehe auch meine Signatur)

Roman B.

Wenn du eine echte Regelung möchtest, wie du es andeutetest, dann bietet sich entweder eine Phasenanschnittsteuerung oder eine Schwingungspaketsteuerung an.

Hierzu sollten andere mit mehr Equipment-Erfahrungen auf den Plan treten. Zusammen mit einem Skript ist so etwas implementierbar.

Best regards to seillehs and Gspjb . Both initiated the LWT topic.

Ich greife den Thread in der neuen Umgebung noch einmal auf, weil ich inzwischen weitere Tests durchgeführt und insbesondere zum Thema "Last Will and Testament" (LWT) recherchiert habe.

Die kurze Diskussion mit AlexAn hat mich zusätzlich dazu angeregt, weiter zu recherchieren und zu verifizieren.

Zunächst dazu zwei Links zur Shelly API Dokumentation:

1. https://shelly-api-docs.shelly.cloud/gen2/Component…cting-over-mqtt
2. https://shelly-api-docs.shelly.cloud/gen2/General/RPCChannels/#mqtt

Meinen Artikel hierzu habe ich überarbeitet.

Auch bei HiveMQ lässt sich dazu einiges finden. Nicht zuletzt kann man auch die man page zu mosquitto_pub heranziehen.

Aus allen diesen Quellen ist zusammengefasst folgendes zu folgern, zumindest mit einer bis an Sicherheit grenzender Wahrscheinlichkeit.

1. Nach dem Booten stellt der Shelly eine Verbindung zu seinem MQTT Broker her.
   Mit der Herstellung der Verbindung wird die Shelly eigene LWT Nachricht an den Broker übermittelt. Ein solches LWT besitzt keinerlei Standard, jeder MQTT Client kann ein eigenes LWT festlegen. Der Broker speichert das LWT unter der Client ID - hier der des Shelly. Das LWT besteht aus einem Topic und einer Payload. Diese sind bei den Shelly Topic:"<MQTT Prefix>/online", Payload:"false".
2. Zusätzlich kann der Client den Wert eines "keep alive" Zeitintervalls festlegen, default 60s, innerhalb dessen der Client ein PING request an den Broker senden muss, um als nicht vermisst zu gelten, welches der Broker mit einem PING response beantwortet. Nach Ablauf des "keep alive" Intervalls ohne den Erhalt des PING request sendet der Broker das LWT (Topic, Payload s.u. 1.) an alle dieses Topic abonnierenden Subscriber. Das tut der Broker immer dann, wenn sich ein das LWT Topic, hier also "<MQTT Prefix>/online", abonnierender Subscriber bei ihm meldet.
3. Zusätzlich veröffentlicht der Shelly eine reguläre retained Nachricht mit dem LWT Topic und der Payload "true". Diese Nachricht ist kein LWT, sie besitzt nur dasselbe Topic wie das LWT. Damit erhalten alle entsprechenden Subscriber die Nachricht, dass der Shelly online ist, genauer: dass er mit dem Broker verbunden ist.
4. Meldet sich der Shelly, aus welchen Gründen auch immer, vom Broker ab, sendet der Shelly zuvor eine reguläre retained Nachricht mit dem LWT Topic und der Payload "false". Das ist daran zu erkennen, dass einem Subscriber diese Nachricht sofort übermittelt wird und nicht erst nach Ablauf des "keep alive" Intervalls. In diesem Fall greift der LWT Mechanismus nicht, weil sich der Client regulär vom Broker abmeldet. Hier ist der Client selbst für eine solche Nachricht verantwortlich.

Somit kann ein Subscriber eines LWT Topic sehr zeitnah den aktuellen Online Zustand eines MQTT Client erhalten. Damit kann eine hohe Verlässlichkeit in der MQTT Kommunikation implementiert werden, in einem übergeordneten System wie auch in einem Shelly Skript. Da die Shelly Firmware das LWT selbst verwaltet, ist es sinnfrei, solches per Skript zu implementieren. Stattdessen kann man selbstverständlich jede andere MQTT Nachricht über den Zustand der per Skript implementierten Anwendung, vom Skript ausgehend, senden lassen.

Klar doch, du musst sie eine Stunde lang in eine Schublade legen.

Ich habe derzeit keinen einsatzfähiges BLU Ding, weshalb ich nichts dergleichen testen kann.

Als ich mir die Skriptvorlage ansah, fand ich aber sehr viel Code, der ausschließlich für DAUs erforderlich ist. Deshalb sollte man das Skript erheblich verschlanken können.

Zitat von akreienbring

Ich hab dann den BLE Scanner ausgelagert. Dieser löst nun Events aus, die die entsprechenden Datenpaket der Devices enthalten.

Du meinst vermutlich Events, welche lokal auf demselben Gateway Shelly verarbeitet werden.

Zitat von akreienbring

Macht die Sache zwar schlanker, allerdings sind aber auch nur 3 aktive Scripte pro Gateway erlaubt.

Ein EventHandler kann leicht verschiedene Events unterscheiden. Dazu braucht es nicht mehrere Skripte.

Hast du mal daran gedacht, den Scanner "Script.Eval" Methoden nutzen zu lassen? Damit ließen sich statt verschiedener Events auszulösen verschiedene Skript-Funktionen aufrufen. Ich kann nicht einschätzen, ob dies Vorteile bringen kann.

Die Sache mit dem KVS habe ich noch nicht verstanden. Willst du damit KVS-Einträge auf anderen Shelly immer dann schreiben/ändern, wenn von einem BLU Ding eine Bluetooth Nachricht eintrifft? Dann müsste dem anderen Shelly dies ja zusätzlich irgendwie mitgeteilt werden. Und mit einer solchen Mitteilung ließen sich ja Parameter senden, deren Werte mit der Nachricht eines BLU Dings korrespondieren.

Btw, Es ist nicht abwegig, von einem "BLU Ding" zu sprechen. Schließlich gibt es auch den Begriff des Internet of Things (IoT).