Beiträge von eiche

Jo_Be

Ich bewerbe hier erstens nichts, es steht nur als Hinweis im Zusammenhang mit mitunter bedenklichem Einsatz einer Cloud.

Und zweitens, wie bereits tvbshelly bemerkte, leiste ich an gegebener Stelle auf eigene Kosten und ohne jeglichen direkten oder indirekten Gewinn Hilfestellung für technisch Interessierte.

Prinzipiell bin ich bereit, ein Impressum einzubauen, was ich auch auf einer anderen der von mir auf eigene Kosten etc. (s.o.) bereitgestellten Subdomains bereits tat. Ich finde es aber sehr merkwürdig, dass sich hieran jemand stößt (Krümelkackerei). Mich interessiert, ob du ( Jo_Be) auch Konstruktives beizusteuern hast.

Nach thgoebel und horkatz wäre darin CMOS-Memory verbaut. Vielleicht wird stattdessen auf nichtflüchtigen Speicher gesetzt, was technisch ungünstiger wäre, wegen geringerer Lebensdauer.

Titty-Twister

Das Skript brauchst du ggf. erst dann hier zu posten, wenn es deinerseits einen weiteren Bedarf geben sollte.

towiat

Die boolesche Algebra greift bei den beiden Alternativen zur Inversion des Schaltens. Ich habe beide angeboten, damit Titty-Twister die für ihn verständlichere wählen kann.

Ansonsten hat das Skript von towiat den Vorteil der Synchronität, d.h. es werden die aktuell vom zweiten Shelly gelieferten Zustandsinformationen verarbeitet. Das von mir gekürzte Skript orientiert sich halt mehr am Ausgangsskript und dürfte für den TE deshalb zunächst vertrauter wirken. Durch die verfügbaren, kürzeren Funktionen ist es auch etwas leichter an Änderungen anpassbar.

Jan_Grz

Ich bin nie auf dem "modernsten" Stand von Verfügbarkeiten, empfehle (leicht naiv) aber generell beim Kauf die neueste Generation. Falls ältere Geräte, bspw. der zweiten Generation, vorhanden sind , können solche hierfür eingesetzt werden.

Der Hinweis von thgoebel sollte für deine Zwecke genügen. Bei finigraleren Wünschen ließe sich eine Kombination aus Schedule Jobs und Skript einsetzen.

Titty-Twister

Du musst schon selbst wissen, wie du es haben willst.

Klar, man kann alles, was gewünscht ist, recht einfach in Code umsetzen.

Ob dies in der Funktion setRelayState() oder in deren Aufruf erfolgen soll, ist perspektivisch zu betrachten - beides ist möglich, nur nicht zugleich. Letzteres täte sich gegenseitig aufheben.

Ich nehme hierfür bspw. mal den Aufruf.

setRelayState(!(switch_status[0] && switch_status[1]));

Alternativ gelingt dies auch per Boolescher Algebra mit einer ODER Verknüpfung:

setRelayState(!switch_status[0] || !switch_status[1]);

Die Boolesche Algebra gehört zu den tiefsten Grundlagen der IT.

Manchmal gewinne ich den Eindruck, dass Grundlagenkenntnisse nicht mehr angemessen geschätzt werden. Vielleicht sehe ich dies als "IT Dinosaurier" so. Die "moderne " KI gibt mir nicht zuletzt unter meiner Perspektive erheblich zu denken, als alter Knabe. Ich werde die Folgen aber nicht mehr ertragen müssen. Meine Kinder und Enkel werden unter den Fehlleistungen aktueller Politik leiden. Die Sprücheklopfer aus jedweder Richtung sind dafür verantwortlich, ohne sich als Schneeflocke für eine Lawine selbst zu erkennen. Nimm mir bitte meine Gedanken nicht übel!

Ich interpretiere "EM" als energy measuremt und weniger als energy management.

Ja klar, das tue ich gerne.

Es wird aber ca. 2,5 Wochen dauern, bis ich wieder zu Hause bin.

Diese Site fand ich bereits, aber keine Doku zu dem Teil.

pdf?

Ich finde dazu keine Doku. Habt ihr die Teile etwa bereits, bevor sie auf den Markt kommen?

Aus gegebenem Anlass kann ich die Firmware 1.5.1-beta2 nicht empfehlen.

