PRESENCE cover version - anderer Ansatz basierend auf aktuellem Code

[JoWiemann]

Hallo Robert,

ehrliche Antwort. Ich habe keine Ahnung. Wie schon mal erwähnt. Ich habe das Modul übernommen und es bisher nur immer insoweit reengeniered, um Fehler oder Anforderungen umsetzen zu können.

thresholdAbsence zu reengenieren war bisher nicht notwendig.

Grüße Jörg

[bertl]

Alles klar!

Dann bitte "thresholdAbsence" in der Commandref von PRESENCE2 so wie "absenceThreshold" von PRESENCE anpassen.

Danke, Robert

[Nobbynews]

Hallo Jörg,

auf fehlende Perl Module hin

Ich habe versucht die fehlenden Module nachzuinstallieren.
Für IO::Async::Loop habe ich diese debian Paket gefunden:

Code Auswählen Erweitern

apt-get install libio-async-perlHat auch soweit den Hinweis im Log-File beseitigt.
Aber für Net::Async::Ping habe ich nur über cpan etwas gefunden:

Code Auswählen Erweitern

cpan install Net::Async::PingDas beseitigt den Log-Eintrag aber leider nicht. FHEM habe ich neu  gestartet und auch den Pi neu gestartet.
Welches Modul ist denn hierfür zuv installieren?

Norbert

[JoWiemann]

Hallo Norbert,

Du musst die Module nicht zwingend installieren. Nur wenn Du auch die entsprechende Funktion nutzen willst. Die Einträge im Log beim Start sind nur ein Hinweis. Siehe auch commandRef. Für net::Async::Ping kann Dir sicherlich Sidey weiterhelfen. Ich habe das einfach aus seinem Vorschlag übernommen, aber nicht wirklich getestet.

Grüße Jörg

[Nobbynews]

Hallo Jörg,

Du musst die Module nicht zwingend installieren.

da ich immer mal wieder Probleme mit dem normalen lan-ping des Moduls habe, wollte ich auf meinem Testsystem mit den Funktionen ein bisschen spielen.

Norbert

[Nobbynews]

Hallo Jörg,

jetzt habe ich Net::Async::Ping doch installieren können, und zwar mit cpanm

Code Auswählen Erweitern

sudo cpanm --install Net::Async::Ping
Im Log steht jetzt nur noch

Code Auswählen Erweitern

2026.08.03 11:29:23 3: PRESENCE2 (PsnceDaemon) - 'missingModul:
Norbert

[JoWiemann]

Hallo Norbert,

danke für die Info. Die Log Zeile passe ich noch an.

Grüße Jörg

[bmwfan]

Betreff: PRESENCE2 – thresholdAbsence verzögert nur "present", nicht "absent" – Fehlalarme bei kurzen Mesh-Roaming-Lücken

Hallo zusammen,

ich nutze PRESENCE2 zur Anwesenheitserkennung von Smartphones, jeweils parallel über zwei Wege pro Person, die in einer structure zusammengefasst werden:

Modus lan-ping (direkter Ping auf feste IP)
Modus function mit checkAllFritzMACpresent(...) (Auswertung der FritzBox-WLAN-Anmeldetabelle über FritzSmart)

Das Zuhause ist über einen Master FrritzBox7530 und mehrere FritzBox-Repeater im WLAN-Mesh abgedeckt. Beim Roaming eines Smartphones zwischen zwei Repeatern kommt es zu kurzen Lücken, in denen das Gerät im Netz nicht erreichbar ist und deswegen als Abwesend gekennzeichnet wird. Das habe ich anhand des FritzBox-Ereignisprotokolls (WLAN-Ereignismeldungen) nachvollzogen:

13:20:12  Pixel-8 abgemeldet (5 GHz) bei FritzRep-1200AX-Garage
13:20:22  Pixel-8 abgemeldet (2,4 GHz) bei FritzRep-1200AX-Garage
13:21:04  Pixel-8 angemeldet (2,4 GHz) bei FritzRep-1200AX-Garage
13:21:24  Pixel-8 abgemeldet bei FritzRep-1200AX-Garage
13:22:42  Pixel-8 abgemeldet (5 GHz) bei FritzRep-1200-Terrasse
13:23:24  Pixel-8 abgemeldet (5 GHz) bei FritzRep-3000-WZ, IP ---

