PRESENCE cover version - anderer Ansatz basierend auf aktuellem Code

Begonnen von martinp876, 23 Dezember 2020, 14:38:45

Vorheriges Thema - Nächstes Thema

Papaloewe

Zitat von: Wolle02 am 25 Dezember 2020, 07:18:33
Aktuell verwende ich nur function, um damit den Status meiner Handys im WLAN aus den Readings meiner Unifi-Komponenten auszulesen.

dito

Jamo

Hallo Martin,
ZitatGrundsätzlich wäre interessant, welche Modis aus presence überhaupt genutzt werden.
weil Du gefragt hast, wer was verwendet:

- function: Ich verwende seit einem Jahr 'function' anstelle von lan-ping für etwa 20 devices, mit der FritzBox sub "check(W)LANMacPresent", aus dem Wiki, nachdem ich festgestellt hatte das lan-ping blocking ist, und dass das immer zu freezes führte. Hatte danach komplett umgestellt und von lan-ping auf function umgestellt.

- lan-bluetooth für die Presence erkennung mit presenced/lepresenced (Handy BT + GTAGS)

- local-bluetooth hatte ich benutzt bevor ich auf lan-bluetooth umgestellt habe

- Event halte ich auch für ueberflüssig.

Gruss, Jamo
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Benni

Hallo Martin,

ich habe dein PRESENCE-Modul nun bei mir auch am Laufen.
Der Umstieg hat problemlos funktioniert. Wie sich das mit den "Freezes" werde ich die nächsten Tage beobachten.

Ein paar Fragen habe ich noch:

- Die Intervall-Angaben im DEF der devices werden nach Umsetzung auf die entsprechenden Attribute (btw.: gute Entscheidung) nicht mehr ausgewertet, sondern nur noch die neuen Attribute, korrekt?
- Die Intervall-Angaben in der Entity-DEF können also weg?

- Fehlen die Intervall-Angaben im DEF UND in den Attributen wird automatisch das am Daemon eingestellete Intervall verwendet.

- Die Intervallangaben bei den einzelnen Entitäten müssen (sinnvollerweise) entsprechend Ein- oder Vielfache der am Daemon eingestellten Intervall-Angaben sein?

Noch eine Idee zu einer möglichen, zukünftigen Umsetzung des PRESENCE-Moduls: Vielleicht lässt sich hier eine ähnliche Geschichte Umsetzen, wie es seinerzeit von Boris und CoolTux beim WEATHER-Modul gemacht wurde. Das heißt, die einzelnen Umsetzungen für lan-ping, bluetooth, .... werden in separaten Modulen, quasi als API-PlugIns bereitgestellt.

gb#


ToKa

Hallo Martin,

das klingt vielversprechend. Ich nutze presence nur mit lan-ping für eine Handvoll Geräte.

Sagt Dir fping etwas? Damit lassen sich gleich mehrere Geräte im round robin verfahren abfragen. Gibt es wohl sogar als perl Modul.

Viele Grüße
Torsten
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

martinp876

ZitatDie Intervall-Angaben im DEF der devices werden nach Umsetzung auf die entsprechenden Attribute (btw.: gute Entscheidung) nicht mehr ausgewertet, sondern nur noch die neuen Attribute, korrekt?
korrekt
ZitatDie Intervall-Angaben in der Entity-DEF können also weg?
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

ZitatFehlen die Intervall-Angaben im DEF UND in den Attributen wird automatisch das am Daemon eingestellete Intervall verwendet.
genau. Präzise: Der Deamon läuft stoisch in seinem Interval. Die Intervalle der entites werden von Deamon auf Ablauf geprüft und alle Abgelaufenen ausgeführt.
Bsp: Deamon: 30s
Entity : 1s => es wird alle 30 s geprüft
Entity : 40s => es wird alle 60 s geprüft, da nach dem prüfen die 40s addiert werden. Der Deamon kommt nach 30s,a lso zu früh. Dann nach 60s: Ausführen

