Beiträge von eiche

Wenn du die Kommunikation zwischen deinem Speicher und dem Pro 3EM offenlegst, könnte ggf. ein Weg via Skript gefunden werden. Wenn der Speicher die Daten des Pro 3EM per RPC ohne Änderungsmöglichkeit abfragt, sehe ich allerdings schwarz.

Zu den parallel geschalteten Tastern/Schaltern:

Ich bin nicht sicher, ob diese bei gleichzeitiger Bedienung an den verschiedenen Stellen ein Problem verursachen könnten. Mit einer Funkverbindung kann bei gleichzeitiger Bedienung zwar Unerwartetes auftreten, aber nichts am Rollladen Shelly zerstört werden.

Sorry, bei vorgesehener Beschaltung kann es doch kein Problem geben.

Beitrag kann gelöscht werden.

Im Rollladenmodus finde ich unter Settings -> Button Type auch detached.

Zitat von Norrby-Schweden

Startseite > Skriptdatenbank > Dynamic Load Shedding Script for Energy Managemen

Ich finde das Skript nicht und bitte um genauere Ortsangaben.

Zitat von stoppeljody

Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.

Das ist überhaupt nicht zweckdienlich. Was hast du da entfernt?

Zitat von stoppeljody

Mit den DC Speichern die einfach in der Steckdose stecken, kann

ich ja mit der App auch genau sagen wieviel Strom abgegeben werden

soll, oder mit wieviel geladen wird.

Vielleicht steckt dahinter aber eine Regelung/ein Automatismus. Eine manuelle Einstellung kann allenfalls als Parameter für eine Speicherinterne Regelung dienen oder nur Zeitplänen unterliegen - ohne Regelung.

Eine, von dir angestrebte, relativ einfache Lösung kann es geben, wenn die Messdaten eines Pro 3EM auch die Summe der Einspeisung über drei Phasen beinhalten.

Ich kenne die vom Pro 3EM erfassten Daten nicht, weil ich keinen solchen Shelly habe. Du kannst eine Sammlung solcher Daten aber hier veröffentlichen, indem du in einem Web Browser folgendes in die Adresszeile eingibst.

http://<IP Adresse Pro 3EM>/rpc/shelly.getstatus

Die Antwort vom Pro 3EM ist eine Datenstruktur, welche du kopieren und hier in einem Beitrag einfügen kannst. Zuvor solltest du eine Darstellung dieser Antwort über viele Zeilen mit Einrückungen erzwingen, was bspw. mit den Browsern Edge, Firefox, Chrome ... durch anklicken einer kleinen Box gelingt.

Dieser so strukturierte Text kann dann leicht von einigen hier gelesen werden, so auch von mir. Auf dieser Grundlage kann ich dann feststellen, ob zwei Aktionen genügen oder ein Skript erforderlich ist.

Ich habe versucht, Messwerte eines im Wall Display (WD) an einen Shelly Generation 3 (im folgenden G3 genannt) zu übertragen - nur mal aus Interesse. Solches kann aber interessant sein, wenn eine anwendungsorientierte Lösung per Shelly Skript gewünscht ist - bspw. in einem Wohnmobil/Wohnw agen. Ich habe im WD statt des dort eingebauten Sensors einen externen BLU H&T Sensor konfiguriert, was aber hier unwesentlich ist. (Nein, mit G3 ist kein Gewehr gemeint. )

Firmware Version auf dem G3: 1.6.2

Ziel

Eine skalierbare Anwendung, ausschließlich per Shelly Skript - also ohne Cloud und ohne die Notwendigkeit eines übergeordneten Systems. Die Skalierbarkeit bezieht sich auf die Verarbeitung von vielen Messwerten per Skript, nicht nur zweien.

Bei meinen Versuchen habe ich folgende Schwierigkeiten erlebt und etwas aufwändige Lösungen kreiert - vielleicht kann das jemand besser, aber bitte keine Cloud Szenen.

