Beiträge von eiche

Ich musste soeben feststellen, dass mein letztes Skript wegen zu vieler RPC Aufrufe abgebrochen wurde - nach geschätzt 10h Laufzeit des Skripts. Deshalb werde ich das Zeitmanagement auf Schedule Jobs stützen, ergänzt durch Skript interne Timer. Das Prinzip habe ich an anderer Stelle beschrieben:

https://iotig.eichelsdoerfer.net/index.php/anwe…iden-reduzieren

Hierzu will ich mindestens eine flexibel nutzbare Datenstruktur kreieren, was mehr "Gripsarbeit" und Recherche/Experimente erfordert.

Ziele und Planungen - hier zwecks Verständlichkeit zusammengefasst

1. Ein Skriptabbruch darf sich nicht ereignen. Die größte Gefahr geht vom Limit 5 parallel ausgeführter RPC aus. Dieses Limit sollten die Shelly Firmware Entwickler wegen leistungsfähigerer Shelly neuerer Generationen erhöhen. Ich muss aber dieses Limit bis auf weiteres berücksichtigen.
2. Warn- und Notsignale sollen hier keine Rolle spielen, da solche am besten kabelgebunden zuzuführen und skriptunabhängig bspw. per Aktion oder gar durch zusätzliche Schaltungen zu verarbeiten sind.
3. Folgende Kategorien von Nachrichten sind zweckmäßig/vorzusehen.
   1. Sofort auszuführende Nachrichten, bspw. auf Grund von Tastendrücken oder Bewegungsmeldungen - Mensch Maschinen Schnittstelle, Usability.
      Deren Anzahl ist stark einzuschränken, da gleichzeitiges Eintreffen mit erforderlichen RPC Methoden schnell zur Überschreitung des RPC Limits führen können. Solche Nachrichten treffen aus Perspektive des Skripts zufällig ein.
   2. Verzögert zu verarbeitende Nachrichten, bspw. Messwerte. Deren Verarbeitung kann leicht in Sekundenabständen erfolgen, evtl. sogar noch stärker verzögert.
   3. Unmittelbare Nachrichten von per Components registrierten/gekoppelten BLU Geräten.
   4. Mittelbare Nachrichten, die von anderen nicht BLU Geräten kommen und deren Daten vor der Verarbeitung noch abzufragen sind (zusätzliche RPC erforderlich).
4. Das Zeitmanagement für Nachrichten der Kategorie 3.2 - und damit Kat. 3.4 sowie mancher von Kat. 3.3 (s.u.) - ist ausschließlich per Schedule Job(s) zu implementieren, weil deren Verarbeitungsstarts deterministisch sind, d.h. innerhalb von Zeitperioden (bspw. 1 Minute) festgelegt.
5. Zwecks Validierung der Funktionssicherheit sind periodisch Skriptstarts per Schedule Job vorzusehen, bspw. alle 10 Minuten. Mit jedem Neustart ist im Skript der aktuelle Zeitstempel zu generieren, möglichst die Ursache für einen vorangehenden Skriptabbruch zu ermitteln und beides in einer separaten, nicht ausführbaren Skriptdatei abzulegen. Damit sind im nachhinein Skriptabbrüche und deren Ursache erkenn- und in Grenzen analysierbar. Dies wird afaik durch Wirkungslosigkeit eines Skriptstarts bei bereits laufendem Skript unterstützt.

Nachrichten der Kategorie 3.3 können entweder zur Kategorie 3.1 oder 3.2 gehören.
Nachrichten der Kat. 3.4 gehören immer zur Kat. 3.2.

In Mengenausdrucksweise:
Kategorien 3.1 und 3.2 sind elementfremd, d.h. deren Schnittmenge ist leer.
Elemente (=Nachrichten) der Kategorie 3.3 sind entweder auch Elemente von Kategorie 3.1 oder von Kat. 3.2.
Elemente von Kategorie 3.4 sind immer auch Elemente von Kat. 3.2, d.h. Kat. 3.4 ist Teilmenge von Kat. 3.2.

