PRESENCE cover version - anderer Ansatz basierend auf aktuellem Code

[gestein]

Nach mehrmaligem Reboot passt nun alles.
Die neuen Devices funktionieren und werden im Deamon angezeigt.

lg, Gerhard

[Frank_Huber]

Reboot tut immer gut. 😂🤪

Ne, denke eher da hat was mit dem reload nicht gepasst.
Ich freue mich auch schon auf nen Test der neuen Version.
Hab presence nur per ping laufen. Zwar keine Probleme bemerkt, denke aber dass sie da sind die Probleme, nur eben unbemerkt....

[Benni]

korrekt. Sie werden in das Attribut übernommen (kompatibilität) und dann ggf durch eine explizizes Attribut überschrieben.  <...> Nach dem ersten Reboot/save ist es also Geschichte

Das hat bei mir letztendlich nicht funktioniert (neueste Version), die Attribute waren nach save und restart trotzdem alle auf 30 Sekunden.
Habe dann die Attribute nochmal explizit von Hand gesetzt und gespeichert, dann hat's gepasst.
Ist aber kein Beinbruch und der Aufwand zu vernachlässigen.

Das könnte ich prüfen... ist aber viel Code frü wenig Brot.

Allerdings! Das ist keinen Aufwand wert!

gb#

[the ratman]

dumme zwischenfrage:

würde ich dieses presence-modul verwenden, bliebe das auch für module kompatibel, die presence verwenden? z.b. das lg-tv modul? oder hab ich da eh nur was mißverstanden und das "alte" presence modul hat nix mit presence in anderen modulen gemein?

und noch ne dumme idee: warum nennt man das gute stück nicht einfach "ping" oder ähnlich? dann könnts nebenher existieren.

[Benni]

dumme zwischenfrage:

würde ich dieses presence-modul verwenden, bliebe das auch für module kompatibel, die presence verwenden? z.b. das lg-tv modul? oder hab ich da eh nur was mißverstanden und das "alte" presence modul hat nix mit presence in anderen modulen gemein?

Interessante Frage: "Wird das Modul von anderen Modulen verwendet?"

Ein schneller grep hat mir keine Verwendung von 73_PRESENCE.pm in irgendeinem weiteren Modul gefunden.

Ich habe mir mal dann noch kurz in der commandref für beide existierenden lg-tv Module die entsprechenden Einträge durchgelesen. Da steht nix, dass die PRESENCE verwenden würden.

Im Wiki habe ich gesehen, dass lg-tv WebOS zumindest ein Reading "presence" bereitstellt. Das hat aber sicherlich nichts mit dem PRESENCE-Modul zu tun.

Ich gehe mal davon aus, dass das vom lg-tv-Modul internt geprüft wird. Darauf deutet auch der entsprechende Satz in der Commandref hin:
"Bei der Definition eines LGTV_WebOS-Moduls wird eine interne Routine in Gang gesetzt, welche regelmäßig alle 15s den Status des TV abfragt und entsprechende Notify-/FileLog-Definitionen triggert."

Von daher sollte deine Sorge unbegründet sein

gb#

[gestein]

Hallo,

Habe mir zum Testen ca. 50 neue Presence-Devices für alle Geräte in meinem Netz angelegt.
Die zeigen auch absent/present und im Deamon angezeigt.

Allerdings stimmt der Status eigenartigerweise nicht bei allen Geräten.
Manche Geräte werden als absent gezeigt, obwohl es definitiv im Netz erreichbar ist.
Ping unter Windows liefert ,,erreichbar" und über Webinterface sind die auch ansprechbar.

Ein Neustart hat etwas geholfen, die allermeisten sind auf present.
Aber nicht alle.

Also habe ich im Deamon ,,verbose 5" gesetzt.
Im log erscheint nun alle 30sec. ,,PRESENCE (PsnceDeamon) - skip Scan due to running job".
Und das Reading ,,skipDeamonCnt" wird periodisch alle 30sec. auf 1 gesetzt.

Ich nehme an, dass die 50 pings zu viel für 30sec. sind.
Allerdings meldet der Deamon auch nach 30min nichts anderes.

