Beiträge von eiche

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.

DonKill

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.

Zitat von stoppeljody

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);

Charly63

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:

1. Wie/womit wird Di1 angesteuert?
2. Mit welcher Drehfrequenz läuft die Pumpe, wenn alle Di2 bis Di4 oder zumindest Di2 und Di4 mit COM verbunden werden?
3. Wozu dient der ANALOG EINGANG? Nutzt du diesen?

Zitat von Tom-DD

Er kann die Wasserpumpe deaktivieren, um das System mit offenen Wasserhähnen leerlaufen zu lassen.

Ich sehe in den Aktionen ausschließlich Lichtsteuerung.

Charly63

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.

1. Es braucht einen Sensor, der feststellt, dass die Poolconsulting "gestartet" bzw. "beendet" wurde. Dazu ist vielleicht ein in die Versorgung der Poolconsulting geschalteter Shelly PM ohne Schaltausgang geeignet. Dieser meldet das Starten/Beenden an andere Geräte, insbesondere den Shelly, welcher die FU einschaltet bzw. steuert. Falls die Poolconsulting einen Signalausgang besitzt, über den andere Geräte informiert werden können, braucht es diesen Shelly voraussichtlich nicht.
2. Ein Shelly schaltet die FU ein/aus. Für den Fall, dass der FU bei offenen D1 bis D3 Eingängen die Pumpe nicht einschaltet, kann die FU auch über diese Eingänge geschaltet werden, allerdings ist dazu eine Mikrocontrollerschaltung mit mindestens drei binären Ausgängen, zwei Shelly oder ein Shelly mit digitalem Demultiplexer erforderlich. Wenn du Letzteres nicht nutzen willst/kannst, bleibt eine dbzgl. Schaltung mit zwei Shelly, wovon mindestens einer über zwei potentialfreie Ausgänge verfügen muss, bspw. zwei Shelly Plus Uni. Diese beiden müssen dann fehlerfrei kommunizieren. Zwecks erhöhter Sicherheit können beide Uni kaskadiert werden, soll heißen, der erste Uni steuert den zweiten redundant mit einem Freigabesignal. Allerdings erfordert solches einen zusätzlichen Shelly in 3 (s.u.). Falls du nur zwischen zwei statt drei Drehfrequenzen umschalten willst, dürfte dies mit einem Plus Uni realisierbar sein. Dabei bliebe einer der digitalen FU Eingänge offen.
3. Ein weiterer Shelly muss die Spannung (offen vs. 24V) des Bypass-Ventils abgreifen und den Status an die FU Shelly übermitteln. Hierfür kann vermutlich auch einer der beiden in 2 erwähnten Uni genutzt werden. Letztlich hängt dies von der gesamten bisherigen Schaltung und deren Potentiale/Spannungen ab. Es ist aber stark zu vermuten, dass dies gelingt.
4. Zur beabsichtigten Steuerung wird zumindest ein Skript erforderlich sein, mit welchem die anderen Shelly kommunizieren müssen.

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

1. Welche Signalausgänge besitzt die Poolconsulting? Damit sind keine Schaltausgänge wie bspw. zum schalten des Bypass Ventils gemeint.
2. Läuft die Pumpe am FU, wenn alle drei Digitaleingänge D1 bis D3 Di2 bis Di4 offen sind, also nicht mit COM verbunden?

Tom-DD Wenn du schon deine Realisierung "anpreist", könntest du auch Einzelheiten dieser uns zukommen lassen.

Zitat von Tom-DD

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.

Zitat von raidboy

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.

Zitat von raidboy

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.

Zitat von raidboy

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.

Zitat von raidboy

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.

raidboy

Nur mal beispielhaft einer deiner Bemerkungen:

Zitat von raidboy

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.

Zitat

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.

Zitat von gisi9617

als sich der shelly heute morgen eingeschaltet hat

Die Formulierung gefällt mir nicht.

1. Das Einschalten ist vermutlich ein Reboot - Methode Shelly.Reboot.
2. Wenn ein Shelly "sich" selbst "einschaltet" - eigentlich ein Reboot, dann gelingt dies allenfalls per Schedule Job (Zeitplan), Aktion oder Skript.
3. Da keine Zeitpläne vorliegen und wohl auch keine Aktion oder Skript, bleibt ein RPC Aufruf mit Shelly.Reboot von einem anderen Gerät.
4. Die uptime in deiner obigen Shelly.GetStatus Antwort ist mit 47min 43s relativ kurz, was auf ein reboot hindeutet.

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.

gisi9617

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 ...

1. Du hast dir etwas Funktionales bestens ausgedacht.
2. Du hast es bestens beschrieben.
3. Du bist offen für Verbesserungen.

Auch wenn du nicht danach fragst. Ich gebe dir 5 Sterne. Weiter so!

Ehrlich gesagt, habe ich bald keine Lust mehr. Warum?

Ich stelle schlichte Fragen und du ignorierst diese in allen deinen späteren Beiträgen.

Hier stelle ich sie noch einmal:

Wie wird diese Elektroheizung betrieben? An einem, zwei oder drei Außenleiter (Phase)? Darf sie partiell (ein- oder zweiphasig) geschaltet werden?

Von dieser Beantwortung hängt es ab, womit du dein(e) Schütz(e) ansteuern kannst. Wenn du drei Außenleiter schalten willst, brauchst du ein bis drei Geräte.

Beim Einsatz eines Gerätes muss dieses

1. potentialfrei schalten können und
2. hinreichend eine Spannung zwischen den Außenleitern isolieren.

Vorteil: Es ist nur eine Konfiguration und ggf. ein Skript erforderlich.

Beim Einsatz von drei Geräten an drei Außenleitern können diese irgendwie schalten, auch nicht potentialfrei.

Nachteil: Es ist mehr Kommunikation und mehr Konfiguration, evtl. drei Skripte.

scheuerer

Es gibt hierzu nichts flexibleres als Node-RED, auch als Ergänzung zu openHAB. Ich täte mit einem Node-RED Flow und MQTT experimentieren.

Zu jedem betroffenen Shelly dessen MQTT LWT ("<pretopic>/online)" abonnieren.

1. Bei payload = false ist der Shelly nicht erreichbar, vermutlich wegen Stromausfall/abklemmen. -> Flow Variable "<Shelly Name>_online" auf false setzen.
2. Bei payload = true Flow Variable "<Shelly Name>_online" abfragen. Bei false -> Variable auf true setzen und etwas passendes für openHAB senden.

Klar, das ist ein Workaround, kann aber weiterhin als redundante Sicherheit genutzt werden.

Wenn dir das zu aufwändig ist, wirst du nie Fehler/Schwächen, die von anderer Seite kommen, ausgleichen können. So what? Dann lebe mit deiner Abhängigkeit! In aller Freundschaft.