1. Da im WD keine Skripte möglich sind, bleiben Aktionen.
2. Im WD lässt sich keine Aktion dazu bringen, einen aktuellen Messwert zu verwenden, wie in anderen Shelly per $value.
3. Vermutlich lässt sich ein komplexer URL zusammenstellen, welcher den G3 per RPC dazu bringt, einen Messwert vom WD abzuholen - Methode "temperature.getstatus" bzw. "humidity.getstatus". Gründe dagegen s.u.
4. Ich erstelle zu jedem Messwert eine Aktion, in welchem URL die RPC Methode "script.eval" auf dem G3 genutzt wird.
5. Der Parameter zu 4. ist ein Objekt, dessen Struktur ich kreierte. Das G3 Skript und die Objektstruktur müssen zueinander passen.
6. Das G3 Skript (s.u.) fragt nicht unmittelbar nach Erhalt des RPC Aufrufs die Werte vom WD ab, sondern speichert das Objekt (als String) zwischen. Dies bevorzuge ich, damit das Skript nicht wegen zu vieler Methodenaufrufe abgebrochen wird. Hierzu ist irgendein Zeitmanagement erforderlich. Nach meiner Erfahrung kann Ausnahmebehandlung (try, catch) einen solchen Abbruch gegenwärtig nicht verhindern.

Zu 3. Ein Skriptloser, komplexer URL täte unmittelbar auf dem G3 den Messwert vom WD holen. Wie auch in 6. bereits dargelegt, kann dies zu Fehlern wegen zu vieler RPC Aufrufe führen, wenn es auch keinen Skriptabbruch deswegen gäbe. Zusätzlich wäre ohne Skript der Spielraum für Verarbeitungsprozesse und die Usability stark eingeschränkt.

Das folgende Skript ist etwas speziell, lässt sich aber für andere Zwecke relativ leicht anpassen.

// created by eiche, 2025-05-26

// This script, running on a Shelly generation 3 or higher, sends MQTT messages with data from all BTHome sensor values of a BTHome device.
// This happens immediately after the script receives a status message from a BTHome device. Nothing further needs to be done.
// The function bths() requires a composition of sensor name and optional unit in the component name.
// Sensor name and unit must be separated by a separator containing the variable Sep, e.g. a colon.

// In function bths you may do something else with the sensor data, e.g. use the "HTTP.Get" method with an URL.
// But that method can be in an action and does not need a script.
// Have fun with it anyway!

//Additionally, puschRPC() stores incoming messages to process them at specific times.

// A small configuration
let
  Topic = "versuch/bthome", // the MQTT topic
  Sep = ':', // the seperator symbol - it may be a string instead of one character
  Dt = 2000, // delay milliseconds before each call of function next
  Max = 10; // maximum of RPC entries
// end of configuration

let RPC = [], Th = null;

function next() { // process next queued message
  if(RPC.length===0) {Timer.clear(Th); return;}
  let msg = RPC.pop();
  //print(msg);
  msg = JSON.parse(msg);
  Shelly.call("http.get", {url:"http://"+msg.target+"/rpc/"+msg.method+(msg.param===undefined?"":msg.param)},
    function(res, errc, errm, msg) {
      if(errc) {console.log("next", errc, errm); return;}
      //print(res.body);
      let val = JSON.parse(res.body.split('"'+msg.comp+'":')[1]);
      let nu = msg.name.split(Sep);
      print(nu[0], val, (nu[1]===undefined?"":nu[1]));
    }, msg
  );
}

function pushRPC(msg) { // stores msg in a queue named RPC
  if(msg===undefined || msg===null || msg.target===undefined || msg.method===undefined) {
    console.log("push() invalid parameter:", msg);
    return;
  }
  //print(JSON.stringify(msg));
  msg = JSON.stringify(msg);
  if(RPC.length>=Max) {console.log("RPC.push overfow"); return;}
  let i = RPC.indexOf(msg);
  if(i<0) RPC.push(msg) else RPC[i] = msg; // place the newest message into RPC
}

function procRPC() { // start processing the queued messages
  Th = Timer.set(Dt, true, next);
}

