Zonen-basierte Anwesenheitserkennung und -steuerung

[curt]

FileLog wäre für mich mit der meisten Arbeit versehen, aber später auch möglich.

Also in der hohen Theorie nimmt sich FileLog und DB bzgl. der Parameter bgzl. der vorrangig eingesetzten Hardware ja nichts. Ok, ich bin parteiisch - ich habe FileLog. Und vermutlich eigentlich alle, die anfangen und später zu faul oder zu unmutig sind.

Die Frage ist, ob es schon ein Zwischenmodul gibt - welches also in Sinne von Auswertung sowohl FileLog als auch DB adressiert. Diese Frage kann ich nicht beantworten. - Falls es das noch nicht gibt, würde es wohl darauf hinauslaufen.

[ComputerZOO]

neue Version, mit einigen Bugfixes und neuem "absenceEvent" im ersten Post.

Cool, danke, komme erst am Samstag dazu das testen, werde dann berichten.

[Thyraz]

Oh Mann KernSani,

du bist Schuld, dass ich jetzt wieder in paar Tür- und Bewegungssensoren bestellt habe.

Werde mich also demnächst auch in die Riege der Tester einreihen...

[KernSani]

https://www.google.com/search?q=xiaomi+motion+sensor


Kannst Du bitte kurz sagen, was die erwartete FHEM-Gegenstelle ist?

ich habe die mit zigbee2mqtt und MQTT2 angebunden. https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#zigbee2mqtt

[KernSani]

Oh Mann KernSani,

du bist Schuld, dass ich jetzt wieder in paar Tür- und Bewegungssensoren bestellt habe.

Hmm... wo kann ich meine Provision abholen?

[KernSani]

Neue Version, die mehrere Türen unterstützt ist im ersten Post verfügbar. im open- und closed- Event kann jetzt eine Leerzeichen-getrennte Liste von kommagetrennten Regexen gepflegt werden. Jeder der Leerzeichen-getrennten Werte entspricht einer Tür - Reihenfolge und Anzahl sollte also bei open- und closed- Event identisch sein. Jede Tür bekommt ein eigenes Reading mit dem jeweiligen Status. Nur wenn alle Türen geschlossen sind, geht die Zone auf closed. Sobald (mindestens) eine Tür geöffnet wird, geht die Zone auf "open".

[KernSani]

Ein paar Fragen, zu denen ich gerne eure Meinung hätte:
1. Wie zufrieden seid ihr mit der Anwesenheitskontrolle bisher? Meine Erfahrung in wenigen Sätzen: Wasp-in-a-box funktioniert gut, auch die hierarchische Abbildung macht Sinn, wo ich noch nicht zufrieden bin sind die angrenzenden Räume, ich habe aber aktuell keine konkrete Idee, wie man das noch verbessern könnte - aktuell wird der Anwesenheitsstatus da ja quasi gespiegelt - dadurch wird z.B die Lichtsteuerung einfacher (aber das ist eigentlich nicht das Ziel - siehe nächster Punkt). In vielen Fällen würde ich mir aber je nach Situation - einen schnelleren oder langsameren decay statt einer Spiegelung wünschen. 
2. Zumindest meine Steuerung ist zu komplex, um sie über die bestehenden Attribute komplett abzudecken, nun könnte ich noch x zusätzliche Attribute einführen und miteinander ausmultiplizieren (um dann 100 userattribute der Form hz_cmd_present_morning_ROOMMATEx_... zu produzieren)  - oder ich konzentriere mich auf die bessere Anwesenheitserkennung und mache die Steuerung wie gehabt über DOIF/notify - Ich tendiere zu Letzterem.
3. Die zeitabhängigen decay-Zeiten klangen für mich wie eine gute Idee - in der Praxis nutze ich sie aber nicht.
4. Insbesondere als Folge der Punkte 1 und 2 würde ich folgenden Ansatz bez. angrenzender Räume verfolgen:
       a) Steuerung angrenzender Zonen (Licht im Flur soll nicht ausgehen, wenn ich auf der Toilette sitze) erfolgt nicht über das Modul selbst, sondern extern - im Modul könnte ich evtl. einen entsprechenden Set Befehl bereitstellen (sowas wie set hz_WC adjacentZones present|likely|unlikely|absent)
       b) Tatsächlich ist es vermutlich so, dass die Anwesenheitswahrscheinlichkeit im aktuellen Raum sinkt, wenn in einem angrenzendem Raum Anwesenheit erkannt wird (oder umgekehrt - sie sinkt im angrenzendem Raum, wenn im aktuellen Raum Anwesenheit erkannt wird), da ich dann wahrscheinlich von einem Raum in den anderen gegangen bin. Meine Idee wäre daher, bei erkannter Anwesenheit in Raum A die Anwesenheitwahrscheinlichkeit in den angrenzenden Räumen zu reduzieren (z.B. auf 30% zu setzen, wenn aktuelle Wahrscheinlichkeit > 30% und < 100%) Was denkt ihr?

