Beiträge von eiche

dasMexxchen

Und lasse gelegentlich von dir lesen, wie du (einen Teil) deines Vorhabens realisiert hast!

Kurzer Einwand an borsti0 :

Der vom TE genutzte Sensor SMT 50 liefert ausschließlich zwei analoge Spannungen und bietet keine zusätzliche Mikrocontroller-Funktionalität. Er kann also nicht kommunizieren, was einen zusätzlichen Mikrocontroller erforderlich macht. Hierfür kann, selbstverständlich nicht muss, ein Shelly eingesetzt werden. Erst dann kann - nicht muss - ein übergeordnetes System genutzt werden.

borsti0

Nein, das habe ich nicht. Wie schnell die Flash Zellen davon "abgenutzt" werden, weiß ich nicht, vermute aber, dass deutlich früher die übernächste Shelly Generation auf dem Markt wäre. Schließlich hängen die Anzahl der Schreibvorgänge insbesondere von der Abtastrate ab - und die legt der Anwender fest.

Btw, ich lasse seit über einem oder zwei (?) Jahren einen Shelly via Skript als Hauptuhr laufen, wobei jeder Tagesminutenstand persistent gespeichert wird. Wie dabei die Speicherplätze im Hintergrund ggf. rotiert werden, entzieht sich meiner Kenntnis. Afaik hat Espressif so etwas aber vorgesehen. Bevor hierzu ein Feldversuch tragfähige Erkenntnisse liefern täte, wäre die Hardware bereits veraltet. Man könnte allerdings die Alterung der Hardware mit sehr hoher Abtastrate beschleunigen. Als nichtkommerzieller Privat-"Entwickler" habe ich daran kein Interesse.

Eine Empfehlung zum Shelly Plus Uni wollte - ich habe ich ? - nicht abgeben. Es gibt aber afaik noch keinen Nachfolger dafür. Und ich kenne für diesen Einsatzzweck keinen besser geeigneten Shelly. Ein Shelly 2PM mit AddOn ist mangels Potentialfreiheit nicht einsetzbar.

Beim Einsatz von potentialfrei schaltendem Shelly 1 kann dieser nur mit zusätzlichem (analogen) RC-Tiefpass/Integrierglied die zwei erforderlichen Aufgaben erfüllen - zu großer Aufwand. Ein SMT 50 liefert zwei analoge Signale, eines zur Bodenfeuchtigkeit und eines zur Bodentemperatur. Mit meinem Vorschlag ließen sich bis zu 4 SMT 50 nutzen, wobei alle analogen Signale erfasst werden können. Dagegen wäre der Einsatz von Shelly 1 mit AddOn sehr unwirtschaftlich.

Steppi Software-Ergänzung zu den Hardware-Informationen

Wie willst du die Messdaten aufzeichnen (speichern)?
Man kann dafür ein Shelly Skriptslot verwenden, d.h. man speichert Messdaten in einem nicht ausführbaren Skript. Dieses lässt sich bei Bedarf lesen, kopieren ... und selbstverständlich löschen. Auch eine Übertragung via MQTT bei kurzem, vorhandenen Internetzugang ist möglich.

Zu etwas ähnlichem habe ich für einen Freund ein Skript erstellt, welches du angepasst nutzen kannst. Es ist hier zu finden:

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

dasMexxchen

Du kannst auch einen Shelly Plus Uni dafür nutzen. Der hat bereits einen analogen Eingang, muss aber mit Niedrigspannung betrieben werden. Ich habe für mehrere analoge Messwerte, ein SMT 50 liefert bereits 2 Werte, einen Schaltungsentwurf mit Analogdemultiplexer erstellt. In meinem Fall noch in Kombination mit einer Hauptuhrfunktion.

Ich will dieses Projekt ohne Hauptuhrfunktion gelegentlich realisieren. Vielleicht ist dieser Entwurf für dich interessant. Damit könntest du leicht mehrere SMT 50 nutzen. Dazu ist allerdings ein Shelly Skript erforderlich.

Hier auf die Schnelle der wesentliche Teil der Schaltung - nur fast komplett.

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Ein Takt von Out 1 kommend lässt den Selektionszähler inkrementieren. Dessen Ausgänge selektieren das anliegende analoge Signal. Zugleich wird der Zähltakt Count In zugeführt, damit jederzeit die ausgewählte Analogspannung, also die Messquelle, bekannt ist. Via Out 2 (im obigen Entwurf noch nicht dafür genutzt) wird der Selektionszähler rückgesetzt, der Count In Zähler zugleich im Skript auch. Entscheidend für eine solche relativ einfache Nutzung sind zwei Ausgänge und ein Zähleingang am einzusetzenden Shelly.