Ist es möglich im Deamon ein Reading einzubauen, in dem man die letzte Meldung sieht?
Also z.B. ,,ok" Oder eben diese Meldung?

Lg, Gerhard

[binford6000]

Moin Zusammen,
lese hier schon von Anfang mit und habe jetzt auf meinem Testsystem das neue PRESENCE losgelassen.
Erstmal vielen DANK @martinp876 für die tolle Arbeit! 

Habe zum Test einmal lan-ping (Fritte) und einmal function (PREDeamon) angelegt.
Beide habe ich in die static Group gepackt. Beide sind present aber in den  Readings vom PsnceDaemon sind trotzdem beide absent:

Code Auswählen Erweitern

Internals:
   ADDRESS    deamon
   DEF        deamon deamon
   FUUID      5fe85f4e-f33f-fe74-270d-a9e899ede42a0dfb
   FVERSION   73_PRESENCE.pm:0.183140/2019-01-18
   MODE       deamon
   NAME       PREDeamon
   NOTIFYDEV  global
   NR         85
   NTFY_ORDER 50-PREDeamon
   STATE      active
   TYPE       PRESENCE
   CL:
     Authenticated 0
     BUF       
     FD         17
     FW_ID      91
     LASTACCESS 1609065949
     NAME       WEB_10.3.3.30_52534
     NR         153
     PEER       10.3.3.30
     PORT       52534
     SNAME      WEB
     SSL       
     STATE      Connected
     TEMPORARY  1
     TYPE       FHEMWEB
     canAsyncOutput 1
     READINGS:
       2020-12-27 11:45:29   state           Connected
   READINGS:
     2020-12-27 11:40:58   model           deamon
     2020-12-27 11:45:36   pGrp_default    ab:0 pres:0
     2020-12-27 11:45:36   pGrp_dynamic    ab:0 pres:0
     2020-12-27 11:45:36   pGrp_static     ab:2 pres:0
     2020-12-27 11:45:36   pr_prfunct      present
     2020-12-27 11:45:36   pr_prping       present
     2020-12-27 11:45:36   state           active
   helper:
     curState   init
     maybe      0
     cnt:
       maybe      0
       state      0
       th         0
     evnt:
     interval:
       absent     30
       init       30
       present    30
     prGroups:
       dynamic
       static
Attributes:
   intervalNormal 30


Wäre es auch nicht "schöner" wenn die Groupreadings getrennt nach absence und presence wären?
=> Nur so ein Vorschlag... 

Ansonsten wünsche ich mir noch wie ein paar andere Mitleser lan-bluetooth für meine gtags 

VG Sebastian

[the ratman]

thx @Benni

[martinp876]

Kurze antwort auf einen Teil der Fragen:
A) es gibt einen bug beim Attribut um die Zeit einzustellen. Daher 30sec. Morgen update
B) die attribute für event werden im nächsten update global vergügbar sein
C) löschen des deamons habe ich noch nicht probiert. Möglich, dass es nicht funktioniert. Es muss in jedem fall die letzte presenz entity sein
D) bt Anwendungen werde ich mir ansehen. Wird etwas mehr Aufwand da ich dies komplett nicht nutze.
E) die zähler der Gruppen werde ich prüfen.

Den rest lese ich noch

[martinp876]

doch noch ein update:
dreher bei der Statistic present/absent behoben

Das Format für function und shellscript ist wegen möglicher und notwendiger hochkomman nicht ganz einfach. Daher nutze ich die enkapsulierung in eigene Trennzeichen - 2er kette. #><commando><#>suchstring<#

somit im Beispiel weiter oben
defmod presenceSynologySMB PRESENCE function  #>{CheckPresenceSMB(\"192.168.0.152\", \"WORKGROUP\")}<#>30<#

Selbiges für Shellfunction
defmod prScript PRESENCE shellscript #>ping -c 1 -w 1 192.168.178.1 2>&1<#>(ttl|TTL)=\d+<#

Das Modul ist noch nicht fertig - klar, oder? Testergebnisse gerne einbringen - hilft sehr

[ToKa]

