PRESENCE cover version - anderer Ansatz basierend auf aktuellem Code

[martinp876]

Hallo,

auf der Suche nach einer Option meine LAN devices zu überwachen bin ich (natürlich) auf PRESENCE gestossen. Ein nettes Modul, schlank und einfach. Allerdings ist es mir etwas zu einfach. Ich bin auf 3 Details gestossen mit mehr oder weniger weitreichenden Auswirkungen.
Erst einmal  vielen Danke an den Entwickler, meine Anmerkungen seid meine Befürfnisse und müssen nicht allgemeingültig sein.
Für mich taugt das Modul in der aktuellen Form leider nicht - so habe ich einmal angefangen, es anzupassen.
Vorneweg:
  - Die Änderungen sind nicht umfassend. Es lan-ping funktioniert prima - alles andere habe ich nicht. Das würde ich nur bei Bedarf implementieren, wenn es jemand braucht, der Entwickler es nicht machen will und/oder ich es einmal selbst benötige
  - die Dokumentation ist nicht komplett - für mich hinreichend. Sollte es Fans geben werden ich es vervollständigen.
 
Nun erst einmal mein Usecase: Ziel ist, einige LAN devices auf vorhanden sein zu überwachen. Das sind dann so 20+ devices.
BT werde ich nicht machen.
Event werde ich sicher nicht mit dieser Implementierung machen - aus verschiedenen Gründen. Es gibt hier aus meiner Sicht deutlich bessere Optionen. Das ist ein anderes Thema.

Warum glaube ich, ändern zu müssen:
A) Attribute und Definition
B) Zu Verfügung gestellte Informationen (readings)
C) Performance!!!

A) für mich geht es schlicht nicht, dass das Ping-Interval bei der Entity Definition  angegeben wird und dann mit einem Kommando geändert werden kann. Das Ping-Interval ist ein Attribut und so zu erstellen

B) Nur present/absent zu sehen ist mir klar zu wenig. Ich will sehen, wann das Gerät das letzte mal present war und wann absent. Das ist das minimum. Weiter werde ich ein Reading einbauen, welches eine Aussage über die Stabilität des Devices gibt, also die Anzahl der "maybe" Änderungen.

C) Ein definitives no-go ist die Nutzung von Blocking. Natürlich ist es notwendig blocking zu nutzen. Aber es ist indiskutabel für jede Entity bei jedem Ping einmal FHEM zu forken. Bei 20 Devices, 30s ist das eine Kopie des gesamten Prozesses fast jede Sekunde zu erstellen. Meine Himbeere hat dies sowieso schon abgelehnt - wegen memory-problemen.
Die(meine) Lösung ändert das Verhalten von Presence. Der Ablauf ist, dass eine übergeordnete Entity, ein PRESENCE-deamon, instanziiert wird welcher alleinig das forken übernimmt.
Will sagen, der deamon (default name: PsnceDeamon) wird alle 30 sec oder über intervalNormal gesteuert aufgerufen und prüft, ob jemand pingen möchte. Es werden alle pings zusammengefasst und los gehts - einmal forken.

Damit sind die Pings der normalen entites auf das Raster des Deamons begrenzt.
Bislang ist es für lan-ping implementiert, was mir reicht.

Weiter habe ich die anzahl der Pings auf 1 festgesetzt. alles andere dauert zu lange, macht keinen Sinn. Die Dauer wird um potenzen reduziert, da bereits count2 min 1s dauert, count 1 aber nur ms. 

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.

Es lässt sich auch der Rest umstellen, bei Bedarf.

Da scheinbar alle mit der aktuellen Anwendunf zufrieden scheinen (was mich eigentlich wundert) werde ich hier wohl einfach meinen eigenen Weg gehen. Ein paralleles PRESENCE plane ich nicht veröffentlichen.

[gestein]

Hallo,