Zitat- Die Intervallangaben bei den einzelnen Entitäten müssen (sinnvollerweise) entsprechend Ein- oder Vielfache der am Daemon eingestellten Intervall-Angaben sein?
Korrekt. Das könnte ich prüfen... ist aber viel Code frü wenig Brot. Wird das Interval des Deamons angepasst müssten alle Attribute der Entities überarbeitet werden.
=> siehe/teste "get PsnceDeamon statusInfo definition"

Modi:
Die erste Version des "event" ist eingebaut. Die Idee
- attr global userAttr um "presentCycle" und "presentReading" erweitern.
- attr <entities> presentCycle <cycle> jeder Entity zuweisen, welche man überwachen will. "cycle" ist die Zeit in Sekunden, in welcher ein Update eines Readings erwartet wird
- attr <entities> presentReadinge <name> kann jeder Entity zuweisen um das zu überwachende Reading zu selektieren. Wird das attr nicht gsetzt wird "state" abgefragt.

Die Überwachnung käuft über den deamon - also wird auch wieder das Raster genutzt.
In der überwachten Entity wird ein Reading "presentStatus" gesetzt, welche den Zustand definiert
=> die Definition der Entity ist nicht notwendig, der Deamon findet alle entities mit Attribt presentCycle
=> maybe gibt es hier nicht (ich sehe den Sinn nicht)

function/shellscript
kann ich beides umplementieren - aktuel nicht enthalten. Allerdings auf die gleiche Weise, wie Ping (intern):
define sc PRESENCE shellscript <OS-command> <passString>

Das OS-command wird ausgeführt und der Rückgabewert verglichen mit <passString>. Ist der String enthalten ist alles gut, wenn nicht eben nicht.
Faktisch kann dann der User auch so(selbst) den Ping erstellen.

Hier schon einmal der Update zwischendurch.

Sollten noch sinnvolle Auswertungen fehlen, bitte info






fping kenne ich nicht Wäre cool - aber der aktuelle Ping nutzt schlicht OS funktionen für
=> die Erklärung sollte reichen.

gestein

Hallo,
danke für die neue Version.
Habe sie gleich ausprobiert.

- Es wird ein ein Device names presenceGateway angelegt.
- Das "lan-ping" scheint mal stabil zu funktionieren.
- "function" pendelt zwischen present/absent/error
  Ich verwende dort {CheckPresenceSMB("192.168.0.152", "WORKGROUP")} 30
- Das "lan-bluetooth" (mit collectord, lepresenced) pendelt zwischen present/absent

