Fussbodenheizung mit PWM steuern

Begonnen von jamesgo, 24 September 2015, 08:28:49

Vorheriges Thema - Nächstes Thema

Corrado

Thema Ventilschutz anzugehen finde ich gut. Wenn ich allerdings das Ventil für 5min anziehen möchte...ziehet es mir die Regelung bei der nächsten Berechnung wieder auf off.

jamesgo

Hallo,
ich habe gerade neue Versionen für 94_PWM.pm und 93_PWMR.pm hochgeladen.

Bei dem PWM objekt könnt ihr nun ein Attribut "valveProtectIdlePeriod" definieren. Es legt einen Zeitraum in Tagen fest nach dem das Ventil für mindestens 5 Minuten geöffnet wird. Referenz ist das Reading "lastswitch" bei den Räumen.

Bei dieser Implementierung werden alle Räume einzeln betrachtet. D.h. es gibt keinen festen Zeitpunkt an dem die Ventile gleichzeitig angesteuert werden.

Grüße
Andy

Corrado

...läuft prima, bequem zu handhaben, Danke!

Skusi

Auch von mir ein dickes Danke !

Hab die Funktion nun schon seit beginn laufen, und wie es aussieht tut es genau das wie ich es mir gewünscht hatte.
Vielen Dank für die schnelle Umsetzung. Nun kann ich mein Behelfs DOIF wieder löschen.

Allerdings hab ich eben folgendes im Logfile gfunden:

2016.08.06 04:19:42 1: PERL WARNING: Use of uninitialized value $temperaturV in substitution (s///) at ./FHEM/93_PWMR.pm line 838.
2016.08.06 04:19:42 1: PERL WARNING: Use of uninitialized value $temperaturV in subtraction (-) at ./FHEM/93_PWMR.pm line 919.
2016.08.06 04:19:42 1: PERL WARNING: Use of uninitialized value in join or string at ./FHEM/93_PWMR.pm line 959.
2016.08.06 04:19:42 1: PERL WARNING: Use of uninitialized value in join or string at ./FHEM/93_PWMR.pm line 960.
2016.08.06 04:19:42 1: PERL WARNING: Use of uninitialized value $temperaturV in subtraction (-) at ./FHEM/93_PWMR.pm line 963.
2016.08.06 04:19:42 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/93_PWMR.pm line 965.
2016.08.06 04:19:42 1: PERL WARNING: Use of uninitialized value $t in subtraction (-) at ./FHEM/93_PWMR.pm line 969.
2016.08.06 04:19:42 1: PERL WARNING: Use of uninitialized value $temperaturV in concatenation (.) or string at ./FHEM/93_PWMR.pm line 1026


Muß ich mir da Sorgen machen ?
HP ThinClient 630, SIGNALduino, NanoCul868 (a-culfw), JeeLink Clone (LaCrosse), Firmata  für FB Heizung,Wasser+Gas+Klingel+Lux, Somfy Rolladen, Pollin Steckd.,TX29DTH,Tasmota+IR Lesekopf an Stromz., MAX Fensterkontakte, IButton, Fingerprint, SonOff Tasmota, ESP LED Controler, WLed,zigbee2mqtt...

jamesgo

Hallo Skusi,

ich habe gerade meine Logs geprüft und diese Warnings habe ich nicht.

Hast du beide Module aktualisiert?

Ich schaue mir das heute mal an.

Grüße
Andy

myhome

Hallo verfolge schon seit diese Diskussion . Ich habe die Module  zwar noch nicht im Einsatz, hätte dazu aber mal eine Frage. Gibt es so etwas wie eine Wartungsfunktion? Die Wartungsfunktion bewirkt das alle Bodenventile gleichzeitig öffnen. Diese Funktion wird genutzt, wenn man die Heizung bzw. Heizstränge durchspülen möchte. Vielleicht kann man dies mit der Ventilschutzfunktion kombinieren. Ansonsten finde ich alle Ideen und vorallem den Einsatz der Personen die solche Module schreiben und ihre Freizeit dafür opfern bemerkenswert! Daher vielen vielen Dank.
Raspberry Pi4, Pi3 und Zero's, Homematic, Zigbee, WLAN, USB, One-wire für Wasser, Heizung und Rücklauftemp und alte F20 für den Garten, Messen GAS, Wasser, Strom, PV, weiteres

Skusi

@jamesgo
Ja, ich habe beide Module aktualisiert.

@myhome
Ich meine das es keinen Sinn macht eine solche Funktion in die Module einzubauen. Wie oft spülst Du denn Deine Fussbodenheizung ? Das kann ja nicht alle Nase lang sein. Also einmal im Jahr vielleicht, oder ? Ich denke da kann man sich dann auch anders helfen. Entweder schraubt man eben die Ventilantriebe ab, oder man deaktiviert die Module und setzt einen on Befehl an alle Ventil Devices ab.
Verstehe mich nicht nicht falsch, aber wenn man für alles eine Funktion in die Module einbaut, hab ich einwenig Angst das es unübersichtlich wird. Die syntax des Define ist mir ehrlich gesagt gestzt schon zu kryptisch geworden seit dem die PID Geschichte eingebaut wurde. Ich bin froh das ich es sauber eingestellt bekommen habe, und fahre auch immer noch auf PWM. Bis heute hatte ich einfach nicht die Zeit mich mit den Parametern der PID Regelung zu befassen, weil sie für mich nicht so einfach verständlich waren.
Aber das ist nur meine Meinung. Wenn es einen Bedarf für diese Service Funktion gibt, dann baut jamesgo sie vielleicht ja ein. Ich brauche sie nicht.

Gruß Holger 
HP ThinClient 630, SIGNALduino, NanoCul868 (a-culfw), JeeLink Clone (LaCrosse), Firmata  für FB Heizung,Wasser+Gas+Klingel+Lux, Somfy Rolladen, Pollin Steckd.,TX29DTH,Tasmota+IR Lesekopf an Stromz., MAX Fensterkontakte, IButton, Fingerprint, SonOff Tasmota, ESP LED Controler, WLed,zigbee2mqtt...

PichlAlex

Hallo,

apropos Servicefunktion: ich schraube dazu die Stellantriebe ab - geht am leichtesten

Grüße
Alex

jamesgo

Hallo,

die Stellantriebe abnehmen würde ich auch preferieren.

Beim Spülen meiner Heizung wurde jeweils nur ein Heizkreis geöffnet und nicht alle auf einmal.

Alternativ könntest du das Interval auf 3600 setzten (d.h. nur einmal pro Stunde berechnen), einen Zyklus warten und dann die Stellantriebe manuell starten. Am Ende fhem neu starten und alles ist wieder beim Alten.

Grüße
Andy

jensbergemann

Hallo zusammen,

vielen Dank für das tolle Modul.

Auch wenn die Heizperiode bald wieder anfängt, wollte ich mal wissen ob man den Regler im Sommer deativieren kann, er brauch ja immer sommer nicht rechnen, wenn die Heizung sowieso aus ist?

jamesgo

Hallo,

im Sommerbetrieb setzte ich das attribut "frostProtect" auf 1. Das führt dazu das die Temperatur auf "tempFrostProtect" (default 6°C) abgesenkt wird.
Nachdem diese Temperatur auch in der Übergangszeit überschritten wird, ist die Heizung de Facto aus. Als erstes mache ich das für Flure und Nebenräume und als letztes im Wohnzimmer. Das "rechnen" wird dadurch aber nicht "gespart".

Aber stell dir vor dass du im Sommer fleissig am FHEM geschraubt hast und dann im Herbst zum Beginn der Heizperiode das System in die Knie geht, weil die Rechnenleistung plötzlich nicht mehr ausreicht - davon abgesehen dass ein Chart anzeigen wesentlich mehr Last bringt als das berechnen eines notwendigen Heizbedarfs.  :(

Viele Grüße
Andy

sledge

Hallo zusammen,

seit längerem verfolge ich diesen Thread und lasse PWM/PWMR in meiner Umgebung den Sommer über "mitlaufen", um Erfahrungen zu sammeln. Zunächst einmal möchte ich sagen: Tolle Arbeit...

Aktuell werden die beiden Module ja noch im "contrib"-Zweig des Repositories verwaltet.

Ich möchte gerne eine Diskussion anregen (oder einfach nur vorschlagen), die beiden Module in den offiziellen Zweig von FHEM zu überführen. Wenn ich das richtig einschätze, sind die Voraussetzungen dazu gegeben:


  • jamesgo kümmert sich ohnehin bereits vorbildlich um die Module und steht Anregungen sehr offen gegenüber
  • Commandref ist zumindest in Englisch vorhanden
  • Die Stabilität ist meines Erachtens gegeben

Was meint ihr dazu?

@jamesgo: Gerne helfe ich dabei, eine deutsche Commandref zu erstellen, falls es Dir die Entscheidung erleichtert, diesen Schritt mitzugehen ;-) Zumindest in meiner (ggfs veralteten) Version gibt es lediglich eine englische Version ...

Gruß,
Tom
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

jamesgo

Hallo,

ich habe die beiden Module vom "contrib" in den "FHEM" Zweig übertragen.
D.h. sie werden nun mit der normalen update funktion von FHEM aktualisiert und müssen nicht mehr manuell geholt werden.

Aktuell bin ich gerade dabei ein paar Readings für die Zeitprogramme hinzuzufügen. (also attribute tempRule1 bis tempRule5)
Gibt es jemanden der das verwendet? Oder übernehmen alle die Wunschtemperatur aus einem Homematik device?


aus
tempRule1  Mo-Fr 6,d 10,e 15,d 22:30,n
tempRule2  Sa-So 6,d 10,e 22,n

würden dann folgende Readings (evtl. sogar mit der Info welcher Temperatur "D,E,C,N" entspricht):
timer1_Mo           06:00-10:00,D 10:00-15:00,E 15:00-22:30,D
timer2_Di            06:00-10:00,D 10:00-15:00,E 15:00-22:30,D
timer3_Mi            06:00-10:00,D 10:00-15:00,E 15:00-22:30,D
timer4_Do           06:00-10:00,D 10:00-15:00,E 15:00-22:30,D
timer5_Fr            06:00-10:00,D 10:00-15:00,E 15:00-22:30,D
timer6_Sa           06:00-10:00,D 10:00-22:00,E
timer7_So           06:00-10:00,D 10:00-22:00,E



Grüße
Andy

pcjogi

Ja, ich verwende das. Was willst du ändern?


Gesendet von iPad mit Tapatalk
Zentral-Fhem , Mehrere Sub-Fhem (433Mhz und 833Mhz; Alexa-Steuerung; Heizungssteuerung; Sicherheitsfunktionen; Energiesteuerung); IoBroker zur Darstellung (alles als Container auf Proxmox), untereinander verbunden über einen MQTT Broker, insgesamt über 200 Sensoren/Aktoren.

jamesgo

Hallo,

eigentlich soll alles abwärtskompatibel bleiben.

Wie oben im post zu sehen möchte ich die Zeitprogramme besser visualisieren.

Ich habe die Zeitpunktregel (ab 6Uhr Tag) gewählt da sich das einfach und schnell parsen läst. In einer Übersicht (z.B. TabletUI) ist die Darstellung "von-bis" aber übersichtlicher. Dafür wird es neue readings geben.

Im PWM Objekt gibt es dann "get timers", was alle Räume durchgeht und das kleinste "von" und größte "bis" ermittelt.

Die Frage in die Runde ist nun: was ist das beste Format:

06:00-10:00,D 10:00-15:00,E 15:00-22:30,D
oder
06:00-10:00,D,20 10:00-15:00,E,19.9 15:00-22:30,D,21
(also incl. der aufgelösten Solltemperaturen)
oder ein andere Delimiter? Was lässt sich z.B. im TabletUI am besten verwenden?

Ein zweites Thema betrifft die Regeln, die übers Wochenende reichen. Also z.B. Sa-Mo. Verwendet das jemand?

Hintergrund:Ich könnte mir ein "set" vorstellen, dass obiges Format als input nimmt und dann die Attribute "tempRule?" setzt.
Somit hätte man die Möglichkeit von-bis Regeln oder "Zeitpunkt Regeln" zu verwenden. (und da hab ich beim parsen von Sa-Mo meine Probleme)

Viele Grüße
Andy