Homematic Ventil hängt bei 1%

Begonnen von moonser, 26 Februar 2013, 18:06:45

Vorheriges Thema - Nächstes Thema

martinp876

ZitatHabe ich dich richtig verstanden, dass deine Variante den VD immer öffnet - egal welche Ist-Temp. herrscht?

so ist es. Im Detail: FHEM kann genau dann mit dem VD reden, wenn der TC seinen Wert gesendet hat. Eingebaut ist also

1) User setzt Kommando ab -landet im Stack wie alle Kommandos
2)TC setzt VD Einstellung wenn die 2,5min periode um ist
3)FHEM schickt sofort hinterher seine kommandos, also überschreibt den Wert des TC
=> VD stellt den "user-wert" ein
4)TC setzt VD Einstellung wenn die nächste 2,5min periode um ist (TC hat nichts gemerkt)
5) FHEM sendet nichts mehr, da stack normal leer ist
=> VD stellt den "TC-wert" ein

eigentlich ganz einfach - und erheblich naheliegender als den TC wert ändern/merken/rücksetzen/timing beachten. Alles unnötig.
Die Erkennung musst du belassen wie vor.

Gruss Martin

herrmannj

Zitat@Jörg:

Nachfragen: Kannst du bitte mal noch ein Beispielaufruf für deine Routine posten?
Der Wert für die Aussentemp. ist die Grenze, über welcher die Justierung nicht mehr ausgeführt wird - oder? D.h. wenn ich einen utopischen Wert eingeben würde (z.B. 50), dann wird das notify immer bearbeitet?ch gebe mal kurz wieder was so der Tenor zu sein scheint:

Danke Uwe

Hi Uwe,

gerne, und vermutlich helfe ich auch mit einer kurzen Erklärung des "was und warum":

Im Netz kursieren ja zahlreiche Erklärungsversuche dazu wie der Fehler im VC entsteht. (hier also als second Hand Meinung ;) )

Im Kern "scheint" es wohl so zu sein das im VC der Motor nicht starr mit dem Ventil gekoppelt ist sondern über eine Gummikupplung die Schlupf hat (haben muss). Wenn der VC seinen Adaptionslauf gemacht hat zählt er die Regelungs-Umdrehungen des Motors und koppelt so die Ventilstellung mit. Da die Kupplung Schlupf hat geht echte Ventilstellung und das was der VC denkt im Lauf der Zeit auseinander. Am Anfang verschwindet das im Spiel des Heizungsventils aber irgendwann kommt, schleichend, der Punkt wo Soll und Ist soweit auseinandergelaufen ist am Heizkörper auch bei "geschlossenem" Ventil Durchlauf ist. Anders herum tritt das vermutlich auch auf, nur da merkt das halt niemand weil der TC dann einfach den VC weiter öffnet.

Erste Maßnahme an der Stelle ist/wäre ein erneuter Adaptionslauf, danach ist es wieder für Tage/Wochen ok.

Warum jetzt das temporäre öffnen des Ventils ebenfalls hilft verstehe ich nicht, anerkanntermaßen tut es das aber. Vielleicht entsteht beim (größen) öffnen kurzfristig genügend Schlupf in die andere Richtung ? Egal, denn was zumindest bei mir ebenfalls funktioniert ist dem TC ein "off" zu sagen. Auch wenn der VC auf 0% steht macht dadurch noch weiter zu.

Bei der Routine wollte ich eine fire-and-forget Lösung. Also auch das ganze Jahr nebenbei mitlaufen, ich möchte nichts was ich im Herbst ein- und im Frühjahr ausschalten muss.

Einfach nur auf "zu hohe" Temperatur zu achten war mir nicht ausreichend da es viel zu viele Ausnahmesituationen gibt. Beispiel Nachtabsenkung: wenn die Außentemperatur mild ist (jetzt) dauert es bei mir viele Stunden bis das Soll der Nachtabsenkung erreicht ist. Formell wäre der Zustand die ganze Zeit über "zu warm".

