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
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.
Kann damit jemand etwas anfangen?
Klar doch. Die für deinen Zweck entscheidenden Komponenten sind
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.
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.
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.
Startseite > Skriptdatenbank > Dynamic Load Shedding Script for Energy Managemen
Ich finde das Skript nicht und bitte um genauere Ortsangaben.
Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.
Das ist überhaupt nicht zweckdienlich. Was hast du da entfernt?
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.getstatusDie 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.
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.
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
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.
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.
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.
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.
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?
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.
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!