Diese Dinge sind notwendig für eine robuste Implementation von Datenstrukturen, welche grundlegend für eine hohe Ausfallsicherheit in der Skriptabarbeitung sind.

Wann ich das Skript hier vorstellen werde, weiß ich noch nicht. Mit dieser Planung ist aber der kreative Anfang gemacht, der Rest ist Fleißarbeit.

Zitat von oldcoolman

Nebenbei: Überwacht der TE den Wasserdurchfluß? Was wenn Heizung mal auf Störung geht?

Mal abwarten, was der TE dazu schreibt. Meinem Eindruck nach hat er so etwas nicht berücksichtigt. Eine Temperaturüberwachung nähe der Heizungsstelle wäre leichter und preisgünstiger zu realisieren als eine (grobe) Durchflussmessung. So täte ich vorgehen, sicherheitshalber mit zwei Temperatursensoren.

Btw, der TE sucht meinem Eindruck nach eine möglichst einfache Lösung und hat weitere Sicherheitsaspekte (noch) nicht in den Blick genommen.

Mig1957

Meine Erfahrung und Einschätzungen - keine direkte Antwort auf dein Problem.

Ich habe das letzte Mal vor 4 oder 5 Jahren mehrere Shelly 1 der Generation 1 mit Tasmota erfolgreich geflasht. Diese tun ihre Rules gesteuerte Arbeit verlässlich nach wie vor. Mit Gen 2 Shelly hatte ich dazu keine Veranlassung, weil mir das Skripten genügend Flexibilität bietet.

Per OTA täte ich jedenfalls keine andere Firmware aufspielen - braucht zusätzlichen Speicher.

Vor dem Flashen ist immer eine Sicherung der bisherigen Firmware zweckmäßig, um bei Bedarf zurück flashen zu können.

Wenn du gerne Tasmota (32) verwendest, ist vielleicht ein ESP32 Board besser geeignet. Ein solches bietet erheblich mehr analoge Eingänge, einen analogen Ausgang und viele digitale Multifunktions Ein-/Ausgänge. Nur mal so als Anregung. Ansonsten wünsche ich dir noch Erfolg bei der Lösung.

Dann bliebe als "saubere Sinus-"Lösung fast nur ein dicker (Spar-)Trafo mit mindestens einem Abgriff.

Aus solchen Gründen setze ich immer wieder auf Lösungen per Skript. Ich wunderte mich damals, ca. 2020?, warum Shelly so sehr lange am alten ESP 8266 festhielt und nicht auf den schon lange auf dem Markt erhältlichen ESP32 umstieg. Nun ja, ein Startup muss sich auch erst einmal etablieren ...

Ansonsten gefällt mir das offene Shelly Konzept außerordentlich gut, weshalb ich solche kleinen Nachlässigkeiten ohne meckern hinnehme. Ich hätte auch Wünsche, deren Realisierung mir Verbesserungen brächte, die aber wohl nicht sehr nachgefragt sind.

Zitat von maschuett

Aber was für einen Sinn machen die URL Actions dann, wenn man die nicht per Schalter auslösen kann?

Tja, Sinn ergibt das nicht. Vielleicht ist dies dem knappen Speicher der 1. Gen. Shelly geschuldet. Darin wirkt ein alter µC vom Typ ESP 8266 oder kompatiblem. Oder vielleicht haben das die Shelly Leute als nicht erforderlich eingestuft. Eine Änderung der Firmware ist jedenfalls nicht zu erwarten - zu alt.

Als Workaround könntest du einen zusätzlichen (alten) Shelly verwenden, der per Taster/Schalter gesteuert wird und auf welchem per Aktion der Rollladen Shelly Kommandos erhält. Ich nutze für so etwas 4er Tastergruppen mit Shelly i4. Damit geht auch das, was du willst.

