FHT und "lazy mode"?
Juergen Lennefer
da drei meiner FHTs momentan im Dachgeschoss unter "reduzierten"
Bedingungen laufen (nach dem Tod meines Sohnes im Februar wohnt da
keiner mehr, deshalb steht desired-temp auf 13.0), haben die dort nach
dem Upgrade auf FHEM 5.0 des öfteren das lime-protection Problem.
Heute wollte ich dann den (in der FAQ nicht ganz richtigen) Workaround
einsetzen. Nachdem ich die Falle mit den Kontextvariablen umschifft
hatte (zusätzliche Zeile: my ($d, $m);;\, bekomme ich nun folgende
Meldungen:
2010.11.29 21:09:43 2: FHT set fht.dg.bad desired-temp 29.0
2010.11.29 21:09:43 2: Lazy mode ignores desired-temp 13.0
Lazy mode ignores desired-temp
Kennt das jemand? Die Suche sagt: nein.
Gruß,
Jürgen
Juergen Lennefer
FHTs:
# lazy
If the lazy attribute is set, FHEM won't send commands to the FHT if
the current reading and the value to be set are already identical.
This may help avoiding conflicts with the max-1%-time-on-air rule in
large installations. Not set per default.
Sorry .... duck und wech ...
Juergen Lennefer
Workaroud im Lazy-Mode nicht funktioniert, oder?
Alternativ sollte man den dann kurz abschalten, um die Workaround-
Sequenz ablaufen zu lassen. Vorschlag:
# Lime-protection Workaround
define lime_reset notify .*lime-protection {\
my ($d, $m);;\
$d = $defs{'@'}{READINGS}{"desired-temp"}{VAL};;\
$m = $defs{'@'}{READINGS}{"measured-temp"}{VAL};;\
if($m gt $d) {\
fhem("attr @ lazy 0");;\
fhem("set @ desired-temp 29");;\
fhem("set @ desired-temp $d");;\
fhem("attr @ lazy 1");;\
}\
}
Allerdings wäre es universeller, wenn man sich den Wert des lazy-
Attributes vorher in einer Variablen sichern und den dann hinterher
wieder setzen würde, damit jemand anderes nicht ungewollt seinen FHT
auf "lazy" gesetzt bekommt.
Wie ich allerdings ein Attribut eines FHT auslese, weiß ich noch
nicht. Please help ... ;-)
Gruß,
Jürgen
Zrrronggg!
Limeprotektion Bug nicht einfach durch Hochsetzen der Temperatur
umgeht. Es ist ja bekannt, WANN Limeprotektion ist. Danach mit FHEM
die desired Temp für paar Minuten auf 20 Grad und direkt wieder
zurück. Müsste es tun und geht auch mit Lazy Mode.
Oder sehe ich da was falsch?
Juergen Lennefer
zuruck auf den vorher eingestellten Wert, heir 13 Grad.
Nur im Lazy-Mode gibt FHEM die Umstellung auf die alte Temperatur
nicht durch, weil die hohe Temperatur noch nicht angekommen bzw.
zurück gemeldet wurde und FHEM der Meinung ist, dass der FHT doch eh
schon auf 13 Grad steht, da gibt's dann nichts zu tun. So schnell geht
das eben nicht mit dem Temperaturwechsel.
Alternativ könnte man zum Rücksetzen der Temperatur einen temporären
notify aufsetzen, der dann erst wieder auf den alten Wert zurücksetzt.
Aber ich finde, den Lazy-Mode kurz abschalten ist einfacher.
Juergen Lennefer
Natuerlich hast Du recht. Statt des dynamischen Workaround hilft es
auch, alle FHTs, die eine Soll-Temperatur niedriger als die Ist-
Temperatur eingestellt haben, kurz vor der Lime-Protection-Zeit
(default Sa, 11:00) auf 29 Grad zu stellen und 5 Minuten später wieder
zurück.
Zrrronggg!
auch nicht mehr Batterie.
Jörg71
seit es jetzt wieder wärmer geworden ist (gestern 11 Grad!),
und da bei mir die Lime-Protection auf Sa 16.00 Uhr eingestellt ist,
gibt mir jetzt seitdem FHEM (neu seit November mit CUN auf einem
zur FB7270 gefritzten Speedport W920V) als Ventilstellung im
Schlafzimmer "Lime-Protection" an.
Das Wärmebedarfsrelais FHT 8W, welches ich schon seit 2 Jahren
benutze um meine Heizung zu schalten, zeigt mir für den betreffenden
FHT80b aber korrekt 0 Prozent an. Offenbar wird also einfach die
Lime-Protection als 0 Prozent interpretiert. Wäre das nicht auch in
FHEM
sinnvoll? Man könnte doch einfach ab dem zweiten Empfangen der LP
diese als 0 Prozent interpretieren. So bekommt man mit, dass sie
korrekt
gesendet wurde (Logfile), würde aber dann nicht mehr weiter damit
belästigt. Unnötige Sendevorgänge (s.o.) könnten so vermieden werden.
Tschüs,
Jörg
Rudolf Koenig
> diese als 0 Prozent interpretieren.
Einverstanden, kommt auf die TODO Liste.
Boris Neubert
>> Man könnte doch einfach ab dem zweiten Empfangen der LP
>> diese als 0 Prozent interpretieren.
>
> Einverstanden, kommt auf die TODO Liste.
>
(http://www.fhemwiki.de/index.php/DevelopmentGuidelines):
Neues Reading limeProtection
Zustände: on oder off
Regelung:
- wenn die Nachricht actuator: lime-protection vom FHT empfangen wird,
wird limeProtection auf on gestellt
- wenn ein actuator: x% vom FHT empfangen wird und limeProtection auf on
steht, wird limeProtection auf off gestellt
Viele Grüße,
Boris
Jörg71
> wird limeProtection auf on gestellt
> - wenn ein actuator: x% vom FHT empfangen wird und limeProtection auf on
> steht, wird limeProtection auf off gestellt
Zeit
statt actuator: 0% lime-protection gemeldet wird. Wenn die lime-
protection
erst durch eine %-Meldung zurück gesetzt wird, die ja gerade nicht
kommt,
ändert sich nichts an dem Problem...
Tschüs,
Jörg
Boris Neubert
ich erkläre es an einem Beispiel.
list myFHT gibt derzeit (gekürzt) im Normalfall
Internals:
...
Readings:
2011-01-09 22:35:48 actuator 0%
2011-01-09 22:24:07 battery ok
...
Attributes:
...
aus und im Lime-Protection-Fall
Internals:
...
Readings:
2011-01-09 22:35:48 actuator lime-protection
2011-01-09 22:24:07 battery ok
...
Attributes:
...
Mit meinem Änderungsvorschlag sähe es im Normalfall so aus:
Internals:
...
Readings:
2011-01-09 22:35:48 actuator 0%
2011-01-09 22:35:48 limeProtection off
2011-01-09 22:24:07 battery ok
...
Attributes:
...
Und im Lime-Protection-Fall so:
Internals:
...
Readings:
2011-01-09 22:35:48 actuator 0%
2011-01-09 22:35:48 limeProtection on
2011-01-09 22:24:07 battery ok
...
Attributes:
...
Die lime-protection-Meldungen werden also nicht in das actuator-Reading
geschrieben sondern in das limeProtection-Reading.
Grüße,
Boris
Jan-Hinrich Fessel
Am 09.01.2011 um 21:07 schrieb Boris Neubert:
> Am 09.01.2011 14:46, schrieb Rudolf Koenig:
>>> Man könnte doch einfach ab dem zweiten Empfangen der LP
>>> diese als 0 Prozent interpretieren.
>>
>> Einverstanden, kommt auf die TODO Liste.
>>
> mein Alternativvorschlag, der auf die künftige Version von FHEM hinzielt
> (http://www.fhemwiki.de/index.php/DevelopmentGuidelines):
>
> Neues Reading limeProtection
> Zustände: on oder off
>
> Regelung:
> - wenn die Nachricht actuator: lime-protection vom FHT empfangen wird,
> wird limeProtection auf on gestellt
... und kein actuator-wert geschrieben.
Ich hatte nämlich schon mal den Fall, das die Ventilstellung nicht 0% war, aber lime-protection gemeldet wurde (die gemessene Temperatur war allerdings über der soll-Temperatur). Nach der nächsten Ventilstellungsänderung wurde wieder ein %-Wert gemeldet.
Grüße
Oskar
Hans-Werner Kneitinger
> Ich hatte n�mlich schon mal den Fall, das die Ventilstellung nicht 0% war, aber lime-protection gemeldet wurde (die gemessene Temperatur war allerdings �ber der soll-Temperatur). Nach der n�chsten Ventilstellungs�nderung wurde wieder ein %-Wert gemeldet.
Bei mir hat sich die lime-protection auch etwas anders verhalten. Die
empfohlene Ma�nahme funktionierte nicht. Darum habe ich folgendes Script
geschrieben.
---
.*lime-protection {
my $d = $defs{@}{READINGS}{"desired-temp"}{VAL};
my $m = $defs{@}{READINGS}{"measured-low"}{VAL};
if($m gt $d) {
$m = ($m + 5)/10;
} else {
$m = ($m - 5)/10;
}
fhem("deleteattr @ lazy");
fhem("set @ desired-temp $m");
fhem("set @ desired-temp $d");
fhem("attr @ lazy");
}
---
mfg
hawe
Jörg71
Mal wieder die Lime-protection...
Angeblich bleibt ja nach einer Lime-protection dieser
Befehl einfach stehen. Da ich mir aber sicher war,
daß die Stellantriebe auch im Sommer jeden Samstag
bei mir durchgefahren werden, habe ich mir meine
Logfiles mal genauer angeschaut:
Dabei bin ich zu dem Schluss gekommen, daß die
actuator (raw) Befehle das folgende Format haben:
Tcccc00xyzz
T = FHT-Befehl
cccc = FHT-Code
00 = Befehl an actuator
x = entspricht 2 oder 3 wenn sich die Ventilstellung
zum vorherigen Befehl geändert hat,
und A oder B, wenn sie gleich geblieben ist.
y = 6 bei Normalbetrieb, A bei Lime-protection
zz = Ventilstellung, bleibt während der LP stehen,
wenn sie bei offenem Ventil gestartet wird,
auch bleibt die LP so lange anstehen, bis
sich die Ventilstellung ändert.
Deswegen mein Alternativ-Vorschlag:
xy = x6 ist normale Ventilstellung
xy = 2A oder 3A: LP
xy = AA oder BA: LP gewesen, wieder Ventilstellung
ausgeben.
Der Unterschied zwischen 2/3 und A/B ist mir
schleierhaft: Klar, es wird ein zusätzliches
Bit gesetzt, unabhängig von der Ventilstellung,
dafür aber immer genau von 10-11, 17-18 und 21-22 Uhr
bei allen mein FHTs!
Tschüs,
Jörg
Rudolf Koenig
>
> xy = x6 ist normale Ventilstellung
> xy = 2A oder 3A: LP
> xy = AA oder BA: LP gewesen, wieder Ventilstellung
> ausgeben.
Eingebaut und eingecheckt.
Koennte jemand berichten, ob es auch funktioniert? :)
Juergen Lennefer
Hat das folgende Meldungen zur Folge?
2011-01-16 13:56:15 FHT fht.kg.mz FHZ:actuator: unknown_79: 67%
2011-01-16 13:56:16 FHT fht.kg.mz start-xmit: 35
2011-01-16 13:56:16 FHT fht.kg.mz actuator: unknown_69: 67%
2011-01-16 13:59:35 FHT fht.dg.bad FHZ:start-xmit: 35
2011-01-16 13:59:36 FHT fht.dg.bad start-xmit: 35
2011-01-16 13:59:36 FHT fht.dg.bad FHZ:actuator: unknown_79: 67%
2011-01-16 13:59:36 FHT fht.dg.bad actuator: unknown_69: 67%
2011-01-16 14:01:11 FHT fht.eg.sz FHZ:start-xmit: 35
2011-01-16 14:01:12 FHT fht.eg.sz start-xmit: 35
2011-01-16 14:01:12 FHT fht.eg.sz FHZ:actuator: unknown_79: 65%
2011-01-16 14:01:12 FHT fht.eg.sz actuator: unknown_69: 65%
Eigentlich stehen alle Aktuatoren auf 0%, denn es gibt nichts zu
heizen?!
Rudolf Koenig
> heizen?!
Ist ja auch "unknown_69", insofern kann man die Argumente ignorieren. 9 ist
unbekannt, genauso wie 3,4,5,7,b und d. Die anderen 9 Werte sind fhem bekannt.
Jörg71
Die seltsamen "actuator: unknown_69"-Ausgaben hatte ich
neulich auch schon mal von einem FHT, der auch nicht mehr
reagierte und wo sich der CUN-Puffer füllte. Nach einem
Neustart des CUN ohne antasten des FHTs lief dieser dann
auch wieder normal...
Nachdem ich jetzt auf FHEM 5.0 umgestellt habe, konnte ich
auch die neue Version des FHT.pm übernehmen, Bei mir
funktioniert die Ausgabe der LP und der Ventilstellung jetzt
so wie erwartet.
Eigentlich könnte man aber auch den Vorschlag vom
Boris Neubert noch mit einbeziehen:
Die Ventilstellung würde immer ausgegeben wenn xy gleich
x6 (normal) oder xA (LP hängengeblieben) ist, wenn ein
2A oder 3A (Befehl, der LP auslöst) empfangen wird, würde
einmalig ein zusätzliches Reading "Lime-protection" mit
z.B. dem Wert "OK" ausgegeben. Dann würde die
Ventilstellung gar nicht mehr mit der LP belastet und man hätte
so eine einzelne Meldung für die Ausführung der LP.
Den Grund für die Ausgaben 2/3 und A/B glaube ich
übrigens auch gefunden zu habe:
Das ominöse zusätzliche Bit wird immer genau von 10-11,
17-18 und 21-22 Uhr bei allen meinen FHTs gesetzt.
Laut der Anleitung des FHT8V (Ventilantrieb) wird eine
schwache Batterie dreimal am Tag für eine Stunde lang alle
zwei Minuten gemeldet. Da der FHT8V ja selbst keine Uhr
hat, vermute ich, das mit diesem Bit das Piepen dafür frei-
gegeben wird. Das ist auch sehr sinnvoll, weil so vermieden
wird, daß es mitten in der Nacht losgeht, für Schichtarbeiter
wie mich aber trotzdem nicht ganz passend...
Tschüs,
Jörg
Zrrronggg!
>wird, daß es mitten in der Nacht losgeht, für Schichtarbeiter
>wie mich aber trotzdem nicht ganz passend...
los... ich gehe normal um 4 ins Bett. Die 6ß% Frühaufsteher
terrorisieren die 40% Spätaufsteher wo sie nur können!
(Zahlenmässige Verteilung entspricht ungefähr der tatsächlichen
genetischen Dispostion in der Bevölkerung, die einem zum Frühaufsther
oder Spätaufsteher macht)
Die Lebensdauern der Batterien sind überraschend ähnlich und alle ca.
1,5 Jahre piepts in einem Zeitraum von 6-8 Wochen immer irgendwo im
Haus. Bs ich dann alle 16 Antriebe durchgetauscht habe.
Leer sind die Batterien übrigens lange nicht, die würden wenn sie
anfangen zu piepen noch locker 2-3 MOANTE weiter durchhalten.
Seufz.