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.
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.
Solange du keine präzisen Auskünfte über deine Heizung und deine beabsichtigte Steuerung derselben erteilst, ist das Erstellen eines Skripts wenig sinnreich. Ich jedenfalls sehe mich dazu bei deinen lückenhaften Informationen nicht in der Lage, obwohl ich schon viele Skripte geschrieben habe.
Teile uns doch bitte mal mit, welche Shelly du im Einsatz hast!
Was du willst, gelingt zunächst mit Aktionen, falls deine Shelly ab Generation 2 sind.
Eine größere Sicherheit gibt es, wenn du in die Stromversorgung der Pumpe einen messenden Shelly (PM) legst. Diese kann den Schaltzustand der Pumpe erfassen und bspw. den Zeitplan des Salzanlagen Shelly deaktivieren/aktivieren. Mit Skript gibt es weitergehende Möglichkeiten, wenn Bedarf besteht.
Zwecks Sicherheit kann ich Cloud basierte Szenen wenig empfehlen.
Ich habe nicht annähernd so viele verschiedene Shelly Geräte wie viele hier, weshalb ich nur einen theoretischen Tipp geben kann.
Ich täte diese Phasenanschnittsteuerung mit einem Shelly Plus 0-10V Dimmer steuern. Dieser sollte passende Nachrichten vom Plus 3EM erhalten.
Für einen ggf. beabsichtigten Hub kann bei Bedarf ein Spannungsteiler am Ausgang dieses Shelly eingesetzt werden.
12kW / 3 (Phasen) = 4 kW -> mit (wassergekühltem 
) Kühlkörper kann es knapp gelingen.
Auf dem Pro 3EM brauchst du ein Skript, welches über die drei Phasen saldiert, wenn du nicht phasenselektiv die Heizung schaltest.
Mit phasenselektiv meine ich folgendes.
Wenn der Pro 3EM auf Phase A mehr als bspw. 2kW ausgehend misst, wird Phase A zur Heizung geschaltet. Entsprechend für die anderen Phasen.
Vor der E- Heizng habe ich etwas
eingebaut, damit ich die Leistung regeln kann.
Was ist das?
Das geht nicht. Mit | meinst du sicher das I für Input. Demgegenüber ist das O für Output. Beide sind die Relaiskontakte und können in Gedanken auch vertauscht werden, da sie potentialfrei sind.
Du wirst I per Leitung mit L verbinden müssen.
Thomas war schneller.
Nach weiteren Experimenten habe ich einen naheliegenden und auf einfache Weise funktionierenden Weg gefunden, BLU Daten unmittelbar nach deren Eintreffen zu verarbeiten. Das folgende Skript sendet diese Daten als MQTT Nachricht weiter. Es kann leicht für andere funktionale Aufgaben angepasst werden. Darin ist nach wie vor die Funktion bths() zuständig.
Zu diesem Skript sind weder anzulegende Aktionen noch ein Schedule Job erforderlich.
Meine Idee, die Einheit im Sensornamen unterzubringen nutze ich weiterhin. Stattdessen kann man die Object Id Tabelle in der BTHome Dokumentation im Skript einbauen und jeweils nach der importierten Komponente obj_id darin suchen lassen. Mir missfällt eine solche Sucherei, weshalb ich einen anderen Weg verwende. Für ein sofort einsetzbares Skript ohne zusätzliche bthomesensor Benamung - diese ist immerhin anwendungsorientiert - mag die Tabelle vorteilhaft sein.
Das Skript
Man entschuldige bitte die vielen auskommentierten print Ausgaben. Sie dienen während des Experimentierens der Kontrolle und können entfernt werden.
// created by eiche, 2025-05-24
// 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!
// A small configuration
let
Topic = "versuch/bthome", // the MQTT topic
Sep = ':'; // the seperator symbol - it may be a string instead of one character
// end of configuration
// 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]);
}
});
}
Shelly.addStatusHandler(bthStatus);Ich habe noch einmal bzgl. der FU Steuerung nachgesehen - ich war zuvor noch nicht sorgfältig genug. Da gibt es zwecks Steuerung Di1 bis Di4.
Du schreibst wiederholt von 2100[rpm]. Vermutlich meinst du 1200rpm, weil in der FU Anleitung 2100rpm nicht auftaucht.
Di1 mit On/off beschriftet
Di2 bis Di4 zur Drehfrequenz Selektion
Deshalb meine korrigierten Fragen:
Er kann die Wasserpumpe deaktivieren, um das System mit offenen Wasserhähnen leerlaufen zu lassen.
Ich sehe in den Aktionen ausschließlich Lichtsteuerung.
Gute Beschreibung, auch wenn du meine Frage zu ggf. vorhandenen Prioritäten der digitalen Eingänge des FU noch nicht beantwortet hast. Ich kenne deine "Poolconsulting" nicht und werde deren Handbuch auch nicht suchen und studieren. Offenbar besitzt diese keine Ausgänge, über welche Signale an optionale Erweiterungen gelangen können, oder? Ich setzte nun solches voraus.
Fazit
Mit einem Shelly PM ohne Schaltausgang und ein/zwei Shelly Plus Uni an 24V Gleichspannung wird dein Projekt realisierbar - evtl. braucht es noch einen weiteren Shelly, der den FU schaltet, falls dies nicht mit den Eingängen D1 bis D3 gelingt. Ohne Skript wird es voraussichtlich scheitern.
Offene Fragen
Tom-DD Wenn du schon deine Realisierung "anpreist", könntest du auch Einzelheiten dieser uns zukommen lassen.
Wie ich gesehen habe, gibt es jedoch kein normales Shelly, welches seine eigene 12V Versorgungsspannung messen kann. Oder?
Mit einem Add-On an einem Shelly, der auch mit 12V betreibbar ist, gelingt dieses - zumindest unter Verwendung eines Spannungsteilers.
Einfach in der GUI eine textuelle Darstellung der kompletten config, die nicht auf factory-default werten steht
Hierfür steht der RPC Aufruf Shelly.GetConfig zur Verfügung, dessen Nutzung mit ausführlichen Informationen beantwortet wird. Diese können in modernen Web Browsern übersichtlich umbrochen werden. Mehr Menüpunkte im WebUI macht diese Oberfläche nicht pflegeleichter sondern unübersichtlicher und zusätzlich würde mehr Speicher verbraucht, sowohl Flash als auch RAM. Es fehlt ja im Vergleich zu proprietären Systemen kaum an Offenlegung und Transparenz.
Da würde man ja sofort sehen, ob die config unerwartet factory-default ist.
Vielleicht, vielleicht auch nicht, je nach Leser. So etwas hilft keinem DAU. Wer die Shelly.GetConfig Antwort nicht verstehend lesen kann, sollte sich entweder professionelle Hilfe kaufen oder gleich zu bevormundenden, proprietären Systemen greifen, die nicht annähernd an die kreativen Möglichkeiten der Shelly Produkte heranreichen.
Ich hoffe/nehme an, das da ja zumindestens schon eine checksum fuer das config flash gibt, wüßte aber nicht, das es eine diagnose gibt, ob die ok. ist.
Da dies nicht offengelegt ist, dürfte dies niemand aus der Community wissen. Jedenfalls findet afaik zu jedem RPC Aufruf eine Syntaxprüfung statt. Meine Experimente ergaben solches immer wieder.
Bei den Preisen, die Shelly inzwischen abverlangt muessen solche Softwarefeatures, die helfen Installations/Wartungsarbeiten zu minimieren IMHO schon Priorität haben.
Ein Shelly 1 Gen 4 ist relativ wenig kostspieliger als einer der Generation 1, verfügt aber über erheblich mehr Ressourcen und ist erheblich flexibler nutzbar. Zudem wird die Firmware ständig weiterentwickelt mit dem Ziel, weitere Nutzungsmöglichkeiten zur Verfügung zu stellen. Diese Shelly Geräte sind imho für mehr oder weniger kreative Nutzer konzipiert und passten zumindest nicht bisher auf den reinen Konsumentenmarkt, auch wenn das Ziel verfolgt wird, Shelly auch dort zu platzieren.
Die Usability der Shelly Firmware ist der von Tasmota weit überlegen, was zumindest mich zu Shelly treibt. Tasmota ist erheblich mehr etwas für Nerds und auch vielseitiger nutzbar, wenn der Anwender dies kann.
Nur mal beispielhaft einer deiner Bemerkungen:
So schwierig kann das doch nicht sein, selbst Diagnose zu machen um zu schauen, ob das Flash funktioniert, oder ?
Solltest du Kenntnisse zu digitalen Halbleiterschaltungen haben, dann solltest du wissen, dass dein Wunsch zwar realisierbar ist, dies aber erheblichen Mehraufwand und entweder zusätzliche Elektronik oder zusätzlichen Softwareaufwand erfordert -> deutliche Kostensteigerung.
Solltest du solche Kenntnisse nicht haben, darfst du gerne solche Behauptungen am Stammtisch äußern. In aller Freundschaft
Ansonsten ist thgoebel hier der beste Ansprechpartner für Hardwareprobleme.
Zum Aktivieren der externen Geschwindigkeitssteuerung mit Hilfe von Digital-Eingang, einen der entsprechenden Eingänge zu Di2/3/4 zu Klammer COM verbinden.
Dies deutet darauf hin, ohne eindeutig zu sein, dass nur einer dieser 3 digitalen Eingänge mit COM verbunden werden darf. Du solltest selbst herausfinden, ob auch mehrere gleichzeitig mit COM verbunden werden dürfen und welche Prioritäten dann vorliegen. Dies erleichtert ggf. die Ansteuerung.
Was ich bisher zu verstehen glaube.
Der Frequenzumrichter (FU) betreibt die Pumpe?
Dann ist der FU dafür zuständig, mit welcher Drehfrequenz die Pumpe läuft?
Wenn das stimmt, dann solltest du uns mal schnell darüber aufklären, ob und wie der FU angesteuert werden kann, um die Pumpen Drehfrequenz zu manipulieren. Dann müssen wir nicht suchen.
Falls der FU ausschließlich über dessen Panel gesteuert werden kann, sehe ich damit keine Möglichkeit der externen Einflussnahme.
Über Di2, Di3, Di4 sollte das gelingen, wenn deine Standard Drehfrequenz unter 2900rpm liegt.
als sich der shelly heute morgen eingeschaltet hat
Die Formulierung gefällt mir nicht.
Zu 3. Wenn das Reboot per MQTT Nachricht von einem anderen Shelly ausgelöst wurde, sollte dieser ermittelbar sein, da die Shelly Firmware in seinen MQTT Nachrichten die Quelle beinhaltet. Mit einem "Detektiv" auf die Lauer legen und alle MQTT Nachrichten mit der Methode Shelly.Reboot in der Payload protokollieren - oder Topic spezifisch zum betreffenden Shelly passend.
Btw, wenn der Shelly rebootet, meldet er sich auch beim MQTT Broker. Wenn dort eine retained Nachricht für den Shelly vorliegt, erhält der Shelly diese. Dies bezieht sich auf meinen Beitrag in #11.
Wenn etwas nicht per Szene (Cloud) und auch nicht per Aktion gelingt, gelingt es nicht selten per Skript.
Ich nutze kein ioBroker, kann deshalb nur etwas zu MQTT sagen.
Rat: Lösche, wenn möglich, die Nachrichten Datenbank deines MQTT Broker.
Grund: Bei sog. Phantom Schaltvorgängen (Nachrichten), auch von Tasmota bekannt, steckt zumeist eine retained Nachricht dahinter. Da du vermutlich nicht weißt welche dafür in Frage kommt, bleibt nur der "Vorschlaghammer" des Löschens der Broker Nachrichten Datenbank.
Zur Spurensuche kann auch bspw. der MQTT Explorer genutzt werden. Noch zielgerichteter gelingt so etwas mit einem Node-RED Flow und Speicherung. Vielleicht bietet ioBroker auch so etwas.
Hinweis zum Löschen einer MQTT retained Nachricht:
Mit dem gleichen Topic und einer leeren Payload wird eine vorherige retained Nachricht gezielt gelöscht.
Puschelelch Ich finde ...
Auch wenn du nicht danach fragst. Ich gebe dir 5 Sterne. Weiter so! 