Die Phasenanschnittsteuerung soll ausschließlich auf einen Verbraucher, hier die Elektroheizung im Rücklauf, wirken.

Zitat von martner

Ich bin beeindruckt, mir wie viel Energie du da ran gehst!

Vielen Dank.

Im letzten Skript in #23 ist zwischen zwei Kategorien zu unterscheiden.

1. Die mit dem Skript Shelly gekoppelten BLU Geräte müssen auf diesem als Components angelegt sein.
   Damit greift die Benachrichtigung der Firmware an den Statushandler, sobald Daten von einem BLU Gerät empfangen wurde. Das Skript holt sich dann von der entsprechenden Component (entspricht BLU Gerät) die verfügbaren Sensoren und mit diesem Resultat letztlich die Sensordaten, also die Nutzdaten.
2. BLU Geräte, die mit anderen Shelly gekoppelt sind - also nicht mit dem Skript Shelly, wie bspw. ein Wall Display, können ggf. die Daten selbst verarbeiten (per Skript). Alternativ können solche Shelly per Methode "Script.Eval" Nachrichten an das Skript übertragen, die dazu geeignet sind, die Daten (zeitversetzt) abzurufen. Letzteres wird bei einem Wall Display benötigt, wenn die Daten ohne übergeordnetes System verarbeitet werden sollen.

Das Wall Display veröffentlich MQTT Nachrichten, die ein übergeordnetes System abonnieren kann und somit die Daten erhält.

Vorteil zu 1: Die Sensordaten enthalten einen Zeitstempel zu den zuletzt erfassten Daten eines gekoppelten BLU Gerätes. Das sind die verlässlichsten Zeitstempel, womit sicher erkennbar ist, von wann die Daten stammen.

Habe ich deine Frage damit hinreichend beantwortet, ohne verwirrt zu haben?

Du wolltest doch eine Insellösung, also ohne dein Haus WLAN. Die Insellösung hat nichts mit Range Extender zu tun. Ich nutze kein Range Extender und kann deshalb dazu nichts genaueres mitteilen. Für die Kopplung mit deinem Haus WLAN könnte ein zwischen Insel und Haus platzierter Access Point oder ein Shelly als Range Extender genutzt werden. Ob dann die Insel noch autark arbeiten kann, weiß ich nicht.

Ein zielorientiertes Vorgehen hängt von deinen Prioritäten ab.

1. Ist die Insel per se gewünscht oder nur als Notlösung gedacht?
2. Falls nur Notlösung ist ein zusätzlicher AP die technisch beste Lösung, alternativ ein Repeater.
3. Falls beides, Insel und WLAN Anbindung gewünscht ist, muss getestet werden, ob beides möglich ist. Da kein Shelly als Zeitserver dienen kann, könnte der mit dem WLAN gekoppelte Shelly seine Zeit an die Insel Shelly übertragen. Dazu gibt es afaik ab Gen. 2 geeignete Methoden.

Falls die Shelly mit Zeitplänen arbeiten, was zu vermuten ist, müssen diese immer nach einem Stromausfall die Zeitinformation von einem Zeitserver holen oder anderweitig die Zeit erhalten, weil sie keine batteriegepufferte Real Time Clock haben. Zur Verbindung mit einem Zeitserver genügt eine max. 1 minütige Verbindung, bspw. über ein Smartphone Hotspot, oder selbstverständlich auch über dein Haus WLAN.

Ich hoffe, nicht zu sehr verwirrt zu haben. Es erscheint mir interessant, ob eine solche Insellösung mit Zeitsynchronisation realisierbar ist, auch wenn ich selbst dafür keine Verwendung habe.

Automatisch wird das in fein abgestimmter Weise nur mit einem Skript gelingen. Ohne Skript sollte es in Stufen mit je einer Aktion pro Stufe auf dem Pro 3 EM gelingen.