// Get BTHome sensor data an send those via MQTT.
function bths(id) {
  //print(id);
  Shelly.call("bthomesensor.getstatus", {id:id}, function(res, errc, errm) {
    if(errc) {console.log(errc, errm); return;}
    //print(JSON.stringify(res));
    let Sensor = {id:res.id, value:res.value, ts:res.last_updated_ts, name:"", unit:""};
      Shelly.call("bthomesensor.getconfig", {id:id}, function(res, errc, errm, s) {
      if(errc) {console.log(errc, errm); return;}
      //print(JSON.stringify(res));
      let n = res.name.split(Sep);
      s.name = n[0];
      if(n.length>1) s.unit = n[1];
      let p = JSON.stringify(s);
      //print(p);
      MQTT.publish(Topic, p); // or do something else with object s respective Sensor
    }, Sensor);
  });
}

function bthStatus(st) {
  if(st.name!=="bthomedevice") return;
  //print(JSON.stringify(st));
  Shelly.call("BTHomeDevice.GetKnownObjects", {id:st.id}, function(res, errc, errm) {
    if(errc) {console.log(errc, errm); return;}
    //print(JSON.stringify(res));
    for(let i=res.objects.length-1; i>=0; --i) {
      //print(res.objects[i].component);
      if(res.objects[i].component!==null) bths(res.objects[i].component.split(':')[1]);
    }
    procRPC();
  });
}

Shelly.addStatusHandler(bthStatus);

Dieses Skript verarbeitet die Messdaten vom selben BLU H&T wie das WD, es können aber auch ganz andere Sensoren sein. Ich habe derzeit nur ein BLU H&T.

Das Zeitmanagement zur Verarbeitung der vom WD eintreffenden RPC Nachrichten unterliegt den Statusmitteilungen (an den Statushandler), die nach eintreffen der BLU H&T Nachrichten dem Skript mitgeteilt werden. Diese kommen nicht ganz regelmäßig, aber verlässlich ca. minütlich an. Mit deren Eintreffen wird per procRPC() ein periodisch arbeitender Timer gestartet, der bspw. jeweils um 2s versetzt rückwärts die in der Queue (RPC) als nächstes gespeicherte Nachricht verarbeitet, hier die Messdaten des WD abfragen. Die in der Queue gespeicherten RPC Nachrichten können aber von beliebigen anderen Geräten kommen. Trotz dieses vorsichtigen Zeitmanagements kommt es mitunter vor, wenn auch eher selten, dass sich ein timeout bei der Abfrage des WD ereignet. Dies erscheint mir aber wenig störend, weil ca. 1 Minute später ein neuer Wert i.d.R erfolgreich geholt wird.

Die in next() berücksichtigte Komponente msg.param ist für parametrierte RPC vorgesehen, aber bisher nicht genutzt und nicht getestet.

Ich arbeite an einer noch flexibleren Lösung, die sich auf mindestens zwei Schedule Jobs stützen wird. Diese wird ein noch verlässlicheres Zeitmanagement implementieren.

Die im WD - oder einem anderen Shelly - konfigurierten Aktionen benötigen folgende Struktur.
Zunächst für die Luftfeuchtigkeit:

http://<IP Adr. G3>/rpc/script.eval?id=1&code="pushRPC({target:'<IP Adr. WD>',method:'humidity.getstatus',comp:'rh',name:'Luftfeuchtigkeit:%'})"

Der name Wert 'Luftfeuchtigkeit:%' ist, wie bereits an anderer Stelle erläutert eine Zusammensetzung aus Name und Einheit und kann selbstverständlich frei gewählt werden, bis auf den trennenden Doppelpunkt. Der id Wert 1 bezieht sich auf die Skript Id und muss ggf. einen anderen Wert haben.

Nun zur Temperatur, entsprechend zur Luftfeuchtigkeit:

http://<IP Adr. G3>/rpc/script.eval?id=1&code="pushRPC({target:'<IP Adr. WD>',method:'temperature.getstatus',comp:'tC',name:'Temperatur:°C'})"

Falls Interesse daran besteht, auch an spezifischen Anpassungen, oder es Fragen dazu gibt, bin ich gerne zur Mitarbeit bereit. Diese kann allerdings durch meine reduzierte Ausstattung begrenzt sein.

Edit:

Da gab es noch etwas offenbar unschädlichen Müll im Skript Zeile 25 (List = [];). Diesen habe ich entfernt.

