Shelly 1PM Regelung Zirkulationspumpe

ich bin kein Shelly Profi, aber wenn ich mir das Schaltbild anschaue,

dann würde ich das auch so machen.

Hier findet man eine gute Sammlung:

Thema

Shelly - bei Wechsel-/Kreuz-/Stromstoß-Schaltung...

Hi zusammen,

gibt ja schon einige Bilder dazu, hab es mal versucht zusammenzufassen -

vielleicht hilft es dem einen oder anderen, bei Bedarf werde ich auch ergänzen



Shelly bei vorhandener Installation...

• Shelly 1 - Ein-Aus-/Wechsel-Schaltung

BUTTON TYPE: Edge Switch

Tasmota : SwitchMode1 0

• Shelly 1 - Kreuz-Schaltung

BUTTON TYPE: Edge Switch

Tasmota : SwitchMode1 0

• Shelly 1 - Taster-/Stromstoß-Schaltung

BUTTON TYPE: Momentary

Tasmota : SwitchMode1 4

• Shelly 2 - Serien-/Doppel-Schaltung

BUTTON…

NoitaercX

4. November 2018 um 17:33

Mein Stand:

1. Die Schaltung von Crusher606 ist eine Shelly 1 und kann keine Leistung messen

2. Wenn die Innenschaltung des Shelly 1 PM klar ist (X1-Messwandler in der Zeichnung ) dann ist deine Schaltung ok mit Messung.

3.) Die Pumpe von der Kesselsteuerung zu trennen birgt die Gefahr einer Kesselüberhitzung. Es gibt elektronische Pumpen welche wenig Leistung verbrauchen wenn die Strömungstemperatur es ermöglicht. Stichwort - Drehzahlgeregelte Pumpe

Eine drehzahlgeregelte Pumpe passt die Pumpenkennlinie automatisch an den Betriebspunkt der Heizungsanlage an. Durch die Veränderung der Drehzahl werden somit die Förderhöhe und der Volumenstrom entweder manuell oder automatisch auf die jeweils aktuelle Situation angepasst. Dies hat den Vorteil, dass die Leistung der Pumpe auf ein Minimum angepasst und der Stromverbrauch somit erheblich reduziert werden kann.

4.) Wenn man aber selbst die Steuerung ausprägen will gibt es nur den Weg über XT ein Tasmota auf den Shelly aufzuspielen und mit Rule oder Script die Steuerung aufzubauen. An XT kann an die Leitungen RX und TX jeweils ein Temperaturfühler für Vor-/Rücklauf integriert werden um die Shelly-Steuerung zu stützen (Achtung - XT-Leitungen haben Netzpotential).

Ist damit eigentlich eine Zirkulationspumpe gemeint, die das Warm-Brauchwasser ab und zu zirkulieren lässt, oder ist hier die Heizungspumpe gemeint, die das Heizwasser durch die Heizkörper zirkuliert?

Als Heizungspumpe habe ich auch so eine moderne elektronische drehzahlgeregelte Vorlaufpumpe und kann sie empfehlen. (Vorlauftemperatur habe ich bei mir 65 Grad)

Ah - Zirkulationspumpe habe ich überlesen bei der schönen Zeichnung war ich abgelenkt

- macht echt Sinn mit dem IOT-Vorhaben für Kosten und CO₂-Einsparung.

Neben einer Standardzeitsteuerung (Mo-Fr, Sa/So ) würde jede neue Verbindung eines bekannten Handys im WLAN auch für 20 Minuten eine Auslösung provozieren?