Ich bin ziemlich sicher, dass dein Ziel, auch fein abgestimmt, erreichbar ist. Nur kann ich keine fertige Lösung bieten, weil ich kein solches Equipment habe.

Ich habe bisher zu so manchem eine Skriptlösung geliefert, obwohl ich die Teile der Anfragenden nicht habe/hatte. Dazu muss der Klient bereit sein, zu experimentieren und mir Rückmeldungen zu geben, was mitunter schwer fällt.

maschuett

Wenn du den Shelly 2.5 durch einen Shelly (Plus) 2PM ersetzt, wird es damit gelingen.

Neben App/Cloud auch im WebUI des Shelly.

http://<IP Adr. Shelly>

Dort unter I/O URL actions.

Edit:
Habe nachgesehen. Ich fand keine Aktion, welche auf Status(änderung) eines Eingangs reagiert - Firmware 1.14.0.

Ich teste mal das Beta Firmware update ...

Auch Firmware 1.14.1 bietet dazu leider nichts brauchbares.

Hm, ich nutze so etwas, was du willst, nicht. Vermutlich können die "Insel Shelly" miteinander über den AP des Shelly kommunizieren, ggf. unter Nutzung von Portnummern. Du solltest damit mal experimentieren, am besten zunächst noch innerhalb deines Haus WLAN.

1. Shelly mit aktivem AP (kurz ShAP) und selbstverständlich passwortgeschützt.
   Netzwerkname und Passwort des ShAP notieren.
2. Shelly mit dem Netzwerk des ShAP verbinden. Da der PC vom ShAP offensichtlich eine IP Adresse erhält, sollte DHCP funktionieren. Vielleicht gelingt es auch mit einer statischen IP Adresse, wie 192.168.33.2. Eine Portnummer dürfte nicht erforderlich sein, weil diese nur bei Nutzung als Range Extender erforderlich ist.
3. Weitere Shelly wie in 2, IP Adressen per DHCP vom ShAP oder 192.168.33.x.
4. Dein PC mit dem AP des ShAP ohne LAN verbinden.
5. Mit RPC Aufrufen vom PC zu sukzessive allen Insel Shelly experimentieren. Wenn diese antworten müsste die Insellösung funktionieren.

Ich habe damit noch keine Erfahrung, aber so täte ich vorgehen.

Die Firmware MQTT Nachrichten reagieren auf eine RPC Anfrage mit einer MQTT Antwort, die Teile der Anfrage enthält. Damit wird eine Peer to Peer Kommunikation über MQTT nachgebildet.

Die Payload der Anfrage muss folgendes enthalten.

• id - Nummer oder String zwecks Zuordnung der Antwort
• src - eine Quellenangabe, welche die Firmware im Antwort Topic verwendet: <src>/rpc
• method - die Shelly RPC Methode, ggf. mit parameter

Die Shelly Antwort enthält in payload.result das Ergebnis der aufgerufenen RPC Methode. Statt "payload.result" kann es, abhängig vom übergeodneten System (ioBroker) auch anders lauten, bspw. "msg.result". Ich verwende Node-RED, wo es payload.xxx lautet.

Versuche, mehr mit der Methode shelly.listmethods herauszufinden!

http://<IP Adr. Ventil>/rpc/shelly.listmethods

In der Antwort sollte etwas hilfreiches auffindbar sein.

Ok, verstanden.

Aber ein Skript dürfte dafür nur dann notwendig sein, wenn du die Phasenanschnittsteuerung abhängig von der im Pro 3 EM gemessenen Gesamtleistung analog steuern willst. Soweit ich dich verstand, willst du die Phasenanschnittsteuerung nur ein- und ausschalten bzw. zwischen zwei (analogen) Werten umschalten, einen für aus, den anderen für 2000W. Das sollte mit einer Reihenschltung aus zwei Widerständen am potentialfrei schaltenden AddOn möglich sein. Das AddOn schließt dann einen der beiden Widerstände kurz. Dazu ist die Phasenanschnittsteuerung genauer ins Visier zu nehmen - kein Kunststück.