Die Routine arbeitet deswegen so das den Temperaturverlauf (steigend/fallend) berücksichtigt sowie für die Sommermonate auch die Außentemperatur.

Ich hab übrigens gerade gesehen das ich kein notify sondern ein at drauf habe, wäre aber Wurscht  8)
DEF
+*00:10:00 {myHmUtils_HeatDog('TCLiving', 1.5, ReadingsVal('THGR810_1', 'temperature', 15))}


Parameter
#1 der Name des TC (kein Channel, gesamter TC).
#2 ist die erlaubte Abweichung vom Soll, hier 1,5°
#3 ist meine Außentemperatur, die kannst Du genauso gut auch von Yahoo nehmen.

Die Regelung selber läuft jetzt so ab:
Vom TC die gewünschte und die aktuelle Temperatur holen. Stimmt innerhalb der Abweichung überein ? Schön, passt.
Nein ? : (es ist zu warm)
Wurde die Solltemp ganz frisch (in den letzen 15min) gesetzt ? Ja: erstmal abwarten ... (Also z.B. kurz nachdem die Nachtabsenkung aktiviert wird. Am Anfang dauert es bis der TC die Daten bekommt, dann muss er regeln und die Heizkörper haben Nachwärme ... )
Nein ? : (es ist zu warm und der TC kennt die Daten seid 15min)
Sinkt die Temperatur ? Ja: dann ist alles gut, keine Aktion erforderlich
Nein ? (temp steigt weiter: das ist ein Fehlerfall !)
hier wird der TC auf "off" gesetzt.
Jetzt greift die Kontrollschleife von oben nach unten erneut: 15 Minuten Füße stillhalten damit der TC einregeln kann und die Heizung ihre Restwärme los wird, etc etc

Wenn nach dieser "Runde" und dem dazugehörigen Abwarten die Temperatur noch weiter steigt (!) dann ist Holland in Not und ein Event wird erzeugt. Das würde eintreten wenn der TC gar nicht mehr regelt und das Ventil offen steht. Auf dieses Event kannst Du dann eine pushmail oder was auch immer legen, da wirst Du dann über den Fehler informiert und musst eingreifen (hatte ich noch nie, der headDog hat immer vorher gegriffen, ist ja zum Glück sowieso selten genug)

Die Außentemperatur wird mit geprüft weil ich ja sonst im Sommer ständig Fehlalarme bekommen würde: Szenario: Heizung ist aus, bzw Übergang: Heizung steht auf 18° aber draußen sind 25°. Da kann der TC zumachen solange er will, formell "zu warm" -> Alarmmeldung.

Dieser Teil der Routine ist noch nicht sicher. Ziel wäre es hier noch Fehlalarme sicher zu unterbinden (Sonderfall Sommer).

Ich hoffe das diese Information reichen damit jeder der gewillt ist die Routine Revision lesen (und bitte auch verbessern) kann, vielleicht findet sich ja auch jemand der das ins Wiki stellt. Die Frage nach dem Watchdog für die TC taucht ja regelmäßig auf.

vg
Jörg

locodriver

Hat mit meiner Reaktion etwas gedauert (die liebe Arbeit).

@Martin: ich werde deine Variante mal einbauen, wenn ich wieder zu Hause bin (fhem-Update über VPN ist etwas heikel - ich spreche aus Erfahrung).

@Jörg:
Du hast den VD wohl in alle Einzelteile zerlegt? :D
So wie du deine Variante beschreibst, "muss" man ja fast hoffen, dass der Fehler mal kommt - damit man sich am Abfangen desselben "ergötzen" kann.
Deine Abhandlung einschließlich des Codes ist sicher was für's Wiki.
Eventuell könnten ja auch andere User, die den Fehler erfolgreich bekämpft haben, ihren Code veröffentlichen. So kann sich jeder die Variante aussuchen, die ihm gefällt.
Ich werde auch deine Variante testen und dann sehen, was meine Vorzugslösung wird...

Erstmal danke an euch beide für die Infos und den Code.

