Homematic Ventil hängt bei 1%

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

Vorheriges Thema - Nächstes Thema

moonser

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

martinp876

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

moonser

Nabend Martin,

Problem ist hier beschrieben: http://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

martinp876

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

Billy

@moonser
Du schreibst, dass das Problem  hier beschrieben ist:
ZitatProblem ist hier beschrieben: http://www.fhemwiki.de/wiki/HM-CC-VD_Funk-Stellantrieb
http://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
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

dougie

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!

Tratonis

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

Rohan

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
Fhem auf Mini-ITX mit Celeron 2-Core, HMLAN (> 55 Devices), CUL (FS20 und EM), RFXtrx 433E, Arduino (einige DS18B20), RPi mit 1-Wire (DS2423 für S0-Signale, DS18B20+), RPi/Arduino mit MQ-5 und MQ-9 (CO- und CNG/LPG-Sensor), CO-20 IAQ Sensor

martinp876

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




moonser

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



martinp876

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

dougie

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

martinp876

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

moonser

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


dougie


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