auch ich bin Anwender vom Presence-Modul und setze es öfters ein um zu sehen, ob Geräte via LAN oder WLAN erreichbar sind.
Über die Probleme, die Du angesprochen hast, bin ich noch nicht gestolpert - obwohl ich auch 20 Geräte überwache.
Das liegt natürlich an meinem "Nichtwissen"

Prinzipiell fehlen mir am aktuellen Presence die gleichen Dinge wie Dir (z.B. Stabilität der Verbindung).

Daher probiere ich Deine Version gerne aus.
Einfach die Datei im Anhang über die in FHEM kopieren und neu starten?

lg, Gerhard

[martinp876]

Hallo Gerhard,
wenn du nur "lan-ping" nutzt sollte es kein Problem sein.
Also austauschen und neu booten.
Es wird dann am Ende ein "PsnceDeamon" deamon angelegt.

Ich würde sagen, dass  es funktionieren sollte. ".cfg" sichern schadet nicht. schlimstenfalls einfach das alte File wieder einspielen und booten - mehr kann nicht passieren.
Ich habe noch kleinigkeiten geändert. Vorschläge gerne.

Was du schlecht sehen kannst sind Fehler und Systemauslastung durch das viele forken.

   

[CQuadrat]

Ich benutze PRESENCE mit lan-ping relativ exzessiv, um den (möglichen) Ausfall diverser Geräte und Anwesenheiten zu erkennen.

Ich habe - ohne es jemals näher untersucht zu haben - auch das Gefühl, dass es wegen PRESENCE gelegentlich zu Freezes bei mir kommt.

Ist Deine Version kompatibel? Teilweise nutzte ich PRESENCE noch mit local-bluetooth und function.

Vielleicht sollte man das Module PRESENCE2 (oder so ähnlich) nennen.

[Benni]

C) Ein definitives no-go ist die Nutzung von Blocking. Natürlich ist es notwendig blocking zu nutzen. Aber es ist indiskutabel für jede Entity bei jedem Ping einmal FHEM zu forken. Bei 20 Devices, 30s ist das eine Kopie des gesamten Prozesses fast jede Sekunde zu erstellen.

Ah! Das erklärt, warum mein FHEM in letzter Zeit immer mal wieder, den einen oder anderen Schaltvorgang etwas verzögert ausführt, bzw. Hänger zu haben scheint!

Seit ich kürzlich mein Netzwerk umgebaut habe, habe ich zur einfachen Überwachung einige (>20) PRESENCE-Instanzen eingerichtet. Und hatte gleich so ein Bauchgefühl, dass das evtl. mit Nebenwirkungen verbunden sein könnte, ohne dem weiter nach zu gehen.

Habe eben mal kurz nachgeschaut und ich verwende PRESENCE aktuell ebenfalls ausschließlich mit lan-ping, von daher werde ich mir deine "Cover-Version" die nächsten Tage auf jeden Fall mal anschauen.

Danke!
gb#

[gestein]

Hallo,

Danke. Das probiere ich mal.

Ich nutze halt nicht nur das LAN-ping, sondern auch lan-bluetooth und function/shellscript.

Da bin ich mal neugierig

lg, Gerhard

[martinp876]

nun, ich bastle mittlerweiel weiter, es in die Form zu bingen, wie es mir gefällt / sinnvoll erscheint.
Achtung: in der letzten Version dauert das Ping zu lange, falls das Device fehlt. Ist nun sinnvoll verkürzt.
===> was ist Sinnvoll

• ===> was ist Sinnvoll
  neue Version  im Anhang - ich beschäfftige mich wie gesagt mit lan-ping. Das andere sollte noch gehen - aber definitiv ohne gewähr.
  Einbringen könnte ich bei gelegenheit noch "event" auf die weise, wie ich es für sinnvoll halte. Beispiel hierzu wäre CUL_HM ActionDetector. Genaueres auf Anfrage.
  
