Homematic Ventil hängt bei 1%

[Rohan]

Hallo Martin,

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.

Hmmm.... mal kurz überschlagen: 10 Heizkörper und 0 Zeilen Code für solche Anwendungsfälle wie du sie schilderst/hast. Deshalb ..

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

Technik 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 ;)

[Rohan]

Weil's wesentlich ist, kein Edit, sondern neuer Post:

deine Peer-IDs vom VD sind leer  => unsauber konfiguriert!

Gruß
Thomas

[LuckyDay]

Code Auswählen Erweitern

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

[moonser]

@ 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 ;-)

@

[martinp876]

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

[moonser]

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

[locodriver]

@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

[martinp876]

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

[herrmannj]

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)

Code Auswählen Erweitern


##############################################
# $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



[martinp876]

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

[herrmannj]

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

[herrmannj]

nachtrag:

Wie gesagt, ist nur ein angebot

sagt ja gar keiner was, im Gegenteil ... 

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

[martinp876]

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.

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

[locodriver]

@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

[locodriver]

@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