Beiträge von eiche

Zitat von Robert400

Pumpenplug geht auf 'Strom fliest' (und sendet via aktion 'Einschalten' an den Gatway: mach Lichtlranz an.
Eingestellte Zeit läuft ab, Pumpenplug senden Lichtkanz aus an Gateway

Genau das funktioniert nicht.

Ich habe eine passende Frage an MS Copilot gerichtet.
(Diesen KI Bot nutze ich für meine Fragen zu Raspberry Pi, Docker, Compose ... seit kurzen relativ erfolgreich.)

Er schlug mir die bereits genutzte Konfiguration vor. Nach meiner Klärung das tatsächlichen Vorhabens teilte er folgendes mit.

"Es gibt keinen RPC‑Call wie PLUGS_UI.SetState oder LED.Set, der die LED unabhängig vom Gerätezustand toggelt.

• Die LED ist beim Plus Plug S ausschließlich an die UI‑Konfiguration gekoppelt.
• Shelly hat keine API vorgesehen, um die LED als „Remote‑Indikator“ zu nutzen."

Vielleicht finde ich trotzdem noch etwas passendes, die Chancen sind aber sehr gering.

Fazit: Das, was du willst, ist vermutlich nicht implementierbar.

Ich habe soeben mal die Vorlage von horkatz zum testen verwendet, da dein Posting unvollständige URL zeigt.
Das funktioniert auf meinem Test Plus Plug S.

Du brauchst aber seitens des Pumpenschalt Shelly eine Aktion mit RPC, der die LED auf dem Gateway Shelly schaltet. Ich schaue mal nach, ob es dazu etwas gibt ...

Edit:
Wenn ich damit richtig liege, waren deine Beobachtungsergebnisse wohl zufälliger Art, da du immer nur den Schaltzustand des Gateway sahst, was ja seitens Shelly so vorgesehen ist.

Meine Stellungnahme noch ohne eigene Tests.
Die IP-Adresse 192.168.178.137 ist die des Gateway, der (nebenbei) auch schaltet. Sollte dies anders sein, bitte ich um Korrektur!

Somit können diese Umkonfigurationen via Aktionen auf dem Pumpenschalt Shelly nicht erfolgreich, im Sinne deines Wunsches, sein.
Damit zeigt der Gateway Shelly ausschließlich seinen Schhaltzustand an.

Gibt es einen Zusammenhang zwischen den Schaltvorgängen auf beiden beteiligten Shelly?

Robert400
Hast du auch mal ein Testszenario gewählt?
Konkret: Den Pumpenschalt-Shelly in eine deutlich bessere WLAN Erreichbarkeit platzieren - selbstverständlich dann ohne die Pumpe zu schalten.
Dann die Funktionsweise wiederholend testen.

Entschuldige bitte meine Nachfrage: Poste für mich deine in beiden Shelly konfigurierten Aktionen!

Szenen interessieren mich in diesem Kontext nicht und ich halte den Hinweis, es ginge mit Szenen, für dilettantisch. Die Shelly bringen für dein Anliegend hinreichend lokal arbeitende Schnittstellen mit.

Robert400
Teile uns bitte mal die IP-Adressen deiner beiden Plug mit!

Lacoste

Verstanden habe ich dein Anliegen noch nicht.

Das Thema und #1 sagt, dass du zu festgelegten Uhrzeiten die Wirkungen der Schalter zur Rollladensteuerung sperren bzw. freigeben willst.

Was hat dies mit den Bewegungsmeldern und Licht schalten zu tun?

Zitat von Reference-Pessimism

//http timeout, magic number, not yet documented

https://shelly-api-docs.shelly.cloud/gen2/Component…es/HTTP#httpget

Your script is mysterious.

Zitat von Reference-Pessimism

print to the console the number of reboots

Reboots? Of which device? Where does the information about the number of reboots come from?

What is hidden behind the IP address of CONFIG.endpoint?

Mit BMW meinst du vermutlich Bewegungsmelder (BWM)?

Mit Home Assistant kenne ich mich nicht aus.

Ich weiß nicht sicher, wie ein Bewegungsmelder deaktivierbar ist. Außerdem hängt solches eindeutig von deiner Beschaltung ab. Welche BWM setzt du ein? Wie sind diese beschaltet, wenn überhaupt?

Hier sind deutlich weitreichendere Informationen erforderlich.

Man kann bspw. an einem Generation 2+ Eingänge aktivieren/deaktivieren.

Zitat von Mika-Wood

Es ist jetzt eine Action definiert mit http://127.0.0.1/relay/0?turn=toggle funktioniert

Ok, allerdings ist dieser URL Code sehr alt, noch rückwärtskompatibel zu Generation 1. Wer weiß, wie lange diese Kompatibilität unterstützt wird. Ab Generation 2 ist folgender URL Code implementiert.

http://127.0.0.1/rpc/switch.toggle?id=0

Da diese Aktion lokal ausgeführt werden soll, ist keine http Kommunikation erforderlich. Hier ist eine lokale Aktion leicht konfigurierbar - unter "Add action to execute".

Dies soll dich beim aktualisieren unterstützen, mehr nicht.

Zum Thema noch eine kleine Anmerkung.

Zitat

Wie (Un)brauchbar ist der Plus UNI zur Spannungsmessung, oder allgemein?!

Allgemein erlebe ich bereits seit geschätzt mindestens 2 Jahren nach wie vor verlässlich laufende Plus Uni, allerdings messen meine Plus Uni keine analoge Spannung. Einer dient dem experimentieren, der andere steuert via längerem Skript eine Nebenuhr, nach wie vor sehr verlässlich.

Ich täte auch nicht auf Grund der Erfahrung mit EINEM Gerät, insbesondere dieser Preisklasse, daraus schließen, dass eine Fehlkonstruktion vorläge. Die finanzielle Investition in ein weiteres solches Teil wäre für mich peanuts, da ich damit die Chance erhielte, eigenständig zu weiteren Erkenntnissen zu gelangen, auch an Hand von Tests in anderen Umgebungen. Ok, ein ausschließlicher Anwender mag dies anders handhaben ...

Hast du auch mal einen anderen Plus Uni eingesetzt, um zu sehen, wie dieser sich verhält. Vielleicht hat deiner einen Schaden - soll ja vorkommen.

Ich halte deine dbzgl. Hinweise/Kommentare für fehl am Platze. Ich verstehe nicht, was du da zu bemängeln hast.

1. n ist hier nicht statisch/konstant, da n konfigurierbar ist.
2. Woher weißt du, was ein Interpreter aus einem solchen Ausdruck macht? Es erscheint kaum vorteilhaft, mit 1/n zu multiplizieren.
3. Die Vorteile des gleitenden Mittelwertes gegenüber der Speicherung und anschließender Berechnung habe ich dargelegt. Offenbar ignorierst du diese Vorteile und suchst nach in diesem Projekt irrelevanten Dingen (Krümeln).
4. Der Aufwand zur Ermittlung eines lokalen Eingangszustandes ist im Vergleich zur Mittelwertberechnung geradezu gigantisch. Und dies erst recht, wenn dazu die RPC Methode HTTP.Get verwendet wird, dessen relativ umfangreiche HTML Antwort im body enthalten ist und die deutlich mehr Speicher beansprucht als ein dafür geeigneter Aufruf von Shelly.call(...). Letzterer braucht weniger Overhead und liefert eine kürzere Antwort im JSON Format.

Zitat von JuergenAC

und das Ergebnis steht auch in JavaScript nach der Berechnung direkt zur Verfügung

Wenn du das Skript hinreichend analysiert hättest, hättest du erkennen müssen, dass darin die Berechnung des Mittelwerts nicht unmittelbar nach Eintreffen des Eingangszustandes (alle 10s) sondern erst nach bspw. 5 Minuten durchgeführt wird. Die Eingangszustände werden erst gespeichert, was zusätzlich Zeit kostet, und später verarbeitet. Somit steht dieser Mittelwert im Skript nie direkt nach der Abfrage des Eingangszustandes zur Verfügung.

JuergenAC

Ich beziehe mich ausschließlich auf den gleitenden Mittelwert, dessen Berechnung normalerweise mit jeweils einer Multiplikation, einer Addition und einer Division erfolgt. In diesem konkreten Fall ist dieser Schritt sogar nur bedingt auszuführen. Mit dem gleitenden Mittelwert liegt jederzeit der aktuelle Mittelwert vor, welcher bereits bei Überschreitung einer gewünschten Schwelle unmittelbar, und nicht erst nach Ablauf des Zeitintervalls (oben 5 Minuten), ausgewertet werden kann, nicht muss. Das kann im Zweifelsfall zum Vorteil genutzt werden.

Das Abfangen eines Fehlers dürfte im obigen Projekt keine Rolle spielen, weil ausschließlich der Eingangszustand (etwas umständlich und aufwändiger als nötig) abgefragt wird. Dein Einwand ist hier grundlos, weil keine Temperaturen oder sonstige analoge Werte erfasst werden.

Off topic: Das Abfangen von Messfehlern ist nicht ganz trivial. Hierzu kann man mehrere Messwerte sortiert speichern und ausgehend vom medianen Mittelwert Ausreißer weitgehend erkennen sowie eliminieren. Wenn ein Wert außerhalb des Messbereichs liegt, ist er trivial erkennbar und nicht zu berücksichtigen. Wie bereits festgestellt, spielt so etwas hier keine Rolle.

WebUI:

Bei Gen 2 Shelly kommt man zu dieser Konfiguration über Home -> Input -> Input settings -> Input/Output settings. Vermutlich ist das bei Gen 3 Geräten zumindest ähnlich.

Mit welchem Shelly willst du solches erreichen? Mit solchen der ersten Generation wird das afaik nicht gelingen.

Zitat von Lacoste

Ich möchte gerne die Schalter der Rolladen gerne zu einer bestimmten Zeit deaktivieren

Meinst du die Schalter an der Eingängen von Shelly Geräten? Dann wären die Eingänge zu sperren (enable = false).

Mit solchen ab Generation 2 ist dies via Schedule Jobs (Zeitpläne) möglich. Dazu braucht es weitergehende Kenntnisse der RPC Methoden. Mit der App/Cloud oder dem WebUI gelingt es auch nicht, weil solches hier nicht vorgesehen ist. Möglich ist es trotzdem, wenn man weiß, wie.

Wenn du deaktivieren willst, willst du sicherlich zu bestimmter Zeit (oder bei bestimmtem Ereignis) auch aktivieren.

Mika-Wood

Warum willst du WiFi deaktivieren? (Rhetorische Frage)

Du kannst bspw. dein Smartphone als Hotspot vorsehen (nicht zwingend aktiv). Darüber kannst du den mini 1 auch erreichen (nicht zwingend). Der Hotspot Einsatz hat den Nebeneffekt, dass darüber (max. 1 Minute online genügt) der Shelly seine Zeit synchronisieren kann.

Und, wie bereits angemerkt, ist auf einem Shelly Generation 3+ kein Skript dafür erforderlich.

Dort kannst du mehrere BTHome Komponenten anlegen, die auf BLU Geräte reagieren. Via Actions kannst du den mini 1 dann auf die Nachrichten vom BLU Button reagieren lassen.

s.ultes

Nutzt du auf dem Rollladen-Shelly Actions oder funzt der via Standard-Konfiguration?
Auf dem remote Shelly wirst du zumindest Actions anlegen müssen, die den anderen via URL steuern. Die URLs müssen zu den Shelly RPC Vorgaben passen, bspw.

http://<IP Adresse>/rpc/Cover.Open?id=0

Genaueres ist hier zu finden: https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Cover

Zitat von s.ultes

Wie funktioniert das mit Scripten?

In einem Skript lassen sich feinere Sensitivitäten bzgl. der Eingänge implementieren. Solches wirst du vermutlich nicht brauchen, wenn die beiden Taster/Schalter mechanisch gegenseitig verriegelt sind.

Ein Shelly i4 ist für so etwas besser geeignet - oder ein BLU RC(?). Mit Letzterem wird auf einem Shelly 2PM ein oder zwei Skripte benötigt.

Spitfire2

Vermutlich meinst du eine Benachrichtigung via Cloud. Darauf gehe ich nun ein.

1. Du legst in der Cloud eine manuell auslösbare Szene an, die die gewünschte Benachrichtigung sendet.
2. Oben rechts kannst du dir die Id-Nummer dieser Szene anzeigen lassen. Sie wird noch gebraucht.
3. In der lokalen Action setzt du den URL wie folgt zusammen:
   https: //shelly-xx-eu.shelly.cloud/scene/manual_run&auth_key=<dein Authorisierungsschlüssel>&id=<Szene-Id> (ohne Leerzeichen vor den //, hier nur, damit es kein Link ist)
   xx durch die Nummer deines Cloud Servers ersetzen!

Man kann auch via callmebot (ohne Cloud) Messenger Nachrichten verschicken lassen - aus einen Skript heraus oder auch via Action.

Ich habe noch einmal über diese Mittelwertbildung nachgedacht. Es geht noch etwas besser (mit etwas Mathematikverständnis). Dabei muss nicht die Summe aller bisherigen Werte verwendet werden, wodurch sich kein Summenüberlauf ergeben kann, d.h. es ergibt sich kein Wert, der für die Zahlendarstellung zu groß werden könnte.

a_n = arithmetischer Mittelwert von n Messwerten x₁, x₂, x₃, ..., x_n

a_n = (x₁ + x₂ + x₃ + ..., + x_n) / n

Nun lässt sich der nächste Mittelwert aus dem vorangegangenen berechnen.

a_n+1 = (x₁ + x₂ + x₃ + ..., + x_n + x_n+1) / (n + 1) = (x₁ + x₂ + x₃ + ..., + x_n) / (n + 1) + x_n+1 / (n + 1)

Zum Ziel führt die Multiplikation mit (n + 1) / n.

a_n+1 * (n + 1) / n = (x₁ + x₂ + x₃ + ..., + x_n) / n + x_n+1 / n = a_n + x_n+1 / n | * n / (n + 1)

a_n+1 = a_n * n / (n +1) + x_n+1 / (n + 1) = (n * a_n + x_n+1) / (n + 1)

Zusammenfassung: a_n+1 = (n * a_n + x_n+1) / (n + 1)

In Prosa: Der neue Mittelwert ergibt sich aus dem bisherigen Mittelwert mal der Anzahl (an Werten), aus der er entstand, plus dem neuen Wert - das Ganze geteilt durch die neue Anzahl. Mir erscheint es folgerichtig, da der bisherige Mittelwert das n-fache Gewicht gegenüber dem neuen Einzelwert haben muss.

Vielleicht gibt es einen einfacheren Weg. Wesentlich ist die obige Zusammenfassung. Damit gelingt die gleitende Mittelwertberechnung ohne Zwischenspeicherung aller in einer Zeitspanne erfassten Werte.

In einem Skript ist somit der aktuelle Mittelwert leicht berechenbar und die Anzahl (n) mit jedem neuen Wert zu inkrementieren.

Ich weiß noch nicht, ob und ggf. wann ich dazu ein Skript zusammenstellen werde. Die mathematische Grundlage dazu steht jedenfalls.

Edit: Ergänzung zu den Startwerten

Vor dem ersten Messwert müssen die Variablen für Mittelwert (a oder average) und Anzahl (n oder number) mit Startwerten initialisiert werden.

a₀ = 0, n = 0 | a₀ ist der Anfangswert für a, x₁ ist der erste Messwert

Anwendung obiger Formel: a₁ = (0 * a₀ + x₁) / 1 = 0 * 0 + x₁ = x₁ | plausibel, weil der erste Messwert zugleich der erste echte Mittelwert ist