(requires #define USE_PING - wenn Tasmota) oder welche Ideen gibt es?

Zitat von SmartHomeFu

Es soll die Möglichkeit bestehen, die Zirkulationspumpe auch über den Shelly ein- bzw. auszuschalten, wenn die Heizungsanlage die Zirkulationspumpe aktiv schaltet, und den Stromverbrauch zu messen....

Meine Erfahrung:

Ich habe die Pumpe der Warmwasser Zirkulation schon lange nicht mehr an der Heizungssteuerung dran.
Die Zirkulation findet timergesteuert zwei mal am Tag statt.
Einmal morgens, bevor alle ins Bad wollen und einmal am späten Nachmittag, wenn man von der Arbeit

oder dem Sport heimkommt und duschen will.

Eine längere oder noch öftere Zikulation würde für mich nur eine Wandheizung
über die Warmwasserrohre darstellen und unnötig Energie verschwenden.

Zitat

Einmal morgens, bevor alle ins Bad wollen und einmal am späten Nachmittag, wenn man von der Arbeit

oder dem Sport heimkommt und duschen will.

genau - späten Nachmittag und Sport mit dynamischen Zeiten - da setzt echte IOT (das Gerät ist ohne hin da und im Netz) und die echte "Grüne-Zeit" an (nicht grüne Panzer verkaufen) !

Wenn bekannte Mobiltelefone sich in das WLAN einbuchen immer auf die gleiche IP, können sie über ein Ping (alle Minute ?) im Heimnetz identifiziert werden und der Shelly kann seine Arbeit zusätzlich aufnehmen oder alternativ die Zeit auslassen weil alle im Urlaub sind.

Mit der Lösung kann auch das Rollo im Winter 45 Minuten zeitiger schließen oder später öffnen, um wertvolle Energie im Haus zu halten (wenn keiner da ist - trifft die Dunkelheit nur Hund und Katze ) .

z.B. Standard

Rule1

ON Time#Minute|1 DO backlog Ping4 192.168.178.70 ENDON

ON Ping#192.168.178.70#Success>0 DO Backlog Power1 1; einschalten ENDON

oder

'ein und aus

Rule1

ON Time#Minute|1 DO backlog Ping4 192.168.178.29 ENDON

ON Ping#192.168.178.29#Success>0 DO Backlog Power1 1; einschalten; RuleTimer1 3600 ENDON

ON Ping#192.168.178.29#Success==0 DO Backlog Power1 0; ausschalten ENDON

on Rules#Timer=1 do Backlog power1 off endon

'mal für 3 IP-Adressen im Test und aus nach 1h

Rule1

Zeile 1 -Scharfschaltung nach Neustart (evtl. nicht nutzen wenn es WLAN-Probleme gibt)

Zeile 2 - Scharfschaltung in der 16 Minute jeden Tages

Zeile 3 - Scharfschaltung in der Rule Zeiteinstellung Timer 16

Rule2

Zeile1 - wenn VAR1 einmal 1 dann Schalten und Ausschalten nach 1 Stunden

aktiv erst wieder wenn Zeilen 1,2 oder 3 Rücksetzung VAR1 auf 0 organisieren

Zeile2 - Überlauf VAR1 absichern

Rule1

on Time#Initialized do VAR1 0 endon

on Time#Minute=16 do VAR1 0 endon

on Clock#Timer=16 do VAR1 0 endon

ON Time#Minute|1 DO Ping4 192.168.178.29 ENDON

ON Ping#192.168.178.29#Success>0 DO ADD1 1 ENDON

ON Time#Minute|1 DO Ping4 192.168.178.30 ENDON

ON Ping#192.168.178.31#Success>0 DO ADD1 1 ENDON

ON Time#Minute|1 DO Ping4 192.168.178.31 ENDON

ON Ping#192.168.178.30#Success>0 DO ADD1 1 ENDON

Rule2

on var1#state==1 do Backlog Power1 on; RuleTimer1 3600 endon

on var1#state>1000 do VAR1 2 endon

on Rules#Timer=1 do Power1 off endon

PS: Anbei eine 12.1. Übersetzung von Tasmota mit Ping und Websendresponse

Da es doch schlechte Geräte-Abschirmungen (Netzbrummen) gibt bei denen Tasmota-Systeme sich nicht mehr im WLAN aktiv befinden, könnte ein aktiver automatischer Neustart etwas helfen.

1.) Variante (benötigt das Compilerrelease - z.B. von oben 12.1. mit integriertem Ping)

'Erklärungszeilen dringen entfernen

Rule3
'nicht vergessen Rule3 1 zu aktivieren 
'nach Systemstart VAR16 und virtuelle Zeit in der Vergangenheit setzen - sonst läuft nichts !!  
on System#Boot do Backlog VAR16 0; Setoption36 20; time 1587435620 endon
'jede Minute ein Ping auf ein bekanntes Ziel versuchen 
on Time#Minute|1 do Backlog time 0; ping4 192.168.188.1 endon
'wenn nicht erfolgreich Zeit in mem16 speichern 
ON Ping#?#Success==0 DO Backlog mem16 %timestamp%;__Verbindungsfehler_; ADD16 1 ENDON
'Neustart auslösen nach 5 Fehlversuchen
ON VAR16#state>5 do restart 99 endon

2.) Varitante - Standardrelease ohne Ping

Idee - ein Hilfsclient setzt eine Variable VAR16 am Zielclient jede Minute auf 0 zurück, wenn das nicht möglich ist Reboot nach 4 Minuten durch Zielclient

##Hilfsclient
Rule3
on Time#Minute|1 do websend [192.168.178.2]/cm?cmnd=VAR16%200 endon


##zu prüfender Client (192.178.188.2)
Rule3
on System#Boot do Backlog VAR16 0; Setoption36 20; time 1587435620 endon
on Time#Minute|1 do Backlog ADD16 1; time 0 endon
ON VAR16#state>3 do Backlog mem16 %timestamp%; delay 50; restart 99 endon