Meine Shelly Plus 2PM Hauptuhr zur Steuerung von Nebenuhren per Skript fiel nach Stromausfall aus, nicht rücksetzbar.

Ich setzte einen anderen Shelly Plus 2PM ein, aktualisierte dessen Firmware auf o.a. Version, richtete den Shelly ein (Skript, KVS, Schedule Jobs) und startete das Skript.

Resultat mit der beta2: Es gibt einen RPC Fehler, den dieses Skript zuvor noch nie verursachte. Nach Rückbau auf Firmware 1.4.4 läuft alles fehlerfrei. Vermutlich täte es dies auch bei 1.5.1, was ich aber nicht testete, da die Firmware Upgrades unterschiedlich zur Verfügung stehen, offenbar abhängig von der aktuellen Firmware auf dem Gerät oder anderen Daten. Diese Unstimmigkeit lässt ebenfalls noch Wünsche übrig ...

Titty-Twister

Noch ein Hinweis:

Mit MQTT ginge es ebenfalls recht verlässlich und komfortabel. Hierfür brauchst du einen MQTT Broker, welchen du vermutlich nicht vorhältst.

Mit retained MQTT Nachrichten kann der Shelly mit den Eingangszuständen ausschließlich bei einer Änderung als MQTT Publisher eine entsprechende Nachricht retained senden. Solche Nachrichten speichert der Broker.

Der empfangende Shelly als MQTT Subscriber erhält automatisch die vom Publisher zuletzt gesendete Nachricht. Dies erfolgt auch dann, wenn dieser Shelly hochfährt, weil er sich dann automatisch als Subscriber beim Broker meldet und dieser die letzte vom Publisher gesendete Nachricht an den Subscriber sendet.

Vorteile:

1. Die beiden Skripte sind relativ einfach.
2. Der Publisher braucht ausschließlich Änderungen eines Eingangs mitzuteilen, einfaches Skript - beim Hochfahren liest er diese ein und sendet (zeitversetzt) die Nachricht an den MQTT Broker.
3. Der Subscriber erhält immer die zuletzt vom Publisher gesendete Nachricht, auch dann, wenn der Publisher aktuell ausfällt, also nicht erreichbar ist.
4. Die Erreichbarkeit des Publisher kann leicht festgestellt werden, indem das Skript zusätzlich das Topic <MQTT prefix>/online abonniert.
   Dies ermöglicht dem verarbeitenden Shelly (oder einem anderen MQTT Subscriber) die Nichterreichbarkeit des anderen Shelly festzustellen und geeignete Maßnahmen durchzuführen.

Nachteile:

1. Es wird ein weiteres Gerät, bspw. ein Raspberry Pi, mit MQTT Broker benötigt.
2. Die Funktion ist nur solange gewährleistet, wie der Broker arbeitet.
   Mein Broker fiel bisher ausschließlich ohne Strom aus.

Titty-Twister

Zur Verarbeitung der aktuellen Zustände beider Eingänge des anderen Shelly fallen mir ad hoc vier echte Alternativen ein.

1. Nur ein Skript (wie bisher)
   1. Die Zustände werden in den callback Funktionen der RPC (=Shelly.call()) verarbeitet.
      Hierzu sollte in der ersten callback Fkt. ein RPC erfolgen, in welchem dessen callback Funktion die vorliegenden Zustände verarbeitet.
      Vorteil: höchst aktuell
      Nachteil: Tiefer verschachtelter Code
   2. Beide Zustände werden per RPC geholt und gespeichert. Ein Timer startet bspw. 5s nach den RPC eine Funktion, welche die Zustände verarbeitet.
      Vorteil: Code ist deinem sehr ähnlich und damit relativ einfach.
      Nachteil: Keine hohe Aktualität
2. Auf jedem der beteiligten Shelly ein Skript
   Auf dem verarbeitenden Shelly steht eine Skriptfunktion bereit, welche diese Informationen entgegennimmt und verarbeitet.
   Auf dem Shelly, dessen Eingangszustände abzufragen sind:
   1. Immer dann, wenn sich ein Zustand ändert, erfasst dies ein Eventhandler im Skript und sendet die Information über beide Eingänge an den anderen Shelly. Beim Hochfahren des Shelly werden beide Zustände abgefragt und übertragen.
      Vorteil: relativ einfache Skripte, höchst aktuell
   2. Per Timer oder besser Schedule Job werden beide Zustände abgefragt und an den verarbeitenden Shelly übertragen.
      Vorteil: Es wird regelmäßig aktualisiert
      Nachteil: keine hohe Aktualität möglich - wie in 1.2