Uwe
fhem 6.0 auf Rpi3 Bookworm
HM-LAN-CFG (FW 0.965), HM-MOD-UART, 2x HM-TC-IT-WM-W-EU, 4x HM-Sec-RHS und 3x HM-CC-RT-DN, 6x HM-LC-Bl1-FM mit je 1x Somfy-Motor,
2x HM-LC-SW2-FM für Licht und Lüfter, 2x HM-PB-6-WM55, Alexa, Jeelinkcross, CUL, CUNO2, IR-Blaster

herrmannj

hey!  :)

'ne, als ich den Fehler zum ersten mal hatte hab ich dumm aus der Wäsche geguckt, die TC / VC abgelernt, neu angelernt ... Dann war einige Wochen Ruhe und es ist wieder aufgetreten. Da hab ich halt gegooglelt und gelernt das man als VC Besitzer damit rechnen muss. Findest auch hier im Forum Geschichten wo sich das Kinderzimmer bei einem Kleinkind über Nacht auf 28° erwärmt und so was ... das will ich hier nicht haben.

Und wozu hab ich fhem wenn ich mich damit zufrieden geben soll ?? Nö, da wird dann gründlich sauber gemacht. Seitdem habe ich auch Ruhe, aller paar Wochen seh ich mal was im log und oft seh ichs wohl auch nicht.

Genau so soll es sein  8)  !

Wenn das tweak von Martin auch läuft, um so besser. "Damals" gabs sowas noch nicht  :)

vg
Jörg

locodriver

So, habe jetzt mal die Varianten eingebaut:

define WZ_VD_supervision at +*03:00:00 {if ((Value("SoWi") eq "on") && (ReadingsVal("WZ_Regler","measured-temp",0)- ReadingsVal("WZ_Regler","desired-temp",0)>2.4) && (ReadingsVal("WZ_Regler","measured-temp",0)>25.5) && (ReadingsVal("WZ_Regler","actuator",0) eq "0 %"))  {Log 1, "VD wird justiert!";;fhem ("set WZ_Regler desired-temp 29");;fhem ("define WZ_VD_close at +00:06:00 set WZ_Regler desired-temp 20")}}
attr WZ_VD_supervision alignTime 04:10
attr WZ_VD_supervision room 001Wohnzimmer

define BD_VD_supervision at +*00:10:00 {myHmUtils_HeatDog('BD_Regler', 2.9, ReadingsVal('BD_Regler', 'measured-temp', 25))}
attr BD_VD_supervision room 004Bad


WZ ist mal mein Ansatz ohne eine "99_my Utils"-Datei, sondern nur in der cfg. Das ist der bis jetzt allgemein in meinem fhem von mir bevorzugte Weg, das muss ich aber für jedes Device einzeln definieren (Temperaturdiff größer 2,4 °C und Isttemp. größer 25,5°C und VD ist zu - Prüfung aller 3 Stunden).

BD ist die Variante von Jörg, die ja allgemeiner gehalten ist, da man nur die Parameter an die Subroutine übergeben muss (Temperaturdiff größer 2,9 °C und Außentemp. (bzw. Festwert) unter 25°C).

In beide Varianten kann man das neue Kommando valvePos einsetzten: bei Jörg (irgendwo) in der 99_myHmUtils.pm und bei mir am Schluss:

...{Log 1, "VD wird justiert!";;fhem ("set WZ_Hk0 valvePos 20")}} ?

Bis jetzt hatte ich den Fehler noch nicht wieder... hoffe, dass das so bleibt :).

Schönen Sonntag,

Uwe
fhem 6.0 auf Rpi3 Bookworm
HM-LAN-CFG (FW 0.965), HM-MOD-UART, 2x HM-TC-IT-WM-W-EU, 4x HM-Sec-RHS und 3x HM-CC-RT-DN, 6x HM-LC-Bl1-FM mit je 1x Somfy-Motor,
2x HM-LC-SW2-FM für Licht und Lüfter, 2x HM-PB-6-WM55, Alexa, Jeelinkcross, CUL, CUNO2, IR-Blaster