• ===> Einschränkungen - kompatibilität
  nun, das ist schwer zu sagen. Kömmt darauf an, was ihr macht.
  1) die Definitionen und Attribute sollten ohne Probleme übernommen werden. Man erhält nach Reboot ein lauffähiges system welches ähnlich wie vorher aggiert
  2) readings "state" und "presence" waren identisch - was schon einmal keinen Sinn macht. "state" liefert nun "absent" oder "present" während "presence" auch "maybe" hinzufügt. Internals "STATE" kann man wie gewohnt über das einschlägige Attribut unschalten.
  3) nachdem es nun mehr Readings gibt müssen notifies ggf. angepasst werden, wenn sie nicht "sauber" und explizit erstellt wurden
  
• ===> Alarming
  Ich werde noch ein "grouping" implementieren. Use-case ist, dass ich erkennen will, welche Devices present sind. Dabei muss ich klassifizieren, "was" es ist. So habe ich network-devices (router, IOs,...) welche vorhanden sein "müssen". fehlen soll einen Alarm generieren (könnnen). Weiter gibt es "smartphones"  - also "wer ist zu hause". Das führt natürlich nicht zu einem Alarm aber ggf zu anderen aktionen.
  Damit ich nicht alles individuell erstellen muss ist ein grouping m.E. hilfreich - und einfach ist es sowieso
  
• ===>updates
  wenn ich dazu komme gibt es heute noch eine Version mit grouping feature
  

Blocking - was ist das
Zur Info - falls jemand glaubt, keine Probleme erkannt zu haben:
Blocking ist eine überaus sinnvolle funktion welche zwingend notwendig ist, halbwegs Echtzeit arbeiten zu können. Für presence unabdingbar.
Was macht es: der FHEM-Prozess wird ge-forked. Bedeuted der KOMPLETTE FHEM Prozess wird auf OS Ebene dupliziert. Das kostet erst einmal Performance und natürlich Speicher (RAM). Auch wenn der Mutter-Prozess erst einmal fast ohne es zu bemerken weiter läuft so ist das doch ein erheblicher Aufwand auf OS Ebene.
Je größer das GeramtSystem desto mehr Aufwand ist es - auch wenn die Aufgabe im geforkten Prozess nur minimal ist. => die Skalierbarkeit und die Auswirkungen sind nicht wirklich absehbar.
###> Blocking sollte man sparsam und dediziert nutzen
a) ich nutze Blocking für User initiierte Aufrufe (kommandos) und seltene Ereignisse
b) Presence MUSS blocking nutzen - aber man MUSS es gruppieren. Die offizielle Version  lässt nur ein Blocking zu - je Entity. Das geht nicht! Es darf nur ein Blocking für Presence overall geben. Ein blocking je mode - möglich, ok. Mehr definitiv nicht.

[gestein]

Wenn ich so genauer darüber nachdenke, dann scheinst Du die gleichen Problem zu haben wie viele von uns.
Nur wäre ich nie draufgekommen

Da Du ja wirklich einen großen Umbau im Modul machst, warum wirfst Du den Ballast der anderen Funktionalität nicht über Board und nennst Dein Modul z.B. PRESENCE2?
Es hat sich zwar schon länger nichts mehr im Presence-Modul getan (glaube ich), aber wenn mal ein Fehler in den anderen Funktionen entdeckt wird, dann muss man den selbst nachziehen.

Was spricht eigentlich dagegen, Deine tolle Arbeit in ein eigenes Modul auszulagern?

lg, Gerhard

p.s.: Das mit dem CUL_HM ActionDetector würde mich z.B. auch schon mal sehr interessieren

[frank]

das forken zu reduzieren, ist eine sehr gute idee!

da kann ich das presence modul ja wieder in meinen fhem werkzeugkasten packen. 

mit einem zusätzlichen attr alignTime, wie zb bei httpmod oder at, könnte man auch den forks anderer module aus dem weg gehen.

das sollte eigentlich jedes periodisch forkende modul können, finde ich.

[martinp876]