3. Eine Kombination von 2.1 und 2.2

Hinweis: Wenn du keine hohe Aktualität der Eingangszustände brauchst, empfehle ich der Einfachheit wegen Variante 1.2. Sie ist relativ robust.

Ich nutze gerne kürzere, übersichtlichere Skripte, wenn möglich. Hier (ungetestet) sollte dies per zusätzlichem Parameter id gelingen. Vielleicht magst du diese Anregung gelegentlich nutzen. Es geht ausschließlich um die Einsparung der beiden Funktionen getSwitchStatus2() und updateSwitchStatus2().

const shelly2_ip = "192.168.120.161";
let switch_status = [false, false]; // Datenfeld mit Indexen 0 und 1

// Funktion, um den Status des Schalters abzurufen
function getSwitchStatus(id, callback) {
  Shelly.call("HTTP.GET",{url: "http://" + shelly2_ip + "/rpc/Switch.GetStatus?id=" + id,},
    function(result, errc, errm, id) { // errc, errm müssen eingefügt werden, damit die id importiert wird, s.u.
      try {
        let response = JSON.parse(result.body);
        callback(id, response);
      } catch (e) {
        print("Fehler beim Parsen der Antwort:", e.message);
        callback(id, null);
      }
    }, id // muss als user defined parameter übergeben werden
  );
}

// Funktion zum Aktualisieren des Schalterstatus
function updateSwitchStatus(id) {
  getSwitchStatus(id, function(id, status) {
    if (status !== null) {
      switch_status[id] = status.output;
      print("Netzspannung" + (id+1) + ":", switch_status[id] ? "Eingeschaltet" : "Ausgeschaltet");
    } else {
      print("Fehler beim Abrufen des Schalterstatus Netzspannung" + (id+1) + ".");
    }
  });
}

// Funktion zur Steuerung des Relais
function setRelayState(state) {
  Shelly.call("Switch.Set", { id: 0, on: state}, function(result, error_code, error_message) {
    if (error_code !== 0) {
      print("Fehler beim Schalten des Relais Starkstrom:", error_message);
    } else {
      print("Starkstrom:", state ? "Eingeschaltet" : "Ausgeschaltet");
    }
  });
}

// Funktion zur regelmäßigen Überprüfung der Intervallsteuerung
function startControl() {
  // Setze eine Funktion zur regelmäßigen Überprüfung alle 10 Sekunden
  Timer.set(10000, true, function() {
    updateSwitchStatus(0); // Lese den Schalterstatus des Relais das den Solarkreislauf von Speicher auf Pool steuerert 
    updateSwitchStatus(1); // Lese den Schalterstatus des Relais das den Solarkreislauf von Speicher auf Pool steuerert 
    print("Das Netz wurde", switch_status[0] ? "auf Netzbetrieb" : "auf Akkubetrieb", "umgeschaltet");
    setRelayState(switch_status[0] && switch_status[1]); // Aktualisiere den gewünschten Relaiszustand
  });
}
// Starte Schleife
startControl();

Da ich dies nicht getestet habe, hoffe ich auf Fehlerfreiheit.

Btw, das von dir verfasste Ausgangsskript erscheint mir im Ansatz durchaus gut gemacht, mit Ausnahme der UND Verknüpfung.

Im übrigen ist der Hinweis von towiat zur asynchronen Abarbeitung von Ereignis gesteuerten Shelly Skripten sehr bedeutsam. Diesen Hinweis solltest du verstehen und bedenken.

Hinweis: Ich habe das Skript in Zeile 24 korrigiert, am 2025-04-01 um 10:45 Uhr.

Titty-Twister

Deine switch_status Variable sind boolsche Variable, d.h. sie beinhalten Wahrheitswerte. Die UND-Verknüpfung beider Variablen erfolgt zielführend per Operator &&. Das einfache & verknüpft bitweise, was auch gelingen kann, aber nicht sicher ist.

setRelayState(switch_status && switch_status2); // Aktualisiere den gewünschten Relaiszustand

Zu mehr Analyse kam ich so schnell jetzt nicht. Vielleicht später ...

