Inzwischen ist ja bekannt, dass die Ventilantriebe von Homematic hängen. Da es mit der Unterstützung ziemlich mau aussieht, dachte ich mir ich schreibe mal einen Fehlerfänger, der beim Auftreten dieses Problems die Temperatur für 5 Minuten hochsetzt und dann wieder auf den eigentlichen Sollwert setzt.
Was haltet Ihr von diesem Code dazu:
define WD_HZ_Schlafzimmer_Ventil notify HZ_Schlafzimmer:actuator:.* { \
if ((split(" ", $value{HZ_Schlafzimmer}) ge ($value{HZ_Schlafzimmer_Solltemp} +2.0)) && $value{D_Trig} eq "on") { \
Log 3, "++++++++++ HZ_Schlafzimmer - Ventil hängt!!!!";;\
fhem("set HZ_Schlafzimmer desired-temp 26.0");;\
fhem("define Ruecksprung at +00:05:00 trigger HZ_Schlafzimmer_Fenster");; \
fhem("set D_Trig off") \
} \
}
Meinungen und Verbesserungsvorschläge gerne erwünscht!
Danke Martin
D_Trig ist ein dummy, der dafür sorgt, dass das Makro nur 2mal am Tag ausgelöst werden kann (wird um 5 Uhr und um 18 Uhr auf off gesetzt).
was meldet eigentlich das Ventil? Wer macht den Fehler?
Wenn du die temp nochsetzt machst du dies ja nicht am Ventil sondern am TC.
Sollte die desired-temp nicht erreicht werden muesste die TC-regelung von alleine auf 'voll-offen' regeln - daher Regelung. Offensichtlich macht sie dies nicht...
kannst du einen log schicken mit den Regelwerten und den Antworten den VD? Ich habe von dem Problem gehoert aber bisher keine Logs erhalten.
Am besten message-logs. Aber falls du andere hast ist auch erst einmal ok
Gruss
Martin
Nabend Martin,
Problem ist hier beschrieben: http://www.fhemwiki.de/wiki/HM-CC-VD_Funk-Stellantrieb (//www.fhemwiki.de/wiki/HM-CC-VD_Funk-Stellantrieb)
Ventil macht nicht voll zu sondern bleibt beim Schließen vorher stehen (bei mir immer bei 1%). Danach heizt sich der Raum immer weiter auf, aber der TC regelt nie auf 0% runter => es wird immer wärmer...
Viel einfacher und eleganter wäre es den Stellantrieb direkt von fhem auf 0% zu setzten, wenn z.B. die Solltemperatur um 2°C überschritten wäre. Allerdings weiss ich nicht, wie man den Antrieb direkt setzen kann.
set HZ_Schlafzimmer_Ventil 0% dürfte wohl nicht fliegen...
Martin
Hi Martin
verstehe ich nicht. Mal sehen was ich schon habe:
Der TC regelt auf 1% statt 0% obwohl die Temperatur schon zu hoch ist
==> Fakt: das Problem ist der TC, nicht der VD
Sollten wir es schaffen den VD 'mal kurz' auf 0% zu setzen waere das Problem nicht geloest. Der TC wuerde doch wieder, sofort danach 1% schicken und du waerst wieder am Anfang.
Mit deiner Aktion wird sowohl der TC alsauch der VD 'bewegt'. Nach deiner Beschreibung loest du m.E. ein regelproblem im TC.
Zu beachten sind die Einstellungen im VD - hast du diese beruecksichtigt? Wie stehen den offset und error-position? Evtl kann man etwas mit Offset machen?
Wenn das Problem im TC ist - und dort in der Regelung - laesst es sich sicher am Besten loesen, wenn man den TC 'durchschuettelt'. Was hast du schon alles probiert? Einfach einmal den mode umschalten koennte auch helfen.
Stimmen meine Aussagen oder liegen ich falsch?
uebrigens - dem VD ein Kommando 'unterzujubeln' im Namen des TC und parallel zu dessen Betrieb koennte schon funktionieren. Empfehle ich aber nicht.
Ein log einers solchen events waere zum Verstaendniss hilfreich
Gruss
Martin
@moonser
Du schreibst, dass das Problem hier beschrieben ist:
ZitatProblem ist hier beschrieben: http://www.fhemwiki.de/wiki/HM-CC-VD_Funk-Stellantrieb (//www.fhemwiki.de/wiki/HM-CC-VD_Funk-Stellantrieb)
http://www.elv.de/output/controller.aspx?cid=834&detail=2&detail2=582 (//www.elv.de/output/controller.aspx?cid=834&detail=2&detail2=582)
Wenn ich dem Folge, dann taucht dieses Problem nur
bei Firmwareversionen vor 2.0 auf!Offene Frage ist nun, welche Firmware Version hast du, oder habe ich da was falsch verstanden?
ZitatVon Dir!
Inzwischen ist ja bekannt, dass die Ventilantriebe von Homematic hängen.
Kann ich deshalb so nicht allgemein nachvollziehen. Meine 13 VD's hängen auf jeden Fall nicht!!!!
Gruss
Billy
Zitat von: Billy schrieb am Do, 28 Februar 2013 10:39Meine 13 VD's hängen auf jeden Fall nicht!!!!
Gruss
Billy
Bei mir auch: 11 VDs -> alle okay!
Von meinen beiden VD's hing einer heute und vor 2 Tagen, davor lief es ca. 6 Wochen ohne Probleme.
Heute habe ich einmal manuell auf ON gestellt, danach wieder auf Automatik und der Regler hat zu gemacht.
Gruss
Thorsten
Hallo Thorsten,
Zitat von: Tratonis schrieb am Do, 28 Februar 2013 20:58Heute habe ich einmal manuell auf ON gestellt, ...
Könntest du das bitte etwas näher erläutern? Wo gibt es "ON"?
Gruß
Thomas
Hallo,
bei jeder Diskussion reden alle davon, dass der VD haengt. Ich habe oben beschrieben, dass wahrscheinlich der TC hängt. Könnten wir dies klären oder interessiert euch dies nicht?
Wenn wieder einer hängt einfach die logs einschalten - also die raw-messages aufzeichnen. 10 min warten - als mindestens 2-3 Zyklen des TC.
Dann das Problem beheben durch TC Einstellungen nach wahl.
Zurueck in den Mormalmode
Dann logs stoppen und schicken + kurze Beschreibung
gruss
Martin
So Martin,
sorry es hat etwas gedauert, leider (?!) tritt der Fehler ja nur sporadisch auf. Heute war mal wieder.
Wie das Bild zeigt, geht das Ventil laut Log TC so gegen 08:20 auf Null und die Temperatur steigt immer schön weiter bzw. fällt bis jetzt (ca. 19:30 Uhr) nicht mehr ab. Das Ventil zeigt aber auf der LCD Anzeige 2 Prozent an. Jetzt zu dem Log des TC HZ_Schlafzimmer: Das zeigt an, dass der Regler seit 08:22 auf Null seht und sich von da auch nicht mehr wegbewegt. Um 19:00 Uhr habe ich den TC dann einmal "geschüttelt" sprich von central über manual und auto wieder auf central (siehe Log). Leider bringt das gar nix, das Ventil zeigt im Display weiter seine 2% an und im Log des TC steht weiter brav die Null. Um 19:24 Uhr habe ich dann das Fenster aufgemacht (wollen schlafen und nicht schwitzen). Desired-temp springt wunderbar auf 12.0 Grad, im Log steht weiterhin brav die Null - nur das Ventil zeigt im Display weiter 2% und heizt brav vor sich hin.
Jetzt kommt der Part den ich nicht verstehe: Das Log des Ventils sagt die Wahrheit - nämlich dass das Ding seit 08:22 Uhr durchgehend auf 2 Prozent steht. Die einzige Möglichkeit die ich gefunden habe dieses Problem zu beheben (und den ich mit dem Skript automatisieren möchte um nicht abends festzustellen, dass ich wieder den ganzen Tag das Schlafzimmer voll geheizt habe) ist den TC auf manual, desired temp auf 26.0 Grad, warten bis das Ventil voll aufmacht, dann auf 16.0 Grad und warten bis das Ventil dann voll zu ist, und zum Schluß wieder auf Central.
Das liest sich dann so:
2013-03-03_19:48:24 HZ_Schlafzimmer_Ventil 2 %
2013-03-03_19:48:24 HZ_Schlafzimmer_Ventil battery: ok
2013-03-03_19:48:24 HZ_Schlafzimmer_Ventil motorErr: ok
2013-03-03_19:48:24 HZ_Schlafzimmer_Ventil motor: stop
2013-03-03_19:50:48 HZ_Schlafzimmer_Ventil ValvePosition: 81 %
2013-03-03_19:50:48 HZ_Schlafzimmer_Ventil 81 %
2013-03-03_19:50:48 HZ_Schlafzimmer_Ventil battery: ok
2013-03-03_19:50:48 HZ_Schlafzimmer_Ventil motorErr: ok
2013-03-03_19:50:48 HZ_Schlafzimmer_Ventil motor: stop
2013-03-03_19:52:58 HZ_Schlafzimmer_Ventil ValvePosition: 81 %
2013-03-03_19:52:58 HZ_Schlafzimmer_Ventil 81 %
2013-03-03_19:52:58 HZ_Schlafzimmer_Ventil battery: ok
2013-03-03_19:52:58 HZ_Schlafzimmer_Ventil motorErr: ok
2013-03-03_19:52:58 HZ_Schlafzimmer_Ventil motor: stop
2013-03-03_19:55:57 HZ_Schlafzimmer_Ventil ValvePosition: 81 %
2013-03-03_19:55:57 HZ_Schlafzimmer_Ventil 81 %
2013-03-03_19:55:57 HZ_Schlafzimmer_Ventil battery: ok
2013-03-03_19:55:57 HZ_Schlafzimmer_Ventil motorErr: ok
2013-03-03_19:55:57 HZ_Schlafzimmer_Ventil motor: stop
2013-03-03_19:58:41 HZ_Schlafzimmer_Ventil ValvePosition: 0 %
2013-03-03_19:58:41 HZ_Schlafzimmer_Ventil 0 %
2013-03-03_19:58:41 HZ_Schlafzimmer_Ventil battery: ok
2013-03-03_19:58:41 HZ_Schlafzimmer_Ventil motorErr: ok
2013-03-03_19:58:41 HZ_Schlafzimmer_Ventil motor: stop
2013-03-03_20:01:12 HZ_Schlafzimmer_Ventil ValvePosition: 0 %
2013-03-03_20:01:12 HZ_Schlafzimmer_Ventil 0 %
Seltsam ist, dass ich 9 TC-VDs habe, von denen nur dieser eine das Problem aufweist. Alle anderen arbeiten ohne jedes Problem.
Zur Firmwarediskussion: VD ist 1.9, TC ist 2.0. Aber von den verbleibenden 8 anderen Geräten sind VDs: 1x 2.0 und 7x 1.9 und bei den TCs: 2x 2.1 und 6x 2.0. Es scheint wohl nicht nur an der 2.0 zu hängen. Ich habe auch eine Watchdog laufen, die auf missing ack schaut. Heute war für den TC im Schlafzimmer kein Eintrag im Log.
Soweit das, was ich Dir hier mit meinem Kenntnisstand bieten kann.
Raw-Messages mache ich Dir auch gerne, musst mir dann aber sagen wie das geht. Ein Trigger für eine Aufzeichung könnte das Delta zwischen VD und TC Meldung zur Stellung des VDs sein (dann müsste ich nicht davor sitzen und warten). Problem tritt ca. 1x pro Woche auf (zum Teil aber auch an zwei Tagen direkt hintereinander).
Hoffe das hilft Dir.
Danke Martin
Hallo Martin,
Zitatsorry es hat etwas gedauert, leider (?!) tritt der Fehler ja nur sporadisch auf. Heute war mal wieder.
ist klar, kein Problem.
das log ist genau was mir zum Ueberblick gefehlt hat.
Das in den Logs des Ventils fehlt ist uebrigens der state "set_0%". Den kannst du auch loggen lassen, wenn du die regexp zu deinem Logfile anpasst.
Klar ist hiermit, dass der VD die Anweisung des TC nicht befolgt. Erste einmal sollte FHEM hier einen Alarm werfen - schliesslich kann man die Soll und Ist-werte vergelichen. Da werde ich mir etwas ausdenken, das darf nicht unbemerkt bleiben.
Ob FHEM hier dann eine automatische Korrektur anwerfen kann/soll - werde ich einmal nachdenken. Wenn, dann aber nur konfigurierbar - also ein autoResetVd, default = off.
macht dies sinn?
Eigentlich sollte der VD irgendeswas darueber sagen, dass der Motor haengt.
Kannst du das naechste mal ein getConfig des VD machen (dauert ~5min) und ein paar messages aufzeichnen mit
attr global verbose off
attr <hmlan/cul> loglevel 1
damit ich die messages ansehen kann, ob bei der auswertung der Motorzustand falsch gemeldet wird.
Klar, dass dies wieder dauern kann ;-)
Gruss
Martin
Zitat von: moonser schrieb am So, 03 März 2013 20:05Leider bringt das gar nix, das Ventil zeigt im Display weiter seine 2% an und im Log des TC steht weiter brav die Null. Um 19:24 Uhr habe ich dann das Fenster aufgemacht (wollen schlafen und nicht schwitzen).
Ich komme da irgendwie nicht mit. Wenn bei mir ein Ventil auf 2% steht, dann ist das Ventil defacto "zu". Der Unterschied zwischen 0% und 2% ist bei mir minimal.
Davon abgesehen, das mir das beschriebene Fehlverhalten unbekannt ist, wurde die korrekte Inbetriebnahme des VD durchgeführt? Ich hatte da zunächst auch so meine Schwierigkeiten.
Grundzätzlich MUSS vor dem Einlegen der Batterien in einen neuen VD dieser direkt auf das Heizungsventil geschraubt werden und dann der Adaptions-Zyklus gestartet werden (ein mal kurz den Knopf drücken).
Erst wenn dies erfolgt ist (dauert so etwa ne Minute), kann der VD an den TC angelernt werden!!
Eine Ventilstellung von 2% kann meines Erachtens nach nicht den Raum aufheizen.
Da muss was anderes im Argen sein. Daher würde ich da keine Software-Änderungen machen, so lange das nicht geklärt ist.
VG
Ralf
Hi Ralf,
ZitatWenn bei mir ein Ventil auf 2% steht, dann ist das Ventil defacto "zu"
das ist bei Martin nicht so, der Raum heizt offensichtlich weiter auf.
Ausserdem sollte das Ventil, wenn der TC '0' sagt auch '0' einstellen - und nicht 'etwa-0'.
Das ganze klappt ziemlich gut bei Martin, der VD stellt immer exakt den Wert ein, den der TC vorgibt. Nur im Fehlerfall nicht.
Nach aenderung der temp wird ja auf '0' geregelt - ohne neues adjusten...
So oder so denke ich, die geplante ueberwachung sollte ok sein, da sie auf Probleme hinweist und erst einmal keine Aktionen macht.
Habe es einmal angesehen, wuerde dann so aussehen:
ValveDesired:xx % # wird quasi TC geschrieben und zeigt an, wie der VD stehen sollte
operState: # neues Reading, das fehlerzustaende anzeigt
onTarget # motor steht, einstellung gemaess sollwert
adjusting#motor arbeitet
errorTargetNotMet # motor steht, aber nicht auf dem Sollwert
operStateErrCnt:yy # zaehlt, wie oft ein error aufgetreten ist
# der Zaehler stellt sicher, dass man aufgetretene Fehler im User-interface sehen kann, auch wenn sie behoben wurden, bevor man hinsieht.
Parsen kann man auf .*operState:Err.*, falls man es ueberwachen will
oper... readings koennte man fuer Fehlermeldungen auch anderer entities nutzen, also operational state.
Anmerkungen?
Gruss
Martin
Also zu Ralf,
komme aus der Industrie und das erste was man da macht wenn ein Baustein nicht funktioniert ist ein Kreuztausch von betroffenen Bauteilen: Man nehme einen anderen VD und paare ihn mit dem nämlichen TC und umgekehrt: Ergebnis: Fehler wandert mit dem VD mit, egal welcher TC ihn anspricht. => für mich ein VD-Problem (deckt sich auch mit dem aus dem ELV-Forum).
Vor dem Kreuztausch habe ich auch mehrfach resetet und neu gepaired (ja auch mit neuer Referenzierungsfahrt des VD) ohne dass das was gebracht hätte. Meist funktioniert es ja auch, nur leider nicht immer...
Zu den 2% => das Log zeigt doch sehr deutlich, dass es mit 2% zumindest nicht annähernd an den Sollwert (16.0 Grad) herangeht sondern auf bis zu 22.1 Grad aufheizt (und das bei einer Aussentemperatur von ca. 5 Grad. => Wenn es draussen jetzt dann mal 15 Grad warm wird müsste ich drinnen bei knapp über 30 Grad landen.... Kann natürlich den hydraulischen Ausgleich so weit zu drehen, dass 2% dann wirklich nahe null sind (oder den VD als Defekt einschicken und ersetzten lassen), aber eigentlich möchte ich ja die Freiheit des Systems nutzen und auftretende Fehler abfangen und beheben (da kommt der Spieltrieb durch).
Heute aber keine Probleme, daher auch kein neues Log für Martin. Habe aber jetzt die Fehlerroutine auskommentiert, damit ich dann das getConfig machen kann. Frage an Martin:
In fhem.cfg das ändern:
attr global verbose off
attr <hmlan/cul> loglevel 1
und dann set HZ_Schlafzimmer_Ventil getConfig eingeben und abschicken - oder? Ergebnis landet dann im "großen" Systemlog?!
Wenn anders dann lass es mich bitte wissen,
Dank Euch
Martin
Nur zur Sicherheit, weil ich mich vielleicht unglücklich ausgedrückt habe: bei allen meinen VDs ist es so, das 0% auch wirklich Null-Durchfluss bedeutet, und 100% bedeutet Ventil voll auf.
In keinem meiner Räume wäre ich in der Lage, mit einer Ventil-Einstellung von 2% irgend eine merkliche Heizleistung zu erzeugen. Da würden die Heizkörper vielleicht gerade mal handwarm.
Daher verstehe ich einfach nicht, was da bei dir anders ist. Das einzige was mir einleuchten würde wäre, das 2% in der Anzeige nicht 2% entsprcht sondern vielleicht 20 oder mehr %, weil der VD seine Position nicht richtig erkennt. Daher auch mein Hinweis mit der Referenz-Fahrt.
Ansonsten: natürlich ist es nicht okay, wenn es eine Abweichung zwischen TC Soll-Wert und dem VD Ist-Wert gibt. Das ist ein klarer Fehler. Aber bevor diese 2% Geschichte nicht geklärt ist, haben wir hier möglicherweise mehr als nur einen Fehler.
Von all meinen VDs musste ich aber nur einen zurück schicken, weil dieser sich partout nicht pairen lassen wollte. Wurde anstandslos ersetzt.
VG
Ralf
Hi,
ich wäre erfreut über die optionale Einbindung entsprechender Prüfroutinen/-möglichkeiten, ob eine Funktionsstörung wie z.B. "TC zeigt 0%, VD hat aber 2%" vorliegt.
Dies aber nicht, um (innerhalb der Garantie/Gewährleistung) mit den Fehlern zu leben, in dem ich um sie "herumskripte", sondern um den defekten Sensor / Aktor ausfindig machen und reklamieren zu können.
Gruß
Thomas
Hallo ihr 3,
zum einen denke ich, dass die Ueberwachung der Abweichung in CUL_HM einfach ist. Nach den Logs muss - wenn der Motor steht auch die Ventilstellung dem Sollwert entsprechen.
Aus meiner sicht ist dies einen Eintrag in Readings wert. Folgeaktionen erste einmal nicht.
Werde es im naechsten update einbauen - noch nicht ganz klar on ich es heute schaffe...
@Martin
Was zu loggen ist waere der Austausch der Settings - oder besser die Antwort des VD im Roh-format.
attr global verbose 1 # off habe ich nicht probiert...
attr <hmlan> loglevel 1
Einfach wenn der haengt ein bischen laufen lassen. Die Ergebnisse stehe im main-log, korrekt
Ein getConfig ist auch immer gut :-)
Gruss
Martin
Hi!
Ich habe angefangen diese Diskussion zu verfolgen, weil ich seit geraumer Zeit genau das gleiche Problem habe. Ab und an steht ein und seit neuesten beide Stellantrieb(e) auf 0-5% und heizen den Raum aber weiter auf. Erst wenn ich die Batterien herausnehme, wieder reinsetze und und Antriebe damit neu justiere, laufen sie eine gewisse Zeit weiter ohne Probleme. Dass im Display beispielsweise 2% steht heißt noch lange nicht, dass es wirklich nur 2% sind. Meine beiden Heizungen waren beim letzten Mal so heiß, dass mann sie nicht anfassen konnte, das Display zeigte definitiv 0% an. Auch hier hat das herausnehmen und reinlegen der Batterien geholfen -> ist aber auf dauer kein Zustand, dann kann ich ja gleich wieder selbst regeln. Hat jemand eine Lösung für dieses Problem? Oder zumindest die Ursache gefunden?
Hi,
ich habe hin und wieder das gleiche Problem. Nach tagelangem Gegoogle und Herumprobiererei bin ich der Meinung, dass der Stellantrieb hin und wieder nicht genug Kraft aufbringt, das Ventil zu schließen. Das führt dann IMHO zu dem Status "2% und Heizkörper heiss". Vielleicht hilft ein wenig Fett oder so?
Meine Lösung war bisher auch: Batterien raus, rein, warten auf Motorstop, Justierfahrt per Knopfdruck, beruhigend auf die Frau einreden.
BTW: Ich habe leider keine Ahnung, wieviel Druck man normalerweise auf den Ventilstift aufbringen muss, um ihn zu schließsen. Bei mir schmerzt der Finger, wenn ich den Stift direkt eindrücken möchte.
Grüße
sk
Hallo ihr Beiden,
bei mechanischen Problemen kann ich nicht helfen.
Meine Frage ist: kann man es irgendwie aus den devices lesen
Habt ihr folgenden Werte gesammelt
- stellvorgaben des TC
- stellausgabe des VD
- fehler ausgaben des VD (motor haengt...)
- register des VD lesen
Es gab die Aussage, dass man es schaffen kann wenn der Motor mit 'schwung' zufährt. Also wenn man kurz den TC auf offen stellt und dann schliessen laesst. Schon probiert? Mir welchen Erfolg?
Gruss
Martin
Hallo,
Zitat von: martinp876 schrieb am Di, 02 April 2013 13:34... Es gab die Aussage, dass man es schaffen kann wenn der Motor mit 'schwung' zufährt. Also wenn man kurz den TC auf offen stellt und dann schliessen laesst. Schon probiert? Mir welchen Erfolg?
Die Aussage kann ich bestätigen. In den letzten 2 bis 3 Wochen hatte ich 2 VDs (FW 2.0) , die ständig auf 1 % standen, obwohl die desired-temperatures unter den gemessenen Raumtemperaturen lagen. Desired-temp per FHEM am TC auf 28 °C gesetzt, gewartet, bis die Ventile den Befehl zum Öffnen bekommen haben und diesen Wert auch erreicht haben (also kein "operState: adjusting") und dann die desired-temp auf 16 °C (also bewusst niedrig) gesetzt. Wieder gewartet, die Ventilstellung am Display der VDs zeigte 0 % an, der TC sagte mir auch 0 %, desired-temp. auf Normalwert und gut war es.
Allerdings habe ich nicht das Problem, dass die Räume sich trotz nur 1 % aufheizen, da ich mit Niedrigtemperatur (Brennwert) fahre. Für euch 2 aktuelle Problemprobanden wäre eine mögliche(?) automatische Fehlerkorrektur wohl dringlicher, aber da kann nur Martin sagen, was da möglich ist.
Edith ergänzt: Logs habe ich jetzt leider keine parat und weiß auch nicht mehr, welche VDs das waren. Nächstes Mal werde ich mir Notizen machen, damit ich die Logs verfügbar machen kann.
Edith die Zweite ergänzt die VD- und TC-Logs einer
Selbstheilung (sorry, auf die Schnelle nicht mehr gefunden).
Für die Schnellleser:
2013-03-11_18:05:02 EG.WZ.ThermostatR set_0 %
2013-03-11_18:05:02 EG.WZ.ThermostatR ValveDesired: 0 %
2013-03-11_18:05:02 EG.WZ.ThermostatR ValvePosition: 1 %
2013-03-11_18:05:02 EG.WZ.ThermostatR 1 %
2013-03-11_18:05:02 EG.WZ.ThermostatR battery: ok
2013-03-11_18:05:02 EG.WZ.ThermostatR motorErr: ok
2013-03-11_18:05:02 EG.WZ.ThermostatR motor: stop
2013-03-11_18:05:02 EG.WZ.ThermostatR operState: errorTargetNotMet
2013-03-11_18:05:02 EG.WZ.ThermostatR operStateErrCnt: 1Also der "operState: errorTargetNotMet" trifft hier ständig zu.
Gruß
Thomas
ich hab die VD mit 1.9 firmware,
und da gibt es den dokumentierten Fehler mit 4% hängen, bzw Vd schliesst nicht,
obwohl TC z.b. 0% Ansage macht.
2012-12-06_12:36:20 EG_WZ set_0 %
2012-12-06_12:36:20 EG_WZ CommandAccepted: yes
2012-12-06_12:36:20 EG_WZ ValvePosition: 4 %
2012-12-06_12:36:20 EG_WZ 4 %
2012-12-06_12:36:20 EG_WZ battery: ok
2012-12-06_12:36:20 EG_WZ motorErr: ok
2012-12-06_12:36:20 EG_WZ motor: stop
2012-12-06_12:43:54 EG_WZ set_0 %
2012-12-06_12:43:54 EG_WZ CommandAccepted: yes
2012-12-06_12:43:54 EG_WZ ValvePosition: 4 %
2012-12-06_12:43:54 EG_WZ 4 %
2012-12-06_12:43:54 EG_WZ motor: stop
2012-12-06_12:51:26 EG_WZ set_0 %
2012-12-06_12:51:26 EG_WZ CommandAccepted: yes
2012-12-06_12:51:26 EG_WZ ValvePosition: 4 %
2012-12-06_12:51:26 EG_WZ 4 %
2012-12-06_12:51:26 EG_WZ motor: stop
2012-12-06_12:58:57 EG_WZ set_11 %
2012-12-06_12:58:57 EG_WZ CommandAccepted: yes
2012-12-06_12:58:57 EG_WZ ValvePosition: 11 %
2012-12-06_12:58:57 EG_WZ 11 %
2012-12-06_12:58:57 EG_WZ motor: stop
Wenn man dan die Desired temp kurzeitig erhöht,
öffnet der Vd und schließt dann richtig auf 0%
für das Problem gibt es ein softwareupdate auf 2.0 der Vd s bei Elv, gegen bares.
(Edit: HaHa von 4% auf 1% mit 2.0 SW)
wenn der Verstellbereich nicht ausreicht, kann man auch eine Münze, entsprechender Durchmesser, Unterlagscheibe geht ja nicht, da loch in der Mitte,
zwischen Vd und Ventil legen.
ich musste letzten winter ein Ventil am Heizkörper wechseln, da das Gummi gerissen war,
und nie schloss. soll ja am Wasserhahn auch vorkommen.
Das wichtige ist, erst den Schuldigen finden, und loggen
lg
Hallo Hary,
Zitat von: fhem-hm-knecht schrieb am Di, 02 April 2013 20:35... für das Problem gibt es ein softwareupdate auf 2.0 der Vd s bei Elv, gegen bares. ...
Das habe ich schon des öfteren gelesen. Weißt du evtl., was die Durchführung des Updates kostet (für diejenigen, die FW 1.9 haben)? Obwohl es mMn wenig Sinn macht, einen 4 % Fehler gegen einen 1 % Fehler zu tauschen.
Gruß
Thomas
Keine Ahnung, was das aktuell kostet, und wie die Bedingungen sind,
wer das machen will, sollte sich eh an den Verkäufer wenden.
Bei mir kommt der Fehler das letzte mal im Anfang Dezember, für mich vernachlässigbar.
es kommen eh neue VDs auf den Markt
http://www.homematic-inside.de/blog/press/item/eq-3-auf-der-ish-2013 (//www.homematic-inside.de/blog/press/item/eq-3-auf-der-ish-2013)
Hi,
FHEM macht es also nicht automatisch (bisher). User koennen selbst probieren, mit dem Event wie von Thomas bescrieben
(hoffentlich ohne tippfehler, aber die konnt ihr sicherlich korrigieren)
define fn notify .*operStateErrCnt.* set $NAME desired-temp 30;;define a5 at +00:00:10 set %NAME 20
man kann sich auch den alten Wert merken.
Wenn ihr es testet und es funktioniert würde ich es einbauen, mit einem neuen Attribut zur Ansteuerung.
Gruss
Martin
Hallo at all,
ich habe zeitweise ein ähnliches Problem - allerdings mit wesentlich höheren %-Werten. Der von Martin erwähnte Schwungtrick hat auch nicht gefunzt. Die VDs gingen weder weiter auf noch dann zu. So hatte ich schon mal 28°C im Wohnzimmer!
Manchmal haben sich die VDs nach Stunden wieder von selbst eingekriegt, manchmal musste ich sie resetten und neu anlernen. Die Funkverbindung war die ganze Zeit über i.O.
Ich glaube ja, dass das eigentlich eine eQ3-Baustelle sein sollte. Die zusätzliche Implementierung von Routinen zum Erkennen und Auflösen solcher Situationen in fhem verkompliziert doch das Ganze noch mehr.
Meine VDs haben FW 2.0 und die TCs 2.1. Ich bin mit meinem Lieferanten so verblieben, dass ich alles einschicke und nach Möglichkeit ein FW-Update auf 2.1 (oder noch neuer?) gemacht werden soll. Ich habe noch Garantie drauf - das sollte also nichts kosten.
Oder wir hoffen auf die neuen VDs und TCs und versuchen diese dann umzutauschen, aber dann müssten wir uns noch bis 2014 mit solchen Bugs rumärgern.
Uwe
@locodriver
wo sind logs?
des hilft eben nicht viel, mit --> ähnlich, gefunzt, manchmal, glaube,
kann keiner etwas anfangen,
bitte net persönlich nehmen, aber fhem bietet alle möglichkeiten des loggens
:) lg
Hallo, schönen Sonntag,
@fhem-knecht: ich nehme nichts persönlich (da gibts in einer anderen Ecke dieses Forums einen speziellen User ;-)).
Mein Beitrag war mehr als allgemeine Wortmeldung zum Thema gedacht und nicht als Fehlermeldung/Hilferuf in engerem Sinn.
Ich werde erstmal meine TCs und VDs außer Betrieb nehmen und für den Rest der Heizperiode die alten Thermostate wieder anbauen.
Ich hoffe, dass ich dann neue VDs und/oder TCs mit neuester FW wieder bekomme. Ein entsprechendes Schreiben werde ich meinem Lieferanten beilegen - das wird dann sicher erstmal eine Weile dauern. Wenn die HW- bzw. FW-Probleme kleiner oder gelöst sind, dann macht es meiner Meinung nach Sinn, den noch verbliebenen "Unzulänglichkeiten" der HM-Hardware auf die Spur zu kommen.
Zu den Logs ins noch zu sagen, dass ich auf Montage arbeite und oft nur telefonische "Beschwerden" meiner Freundin bekomme, die dann nicht unbedingt so genau sind, dass ich den monierten Fehler vollständig geloggten Ereignissen zuordnen kann. Ich will sie dann auch nicht weiter in Beschlag nehmen, da sie bis jetzt die Sache als "Spielerei" abtut, da für sie noch kein rechter Vorteil gegenüber normalen Thermostatreglern ersichtlich war (muss ihr leider in geheim recht geben).
Mittlerweile bin ich ja auch auf einen HMLANCFG umgestiegen, da die CUNO ja nicht so recht mit den TCs will. Damit ist schon mal ein großer Schritt in die angestrebte Richtung getan. Die CUNO harrt derweil anderen Aufgaben (MAX oder FS20).
Uwe
Nabend die Herren (und Damen?),
also das mit dem Fehlerfangen über .*operStateErrCnt.* bzw. bei mir dann noch über eine zweite Abfrage mit operState =~ m/errorTargetNotMet/i um sicherzugehen fliegt inzwischen wunderbar seine Kreise.
Allerdings plage ich mich jetzt noch mit dem Thema: Ventil sagt zu (=0%) ist es aber gar nicht... Habe jetzt eine weitere Routine angelegt, die das Ventil mit Schwung zufährt, wenn die Innentemperatur die Soll-Temperatur um 2 Grad übersteigt (aber nur wenn es draußen nicht zu warm ist...).
Inzwischen sind das für meine acht Heizkörper satte 400 Zeilen Code (zugegeben gibt es hier sicher fittere Menschen als ich, die das auch elegant in 150 Zeilen programmieren können) - aber sei es drum.
Bananen reifen beim Kunden. Diese hier gar nicht, die muss man täglich pflegen, damit sie nicht im Zimmer verkochen...
Technik die begeistert...
Einen schönen Abend
Martin....
PS: Ich weiss Ihr wollt wieder ZDF - also: anbei ein wenig Logfile und ein Plot dazu (bei 5°C Aussentemperatur innen auf knappe 30°C - dann hat meine Frau das Fenster auf gemacht....)
Schon beeindruckend, was eine Heizung bei 0% so zu leisten vermag - ist jetzt nur mal das Badezimmer - hatten wir auch schon im Schlafzimmer bzw. in der Küche....
(siehe Anhang / see attachement)
(siehe Anhang / see attachement)
(siehe Anhang / see attachement)
Hallo Martin,
Zitat von: moonser schrieb am So, 12 Mai 2013 21:14Inzwischen sind das für meine acht Heizkörper satte 400 Zeilen Code (zugegeben gibt es hier sicher fittere Menschen als ich, die das auch elegant in 150 Zeilen programmieren können) - aber sei es drum.
Hmmm.... mal kurz überschlagen: 10 Heizkörper und 0 Zeilen Code für solche Anwendungsfälle wie du sie schilderst/hast. Deshalb ..
Zitat von: moonser schrieb am So, 12 Mai 2013 21:14Bananen reifen beim Kunden. Diese hier gar nicht, die muss man täglich pflegen, damit sie nicht im Zimmer verkochen...
... kann ich diese o.a. Äußerung - für mich - nicht nachvollziehen.
Zitat von: moonser schrieb am So, 12 Mai 2013 21:14Technik die begeistert...
Nicht begeistert, aber (mich) zufrieden stellt.
Es wird Fälle bzw. Konstellationen (Heizungsart/Heizkörper/HT/NT/Ventile usw. usf.) geben, für die die HM-Heizkörperregelung nicht geeignet ist.
Tja, aber das WWW lebt ja von negativen Unmutsäußerungen.
Schon mal Alternativen versucht? Also bitte...
Gruß
Thomas
Edith musste Typos korrigieren ;)
Weil's wesentlich ist, kein Edit, sondern neuer Post:
deine Peer-IDs vom VD sind leer => unsauber konfiguriert!
Gruß
Thomas
die das Ventil mit Schwung zufährt
ZDF ist immer gut :)
Dein Problem ist, vd sagt 0% und das Ventil schließt nicht richtig, undicht
ich hab ja auch lauter vds mit 1.9 sw und die haben eigentlich nur das 4% problem.
deiner sagt aber 0%, ist richtig.
Ich musste bei mir, Heizkörper 8 Jahre alt, die teilweise Ventile tauschen, Gummi morsch, bzw, glaube 20Cent Münze als Verlangerung
(Gugg mal in den Geldbeutel was de so findest), Unterlagscheibe ohne Loch
zwischen VD und Ventil einbauen, Habe verschiedene Hersteller von Heizkörpern.
Nicht das dein VD am Limit arbeitet.bezüglich des Anpressdrucks.
Das mit dem Schwung halte ich für ein Gerücht, aber wenns hilft. bin ich der letzte der dagegen redet
VG
@ Rohan:
Peer ID ist leer, weil ich gegen 21:00 Uhr die Batterien rausgenommen und damit eine neue Referenzfahrt erzwungen habe. Danach hat das Ding wieder sauber geschlossen - nur das Pairing hatte ich zum Zeitpunkt des Screenshots nicht wiederholt...
=> Schön wenn es glückliche Menschen gibt - manche sind ja schon mit sehr wenig im Leben zufrieden.
@ fhem-hm-knecht:
Was mich halt wundert ist, dass das ein sporadischer Fehler ist, der sich - wie gestern - mit einer neuen Referenzfahrt oder etwas "Schwung" nehmen beheben läßt.
20 ct hatte ich schon, waren aber zu dick - 5ct gehen besser sind aber in dem Antrieb nicht drin, weil passt auch so ;-)
@
Hi Martin,
FHEM scheint mir hier wenig machen zu koennen, was HM macht ist nicht ganz klar.
Fakten (bitte korrigieren):
- der TC stellt 0% ein, der VD bestaetigt 0%
- der Raum wird weiter geheizt, obwohl 0%
- deine Heizung hat eine geregelte Umwaelzpumpe bzw es sind einege Heizkoerper offen so dass die Pumpe nicht zu hohen Druck aufbaut. Andere Dinge sind vorgesehen um den Druck zu regulieren (Zirkulations-kurzschluss...)
- ein fahren auf Hohe temp und dann ein Runter-regeln (also ohne Batterie-reset) haben nicht gefruchtet.
- er werden keine Motor-fehler des VD angezeigt.
- Manuelle Einstellung des VD (kann man ja auch) hilft nicht
Sollte dies alles stimmen kann ich mir nur noch vorstellen, dass dein Ventil an der Heizung haengt oder hackt.
Gruss Martin
Mahlzeit Martin,
- TC soll null - ist null - vd bestätigt null => kein Fehler, systemseitig alles i.o. => operState: On Target (nur Ventil ist halt nicht zu)
- Ja, Raum geht nach oben, weil Heizkörper glüht.
- Ja, druckgesteuerte Pumpe und bei den Außentemperaturen sind viele Heizkörper zumindest teilweise offen
- NEIN: Das setzten auf 29.0 und danach wieder auf 20.0 behebt normalerweise auch das Problem. Hatte nur das Problem, dass der Raum schon 30 Grad hatte und ein setzten von 29.0 dann noch wenig gefruchtet hätte. War zu faul den TC aus dem Raum zu tragen und ihn nach einer Abkühlzeit zum hoch und runterstellen zu nutzten. Daher habe ich als "schnelle" Lösung die Batterien raus und rein.
Temperatur hoch und wieder runter hilft auch in diesem Falle immer ziemlich sicher.
- nein, laut Log keine VD-Motorfehler (Batterie ist auch ok).
- Manuelles Zukurbeln des VD hätte auch geholfen, habe ich ab und an auch schon gemacht.
Fange das wie gesagt mit einem Script ab (hat in dem Fall nicht gefruchtet, weil ich in der Routine fürs Badezimmer einen Typo hatte), wollte nur wissen ob ich mit diesem Thema allein auf weiter Welt bin...
Schönen Mittag
Martin
@all
Muss leider das "alte" Thema wieder reaktivieren :(.
Ich habe leider wieder das 0% Problem in Verbindung mit 2 TCs.
Einer steuert eine FB-Hz im Bad, der andere zwei normale Heizkörper im Wohnzimmer.
Die VDs melden geschlossen - sind es aber nicht, es gibt auch keine Fehlermeldungen. Der einzige Anhaltspunkt zur Analyse ist, dass die VDs nach einem gewollten Öffnen und Schließen nicht vollständig schließen aber 0% und "on target" melden.
Will evtl. für den Rest der Heizperiode Abfangroutinen einbauen, im WZ wird das aber etwas schwierig, da durch große Südseitenfenster auch eine große Aufheizung durch Sonneneinstrahlung möglich ist und ich nur Yahoowetter verwende.
An alten Ventilen kann es meiner Meinung nach auch nicht liegen, da die FB-Hz neu errichtet wurde.
Ich habe als Abhilfe die Solltemp. auf 30°C erhöht und dann wieder gesenkt, das hat bis jetzt immer geholfen. Da ich oft nicht zu Hause bin, muss ich momentan oft die Temperaturen prüfen, was aber nicht immer so klappt (heute 28°C).
Anbei noch die Plots zur Verdeutlichung.
Uwe
Hi Uwe - und alle Leidenden,
lösen kann ich das Problem auch nicht - aber evtl unterstützen.
für den VD gibt es jetzt das Kommando valvePos. Da mit kann man die Ventilstellung einstellen.
Details und Gebrauchsanweisung
- das geht nur, wenn der VD von einem TC (auch einem virtuellen TC) bedient wird. Das kommando wird nach dem 'regulären' gesendet - und übersteuert es somit. Das Kommando wird nur einmal gesendet - der TC wird es also nach 2,5min überschreiben. Es kommen alle Alarme: Target not met und so - stimmt ja auch.
Wenn der VD also hängt einfach einmal ein valvePos 20 absetzen.
Version 4849
Gruss Martin
Gruss Martin
Hi,
es gab ja schon einige threads dazu.
Das Problem liegt im VC selber, da stimmt nach einiger Betriebszeit der physische Ventilstellung nicht mehr mit dem überein was sich der VC denkt. Fehler IM VC!
EQ3 hat ja mehrfach versucht die Firmware zu flicken (besser kann man das leider nicht nennen) deshalb gibt es den Bug jetzt in diversen Variationen (0%, 1%, 4% ...). Am Ende ist es aber immer das gleiche Symptom, der TC sagt "mach zu" der VC macht das auch aber der Raum wird trotzdem immer wärmer.
Ich lasse mich gerne eines besseren belehren, aber ein überschreiben der Ventilstellung wird nicht reichen weil je nach Situation und Firmware die VC garnicht "target not meet" melden.
Die gängige Prozedur ist es die Temperaturstellung einige Minuten sehr hoch zu fahren und dann wieder auf des Sollwert zurückzusetzen. Ich setze eine andere Variante schon seid 4 Monaten erfolgreich ein. Per notify prüfe ich den TC nach Soll und ist mit diversen Ausnahmeregeln wie Außentemperatur, Zeit seid dem letzten setzen von Soll etc.
Wenn notwendig (Fehlerfall) setze ich den TC temporär auf "off" (!). Das bewirkt zumindest bei mir (fw 1.9 und 2.0) das die VC (auch wenn sie denken und melden auf 0% zu stehen) tatsächlich nochmal weiter zumachen. Hörbar regeln. Seid dem ich die Routine so nehme merke ich von den Fehlern im VC nichts mehr, nur im Log sehe ich ab und zu das der headDog gegriffen hat.
vg
Jörg
speichern unter 99_myHmUtils.pm. Notify auf den TC und im notify aufruf von myHmUtils_HeatDog(Name_des_TC, erlaubte_temp_Abweichung, Aussentemp)
##############################################
# $Id: 99_myHmUtils.pm 0 2013-11-18 00:00:00Z herrmannj $
package main;
use strict;
use warnings;
use POSIX;
use Time::HiRes qw(gettimeofday);
sub
myHmUtils_Initialize($$)
{
my ($hash) = @_;
}
my $history;
sub
myHmUtils_HeatDog(@)
{
my ($tcDevice, $deviation, $outsideTemp) = @_;
my $desiredTemp = stripSet(ReadingsVal($tcDevice, "desired-temp", 17));
#watchdog active
if (($history -> {$tcDevice} -> {'wdFlag'} || 0) == 1)
{
# if we are in recovery mode we compare it with cached desired temp.
$desiredTemp = $history -> {$tcDevice} -> {'wdDesiredTemp'} if ($desiredTemp eq 'off');
}
else
{
$desiredTemp = 4 if ($desiredTemp eq 'off');
}
my $desiredSetTime = time_str2num(ReadingsTimestamp($tcDevice, "desired-temp", 0));
my $actualTemp = stripSet(ReadingsVal($tcDevice, "measured-temp", undef));
# save temp for further reference
$history -> {$tcDevice} -> {'lastTemp'} = ($history -> {$tcDevice} -> {'Temp'} || $actualTemp);
$history -> {$tcDevice} -> {'Temp'} = $actualTemp;
# return if we are fine
return undef if ((($desiredTemp - $deviation) < $actualTemp) && ($actualTemp < ($desiredTemp + $deviation)));
# allow 15 min to transmit and set valve
return undef if ((gettimeofday() - $desiredSetTime) < 900);
if ($actualTemp > ($desiredTemp + $deviation))
{
# we are still to high, but temp doesnt rise. Stay calm and wait !
return undef if (($actualTemp - $history -> {$tcDevice} -> {'lastTemp'}) <= 0);
# set heating off if not done anyway
if (($history -> {$tcDevice} -> {'wdFlag'} || 0) == 0)
{
# first, set wd flag on to indicate that we manual adjusting
$history -> {$tcDevice} -> {'wdFlag'} = 1;
# save actual desired temp to be able to restore it later
$history -> {$tcDevice} -> {'wdDesiredTemp'} = stripSet(ReadingsVal($tcDevice, "desired-temp", undef));
fhem "set $tcDevice desired-temp off";
DoTrigger("global", "heatdog: cut off $tcDevice, now: $actualTemp, desired: $desiredTemp", 1);
return undef;
}
# heating is off and we are still to high:
# dont panic if "to high" means below 16 degrees, thats what we expect in a normal room even with heating turned off
return undef if ($actualTemp < 16);
# lets see if there is enviromental influence (hugh, maybe simple summer time ?)
if (defined($outsideTemp))
{
# dont bother if we have 22 degrees in if it's 27 degrees out there. take a beer and relax ... :-)
return undef if (($actualTemp - $outsideTemp) < 8);
}
DoTrigger("global", "heatdog: emergency $tcDevice, now: $actualTemp, desired: $desiredTemp", 1);
return undef;
}
if ($actualTemp < ($desiredTemp - $deviation))
{
if (($history -> {$tcDevice} -> {'wdFlag'} || 0) == 1)
{
# first, clear wd flag
$history -> {$tcDevice} -> {'wdFlag'} = 0;
# restore desired temp
fhem "set $tcDevice desired-temp $desiredTemp";
DoTrigger("global", "heatdog: return to normal operation $tcDevice, now: $actualTemp, desired: $desiredTemp", 1);
return undef;
}
return undef if ((gettimeofday() - $desiredSetTime) < 900);
# we are still to low, but temp is rising. Stay calm and wait !
return if (($actualTemp - $history -> {$tcDevice} -> {'lastTemp'}) >= 0);
}
}
sub
stripSet($)
{
my $str = shift || '';
$str =~ s/'set_'//g;
return $str;
}
1;
=pod
=begin html
<a name="myUtils"></a>
<h3>Utils</h3>
=end html
=cut
nun, ich habe den Fehler nicht.
es gibt den Fehler mit und ohne "target not met".
In beiden Fällen vermute ich ein Problem mit geringfügigem Verstellen. Das könnte auch an anderen stellen auftreten, würde aber nie jemand merken. Nur bei null geht es eben nicht noch nullen. Wenn er es also nicht mehr schafft, das letzte Prozent zu steuern muss er Anlauf nehmen.
Die gängige Prozedur ist (habe ich verstanden) dass man dem TC einen höhen Temp-wert vorgibt. Der VD bekommt dann einen grossen stellwert. Danach musst du den TC wieder runter regeln , der VD macht er wieder zu - und schafft es mit dem Anlauf auf Null.
Das neue Angebot macht nichts anderes. Nur einfacher, und es klappt immer. Du musst nur ein kommando geben, den TC umstellen ist nicht notwendig. Der VD regelt einmal auf, dann übernimmt der TC (implizit) und stellt auf Null.
Das funktioniert auch, wenn die temp schon 30Grad hat und der TC keinen größeren Wert mehr kennt, also den VD nicht aufregelt.
Falls du testen willst (kleine Werte stellen) kannst du den VD einmal mit dem neuen Kommando auf 1% setzen, wenn eigentlich zu ist. Dann prüfen, ob der TC es schafft, die Null wieder einzustellen - oder ob der Fehler bestehen beleibt.
Wie gesagt, ist nur ein angebot - einiges einfacher und ein bisschen sicherer
Gruss Martin
das verstehe ich nicht. Du möchtest dem VC (der bei 0% zu stehen denkt) einmal 20% geben und der TC sagt ihm danach (später) regulär er soll 0% machen ? Und dann fährt der VC "mit Schwung" auf 0% und macht zu. So richtig ? Macht Dein Modul das automatisch ?
vg
Jörg
nachtrag:
ZitatWie gesagt, ist nur ein angebot
sagt ja gar keiner was, im Gegenteil ... 8)
Was mir eben noch eingefallen ist: der TC schafft es ja sichtlich die VD "unter" 0% zu stellen wenn man ihn auf "off" schaltet. Der Königsweg ist doch das in Dein Modul einzubauen! Ist doch besser als das Ventil in einem ohnehin über-heizten Raum nochmal weiter aufzumachen.
vg
Jörg
Zitatder TC schafft es ja sichtlich die VD "unter" 0% zu stellen wenn man ihn auf "off" schaltet. Der Königsweg ist doch das in Dein Modul einzubauen! Ist doch besser als das Ventil in einem ohnehin über-heizten Raum nochmal weiter aufzumachen.
das verstehe ich jetzt nicht. Mit unter sendet der TC 0% und der VD bleibt bei 1%. Oder der TC sendet 0% und der VD meldet 0%, ist aber nicht dicht. In beiden Fällen sagt der TC 0% - weniger geht nicht. Der TC sagt dem VD
nie off . (FHEM dem TC übrigens auch nicht, ist nur für User - ist einfach min temp).
Sollte es bei dir Funktionieren, den VD mit "off" auszuschalten ist alles in Butten, vergiss den Workaround.
Solltest du Probleme haben wäre mein vorschlag - nach der Erkennung! - ein valvePos 10 (oder 20 oder sonst etwas) zu senden. Klar wird es erst einmal wärmer - aber nach 2,5min sollte dann zu sein.
Der aktuell gepostete workaround macht doch nichts anderes - nur indirekt und mit 2 Schritten (hoch setzen solltemp=>vd öffnen =>runtersetzen solltemp=> vd schliessen mit Schwung)
Im übrigen könnte man mutmassen, das der VD beim stellen kleiner werte - insbesondere im schwergängigen Bereich (wenn das Ventil gegendruck hat)- ein Problem hat, den Motor zu bewegen. Könnte an der Batteriespannung liegen (akku oder Batterie?, Batterie alt?). Nur eine Idee
@Jörg und Martin,
danke für eure Rückmeldung.
Ich wollte eigentlich die Variante mit Solltemp=30°C (bzw. on) wählen, da das bisher mit manuellem Eingriff immer gefunzt hat. Aber da ist ja immer das Problem, bei zu hohen Ist-Temp. den VD nicht mehr öffnen zu können.
@Martin:
Habe ich dich richtig verstanden, dass deine Variante den VD immer öffnet - egal welche Ist-Temp. herrscht?
Im letzten Jahr hatte ich übrigens - wie weiter oben angekündigt - die VDs und TCs eingeschickt und komplett neue bekommen (VD-FW 2.0 und TC-FW 2.1). Aber offensichtlich ist der Fehler nicht behoben. Gibt es für die VDs schon die FW 2.1 und wenn ja hat jemand Erfahrungen mit diesem Fehler?
Ich werde mal eure beide Varianten in den beiden verschiedenen Räumen einbauen und schauen was passiert...
Schönen Sonntag
Uwe
@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?
Danke Uwe
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
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
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
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
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