nun, ich muss mir überlegen, die Pflege eines neuen Module "allgemein" zu übernehmen. 
ein PRESENCE2 gefällt mir nicht so recht. Das ist einfach - aber irgendwie vermüllt es fhem.

Grundsätzlich wäre interessant, welche Modis aus presence überhaupt genutzt werden.
lan-ping - klar
fritzbox - outdated?
local-bluetooth - unklar
lan-bluetooth - unklar
function - unklar
shellscript - unklar

event - hier werden etliche timer aufgezogen. Event überwacht vorhandene Devices, welche schon eine Entitys haben. Ich möchte also keine weitere "Presence- entity welche die "phys-entits" überwacht. Anzustreben ist m.e. ein "Deamon" in welchen die zu überwachenden physEntites eingehängt werden.
Bei CUL_HM ist das der "ActionDetector" - hier könnte es über den "ping-deamon" geschehen. Dann braucht man keine neue entität.
Beim Überwachen kommt es nicht auf hohe Geschwindigkeit an. Es reicht, periodisch (bspw mit der deamon zeit) die phys-entits abzuklappern.
Den Status kann man dann gesammelt im deamon und einzeln als reading in der Phys-Entity abfragen - und hierzu notifies zuordnen wie gewohnt.
Das sollte schnell zusammencodiert sein, kein großer Stress. Die erwartete Meldezeit wird als Attribut in der (phys) entity eingegeben. Weiter braucht man noch das Reading, aus welchem der Zeitstempel kontrolliert werden muss (noch ein Attribut) - fertig.

Zum Kommentar, dass Module gewisse Aktionen bündeln sollten - unbedingt. Schon seit beginn vermisse ich eine "modul-entität". Eigentlich sollte diese den Deamon beinhalten, modul-status darstellen,... Vielleicht ist es mir bisher entgangen, aber ich meine FHEM unterstützt dies (aktuell) nicht. Schade.

[Wzut]

oh das ist schön, bei mir läuft seit Jahren schon eine umgebaute PRESENCE Version weil mir damals auch das ein oder andere nicht gefallen hat.
Den Ping 1 habe ich auch so , ebenfalls die fehlenden Readings zum Teil, aber das mit dem Deamon gefällt mir richtig gut.
BTW ich nutze auch nur lan-ping.

[Wolle02]

Guten Morgen und frohe Weihnachten euch allen,

Grundsätzlich wäre interessant, welche Modis aus presence überhaupt genutzt werden.
lan-ping - klar
fritzbox - outdated?
local-bluetooth - unklar
lan-bluetooth - unklar
function - unklar
shellscript - unklar

In der Vergangenheit habe ich lan-ping und lan-bluetooth verwendet. Insbesondere lan-bluetooth mit der Verwendung von presenced und collectord fand ich sehr interessant.

Aktuell verwende ich nur function, um damit den Status meiner Handys im WLAN aus den Readings meiner Unifi-Komponenten auszulesen.

[eurofinder]

Ich finde den Ansatz hervorragend und werde das hier weiter verfolgen.

Da es WLan-Geräten immer wieder Probleme gegeben hatta, bin ich dann auf G-Tags`s umgestiegen - also lan-bluetooth - und das funktioniert hervorragend.
Insofern wäre ich natürlich an einer weiteren Berücksichtigung von lan-bluetooth oder was vergleichbaren interessiert:-)

Gruß und frohe Festtage
eurofinder

[Frank_Huber]

Aktuell verwende ich nur function, um damit den Status meiner Handys im WLAN aus den Readings meiner Unifi-Komponenten auszulesen.

Moregähn.
Das löse ich mit einem Userreading im UnifiClient Gerät.
Ganz ohne Presence

[Wolle02]

Das löse ich mit einem Userreading im UnifiClient Gerät.
Ganz ohne Presence

Ja klar geht das. Viele Wege und so ........

Aber die Frage war ja, wie das Modul aktuell genutzt wird. Und da stand bei function -> unklar .....