Nach Beschreibung ist evtl. Zusatzmodul M150 erforderlich, aber nur dann, wenn du analog steuern willst.

Zitat von Westerwald2000

Längere Leitung = zusätzliche Dämpfung = schlechterer Empfang

Aber: Bessere Platzierung der kleinen Stabantenne möglich und damit höhere Empfangs- und Sendefeldstärken als mit den Mäanderleiterbahnen.

Norrby-Schweden

Ohne das Skript im einzelnen genau analysiert zu haben, sollte dein Ziel mit dem Vertauschen zweier "Daten" in zwei Zeilen erreichbar sein.

1. In Zeile 159 device.on_url durch device.off_url und
2. in Zeile 163 device.off_url durch device.on_url ersetzen.

Dies verändert das Verhalten in das, was du willst, ohne den Quellcode unverständlicher zu machen.

Zitat von Dutoit

Ich möchte jedoch keinen direkten Zugriff in meinen Speicher.

Es geht hierbei nicht um die Steuerung deines Speichers sondern um die Art und Weise, wie der Speicher die Daten

1. entweder vom Pro 3EM abfragt (wahrscheinlicher) oder
2. vom Pro 3 EM gesendet bekommt.

Ich setze mal 1. voraus. Nur dann, wenn diese Abfrage des Speichers so geändert werden kann, dass dafür die Methode "Script.Eval" eingesetzt werden kann, ist dein Ziel per Skript erreichbar. Ich wüsste keinen anderen Weg.

Aha. Da wird das schaltende AddOn zum Pro 3EM verwendet. Wenn du zur Heizung die Leitung ziehen kannst/ bereits gezogen hast, kannst du damit dein Schütz schalten.

Zitat von stoppeljody

Kann damit jemand etwas anfangen?

Klar doch. Die für deinen Zweck entscheidenden Komponenten sind

• a_act_power = aktuelle Leistung von L1, hier -359.2W
• b_act_power = aktuelle Leistung von L2, hier 308,3W
• c_act_power = aktuelle Leistung von L3, hier 56,6W

In der Summe ergibt dies die Gesamtleistung über alle drei Außenleiter von 5,7W, was entweder 5,7W vom Energieversorger in dein Hausnetz bedeutet, was ich annehme, oder umgekehrt.

Die Komponente total_act_power = Gesamtleistung, hier 5,619W (ca. 5,7W) wird offenbar genauer berechnet, also unter Verwendung von mehr Nachkommastellen. Dieser Wert sollte dich am meisten interessieren. Hierzu solltest du zwei Aktionen anlegen können.

1. Bei Überschreitung der Gesamtleistung von bspw. 2100W (bzw. Unterschreitung von -2100W) sollte das AddOn den Ausgang (Schütz) einschalten.
2. Bei Unterschreitung der Gesamtleistung von bspw. -100W (bzw. Überschreitung von 100W) sollte das AddOn den Ausgang ausschalten.

Mit diesen Werten dürfte der Ausgang (Schütz) wegen der Rückwirkung des Heizungsverbrauchs auf die Pro 3EM Messwerte nicht ständig ein- und ausschalten. Um für dich passende Schaltschwellen zu finden, musst du experimentieren. Wer selbst ein Shelly Pro 3EM in Betrieb hat, wird hierzu Genaueres zum nachmachen zeigen können.

Es bleibt noch immer die Frage offen, was du mit der Phasenanschnittsteuerung vorhast, vermutlich manuell fest einstellen? Braucht es dann noch den Schütz? Die Phasenanschnittsteuerung muss ja unmittelbar die Heizung versorgen - allerdings nicht ohne beste Kühlung, weil deren Leistungsvermögen hart an der Grenze deines Vorhabens liegt. Ich täte sie, zumindest zunächst, weglassen.