Du hattest ja gefragt, ob presence in Modulen benutzt wird. Roommate Kannur Anwesenheitserkennung mit einem presence device verknüpft werden.

[gestein]

Hallo,

habe gerade die letzte Version eingespielt und neu gestartet.
Nun kommt der Deamon anscheinend mit den 50+ pings gut zurecht.

Auch die Anzeige vom pGrp_default passt nun.

Die Aufrufe von function/shellscript habe ich so kopiert, wie Du es machst.
Das klappt auch.
Darauf wäre im Leben nicht gekommen.

Vielen Dank!
Wenn mir Fehler auffallen, melde ich mich gerne.

Auch beim Bluetooth melde ich mich gerne als Tester.

Bzgl. Löschen des Deamon-Devices: das scheint ein Missverständnis zu sein.
Nach Deiner ersten Antwort dachte ich, ich muss es löschen. Da kam dann die Fehlermeldung.
Aber die dürfte ja richtig sein, weil es ja noch benutzt wird.

lg, Gerhard

[martinp876]

Im Post:
a) Umstellungen
b) generelle Infos / Performance / Risk

a) Umstellungen

• reading maxScanTime renamed deamonMaxScanTime
  reading skipDeamonCnt renamed deamonSkipCnt
  Grund: Die "Deamon Internen" readings gehen unsortiert in den Status-readings unter. Daher muss der Reading name mit einem einheitlichen Wort beginnen
  