Die Kosten sind gering. Ohne Löten geht es aber nicht.

Robert400

Ich habe ein wenig experimentiert.

Am weitreichendsten und flexibelsten sind die langen URL von horkatz mit allen möglichen Angaben zu Farben und Helligkeit.

Wenn nur zwischen LED aus und LED an gewechselt werden soll, bieten sich in den beiden Actions auch folgende URLs an.

Mit dem Ausschalten des nicht sichtbaren Shelly:

http://<IP Adresse>/rpc/PLUGS_UI.SetConfig?config={"leds":{"colors":{"switch:0":{"on":{"brightness":0},"off":{"brightness":0}}}}}

Mit dem Einschalten des nicht sichtbaren Shelly:

http://<IP Adresse>/rpc/PLUGS_UI.SetConfig?config={"leds":{"colors":{"switch:0":{"on":{"brightness":30},"off":{"brightness":30}}}}}

Dies bewirkt, dass der via LED anzeigende Shelly zwischen aus ("brigthness":0) und ein ("brightness":30) wechselt. Die "brightness" Werte werden relativ zischen 0% und 100% interpretiert.

Nun kann man sehr leicht auf dem anzeigenden Shelly die gewünschte LED Farbe einstellen und bei Bedarf ändern, ohne die Actions anpassen zu müssen.

Ob die kurzen URL besser oder schlechter sind, hängt von der gewünschten Handhabung ab.

Bei einer manuellen LED Konfiguration auf dem Zielgerät kann diese Funktion ungewollt deaktiviert sowie die Leuchtstärke verändert werden. Da kann aber auch zum Vorteil genutzt werden, wenn man auf einfache Weise diese Anzeigefunktion deaktivieren oder die Leuchtstärke verändern will.

Robert400

Nimm bitte dafür einen Web Browser und nutze das Web UI des Pumpen Shelly! Schaue dort unter Actions nach und erstelle einen Screenshot, welchen du dann bitte hier postest!

Wenn du einen "richtigen Computer" hast, und nicht nur ein Smartphone, nimm diesen dafür!

Zitat von Robert400

Was mich wundert, beim Anlegen der Aktion bekomme ich eine Fehlermeldung.

So, ich habe dein Szenario mal nachgebildet - so weit ich kann. Dazu verwende ich zwei Shelly Plus Plug S, also Generation 2 - ohne BLU Gateway Funktion. Du wirst zumindest für den Gateway Shelly Generation 3 nutzen, da du keine Shelly Skript Erfahrung hast. Das sind die einzigen Unterschiede zwischen deinem Szenario und meiner Nachbildung.

Ich kann eine Fehlermeldung, wie du sie andeutest, nicht reproduzieren. Ich sehe auch keinerlei Grund/Ursache dafür, wenn die URL syntaxgerecht zusammengestellt sind. Auch verstehe ich nicht, wo darin Leerzeichen sein sollen. Bei mir vollzieht sich auch keinerlei Zeichenersetzung. Wenn überhaupt, dann müssten Leerzeichen durch %20 und nicht etwa durch %22 ersetzt werden.

Mich interessiert der genaue Wortlaut der Fehlermeldung.

Edit: Ich nutze für solche Dinge allerdings nicht die App, wozu auch? Das Web UI ist immer der funktionssicherere Zugriff.

Robert400

Es gibt noch eine interessante Idee. Du kannst den Gateway Shelly (A genannt) via dritter Farbe signalisieren lassen, wenn der Pumpen Shelly (B genannt) nicht erreichbar ist. Das gelingt entweder mit einem Skript oder via MQTT LWT (Last Will and Testament), wofür du einen öffentlichen MQTT Broker nutzen kannst, solange du selbst keinen solchen betreibst. So kannst du an dieser dritten Farbe erkennen, dass die Kommunikation B -> A gerade nicht funktionieren dürfte.

In jedem Fall wird das nur mit Skript gelingen.

Btw, die dritte Signalfarbe basiert auf einer Anregung von der KI. Ich werde sie testen, ob sie lernfähig bzgl. meiner Lösungsidee ist.