Code für CheckPresenceSMB:
sub CheckPresenceSMB($$) {
  my ($ip,$wg) = @_;
  my $ret = "";

  $ret = qx(nmblookup $wg | grep -o $ip);

  $ret =~ s,[\r\n]*,,g; # remove CR from return-string

  if ($ret eq $ip) {
    return 1;
   }


lg, Gerhard

p.s.: Vor dem Einspielen des neuen Codes hat das stabil funktioniert. Vor allem das "lan-bluetooth"

martinp876

So, update:
Die Version im Anhang kann nun
- lan-ping
- function (define <entity> PRESENCE function "{<function>}" '<testString>'
- shellscript (define <entity> PRESENCE shellscript "<command>" '<testString>'
- event durch die Nutzung der beschriebenen Attribute - kein "Define", keine Entity

Beispiel
defmod prfunct PRESENCE function "{PRESENCE_getDeamonName()}" 'PsnceDeamon'
defmod prScript PRESENCE shellscript "ping -c 1 -w 1 192.168.178.1 2>&1" '(ttl|TTL)=\d+'

Dokumentation ist noch nicht berichtigt.

Das eineoder andere wird sicher noch korrigiert -aber im gr0ßenund ganzen ist es erledigt.
Entfernt: Bluetooth und PowerCmd

martinp876

- Es wird ein ein Device names presenceGateway angelegt.
=> sollte nun nicht mehr vorkommen - sicher ein Rest von BT
- "function" pendelt zwischen present/absent/error
  Ich verwende dort {CheckPresenceSMB("192.168.0.152", "WORKGROUP")} 30
=> das ist auch erst jetzt drin. Die Definition hat sich geändert. Die Funktion muss nocht 0/1 zurückgeben sondern nur einen beleibigen string. Du gibst weiter einen "vergleich" an. Wird der Vergleich im reply gefuden ist alles ok, "present"

- Das "lan-bluetooth" (mit collectord, lepresenced) pendelt zwischen present/absent
=> das habe ich auch nicht implementiert. Brauchst du das?

gestein

Probiere ich gleich. Danke!

Bei Deiner kurzen Umfrage haben ein paar Leute "ja" für "lan-bluetooth" (mit collectord, lepresenced) zurückgemeldet.
Ich denke, dass das einige Leute gerne hätten.

Und ja, ich würde es gerne haben.
Immerhin funktioniert die Abfrage der Gtags meiner Familie damit bisher ohne Probleme.
Bei den iPhones klappt es leider nicht mir lan-ping etc.
Anfangs melden die sich als "present", aber nach einiger Zeit sind die immer "absent" :(

lg, Gerhard

gestein

Habe gerade die neue Version eingespielt und fhem neu gestartet.
Beim Löschen des PsnceDeamon kommt die Meldung:
deletion of deamon not possible unless objects still present

lg, Gerhard

gestein

Noch eine Frage bitte:
Wie muss ich nun mein Presence-Device definieren?

Bisher hatte ich:
defmod presenceSynologySMB PRESENCE function {CheckPresenceSMB("192.168.0.152", "WORKGROUP")} 30

Egal was ich eingebe, es kommt immer die Fehlermeldung: "The function call must be encapsulated by brackets ( {...} )."

Danke für die Hilfe.
lg, Gerhard

eurofinder

@martinp876:

Wie gestein bereits geschrieben hat:
ZitatImmerhin funktioniert die Abfrage der Gtags meiner Familie damit bisher ohne Probleme.
Bei den iPhones klappt es leider nicht mir lan-ping etc.

Genau aus diesem Grund setzte ich auch G-Tags ein. Wäre also super, wenn du lan-bluetooth wieder berücksichtigst.

Gruß
eurofinder
RPI3+; Raspbian Buster Lite; RPI-RF-MOD; piVCCU3, HMIP-eTRV-2, HmIP-SWDO, HmIP-SRH, HmIP-STHO, HmIP-SLO

gestein

Hallo,

ich habe mir gerade ein neues PRESENCE-Device angelegt.
defmod Presence_Shelly_50 PRESENCE lan-ping 192.168.0.50 30
attr Presence_Shelly_50 room 0_Testing


Aber es werden keine Readings angelegt, der Status bleibt auf "???".

Die raw-Definition lautet:
defmod Presence_Shelly_50 PRESENCE lan-ping 192.168.0.50 30
attr Presence_Shelly_50 intervalNormal 30
attr Presence_Shelly_50 intervalPresent 30
attr Presence_Shelly_50 room 0_Testing
attr Presence_Shelly_50 verbose 5

setstate Presence_Shelly_50 2020-12-26 21:04:18 .associatedWith PsnceDeamon
setstate Presence_Shelly_50 2020-12-26 21:04:18 model lan-ping


Wieso gibt es keinen ping auf das Gerät?

Im PsnceDeamon gibt es auch kein Reading für den "Presence_Shelly_50".
lg, Gerhard

enno

Zitat von: gestein am 26 Dezember 2020, 21:09:02
defmod Presence_Shelly_50 PRESENCE lan-ping 192.168.0.50 30

Moin Gerhard,

hast du mal ohne die 30 probiert?

defmod Presence_Shelly_50 PRESENCE lan-ping 192.168.0.50

Gruss
  Enno
Einfacher FHEM Anwender auf Intel®NUC

gestein

Moin Enno,

ja, habe ich. Aber das gleiche Ergebnis.
Auch ein zweites Device mit der Adresse xxx.49 wird angelegt, aber im Device PsnceDeamon tauchen die beiden nicht in den Readings auf - nur die, die es zum Zeitpunkt des Anlegens des Deamon-Devices schon gab.

Im Reading pGrp_default steht "ab:8 pres:13", obwohl es eigentlich nun 23 PRESENCE-Devices gibt, von denen 21 zum Zeitpunkt des Anelgens da waren.
Die beiden neuen tauchen nicht auf.
Und eigentlich sind 8 present und 13 abwesend.

lg, Gerhard