Offenbar schaltet die Hauptstelle die Lampe. Diese Klemme sollte an den SW-Eingang eines schaltenden Shelly (Shelly 1, Shelly Plus 1, Shelly Plus 1 PM, ...) geführt werden. Dann schaltet der Shelly die Lampe(n) und "kennt" somit auch den Schaltzustand, welcher damit automatisch in der App, in der Cloud und auch auf der Webseite des Shelly zu sehen ist.

Dazu ist der graue Shelly PM Mini Gen 3 durch einen Shelly mit SW Eingang und Schaltausgang zu ersetzen.

Zitat

Könnte man es denn mit einem Shelly Plus 1PM realisieren? L und N anschliessen. Lichtstrom aus dem Zeptrion auf SW (schwarzer Draht auf meinem Foto) und O mit der Lampe verbinden (roter Draht).

Ja, das sollte dein Ziel erreichen.

Zitat

Denn es gibt Zeptrion Schalter, die die Lampe ebenfalls ein- und ausschalten können.

Wenn diese Zeptrion Schalter auf den SW Eingang des Shelly geführt werden können/sollen, dann täte dies ohne Messung genügen, weil dann der die Lampe schaltende Shelly den Schaltzustand "kennt".

Ich kenne deine gesamte Schaltung nicht (mehr).

Bitte skizziere diese mit allen beteiligten Teilen - Schalter/Taster, alle die Lampe(n) schaltenden Zeptrion Schalter, Verbindungen!

Brendianer

Ich muss mich ein wenig verbessern. Der die Lampe schaltende Shelly braucht nicht zu messen. Außerdem sollte so der Schaltzustand der Lampe direkt von diesem Shelly signalisiert werden. Hierfür genügt sogar ein Shelly (Plus) 1, also auch ein Shelly der ersten Generation käme in Frage.

Zitat

Was kommt dann an SW und was an O?

An SW kommt der bisher schaltende Ausgang deiner Elektronik. Es bleibt zu prüfen, ob diese Beschaltung wie erwartet schaltet. Die Ausgangsspannungen deiner Elektronik sind hierbei entscheidend. Falls das Schalten nicht erfolgreich gelingt, käme vermutlich noch der hier sog. "Bukoski-Draht" zum Zuge.

O ist der Schaltausgang des Shelly, mit welchem die Lampe letztlich geschaltet wird. An I sollte L gelegt werden.

Falls diese Lösung gelingt, was ich stark vermute, ist die Lehre daraus "Es ist mitunter zielführend, Abstand von den eigenen Gedanken zu gewinnen. Das fördert Alternativen."

Du schaltest also den messenden Shelly und damit die Lampe. Das ist keine wirklich gute Idee.

Dazu habe ich einen kleinen Verbesserungsvorschlag.

Nimm einen schaltenden Shelly, der auch messen kann! Dieser wird dauerhaft versorgt und per SW Eingang das Schalten der Lampe gesteuert.

Zitat

const json = response['body'];

const obj = JSON.parse(json);

Offenbar hast du Programmiererfahrung. Warum legst du die Variablen json und obj per const statt per let an?

(Ich bevorzuge Zugriffe auf Komponenten per Punktnotation.)

Zwei Schritte sind hier nicht erforderlich. Es genügt bspw.

let obj = JSON.parse(response.body);

Edit: Der Code von HighFive tat dies übrigens bereits so.

GuenterP

Ein Shelly Skript wird immer auf dem Shelly gespeichert, welcher das Skript abarbeitet. Damit kann ein Shelly weitgehend autark arbeiten, was ein erheblicher Vorteil sein kann.

Die Firmware liefert Messwerte

1. in gewissen Zeitabständen, bspw. ca. 60s,
2. wenn sich ein solcher Messwert gendert hat.

Wohin liefert die Firmware solche Messwerte?

1. In die Cloud, wenn der Shelly in die Cloud eingebunden ist.
2. An die Web UI des Shelly.
3. An eine dafür im Skript erstellte Funktion, welche hierfür in der Firmware registriert wurde.
4. An ein übergeordnetes lokales System, wenn die Kommunikation dafür konfiguriert ist.

Die zügigste, sicherste und flexibelste Verarbeitung solcher Messwerte findet lokal im Shelly per Skript statt. Auch übergeordnete Systeme bieten reichlich Möglichkeiten hierfür, wofür aber zwingend die Kommunikation mit dem Shelly funktionieren muss. Die Funktion im Skript, welche die Messwerte entgegennimmt ist entweder ein sog. Eventhandler oder ein Statushandler. Wenn es ein Eventhandler tut, täte ich diesen bevorzugen. In deinem Fall ist dies so.

