FHT und "lazy mode"?

Guest · 29 November 2010, 21:17:50

Originally posted by: <email address deleted>

Hallo,

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

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Guest · 29 November 2010, 21:23:14

Originally posted by: <email address deleted>

Hab's doch gefunden, in der Command-Reference bei den Attribs für
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 ...

On 29 Nov., 21:17, Juergen Lennefer wrote:
> Hallo,
>
> 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

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Guest · 29 November 2010, 21:36:30

Originally posted by: <email address deleted>

In der Konsequenz heißt das aber doch, dass der Lime-Protection-
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

On 29 Nov., 21:23, Juergen Lennefer wrote:
> Hab's doch gefunden, in der Command-Reference bei den Attribs für
> 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 ...
>
> On 29 Nov., 21:17, Juergen Lennefer wrote:
>
> > Hallo,
>
> > 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
>
>

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Guest · 29 November 2010, 21:49:20

Originally posted by: <email address deleted>

In der Konsequenz heißt das aber doch, dass der Lime-Protection-
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

On 29 Nov., 21:23, Juergen Lennefer wrote:
> Hab's doch gefunden, in der Command-Reference bei den Attribs für
> 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 ...
>
> On 29 Nov., 21:17, Juergen Lennefer wrote:
>
> > Hallo,
>
> > 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
>
>

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Zrrronggg! · 30 November 2010, 03:52:33

Was ich noch nicht ganz verstanden habe, ist wieso man den
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?

On 29 Nov., 21:49, Juergen Lennefer wrote:
> In der Konsequenz heißt das aber doch, dass der Lime-Protection-
> 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
>
> On 29 Nov., 21:23, Juergen Lennefer wrote:
>
>
>
> > Hab's doch gefunden, in der Command-Reference bei den Attribs für
> > 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 ...
>
> > On 29 Nov., 21:17, Juergen Lennefer wrote:
>
> > > Hallo,
>
> > > 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

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Guest · 30 November 2010, 10:03:13

Originally posted by: <email address deleted>

Genau das macht der Workaround. Kurz hoch auf 29 Grad, dann wieder
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.

On Nov 30, 3:52 am, "Zrrronggg!" wrote:
> Was ich noch nicht ganz verstanden habe, ist wieso man den
> 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?
>
> On 29 Nov., 21:49, Juergen Lennefer wrote:
>
> > In der Konsequenz heißt das aber doch, dass der Lime-Protection-
> > 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
>
> > On 29 Nov., 21:23, Juergen Lennefer wrote:
>
> > > Hab's doch gefunden, in der Command-Reference bei den Attribs für
> > > 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 ...
>
> > > On 29 Nov., 21:17, Juergen Lennefer wrote:
>
> > > > Hallo,
>
> > > > 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
>
>

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Guest · 30 November 2010, 10:22:04

Originally posted by: <email address deleted>

Wer alles liest, weiß auch die richtige Antwort.

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.

On 30 Nov., 03:52, "Zrrronggg!" wrote:
> Was ich noch nicht ganz verstanden habe, ist wieso man den
> 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?
>
> On 29 Nov., 21:49, Juergen Lennefer wrote:
>
>
>
>
>
>
>
> > In der Konsequenz heißt das aber doch, dass der Lime-Protection-
> > 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
>
> > On 29 Nov., 21:23, Juergen Lennefer wrote:
>
> > > Hab's doch gefunden, in der Command-Reference bei den Attribs für
> > > 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 ...
>
> > > On 29 Nov., 21:17, Juergen Lennefer wrote:
>
> > > > Hallo,
>
> > > > 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

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Zrrronggg! · 30 November 2010, 14:53:03

Eben, das bringt auch keine zusätzliche Ventilbewegung, braucht also
auch nicht mehr Batterie.

On 30 Nov., 10:22, Juergen Lennefer wrote:
> Wer alles liest, weiß auch die richtige Antwort.

>
> 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.
>
> On 30 Nov., 03:52, "Zrrronggg!" wrote:
>
>
>
> > Was ich noch nicht ganz verstanden habe, ist wieso man den
> > 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?
>
> > On 29 Nov., 21:49, Juergen Lennefer wrote:
>
> > > In der Konsequenz heißt das aber doch, dass der Lime-Protection-
> > > 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
>
> > > On 29 Nov., 21:23, Juergen Lennefer wrote:
>
> > > > Hab's doch gefunden, in der Command-Reference bei den Attribs für
> > > > 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 ...
>
> > > > On 29 Nov., 21:17, Juergen Lennefer wrote:
>
> > > > > Hallo,
>
> > > > > 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

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Guest · 09 Januar 2011, 08:58:22

Originally posted by: <email address deleted>

Hallo,

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

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

rudolfkoenig · 09 Januar 2011, 14:46:07

> Man könnte doch einfach ab dem zweiten Empfangen der LP
> diese als 0 Prozent interpretieren.

Einverstanden, kommt auf die TODO Liste.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Dr. Boris Neubert · 09 Januar 2011, 21:07:41

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
- wenn ein actuator: x% vom FHT empfangen wird und limeProtection auf on
steht, wird limeProtection auf off gestellt

Viele Grüße,
Boris

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Guest · 09 Januar 2011, 21:40:19

Originally posted by: <email address deleted>

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

Das verstehe ich jetzt nicht: Das Problem ist doch, dass die ganze
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

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Dr. Boris Neubert · 09 Januar 2011, 22:42:00

Hallo,

Am 09.01.2011 21:40, schrieb Jörg71:
>> - 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
>
> Das verstehe ich jetzt nicht: Das Problem ist doch, dass die ganze
> 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...

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

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Oskar · 11 Januar 2011, 11:05:12

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

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Guest · 11 Januar 2011, 18:53:22

Originally posted by: <email address deleted>

Am 11.01.2011 11:05, schrieb Jan-Hinrich Fessel:

> 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

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

FHEM Forum

FHT und "lazy mode"?

Guest

Guest

Guest

Guest

Zrrronggg!

Guest

Guest

Zrrronggg!

Guest

rudolfkoenig

Dr. Boris Neubert

Guest

Dr. Boris Neubert

Oskar

Guest