Hallo zusammen,
nach meinen gestrigen Update liefert presence einen timeout state.
Besteht die Möglichkeit dieses timeout zu unterdrücken?
Mein Watchdog ist absent und present gewohnt. Ein zusätzliches timeout mag er nicht.
Danke
Gruß Mark
Änderungen an presence:
--- a/FHEM/73_PRESENCE.pm
+++ b/FHEM/73_PRESENCE.pm
@@ -1,4 +1,4 @@
-# $Id: 73_PRESENCE.pm 15140 2017-09-26 09:20:09Z markusbloch $
+# $Id: 73_PRESENCE.pm 15194 2017-10-04 16:26:36Z markusbloch $
##############################################################################
#
# 73_PRESENCE.pm
@@ -1140,7 +1140,7 @@ sub PRESENCE_ProcessLocalScan($)
sub PRESENCE_ProcessAbortedScan($)
{
- my ($hash) = @_;
+ my ($hash, $msg) = @_;
my $name = $hash->{NAME};
delete($hash->{helper}{RUNNING_PID});
RemoveInternalTimer($hash);
@@ -1149,13 +1149,13 @@ sub PRESENCE_ProcessAbortedScan($)
{
if($hash->{helper}{RETRY_COUNT} >= 3)
{
- Log3 $hash->{NAME}, 2, "PRESENCE ($name) - device could not be checked after ".$hash->{helper}{RETRY_COUNT}." ".($hash->{helper}{RETRY_COUNT} > 1 ? "retries" : "retry"). " (resuming normal operation)" if($hash->{helper}{RETRY_COUNT} == 3);
+ Log3 $hash->{NAME}, 2, "PRESENCE ($name) - device could not be checked after ".$hash->{helper}{RETRY_COUNT}." ".($hash->{helper}{RETRY_COUNT} > 1 ? "retries" : "retry"). " (resuming normal operation): $msg" if($hash->{helper}{RETRY_COUNT} == 3);
InternalTimer(gettimeofday()+10, "PRESENCE_StartLocalScan", $hash, 0) unless($hash->{helper}{DISABLED});
$hash->{helper}{RETRY_COUNT}++;
}
else
{
- Log3 $hash->{NAME}, 2, "PRESENCE ($name) - device could not be checked after ".$hash->{helper}{RETRY_COUNT}." ".($hash->{helper}{RETRY_COUNT} > 1 ? "retries" : "retry")." (retrying in 10 seconds)";
+ Log3 $hash->{NAME}, 2, "PRESENCE ($name) - device could not be checked after ".$hash->{helper}{RETRY_COUNT}." ".($hash->{helper}{RETRY_COUNT} > 1 ? "retries" : "retry")." (retrying in 10 seconds): $msg";
InternalTimer(gettimeofday()+10, "PRESENCE_StartLocalScan", $hash, 0) unless($hash->{helper}{DISABLED});
$hash->{helper}{RETRY_COUNT}++;
}
@@ -1164,7 +1164,7 @@ sub PRESENCE_ProcessAbortedScan($)
{
$hash->{helper}{RETRY_COUNT} = 1;
InternalTimer(gettimeofday()+10, "PRESENCE_StartLocalScan", $hash, 0) unless($hash->{helper}{DISABLED});
- Log3 $hash->{NAME}, 2, "PRESENCE ($name) - device could not be checked (retrying in 10 seconds)"
+ Log3 $hash->{NAME}, 2, "PRESENCE ($name) - device could not be checked (retrying in 10 seconds): $msg"
}
readingsSingleUpdate($hash, "state", "timeout",1);
Wenn Dein Watchdog present und absent gewöhnt ist, also darauf matcht dann stört das mit dem timeout nicht
Das timeout erzeugt ein event-on-change-reading, deshalb stört es. Oder ich mache etwas falsch...
Ein Beispiel aus dem Log des presence Teil.
Watchdog wird durch den Wechsel von timeout auf absent unnötig aktiviert um 15:01:44, 15:17:03, 15:22:10
Logfile:
2017-10-05_07:34:50 Mark_PC present
2017-10-05_08:15:25 Mark_PC absent
2017-10-05_15:01:44 Mark_PC timeout
2017-10-05_15:01:44 Mark_PC absent
2017-10-05_15:17:03 Mark_PC timeout
2017-10-05_15:17:03 Mark_PC absent
2017-10-05_15:22:10 Mark_PC timeout
2017-10-05_15:22:10 Mark_PC absent
Watchdog:
Mark_PC:absent 00:08 Mark_PC:present {
fhem "set Steckdose_PC off";
fhem "trigger Mark_PC_wd .";
}
Zitat von: Mark am 06 Oktober 2017, 10:38:26
Das timeout erzeugt ein event-on-change-reading, deshalb stört es. Oder ich mache etwas falsch...
Ein Beispiel aus dem Log des presence Teil.
Watchdog wird durch den Wechsel von timeout auf absent unnötig aktiviert um 15:01:44, 15:17:03, 15:22:10
Logfile:
2017-10-05_07:34:50 Mark_PC present
2017-10-05_08:15:25 Mark_PC absent
2017-10-05_15:01:44 Mark_PC timeout
2017-10-05_15:01:44 Mark_PC absent
2017-10-05_15:17:03 Mark_PC timeout
2017-10-05_15:17:03 Mark_PC absent
2017-10-05_15:22:10 Mark_PC timeout
2017-10-05_15:22:10 Mark_PC absent
Watchdog:
Mark_PC:absent 00:08 Mark_PC:present {
fhem "set Steckdose_PC off";
fhem "trigger Mark_PC_wd .";
}
Das timeout erzeugt ein Event. Aber das stört nicht, sprich Dein watchdog sollte nicht darauf ansprechen.
ZitatDein watchdog sollte nicht darauf ansprechen.
Okay, Du meinst der "Fehler" liegt bei meinem Watchdog und nicht an der Änderung des presence Modul ?
Dein watchdog ist eigentlich ok. zu mindest in meiner Testumgebung klappt das
Danke für den Hilfeversuch, ich komme leider nicht weiter.
Für mein Verständnis verhält sich mein Watchdog absolut korrekt. Kommt ein Mark_PC:absent wird er aktiviert, folgt 8 Minuten später KEIN Mark_PC:presence, löst er aus.
Das zusätzliche absent/timeout kommt seit dem Update vom presence modul. Daher sehe ich dort die Ursache.
Die folgenden Attribute sind noch am Watchdog gesetzt (falls Du testen möchtest):
attr Mark_PC_wd autoRestart 1
attr Mark_PC_wd regexp1WontReactivate 1
Das Verhalten das watchdog hat sich durch den Timeout wirklich geändert.
Ob Dein Vorschlag zur Rückänderung von presence übernommen wird, solltest Du den Vorschlag im entsprechenden Unterforum machen Unterstuetzende Dienste
Allerdings dürfte das problem auch durch die Änderung an Blocking -> siehe verschiedene Threads dazu beeinflusst.
Ansonsten bleibt Dir nur den watchdog anzupassen und zum Beispiel bei timeout status keine Nachricht zu senden, denn das Abschlaten ist ja vermutlich kein Problem
Danke für Dein Feedback. Ich habe das Thema in "Unterstuetzende Dienste" verschoben.
Vielleicht meldet sich ja der Author markusbloch.
Ich erwarte keine Rückänderung, sondern möchte auf den Seiteneffekt der Änderung hinweisen.
Für diesen Fall existiert das Reading "presence". Es hat nur die Werte "absent" oder "present". Wenn der Watchdog also nur auf "presence:.present" bzw. "presence:.absent" lauscht, dann ist doch alles OK. Genau deswegen ist das Reading da. Das Reading state gibt einen allgemeinen Status zu der Definition ab. Das kann natürlich absent/present sein, aber eben auch "error" oder "timeout".
Viele Grüße
Markus
Hallo Markus,
aber wie ist das denn dann bei einer Structure, die verschiedene PRESENCE devices (z.B BT, GTAG, WLAN) zusammenfasst?
Die Structure fasst ja den "state", aber nicht das reading "presence', zusammen, oder?
Ich kann zwar beim einzelnen Presence wie beim Beispiel von Mark auf "Mark_PC:presence:.absent oder Mark_PC:presence:.present triggern,
aber spätestens wenn ich eine structure für mehrere PRESENCE devices verwende, hat man wieder das gleiche Thema.
Aus der Commandref:
Zitatclientstate_behavior Der Status einer Struktur hängt von den Status der zugefügten Devices ab.
Bei einer structure kann man dies mit clientstate_behavior = "relativeKnown" und clientstate_priority anpassen. Dort kannst du dann nur present/absent angeben und alle anderen Werte werden ignoriert.
Gruß
Markus
Was wäre den euer Vorschlag wie ich mit Timeouts umgehen sollte? Nur ins Log schreiben?
Gruß
Markus
Genauso wie bisher also wie dokumentiert - die Information gehört auch in den Status des devices- die Unterschiede zwischen Reading presence und state erlaubt aus meiner Sicht ja den hier behandelten use case.
Hallo Markus,
das passt so für mich, ich habe es auch wie Du vorgeschlagen hast, mit clientstate_behavior relativeKnown und clientstate_priority gelöst.
Das timeout gehört auch ins 'state'. Danke !