Ein Skript erfordert programmieren. Mit Klicken, Selektieren und hier und da einen Eintrag erstellen ist es nicht getan.

Ein erstes Skript, um sich einer Lösung zu nähern sieht bspw. so aus.

function evh(ev) {
	print(JSON.stringify(ev);
}

Shelly.addEventHandler(ev);

Der Eventhandler, welcher über die Messwerte per Parameter "ev" von der Firmware informiert wird, ist hier die Funktion "evh", welche per letzter Anweisung der Firmware als Eventhandler zwecks Registrierung mitgeteilt wird.

Dieser Eventhandler ist sehr schlicht und gibt nur die Datenstrukturen aller eintreffenden Events aus, auch der Events von Messwerten. An Hand solcher Ausgaben ist es möglich, die interessanten Teile per Analyse ausfindig zu machen und zu erkennen, wie man per Skript auf diese Teile zugreifen kann. Vermutlich lauten die für deine Zwecke zielführenden Teile des Parameters "ev"

• "name": "temperature"
• "id": 100 oder 101 oder 102
• "info": eine Datenstruktur, in welcher der jeweilige Messwert steckt.

Ungeprüft fokussiert vermutlich das folgende Skript die Ereignisse, welche gemessene Temperaturwerte liefern.

function evh(ev) {
	if(ev.name==="temperature") {
		print(JSON.stringify(ev);
	}
}

Shelly.addEventHandler(ev);

Zur Regelung

Für deine Anwendung halte ich es zielführender, wenn du

• einen ad hoc änderbaren Wert für die Zieltemperatur "targetTemp",
• einen Hysteresewert "dTargetTemp" und
• eine feste Temperaturdifferenz "dTemp" festlegst.

"targetTemp" ist die angestrebte Zieltemperatur des Poolwassers. Ist dessen gemessene Temperatur "tempPool" unterhalb targetTemp - dTargetTemp, wird die Erwärmung freigegeben. Ist tempPool > targetTemp + dTargetTemp, wird die Erwärmung gesperrt und ggf. abgestellt.

Ist bei freigegebener Erwärmung die Differenz der Temperaturen von Heizmatte und Einspeisung mindestens gleich dTemp, so wird die Heizungzirkulation eingeschaltet.

Zusätzlich ist noch eine manuelle Freigabe/Sperrung der Heizung vorzusehen.

Hinweise für ein anwendungsgerechtes Skript

1. Die im Eventhandler eintreffenden Messwerte sind in globalen Variablen zwischenzuspeichern.
2. Wenn alle zwischengespeicherten Messwerte gültig sind, sollte der Eventhandler (hier evh) an Hand der Parameter (s. "Zur Regelung") prüfen, ob eine Erwärmung zu aktivieren ist und dies ggf. tun, d.h. die Heizungszirkulationspumpe einschalten.

Zusatzhinweise

Ein ausgereiftes Skript ist etwas komplexer und sollte wenigstens die Änderung der Zieltemperatur ermöglichen. Hierfür ist bspw. die Kommunikation per MQTT geeignet. Bei Verwendung eines übergeordneten Systems genügt vermutlich bereits HTTP. Wenn du ohne zusätzliche Installationen auskommen möchtest, gelingt die Einstellung von Parametern auch per Shelly ab dritter Generation und virtuellen Komponenten (virtual Components), die auf der Web UI des Shelly verfügbar gemacht werden können. So kann bspw. per Schiebeeinsteller auf der Web UI die Zieltemperatur geändert werden. Solche virtuellen Komponenten können per Skript verwendet werden - Werte lesen, Änderung erfassen, schreibend ändern.

Vielleicht käme dir die Nutzung solcher virtueller Komponenten für deine Zwecke entgegen.

Falls du alles auch remote ablesen und manipulieren können möchtest bleibt die Cloud (auch ohne Skript) oder VPN und Skript. Ich halte die zweite Variante für die erheblich bessere, allerdings ist sie aufwändiger zu implementieren.

Ich hoffe, hiermit ein wenig zur Erhellung beigetragen und dich nicht allzusehr verwirrt zu haben.