Danke,

Grüße,

Oli

[binford6000]

Moin Oli,

1. Wie zufrieden seid ihr mit der Anwesenheitskontrolle bisher? Meine Erfahrung in wenigen Sätzen: Wasp-in-a-box funktioniert gut, auch die hierarchische Abbildung macht Sinn, wo ich noch nicht zufrieden bin sind die angrenzenden Räume, ich habe aber aktuell keine konkrete Idee, wie man das noch verbessern könnte - aktuell wird der Anwesenheitsstatus da ja quasi gespiegelt - dadurch wird z.B die Lichtsteuerung einfacher (aber das ist eigentlich nicht das Ziel - siehe nächster Punkt). In vielen Fällen würde ich mir aber je nach Situation - einen schnelleren oder langsameren decay statt einer Spiegelung wünschen. 

Die Anwesenheitskontrolle funktioniert super. Angrenzende Räume nutze ich nicht (mehr). Ist in meinem Fall auch auf asleep
und damit auf Schlafzimmer, Flur, Klo und Küche begrenzt. Die könnte ich dann schalten wenn die Bewegung im sz bei asleep erkannt wird.

2. Zumindest meine Steuerung ist zu komplex, um sie über die bestehenden Attribute komplett abzudecken, nun könnte ich noch x zusätzliche Attribute einführen und miteinander ausmultiplizieren (um dann 100 userattribute der Form hz_cmd_present_morning_ROOMMATEx_... zu produzieren)  - oder ich konzentriere mich auf die bessere Anwesenheitserkennung und mache die Steuerung wie gehabt über DOIF/notify - Ich tendiere zu Letzterem.

Ein klares jein 
Ja: Es wird (teils) unübersichtlich und vermutlich wird auch etwas Code dupliziert.
Nein: einmal dran gewöhnt (ich liebe HOMEMODE...) geht das schon mit den ganzen userattr.

3. Die zeitabhängigen decay-Zeiten klangen für mich wie eine gute Idee - in der Praxis nutze ich sie aber nicht.

Ich finde sie immer noch eine gute Idee und nutze sie weiterhin.

4. Insbesondere als Folge der Punkte 1 und 2 würde ich folgenden Ansatz bez. angrenzender Räume verfolgen:
       a) Steuerung angrenzender Zonen (Licht im Flur soll nicht ausgehen, wenn ich auf der Toilette sitze) erfolgt nicht über das Modul selbst, sondern extern - im Modul könnte ich evtl. einen entsprechenden Set Befehl bereitstellen (sowas wie set hz_WC adjacentZones present|likely|unlikely|absent)
       b) Tatsächlich ist es vermutlich so, dass die Anwesenheitswahrscheinlichkeit im aktuellen Raum sinkt, wenn in einem angrenzendem Raum Anwesenheit erkannt wird (oder umgekehrt - sie sinkt im angrenzendem Raum, wenn im aktuellen Raum Anwesenheit erkannt wird), da ich dann wahrscheinlich von einem Raum in den anderen gegangen bin. Meine Idee wäre daher, bei erkannter Anwesenheit in Raum A die Anwesenheitwahrscheinlichkeit in den angrenzenden Räumen zu reduzieren (z.B. auf 30% zu setzen, wenn aktuelle Wahrscheinlichkeit > 30% und < 100%) Was denkt ihr?

4.a) Siehe Kommentar zu 1.
4.b) Klingt gut. Du wirst eh nicht alle Eventualitäten abdecken können. Bei einer Etage und nur einem Bewohner ist die Sache relativ klar.
Bei mehreren Etagen und/oder mehreren Bewohnern wirds tricky.

VG Sebastian

[binford6000]

eine Leerzeichen-getrennte Liste von kommagetrennten Regexen...

Damit stellst du selbst HOMEMODE in den Schatten... 

[enno]

Moin Oli,

zu 1: Sehr zufrieden ich nutze das Modul bisher in zwei Räumen => einer Etage => und dem Haus. Die schnelleren oder langsameren decay würde ich mir stark wünschen.
zu 2: Weitere Steuerung über Attribute würde ich stark hinterfrage. Für mich ist ASC ein negativ Beispiel. Ich habe es genutzt, es ist aber inzwischen so komplex, dass ich nicht mehr durchblicke welches Attribut zu welchem Ergebnis führt. Ich bin daher wieder zu selbstprogrammierten DOIF zurück gekehrt. Dein Modul in Kombination mit DOIF tut eigentlich einfach und übersichtlich was es soll. Was komplizierter wird, kann man mit DOIF/notify anflanschen.
zu 3: nutze ich noch nicht, könnte mir aber einige Anwendungsmöglichkeiten vorstellen.
zu 4: a würde ich auch extern sehen,
      b: macht bei mir keinen Sinn, da ich nicht allein Wohne. Eine Person kann gerade den Raum verlassen haben und eine andere ist über die zweite Tür in den Raum gekommen sein. Bei Kindern ein Bewegungsmuster zu finden, das habe ich aufgegeben.