• Function/Shellscript  delimiter
  Die Spezifikation des "commands cmd" und des "scan" strings sind nicht ganz so einfach zu parsen. In beiden könnten beliebige Zeichen vorkommen. in der getrigen Version hatte ich daher einen mehr-Zeiche-String als delimiter vorgesehen. Der ist allerdings noch hässlich. Ich stelle das um auf
  " cmd:<cmd> scan:<scan>"
  Das ist schon einmal schöner. Der Parser prüft auf
  $def =~ /[ \t]+cmd:(.*?)[ \t]+scan:(.*)[ \t]*$/s
  - spaces am Ende den Commands oder Scan werden ignoriert
  - beliebige Sonderzeichen sollten kein Problem sein
  - "scan" ist ein regex
  Das Beispiel von gestern muss also geändert werden
  defmod presenceSynologySMB PRESENCE function  cmd:{CheckPresenceSMB(\"192.168.0.152\", \"WORKGROUP\")} scan:30
  

b) generelle Infos / Performance / Risk

• Klar sollte mittlerweile der Kern des neuen Presence sein: Der Deamon.
  ALLE Auswertungen werden vom Deamon erledigt. Daher werden ALLE timings in das Deamon Raster gezwungen. Es wird IMMER aufgerundet. Ist der deamon auf 30s eingestellt und eine Entity soll alle 35s geprüft werden wird bei "Itteration 0" gescannt. Bei "Itt 1" (30s) ist die Zeit noch nicht abgelaufen, entity wird nicht geprüft. Bei Itt2 ist dann entity wieder dran, bei Itt 3 nicht
  
• Deamon präzision
  der Deamon wird alle 30s +x ausgeführt. Das X kommt vom Delay des FHEM Prozesses und kann nicht umgangen werden (single-process). Der Delay wird explizit für die nächste Ausführung nicht ausgeglichen. Will sagen stellt man 60s itteration ein und startet um 11:00:00 ist zu erwarten, dass nach einem Tag der Test  nicht um 11:00:00 sondern bspw um 11:00:05 stattfindet. Die Größe des Delays hängt von den aktiven Modulen ab.
  
• Entity scan default
  der Entity Scan default wird auf 1 gesetzt. Damit wird die entity mit jedem Aufruf des Deamon gescannt. Halte ich für sinnvoller
  
• Es wird immer nur EIN scan des deamon durchgeführt.
  Sollte der Scan (sub-prozess) noch am Laufen sein, wenn der Deamon Timer abläuft wird der Scan ausgesetzt und erst nach dem nächsten Timerablauf wieder geprüft.
  Der Anwender kann dies anhand der Readings deamonSkipCnt (wie oft wurde ein Scan ausgesetzt) prüfen.
  Mit "attr PsnceDeamon intervalNormal 1" kann man die ScanSpeed hochsetzen und wird wohl denSkip-counter zählen sehen. Auf Dauer ist die Einstellung nicht zu empfehlen!!!!
  
• Scan duration
  Pings werden je nach OS unterschiedlich angesteuert. Genereller Ansatz ist, die Zeit zu minimieren. Es wird daher auf EINE Antwort gewartet, einmal probiert und max 1s gewartet. Daraus folgt:
  - Sind entites nicht erreichbar braucht der Ping 1s. Sind enties erreichbar geht es deutlich schneller
  => die Scandauer ist also dynamisch.
  Die Ausführungdauer von function und shellscript liegt komplett in der Verantwortung des Anwenders. Es muss klar sein, dass hier alles blockiert werden kann.
  Blocking ist per default auf max 60s eingestellt. Könnte man noch einstellbar machen. Worst case ist also, dass 60 pings von nicht erreichbaren Devices zu einem Timeout führen.
  => Der Deamon schützt das Gesamtsystem, aber auch hier ist die Performace endlich. Allerdingswäre bei der alten Implementierung 60 Prozesse an Laufen, was fatal wäre und auch von Blocking unterdrückt würde
  
• nicht startende Pings
  in einer der Versionen hatte ich den Abbruch des Pings nicht auf 1s begrenzt - somit war dieser 10s. Möglich, dass dies zun Abbruch des Scans wegen Zeitüberschreitung geführt hat.
  
• deamonMaxScanTime
  das ist ein zentrales reading. Ist diese Zeit länger also das Interval kommt es gelegentlich zu skip (siehe counter).
  

[martinp876]

ROOMMATE kannte ich nicht, habe einmal reingesehen. Das nutzt eigentlich "RESIDENTS".
Sollte kein Problem sein, da hier das Reading "state" nur auch "absent"/"present" geprüft wird. Das ändert sich nicht und ich sehe keine Probleme.

Ich hoffe allerdings, hier kennt sich jemand aus - auch in der Anwendung. HMan braucht RESIDENT/GUEST/PET/ROOMMATE - 4 Module es zum Laufen zu bekommen.
Performance spielt in FHEM sicher keine Rolle nach dem ersten Blick auf den Code. Das Reading "state" wird sage und schreibe 3 mal per Funktion angefragt um es auf den Inhalt zu prüfen.

Prima allerding die namensgebung "lastArrival" und "lastDeparture"  werde ich wohl auch übernehmen - das ist deutlich besser als mein Vorschlag

[Benni]

Für die Anwendung der Bewohner-Anwesenheitserkennung reicht eigentlich die Anwendung von RESIDENTS und ROOMMATE, die anderen beiden (GUEST/PET) sollten optional sein. Die einzelnen Bewohner (ROOMMATES) werden über eine übergeordnete Bewohner-Instanz (RESIDENTS) gebündelt wird (wobei auch das m.E. optional sein dürfte).

Man kann für die einzelnen ROOMMATES ein oder mehrere PRESENCE-Devices, bzw. beliebige Devices, die einen Anwesenheitsstatus zurückliefern, angeben (Attribut rr_presenceDevice). Über die wird der Anwesenhenheitsstatus dann automatisiert gesetzt (ich mache das bei mir aber selbst über entsprechende notify)

Es lässt sich im Attribut auch zusätzlich explizit das zu verwendende Reading des Presence-Device angeben.

Zulässige Werte für den zurückzuliefernden Presence-Status sind dabei (case insensitiv)

Für Abwesend: 0|false|absent|disappeared|unavailable|unreachable|disconnected
Für Anwesend: 1|true|present|appeared|available|reachable|connected

Beim Presence-Verhalten, werden sich GUEST und PET schätzungsweise gleich/ähnlich wie ROOMMATE verhalten. Allerdings verwende ich diese beiden derzeit nicht.

TL;DR: Die Änderungen sollten kein Problem in Verbindung mit RESIDENTS & Co. bereiten. Anpassungen wären, wenn überhaupt erforderlich, nur minimal.

gb#