Ich versuche, solche Skripte möglichst kurz und leichter verständlich zu halten. Bei komplexeren Skripten kommen oft komplexere Datenstrukturen zum Einsatz, um den Code kurz zu halten. Objektorientierung wird von mir zwar beherrscht, aber nicht angestrebt.

Zitat von borsti0

Du musst dir hier eine >2kW-Hysterese einbauen?!?

Dieser Einwand ist berechtigt. Somit sollte bspw. erst mit negativer Einspeisung abgeschaltet werden. Zusätzlich kann eine Mindesteinschaltdauer genutzt werden. Für Letzteres ist eine Rückmeldung per Aktion an den Pro 3EM erforderlich und damit ein Skript auf dem Pro 3EM zumindest naheliegend.

Mit einer Leistungssteuerung kann diese Funktionalität noch intelligenter gemacht werden, was experimentieren erfordert.

Hast du es mal mit einer lokalen Aktion statt eine Cloud Szene versucht? Das ist eh unmittelbarer und nicht auf die Cloud angewiesen.

Ich habe keinen BLU motion und kann es nicht testen. Mit zwei anderen BLU Geräten (H&T, Door/Window) habe ich experimentiert und dazu ein Skript erstellt, welches die Sensor Informationen via MQTT weiterreicht. Statt senden einer solchen MQTT Nachricht kann man leicht den lokalen Ausgang schalten.

Hier ist das Skript zu finden: BLU Daten per Shelly Gen 3 und MQTT senden - ohne oder mit Skript
unter #22

Zitat von VScheli

Bei mir war es der W-lan Empfang in der Scheune ,wo ja nun mal meine Hühner wohnen.

Das ist insofern verwunderlich, als der Uni eine kurze Stabantenne hat, deren Leitung auch verlängerbar ist.

Tja, wenn du eine Automatik erreichen willst, sind die von mir nachgefragten Informationen erforderlich.

Du kannst aber (unverbindlich) risikofrei experimentieren und Antworten finden.

1. Nimm dazu einen Schalter und schließe diesen zwischen Di1 und COM an! Nun solltest du den FU mit diesem Schalter ein- und ausschalten können. Gelingt dies? Wenn ja, lässt sich der FU mit einem potentialfreien Ausgang eines Shelly ein- und ausschalten.
2. Brücke Di4 mit COM! Je nach Klemmen gelingt dies mit einem Stück Leitungsdraht oder mit zwei Krokodilklemmen an den Enden eines Stück Leitungsdrahtes. Nun sollte bei eingeschaltetem FU die Pumpe mit niedriger Drehfrequenz (1200rpm) laufen.
3. Brücke zusätzlich Di2 mit COM! Erhöht sich nun die Drehfrequenz auf 2900rpm? Der Unterschied sollte hörbar sein. Wenn ja, lässt sich auf diese einfache Weise mit einem potentialfreien Ausgang eines Shelly die Drehfrequenz zwischen zwei Werten umschalten.

Wenn dies alles gelingt, lassen sich auch Zeitpläne der Shelly nutzen, evtl. flexibler als solche des FU. Eine Einstellung der Drehfrequenz in 50er Schritten wäre vielleicht über die RS485 Schnittstelle möglich, soweit ich verstand, brauchst du das aber nicht.

DonKill

Ich beschreibe nun etwas, das funktionieren sollte. Vermutlich gelingt dies alles statt mit mehreren Shelly mit deinem Pro 4PM. Interpretiere somit bitte jeden der von mir aufgeführten Shelly ggf. als Teil deines Pro 4PM! Alle Shelly an Dauerphase.

1. Gerät: Einen messenden (nicht schaltenden) Shelly vor den Schalter der Pumpe setzen. Dieser misst die Stromaufnahme der Pumpe und erkennt so, ob diese ein- oder ausgeschaltet ist. Falls du die Pumpe ausschließlich via Pro 4PM schaltest, ist der Schaltzustand abfragbar/bekannt.
2. Gerät: Einen schaltenden Shelly vor die Salzanlage setzen.
3. Zeitpläne wie gehabt.