Für mein einfach strukturiertes Anwendergehirn macht das Modul schon genau das was ich benötige wenn Punkt 1 noch kommt, dann bin ich glücklich.

Gruss
  Enno

[curt]

@KernSani
Ich habe damit noch nicht angefangen; wegen fehlender/falscher Melder ist der derzeitige Nutzwert bei mir nicht soo groß. Aber ich möchte gern mal probieren...

Ich weiß nicht, ob meine Bitte zu unverfroren ist: Wäre es denn möglich, mal ein einfaches Beispiel (ich weiß nicht, zwei Zonen, zwei doif) zu veröffentlichen? Und natürlich die Moduldefinition mit Attributen.

Also *mir* würde es den Start deutlich erleichtern.

[KernSani]

Mal kleines Beispiel vielleicht hilft das beim Verständnis - die Toilette besteht im Wesentlichen aus den Default-Attributen und ein paar zusätzlichen Attributen:
- die .*Event-Attribute zur Erkennung von Bewegung und open/close der Türe
- die cmd.* Attribute steuern in welchem state das Licht an und aus geht.

Zusätzlich ist noch ein genereller Threshold für die Helligkeit hinterlegt, d.h. die cmds werden nur ausgeführt wenn die Helligkeit < 40 ist. Nur das absent-Cmd wird immer ausgeführt (threshold 0 - unendlich)

Code Auswählen Erweitern


defmod hz_EG_WC homezone
attr hz_EG_WC userattr hz_cmd_absent hz_cmd_likely hz_cmd_present hz_cmd_unlikely hz_lumiThreshold_absent hz_lumiThreshold_likely hz_lumiThreshold_present hz_lumiThreshold_unlikely
attr hz_EG_WC alias EG WC Anwesenheit
attr hz_EG_WC devStateIcon present:user_available@green likely:user_available@lightgreen unlikely:user_unknown@yellow absent:user_away
attr hz_EG_WC group Zonen
attr hz_EG_WC hz_closedEvent EG_WC_Tuer:contact:.close
attr hz_EG_WC hz_cmd_absent set EG_WC_Licht off
attr hz_EG_WC hz_cmd_likely set EG_WC_Licht on
attr hz_EG_WC hz_cmd_present set EG_WC_Licht on
attr hz_EG_WC hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
attr hz_EG_WC hz_decay 120
attr hz_EG_WC hz_lumiThreshold 0:40
attr hz_EG_WC hz_lumiThreshold_absent 0:
attr hz_EG_WC hz_occupancyEvent EG_WC_motion2:occupancy:.true
attr hz_EG_WC hz_openEvent EG_WC_Tuer:contact:.open
attr hz_EG_WC hz_state 100:present 50:likely 1:unlikely 0:absent


Hilft das schon?

[Laffer72]

Hallo KernSani,

erstmal danke für das interessante Modul.
Kann es sein, daß man beim cmd-Attribut nur einen Befehl angeben kann? Ich hätte da mehrere Aktoren zu schalten.
Habe schon mit ; oder , oder ;; versucht zwei set-Befehle zu trennen. Es klappt aber nicht, es wird dann gar kein Befehl ausgeführt.

[KernSani]

Hallo KernSani,

erstmal danke für das interessante Modul.
Kann es sein, daß man beim cmd-Attribut nur einen Befehl angeben kann? Ich hätte da mehrere Aktoren zu schalten.
Habe schon mit ; oder , oder ;; versucht zwei set-Befehle zu trennen. Es klappt aber nicht, es wird dann gar kein Befehl ausgeführt.

Bei mir funktioniert das (mit einfachem ";" getrennt). Hst du mal ins Log geschaut? Da sollte eine Meldung stehen, wenn der Befehl nicht funktioniert.

[curt]

Hilft das schon?

Das kann ich noch nicht beantworten; ich ärgere mich erstmal mit einem SignalDuino-Dingens rum. Danach ... ich habe zwei Bewegungsmelder, die ich mal aus einer Laune heraus beschaffte. Den einen habe ich jetzt so auffällig auf den Esstisch gelegt, dass es schon wieder unauffällig ist.

Ich danke Dir für den Beispielcode.