vorschlag PRESENCE threshold

[justme1968]

hallo markus,

ich spiele seit ein paar tagen mit dem gedanken ob man presence nicht um einen optionalen threshold erweitern könnte.

dieser würde festlegen nach wie vielen malen nichterreichbarkeit der status tatsächlich auf absent geht. d.h. wenn das attribut gesetzt ist würde der zustand beim ersten mal nicht direkt auf absent gehen sondern zuerst auf 'maybe absent' oder auch undetermined. erst wenn sich die nichterreichbarkeit dann x mal wiederholt geht der status auf 'absent'. beim ersten erreichbar geht der status auf jeden fall sofort auf 'present'.

den zusätzlichen zustand könnte man in plots und auch notifys direkt mit auswerten oder je nach dem wie rum man die plot function bzw. regex wählt dem absent oder present status zuschlagen.

das ganze kann man zwar auch über einen watchdog lösen aber wenn mehrere presence devices hat ist der overhead deutlich größer als wenn es direkt eingebaut wäre. weil es zusätzliche devices braucht und auch deutlich mehr events erzeugt werden.

würdest du einen solchen patch einbauen oder es sogar selber machen wollen?

eigentlich ist es nur ein zusätzlicher zähler und ein bisschen umräumen um die verteilten updates von state und presence an einer stelle zusammen zu fassen und dort dann auch den zähler auszuwerten.

gruss
  andre

[Markus Bloch]

Hallo Andre,

anbei mein Vorschlag wie ich es einchecken würde. Am Ende gibt es eine neue Funktion PRESENCE_ProcessState(). Diese bildet die Logik dazu ab und wird an den entsprechenden Stellen genutzt um die state/presence-Readings zu updaten.

Zu nutzendes Attribut ist absenceThreshold.

Erstmal alles ohne commandref-Doku für dich zum testen. Sollte alles passen, würde ich es so inkl. Doku einchecken.

Gruß
Markus

[justme1968]

das klingt klasse. schaue ich mir nachher gleich an.

vielen dank
  andre

[justme1968]

hallo markus,

ich hätte nur zwei anmerkungen:

- ich würde für den zwischenzustand die readings auf einen eigenen wert setzen. 'undetermined' oder 'maybe absent'. dann kann man auch bei gesetzten attribut ohne am wert etwas zu ändern in notifys oder in den plots flexibel reagieren. sogar auf alle drei zustände.

- den counter stand würde ich mit level 3 oder besser noch 4 loggen. nicht mit 2.

ansonsten: vielen dank

  andre

[Markus Bloch]

Hallo Andre,

zu deinen Anmerkungen:

- ich würde für den zwischenzustand die readings auf einen eigenen wert setzen. 'undetermined' oder 'maybe absent'. dann kann man auch bei gesetzten attribut ohne am wert etwas zu ändern in notifys oder in den plots flexibel reagieren. sogar auf alle drei zustände.

Bei dem Zwischenzustand bin ich mir momentan nicht sicher, ob man ihn ausgeben soll oder nicht. Unter dem Gesichtspunkt "der User sollte wissen, was er da konfiguriert hat", sollte man davon ausgehen können, dass dem User der Verzug um bspw. 3 Checkintervalle bekannt sein sollte, bis der Status auf "absent" umspringt. Wenn ich nun einen Zwischenstatus wie bspw. "maybe absent" einführe, sehe ich die Gefahr, das einige User aufgrund von Unwissen oder gefährlichem Halbwissen ein notify mit "iPhone:.*absent" oder "iPhone:.*absent.*" definiert haben, das gar nicht mehr auf dem Schirm haben und dann diese tolle neue Funktion im CHANGED entdecken.

Ich bin daher gespalten was das angeht.

- den counter stand würde ich mit level 3 oder besser noch 4 loggen. nicht mit 2.

Das war nur für mich zum testen/debuggen. In der Live-Version würde ich es auf 4 setzen.

Gruß
Markus

[justme1968]

ich hätte kein problem damit da es ja nur aktiv wird wenn das attribut gesetzt wird.

wenn du meinst das es trotzdem zu problem kommen könnte würde ich den zwischenzustand durch ein weiteres attribut aktivieren. die möglichkeit alle drei zustände zu haben ist neben der einfacheren konfiguration und dem einsparen von zusätzlichen devices noch ein vorteil gegenüber threshold.

gruss
  andre

[Markus Bloch]

Ich werde es morgen mit "maybe absent" als Zwischenstatus bei aktiviertem absenceThreshold einchecken.

Gruß
Markus

[justme1968]

danke

gruss
  andre

[dev0]

@Andre: Ich benutze noch das angepasste 73_PRESENCE.pm Modul von Dir aus dem diesem Beitrag. Um das Modul nicht immer selbst patchen zu müssen, würde mich in diesem Zusammenhang interesssieren, wie Du jetzt die BT-LE Dongles auswertest. Angepasstes presenced script oder habe ich die "offizielle Lösung" verschlafen?

/Uli

[Markus Bloch]

Änderung mit neuem Attribut ist eingecheckt.

Schönes Wochenende wünsch ich

Gruß
Markus

[kumue]

ich kann kein neues Attribut finden...

Code Auswählen Erweitern

73_PRESENCE.pm       11213 2016-04-09 16:48:28Z markusbloch


[Markus Bloch]

Erst mit dem morgigen update ansonsten musst du dir es manuell aus dem SVN herunterladen und in den Modul-Ordner schieben:

https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/73_PRESENCE.pm?format=raw

Gruß
Markus

[kumue]

Erst mit dem morgigen update ansonsten musst du dir es manuell aus dem SVN herunterladen und in den Modul-Ordner schieben:

https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/73_PRESENCE.pm?format=raw

Gruß
Markus

Ok, danke.
Ich glaub, ich kann mich bis morgen noch gedulden.
Schönen Sonntag noch !

[raimundl]

Hallo,

vorerst DANKE - funktioniert prima und vereinfacht einiges bei mir - tolles Modul!

Nur eine Frage interessehalber:

Wofür ist das Attribut "powerCmd" gedacht?

LG

[justme1968]

wenn du powerCmd passend setzt kannst du es z.b. mit devStateIcon als kommando beim klick auf das icon hinterlegen und so geräte ein oder aus schalten.

gruss
  andre