Puh, es gibt in JSON doch immer mal wieder Stolperfallen. Folgende URL genügen, nachdem Die LED Konfiguration auf "switch state" und die gewünschte "brightness" eingestellt sind. Dann genügen in beiden Aktionen folgende URL.

Für Rot:

http://<IP-Adresse>/rpc/PLUGS_UI.SetConfig?config={"leds":{"colors":{"switch:0":{"on":{"rgb":[100,000,000]},"off":{"rgb":[100,000,000]}}}}}

Für Grün:

http://<IP-Adresse>/rpc/PLUGS_UI.SetConfig?config={"leds":{"colors":{"switch:0":{"on":{"rgb":[000,100,000]},"off":{"rgb":[000,100,000]}}}}}

Und für jede andere Farbe entsprechend.

Je kürzer die URL, desto weniger fehleranfällig. "brightness" lässt sich bspw. im Web UI manuell fest einstellen, was hier genügen dürfte.

Robert400

Soeben mit einem Plus Plug S und Web Browser getestet. Das Umschalten der LED Farbe gelingt mit sofortiger Wirkung. Somit ist dein Anliegen doch realisierbar. Glückwunsch

Ein weiteres Experiment zeigte, dass die Komponente "power" weggelassen werden kann. Folgendes funktioniert bereits:

http://<IP-Adresse-Gateway>/rpc/PLUGS_UI.SetConfig?config={"leds":{"mode":"switch","colors":{"switch:0":{"on":{"rgb":[000,100,000],"brightness":100},"off":{"rgb":[000,100,000],"brightness":100}}}}}

Versuche mit noch weniger Angaben verliefen bisher ohne Erfolg, obwohl hier die API Dokumentation etwas geringfügig anderes aussagt.

Korrektur meinerseits: Es gelingt doch nach API Dokumentation folgendermaßen.

http://<IP-Adresse-Gateway>/rpc/PLUGS_UI.SetConfig?config={"leds":{"colors":{"switch:0":{"on":{"rgb":[000,100,000],"brightness":100},"off":{"rgb":[000,100,000],"brightness":100}}}}}

Man kann also "power" und "mode" weglassen, alles andere ist erforderlich.

Robert400 (und andere?)
Noch einmal nachgedacht mit folgendem Resultat.

A = Gateway Shelly, B = Pumpen Shelly

Zunächst sollte es ohne Skript gelingen.

Beide Schaltzustände von A erwirken immer dieselbe LED Farbe. Die (Um)Konfiguration auf A, welche von B gesendet wird, orientiert sich immer nur am Schaltzustand von B.

Ist dies die Lösung von horkatz ? Eher nicht, weil seine LED Konfiguration verschiedene Farben vorsieht. Farben sind selbstverständlich austauschbar.

Immer dann, wenn B auf On wechselt, wird A auf rot leuchten konfiguriert.

http://<IP-Adresse von A>/rpc/PLUGS_UI.SetConfig?config={"leds":{"mode":"switch","colors":{"switch:0":{"on":{"rgb":[100,000,000],"brightness":100},"off":{"rgb":[100,000,100],"brightness":100}},"power":{"brightness":100}}}}

Vermutlich kann man "power" weglassen.

Immer dann, wenn B auf Off wechselt, wird A auf grün leuchten konfiguriert.

http://<IP-Adresse von A>/rpc/PLUGS_UI.SetConfig?config={"leds":{"mode":"switch","colors":{"switch:0":{"on":{"rgb":[000,100,000],"brightness":100},"off":{"rgb":[000,100,000],"brightness":100}},"power":{"brightness":100}}}}

Das sollte im Regelfall bereits ohne Skript funktionieren.

Achte darauf, dass hinter "on" die gleiche Farbe genutzt wird wie hinter "off"!

Kleines Problem beim Power On Reset bzw. Hochfahren von B: Hier muss der Zustand von B abgefragt werden und auf Grund dessen eine passende Konfiguriernachricht an A gesendet werden. Damit alles auch nach Stromausfall oder A (temporär) nicht erreichbar zuverlässig läuft, muss B immer wieder nach A "schauen", bspw. getriggert via Schedule Job oder via Skript Timer. Das dazu erforderliche Skript muss in regelmäßigen Abständen (bspw. 1 Minute) A konfigurieren. Das ist etwas ungünstig, weil die Konfiguration im non volatile storage (NVS) abgelegt werden muss. Hier ist empfehlenswert eine neue A-Erreichbarkeit oder ein B-Umschalten als Trigger zu nutzen. Dies erfordert jedenfalls ein Skript.