Zeitgleich zeigt das PRESENCE2-Device (lan-ping, IP-basiert) genau in diesem Fenster einen Fehlalarm:

lastAppear:    2026-09-22 12:12:40
lastDisappear:  2026-09-22 13:22:41  <- 1 Sekunde vor der Abmeldung an der Terrasse im FritzBox-Log

34 Sekunden später ist das Device wieder "present", das Handy war die ganze Zeit im Haus.

Meine Frage: Ich hatte erwartet, dass sich ein solcher kurzzeitiger Ausfall über das Attribut thresholdAbsence abfedern lässt. Laut commandref gilt aber:

Die Anzahl der Prüfungen, welche in "present" resultieren müssen, bevor der Status der PRESENCE-Definition auf "present" wechselt. [...] Standardwert ist 1 (keine Kontrolle der Anwesenheitsverifizierung)

Das Attribut wirkt also offenbar nur beim Übergang nach "present", nicht beim Übergang nach "absent". Mein Fall bestätigt das: Der Wechsel nach "absent" erfolgte ohne erkennbare Verzögerung nach vermutlich einer einzigen fehlgeschlagenen Prüfung (thresHldCnt stand bei 0), obwohl thresholdAbsence 5 gesetzt war.

Gibt es ein Attribut oder eine vorgesehene Möglichkeit, umgekehrt den Wechsel nach "absent" erst nach mehreren aufeinanderfolgenden fehlgeschlagenen Prüfungen vorzunehmen (quasi ein thresholdPresence)? Falls nicht: Wäre das etwas, das sich ergänzen ließe, oder gibt es einen empfohlenen Weg, das über pingParam (z. B. großzügigere -c/-w-Werte) oder eine externe Entprellung (DOIF/notify) sauberer zu lösen? Ich bin sicherlich nicht der einzige, der Android-Smartphone im WLAN-Mesh nutzt undd aher müsste es doch eine Lösung geben.

Nutze aktuell:

PRESENCE2 Version 01.05; 73_PRESENCE2.pm Rev. 31562 vom 2026-08-13 13:10:19Z jowiemann
FHEM auf Docker (fhem/fhem:latest), Perl 5.038005; fhem.pl Rev. 31669 vom 2026-09-20
FritzSmart Version 26.09.15; 72_FritzSmart.pm Rev. 31650 vom 2026-09-15 13:06:00Z jowiemann

Danke für jeden Hinweis!

[bertl]

Aufgrund der Beschreibung und des Verhaltens müsste das Attribut 'thresholdAbsence' eigentlich 'thresholdPresence' heißen.

Und für deinen Fall fehlt dann das gegenteilige Attribut - welches ich auch begrüßen würde.

Beim Aufräumen haben ich schon einmal aus meiner Sicht ungeeignete Attribute entfernt. So ist ein thresholdPresent aus meiner Sicht sinnlos. Wenn ich ein Device einmal sehe ist es da. Umgekehrt ist es sinnvoll. Man muss nicht alles implementieren, was technsich möglich ist, wenn es inhaltlich keinen Sinn macht.

So wich ich das sehe, hat der damalige Modulautor zwar das Attribut 'thresholdPresence' entfernt aber 'thresholdAbsence' hat die Logik von 'thresholdPresence' bekommen.
Somit kann ich seiner Aussage, dass 'thresholdPresence' überflüssig ist, durchaus etwas abgewinnen, aber die Logik von 'thresholdAbsence' müsste korrigiert werden!

'thresholdAbsence': state wird erst nach einer gewissen Anzahl von 'absent' von 'present' auf 'absent' geändert. dazwischen wird 'presence' auf 'maybe absent' gesetzt

Jörg vielleicht kannst du die Logik von 'thresholdAbsence' richtig stellen?

Gruß, Robert