PS: mem16 speichert den Zeitpunkt des letzten Neustarts in beiden Varianten

das Einfrieren des Tasmota-WLAN-Systems durch Reboot auflösen.

Variante 1a - Umgebaut und geht auch mit ESP32-Standardrelease (mindestens bei 14.3.0 ESP32-C3)

(Webquery als Variante braucht RESPONSE als Compileroption und ist erst recht nicht im Standardrelease)

Wenn in der Zeiteinheit 3*1 Minute wenigstens eine Verbindung zum Gateway erfolgreich getestet wurde, erfolgt kein Reboot.

letzte Rebootzeit steht in mem2

Rule3
on system#init do Backlog VAR4 1; VAR5 1; VAR3 0; time 1587435620 endon
on time#minute|1 do Backlog time 0; Status 5 endon
on StatusNET#Gateway do Backlog VAR2 %value% endon
on VAR2#State do ping4 %VAR2% endon
on Ping#?#Success do Backlog ADD3 %value%; ADD4 1 endon
on VAR4#State>2 do Mult5 %VAR3% endon
on VAR5#State<1 do Backlog Boot; mem2 %timestamp%; Restart 1 endon
on VAR5#State>1 do Backlog O.K:; VAR4 1; VAR5 1; VAR3 0 endon

PS: Hat jemand eine bessere Lösung - speziell für ESP8266 Systeme für ein Standardrelease? ? abgesehen von der Variante !

Variante 3 - für alle ESP-Systeme (das Einfrieren des Tasmota-WLAN-Systems durch Reboot auflösen)

in der Standard-Software ist kein ping4 und kein Response aktiv, somit sind andere Lösungen zur Selbsterkennung erforderlich

die Idee - wenn der ESP sein Ziel-WLAN 5 mal (WLAN-Router) nicht mehr Scannen kann wird er neu gestartet

sleep 250 setzen um WLAN zu verbessern
mem1 = SSID eintragen auf die geprüft werden soll

mem4=5 Anzahl der Prüfungen bis Reboot

counter1 und Relay3 in der Config etablieren
mem2 erstes Reboot und mem3 letzte Reboot zum WLAN-Problemen
counter1 Anzahl Reboot zu WLAN
WebUI-Button3 Reset der WLAN-Messdaten

rule3
on system#init do Backlog VAR3 0; time 1587435620; time 0; power3 0 endon
on time#minute|1 do Backlog ADD3 1; Time 0 endon
on VAR3#state>%mem5% do Backlog counter1 +1; mem3 %timestamp%; Restart 1 endon
on counter#c1=1 do Backlog mem2 %timestamp%; counter1 +1 endon
on VAR3#State>0 do wifiscan 1 endon
on WifiScan#?#SSId=%mem1% do var1 %value% endon
on VAR1#state=%mem1% do backlog WLAN-OK; VAR3 0 endon
on tele-Wifi#Downtime do Backlog ohne WLAN==>>%value%; mem4 %value% endon
on power3#State>=1 do Backlog test==>; counter1 0.0; mem2 0; mem3 0; mem4 0; VAR3 0; time 0; power3 0 endon

und wenn das Teststadium durch ist kann auch die letzte Zeile substituiert werden

rule3
on system#init do Backlog VAR3 0; time 1587435620 endon
on time#minute|1 do Backlog ADD3 1; Time 0 endon
on VAR3#state>%mem5% do Backlog mem3 %timestamp%; counter1 +1; Restart 1 endon
on VAR3#State>0 do wifiscan 1 endon
on WifiScan#?#SSId=%mem1% do var3 0 endon

mem1 = SSID eintragen auf die geprüft werden soll

counter1 = Anzahl der Reboots wegen WLAN-Verlust (Config counter1 einstellen)

mem3 = beinhaltet letzten Reboot-Zeitpunkt

Variante 4 einer Systemselbstüberwachung

mit separater MQTT-Beobachtung (Achtung - diese Prozesse laufen schneller ab)

Rule3
on system#init do Backlog VAR3 0; VAR4 0 endon
on time#minute|1 do Backlog ADD2 %VAR3%; ADD5 %VAR4% endon
ON mqtt#disconnected DO ADD3 1 endon
ON wifi#disconnected DO ADD4 1 endon
ON mqtt#connected DO Backlog VAR2 0; VAR3 0 endon
ON wifi#connected DO Backlog VAR5 0; VAR4 0 endon
on VAR2#state>20 do Backlog mem3 %timestamp%; Restart 1 endon
on VAR5#state>2 do Backlog mem4 %timestamp%; Restart 1 endon