Und nein, dazu ist kein übergeordnetes System (bspw. HomeAssistant) erforderlich, was gut ist, weil dies auch funktioniert, wenn ausschließlich A und B laufen - ohne zusätzlichen Overhead bzw. Ballast.

Ich habe noch eine leicht "wahnsinnige Idee" zur Lösung. Diese ist relativ aufwändig und müsste erprobt werden.

A sei der Gateway Shelly.
B sei der Pumpenschalt Shelly.
Das Szenario ist abstrahierbar.

Voraussetzung: A und B schalten ihre Ausgänge völlig unabhängig voneinander.

Lösungsidee: Skript erforderlich!

1. Aktion auf A teilt B via Methode Script.Eval jede Zustandsänderung seines Ausgangs mit.
   Anmerkung: Sehr kurzzeitig wird sich die LED an A ändern.
2. B fragt seinen Ausgangszustand ab und sendet via Skript und RPC die passende Konfiguration an A.
3. Aktion auf B ruft via Methode Script.Eval eine (andere) Skriptfunktion auf, die entweder
   1. den Zustand von A abfragt oder
   2. den Zustand von A gespeichert vorfindet und
      entsprechend Punkt 2 (oben) die Konfiguration via RPC anpasst.

Ein Beispiel soll die Lösungsidee etwas verständlicher machen.

Die LED von A (kurz LED) möge bei eigenem On grün und bei eigenem Off rot leuchten.

1. LED ist grün, weil A On ist und B Off (wichtig!).
2. B wird getoggelt, also On. => Skript ermittelt Zustand von A (=On) und konfiguriert A so um, dass dessen LED bei On rot leuchtet.
3. A schaltet auf Off => Mitteilung an B. B fragt seinen Zustand (=On) ab und konfiguriert A so um, dass dessen LED bei Off rot leuchtet.

Entsprechend läuft es ab, wenn B Off geschaltet wird, nur mit jeweils grün leuchtender LED auf A.

Das sollte funktionieren. Ich täte dazu aber nur dann ein Skript schreiben, wenn ich hoch dafür entlohnt würde. Ich habe genügend andere Punkte auf meiner to do Liste.

Robert400
Falls irgendwann seitens des Firmware Entwicklers/Pflegers das API so erweitert wird, dass die LED eines Plug S via RPC schaltbar ist, unabhängig vom seinem eigenen Schaltzustand, dann wird dein Wunsch erfüllbar sein.

Btw und off topic: Ich fragte den KI Bot nur, weil ich selbst keine Lösung fand. Demzufolge hat er mein Resultat bestätigt.

Ich bin so frei, diese Funktion als derzeit (Firmware abhängig) nicht implementierbar zu halten.
Grund: Mit einer (Um-)Konfiguration eines remote Plus Plug S ändert sich die Anzeige des remote Shelly immer ausschließlich abhängig von dessen Schaltzustand.

Habe ich etwas übersehen?

horkatz Mich würde deine konkrete Realisierung interessieren.

Zitat von horkatz

Einen ähnlichen Aufbau habe ich gestern Nachmittag bei mir zu Hause getestet, funktionierte einwandfrei. Den "Pumpenshelly" habe ich über die App und über einen HTTP-Request eingeschaltet, der Farbring des "Gateway" - Plug folgte dann dem Schaltzustand des PumpenPlug.

horkatz Wie lautet deine Aktion auf dem nachgebildeten Pumpen Shelly? Mit Umkonfiguration kann es afaik nicht gelingen.

Nachgereicht: Hast du den Schaltzustand des Gateway Shelly dem des Pumpen Shelly folgen lassen?

Du könntest die folgende Lösung nutzen - kleiner Scherz, aber technisch möglich.

Der Pumpen Shelly wird passend konfiguriert und via Kamera beobachtet.

Ernsthaftere Lösungen:

1. Nutzung eines Dashboards, auf dem der Schaltstatus des Pumpen Shelly angezeigt wird.
2. Du ersetzt den Gateway Shelly durch einen solchen mit zwei Schaltausgängen. Der zweite (ansonsten nicht genutzte) Ausgang schaltet ein Signal (bspw. eine LED), welches den Schaltzustand des Pumpen Shelly anzeigt. Solches ist leicht via Aktion auf dem Pumpen Shelly und RPC implementierbar.