Alleine den Zeitplan zu Gerät 2 abhängig vom Schaltzustand der Pumpe zu enablen/disablen ist suboptimal, weil die Pumpe auch bei eingeschalteter Salzanlage ausgeschaltet werden kann. Deshalb sollte mit dem Ausschalten der Pumpe die Salzanlage zusätzlich ausgeschaltet werden. Hierfür sind folgende Aktionen auf Gerät 1 erforderlich.

1. Bei Einschalten bzw. Leistungsschwellenüberschreitung
   1. gibt den Zeitplan von Gerät 2 frei,
   2. Option: schaltet Salzanlage über Gerät 2 bedingt ein.
      Hierfür ist ein Skript erforderlich, welches die Einschaltdauer der Salzanlage eines Tages erfasst und nur einschaltet, wenn die vorgesehene Einschaltdauer noch nicht erreicht ist bzw. bei deren erreichen ausschaltet. Mit zusätzlichem Zeitplan wird der Zeitzähler um bspw. 00:00 Uhr rückgesetzt.
2. Bei Ausschalten bzw. Leistungsschwellenunterschreitung
   1. sperrt den Zeitplan von Gerät 2 und
   2. schaltet Salzanlage über Gerät 2 aus.

Meine Antwort dauerte, weil ich auch nachdenken musste.

Womit schaltest du die Pumpe dann aus? Per Shelly, per manuellem Schalter, ...?

Wo sitzt das schaltende Teil in deiner Anlage?

Na endlich mal diese Aussage. Darauf wartete ich schon fast seit Beginn dieses Thread.

Mir gefällt diese Anregung des Vergießens.

Ich habe eine Füllstandsmessung per Ultraschall und einem ESP32 Board mit Tasmota in einer Box mit Silikon versucht abzudichten. Die Box liegt über dem Wasserspiegel in meiner Zisterne. Verschraubungsabdichtungen passen wegen verschiedener, auch dünner Leitungen nicht.

Ergebnis: Nach ca. 1/2 Jahr versagte die Elektronik wegen Feuchtigkeit in der Box.

Ich sollte das Vergießen mit Gel einmal versuchen.

Frage: Wird das Gel nur an/in der Leitungsdurchführung angebracht oder die ganze Dose damit gefüllt?

Rookimike

Du hast es bisher nicht erwähnt. Trotzdem könnte es sein, dass du irgendwann beabsichtigst, das Tor per Sprachbefehl (Alexa und Konsorten) steuern zu wollen. In einem solchen Fall ist der Plus Uni suboptimal.

Diese Eindeutigkeit ist trivial, die möglichen Gründe sind es nicht.

Zitat von eiche

Ich interpretiere, dass auch ein Überlastungsschutz die Pumpe ausschalten könnte

Do replace "duration" with "toggle_after"! The unit is second, not millisecond.

https://shelly-api-docs.shelly.cloud/gen2/Component…witch#switchset

Du tust so, als ob es nur einphasigen Wechselstrom gäbe. Denke bitte an alle drei Phasen und stelle diese auch in deiner Skizze dar!

Das ist die Installations- und Bedienungsanleitung deiner Zusatzheizung. Damit weiß ich noch immer nicht genau, wie du in diese schaltungstechnisch eingreifen und steuern willst. Offenbar wird diese Heizung mit drei Phasen betrieben. Wenn du Elektroinstallateur gelernt hast, solltest du in der Lage sein, einen Schaltplan zu skizzieren - Bleistiftskizze abfotografiert täte genügen. Vollständig, mit allen von dir bisher vorgesehenen Komponenten und Daten.

Das kann doch nicht so schwierig sein.

Zitat von DonKill

wenn aber die poolpumpe (aus welchen gründen auch immer) abgeschaltet ist, soll sich die salzanlage dann um 14 uhr nicht einschalten

Was soll "aus welchen Gründen auch immer" bedeuten?

Ich interpretiere, dass auch ein Überlastungsschutz die Pumpe ausschalten könnte. Wenn dies eingeschlossen sein soll, genügt eine Lösung mit bisher vorhandenen Shelly vermutlich nicht.