Zonen-basierte Anwesenheitserkennung und -steuerung

Begonnen von KernSani, 15 März 2019, 19:06:04

Vorheriges Thema - Nächstes Thema

ComputerZOO

Moin,
wäre es evtl. noch möglich ein Userattribut einzubauen, welches das sofortige setzen einer Zone auf ,,absent" stellt? Ich benutze die Homematic Bewegungsmelder mit den zwei Tastern. Wenn ich das Licht manuell abschalte, dann ist auch keiner mehr im Raum.

ComputerZOO

...Ich gehe mal besser ins Bett...
habe gerade gesehen, dass es bereits open- und close-Events gibt...

Sehr schönes Modul, ist dir echt gelungen!

curt

@Pythonf
Zitat von: KernSani am 15 März 2019, 19:06:04
das Haus mit den kleinen XIAOMI motion Sensoren zu pflastern

Link?

Das Problem bei allen derzeitigen Bewegungssensoren ist ja im Grunde, dass die sehr auftragen. Ein Balanceakt zwischen "wir sind die Guten" und "wir sind die gute NSA" ...

Als derzeitiger Tester falle ich aus - nicht genügend Sensoren vorhanden.

Zitat von: KernSani am 15 März 2019, 19:06:04
mit dem ich versuche eine "Zonen-basierte Anwesenheitserkennung" zu verwirklichen.

Nur das käme für mich in Frage. Ich will weder ein Familienmitglied noch einen Gast überwachen - ich will lediglich wissen, ob jemand da ist. Die Draußen-Katze ist übrigens ein kritischer Sonderfall: Die darf drin sein, soll aber nicht als anwesend zählen.

Zitat von: KernSani am 15 März 2019, 19:06:04
Mich würde interessieren:

Das da jemand einen vielleicht spannenden ersten Ansatz hat: https://forum.fhem.de/index.php/topic,95971.0.html

Zitat von: KernSani am 15 März 2019, 19:06:04
ob ihr Interesse an einem solchen Modul hättet

Ja.
RPI 4 - Jeelink HomeMatic Z-Wave

binford6000

Moin Oli,
als Feedback zu 0.0.5:
nach dem reload kommt folgende Meldung:
2019.03.18 09:58:40 1: PERL WARNING: Subroutine homezone_Initialize redefined at ./FHEM/98_homezone.pm line 48.
2019.03.18 09:58:40 1: PERL WARNING: Subroutine homezone_Define redefined at ./FHEM/98_homezone.pm line 74.
2019.03.18 09:58:40 1: PERL WARNING: Subroutine homezone_Undefine redefined at ./FHEM/98_homezone.pm line 109.


Danach habe ich ein Update gemacht um auch shutdown/restart zu machen:
Messages collected while initializing FHEM:
configfile: Couldn't get a luminance value for reading brightness of device fl_bwm

fl_bwm ist ein Homematic device mit brightness Reading.
Bei folgendem device bekomme ich partout keine hz_cmd userattr - auch nach manuellem attr hz_state:

Historie löschen
Internals:
   FUUID      5c8bead4-f33f-0308-08a7-e01e244c7c0155f4
   FVERSION   98_homezone.pm:v0.0.5-s18522/2019-02-07
   NAME       fl_zone
   NR         404
   NTFY_ORDER 50-fl_zone
   STATE      absent
   TYPE       homezone
   VERSION    0.0.5
   READINGS:
     2019-03-17 20:24:33   condition       open
     2019-03-18 07:37:39   dayTime         morning
     2019-03-18 10:05:27   lastDayTime     day
     2019-03-18 10:05:27   lastZone        timer
     2019-03-18 10:05:27   occupied        0
     2019-03-18 10:05:27   state           absent
   helper:
     TIMER      1552899927
Attributes:
   devStateIcon present:user_available@blue likely:user_available@lightgreen unlikely:user_unknown@orange absent:user_away@red
   hz_dayTimes $SUNRISE|sr $SUNSET|ss 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
   hz_decay   300
   hz_occupancyEvent fl_bwm:motion
   hz_state   100:present 50:likely 1:unlikely 0:absent
   icon       floor
   userattr   hz_decay_afternoon hz_decay_day hz_decay_evening hz_decay_morning hz_decay_night hz_decay_sr hz_decay_ss hz_decay_sr hz_decay_ss


Füge ich einen weiteren state hinzu:
100:present 50:likely 30:test 1:unlikely 0:absent
bekomme ich nur für diesen ein hz_cmd_test userattr:
hz_decay_afternoon hz_decay_day hz_decay_evening hz_decay_morning hz_decay_night hz_decay_sr hz_decay_ss hz_decay_sr hz_decay_ss hz_cmd_test hz_lumiThreshold_test

VG Sebastian



patlabor

Mir ist gerade noch eine Sache aufgefallen. Liegt aber vermutlich eher daran das ich noch lange nicht alle Möglichkeiten von fhem durchschaut habe.

Wenn es zu einem Raum mehrere Türen gibt, reicht es wenn eine einzige Tür wieder geschlossen wird, damit der Raum als closed gilt. Unabhängig davon ob noch andere Türen auf sind.

Als Beispiel: Ein Flur mit einer Tür in einen weiteren Flur (tk_flur) und einer Tür zu einer Abstellkammer (tk_abstellkammer). Als hz_openEvent ist tk_(flur|abstellkammer):contact:.false, als hz_closedEvent ist tk_(flur|abstellkammer):contact:.true definiert.
Geht jetzt jemand durch tk_flur und lässt die Tür offen ist der Raum open. Danach öffnet man die Abstellkammer, der Raum bleibt weiter open. Schließe ich jetzt die Abstellkammer ist der Raum closed obwohl tk_flur noch offen ist. Auf dem Weg durch den Flur, löse ich den Bewegungsmelder aus, jetzt ist occupied 100 %. Verlasse ich den Raum jetzt, ohne tk_flur zu schließen bleibt occupancy auf 100 % stehen, auch ein nachträgliches schließen von tk_flur ändert nichts. Erst wenn die Tür geschlossen und wieder geoffnet wird, zählt der contdown wieder runter.

Eisix

Hallo,

interessanter Ansatz, werde ich mal testet. Gibt es die Möglichkeit bei bestimmten Events einen festen Wert zu setzen. Als Beispiel: Ist der PC im Kinderzimmer an kann ich zu 80% davon ausgehen das jemand im Raum ist und mit 90% Sicherheit auch wer das in dem Moment ist.
Das über mehrere Räume und diverse Bedingungen sollte dann für jeden Raum und Person eine Wahrscheinlichkeit ergeben. Geht schon in Richtung Rasterfahndung oder KI  ::)

Gruß
Eisix

KernSani

Zitat von: ComputerZOO am 17 März 2019, 23:53:03
Moin,
wäre es evtl. noch möglich ein Userattribut einzubauen, welches das sofortige setzen einer Zone auf ,,absent" stellt? Ich benutze die Homematic Bewegungsmelder mit den zwei Tastern. Wenn ich das Licht manuell abschalte, dann ist auch keiner mehr im Raum.
open und close Events sind dafür nicht geeignet. ein "absenceEvent" würde aber tatsächlich Sinn machen - bei Licht aus wäre ein möglicher Anwendungsfall, bei RESIDENTS absent macht es aber sicherlich auch Sinn :-)

Zitat von: curt am 18 März 2019, 05:07:22
Link?
https://www.google.com/search?q=xiaomi+motion+sensor

ZitatAls derzeitiger Tester falle ich aus - nicht genügend Sensoren vorhanden.
Als "Anwesenheits-Event" kann z.B. auch ein gedrückter Lichtschalter oder das Einschalten des Fernsehers dienen ;-)

ZitatNur das käme für mich in Frage. Ich will weder ein Familienmitglied noch einen Gast überwachen - ich will lediglich wissen, ob jemand da ist. Die Draußen-Katze ist übrigens ein kritischer Sonderfall: Die darf drin sein, soll aber nicht als anwesend zählen.
Das ist das realistischste Szenario - noch besser aber wenn man tatsächlich die Person erkennt und auf deren Bedürfnisse oder Verhaltensweisen reagieren kann (Wenn Oma auf Toilette geht, wird dort Helene Fischer gespielt :-D) Es geht nicht um Überwachung


ZitatDas da jemand einen vielleicht spannenden ersten Ansatz hat: https://forum.fhem.de/index.php/topic,95971.0.html
Schau ich mir definitiv genauer an

Zitat von: binford6000 am 18 März 2019, 10:25:44
Moin Oli,
als Feedback zu 0.0.5:
nach dem reload kommt folgende Meldung:
(..)
Ich war gestern ein bisschen voreilig mit dem Hochladen, nach der großen Umbau-Aktion. Schaue ich mir an, ich habe auch noch ein/zwei Bugs bei mir, die ich fixen muss.

Zitat von: patlabor am 18 März 2019, 15:23:44
Mir ist gerade noch eine Sache aufgefallen. Liegt aber vermutlich eher daran das ich noch lange nicht alle Möglichkeiten von fhem durchschaut habe.

Wenn es zu einem Raum mehrere Türen gibt, reicht es wenn eine einzige Tür wieder geschlossen wird, damit der Raum als closed gilt. Unabhängig davon ob noch andere Türen auf sind.

Als Beispiel: Ein Flur mit einer Tür in einen weiteren Flur (tk_flur) und einer Tür zu einer Abstellkammer (tk_abstellkammer). Als hz_openEvent ist tk_(flur|abstellkammer):contact:.false, als hz_closedEvent ist tk_(flur|abstellkammer):contact:.true definiert.
Geht jetzt jemand durch tk_flur und lässt die Tür offen ist der Raum open. Danach öffnet man die Abstellkammer, der Raum bleibt weiter open. Schließe ich jetzt die Abstellkammer ist der Raum closed obwohl tk_flur noch offen ist. Auf dem Weg durch den Flur, löse ich den Bewegungsmelder aus, jetzt ist occupied 100 %. Verlasse ich den Raum jetzt, ohne tk_flur zu schließen bleibt occupancy auf 100 % stehen, auch ein nachträgliches schließen von tk_flur ändert nichts. Erst wenn die Tür geschlossen und wieder geoffnet wird, zählt der contdown wieder runter.
Korrekte Beobachtung... Mist, habe ich nicht bedacht... Die Lösung wäre, dass man mehrere "closed"-Events definiert, die alle erfüllt sein müssen - mal schauen, wie ich das elegant hinbekomme

Zitat von: Eisix am 18 März 2019, 16:26:46
Hallo,

interessanter Ansatz, werde ich mal testet. Gibt es die Möglichkeit bei bestimmten Events einen festen Wert zu setzen. Als Beispiel: Ist der PC im Kinderzimmer an kann ich zu 80% davon ausgehen das jemand im Raum ist und mit 90% Sicherheit auch wer das in dem Moment ist.
Das über mehrere Räume und diverse Bedingungen sollte dann für jeden Raum und Person eine Wahrscheinlichkeit ergeben. Geht schon in Richtung Rasterfahndung oder KI  ::)

Gruß
Eisix

Zum ersten Punkt: Man kann über set occupied einen Wert setzen - sofern der Raum nicht "geschlossen" ist, wenn der nicht 100 ist, wird dann aber runtergezählt. Ich habe tatsächlich meinen PC als "closedEvent" definiert - solange er an ist, ist jemand im Raum. Wenn ich weggehe geht er nach ein paar Minuten in Standby und der Timer läuft los. (Der Fernseher ist auch ein "closedEvent")

Zum zweiten Punkt: Tatsächlich habe ich mir dazu auch schon Gedanken gemacht, bin aber noch nicht wirklich zu einem Ergebnis gekommen. Mal angeommen ich identifiziere alle Familienmitglieder über Roomates alle 4 sind zu Hause, ein Sohn sitzt an seinem PC, die Bewegung im Arbeitszimmer war wahrscheinlich ich, dann ist die Bewegung in der Küche mit hoher Wahrscheinlichkeit meine Frau etc... Das geht dann aber wahrscheinlich in die oben verlinkte KI Ecke ;-)


RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

loescher

Google findet da relativ viel mit Xiaomi Motion Sensor.
Hast du da eine genauere Modell-Bezeichnung?
LG, Stephan.

KernSani

Zitat von: loescher am 18 März 2019, 20:56:42
Google findet da relativ viel mit Xiaomi Motion Sensor.
Hast du da eine genauere Modell-Bezeichnung?
LG, Stephan.

Sorry, hatte das Stichwort "aqara" vergessen, das sind die die ich habe. In aller Kürze (es gibt genügend Bewertungen und Erfahrungen zu den Dingern, auch hier im Forum):
+ günstig (insbesondere aus China)
+ über zigbee2mqtt ohne proprietäres Gateway an FHEM anzubinden
+ klein und unauffällig
+ lange Batterielaufzeit (angeblich 2 Jahre)
- nicht konfigurierbar
- lange "dead"-Zeit nach erkannter Bewegung

RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

binford6000

ZitatIch war gestern ein bisschen voreilig mit dem Hochladen, nach der großen Umbau-Aktion. Schaue ich mir an, ich habe auch noch ein/zwei Bugs bei mir, die ich fixen muss.

Ergänzung: Bei allen meinen homezone devices aktualisiert sich das dayTime reading nicht mehr. Alle anderen readings schon:
Internals:
   DEF       
   FUUID      5c8d2444-f33f-0308-7de3-bff15558551011af
   FVERSION   98_homezone.pm:v0.0.5-s18522/2019-02-07
   NAME       bu_zone
   NR         413
   NTFY_ORDER 50-bu_zone
   STATE      present
   TYPE       homezone
   VERSION    0.0.5
   READINGS:
     2019-03-18 21:40:34   condition       closed
     2019-03-17 23:06:55   dayTime         night
     2019-03-18 22:12:47   lastDayTime     evening
     2019-03-18 22:12:47   lastZone        self
     2019-03-18 22:12:47   occupied        100
     2019-03-18 22:12:47   state           present
   helper:
     TIMER      1552941969
Attributes:
   devStateIcon present:user_available@blue likely:user_available@lightgreen unlikely:user_unknown@orange absent:user_away@red
   hz_adjacent fl_zone
   hz_closedEvent shuttle.pc:on
   hz_cmd_absent set bu_scene scene abwesend
   hz_cmd_present set bu_scene scene anwesend
   hz_dayTimes $SUNRISE|sr $SUNSET|ss 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
   hz_decay   500
   hz_decay_afternoon 300
   hz_decay_evening 3600
   hz_occupancyEvent bu_bwm:on
   hz_openEvent shuttle.pc:off
   hz_state   100:present 50:likely 1:unlikely 0:absent
   icon       floor
   userattr   hz_cmd_absent hz_cmd_likely hz_cmd_present hz_cmd_unlikely hz_decay_afternoon hz_decay_day hz_decay_evening hz_decay_morning hz_decay_night hz_decay_sr hz_decay_ss hz_lumiThreshold_absent hz_lumiThreshold_likely hz_lumiThreshold_present hz_lumiThreshold_unlikely hz_decay_sr hz_decay_ss


VG Sebastian

KernSani

Hi Sebastian,

ich habe dayTime durch lastDayTime ersetzt (da das Reading nur bei einem Anwesenheitsevent aktualisiert wird und nicht den aktuellen Wert anzeigt). Letzteres scheint korrekt aktualisiert zu werden.

Grüße,

Oli
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

KernSani

@Sebastian: Was mir noch aufgefallen ist, unabhängig von dem Fehler, den ich noch finden muss:
hz_dayTimes $SUNRISE|sr $SUNSET|ss 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
wird nicht funktionieren, da die jeweiligen Zeiträume wie bei HOMEMODE über den Abstand von Zeitpunkt x - Zeitpunkt y berechnen und sortiert sein müssen. Bei variablen Angaben mit $SUNRISE/$SUNSET macht eigentlich nur sowas Sinn
hz_dayTimes $SUNRISE|day $SUNSET|night
oder vielleicht in der Art:
hz_dayTimes 03:00|earlyMorning $SUNRISE|morning 11:30|lunch 13:00|afternoon $SUNSET|night
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

KernSani

neue Version, mit einigen Bugfixes und neuem "absenceEvent" im ersten Post.
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

curt

Zitat von: KernSani am 18 März 2019, 20:34:15
ZitatLink?
https://www.google.com/search?q=xiaomi+motion+sensor

Kannst Du bitte kurz sagen, was die erwartete FHEM-Gegenstelle ist? Ich würde sodann mal einen bestellen wollen. Anscih weiß ich aber nicht, ob das in einem Haushalt, der extrem sensibel auf das Wort "Überwachung" hört, so gut kommt. Will sagen: Der trägt immer noch stark auf.

Zitat von: KernSani am 18 März 2019, 20:34:15
ZitatAls derzeitiger Tester falle ich aus - nicht genügend Sensoren vorhanden.
Als "Anwesenheits-Event" kann z.B. auch ein gedrückter Lichtschalter oder das Einschalten des Fernsehers dienen ;-)

Das habe ich alles nicht. Also schon, nur nicht sooo ... ok, kurz OT:

FHEM-geeignet und angebunden sind (ca.) 10 Temperatursensoren, 10 Fenstermelder, 10 Strom-Zwischenstecker (die durchaus zur Abschätzung dienen könnten).

Nicht FHEM-geeignet sind alle Taster/Schalter, weiterhin 20 Rolladen-Taster Marke Somfy-sehr_alt. Da könnte man überlegen - allerdings neige ich zu dem Modell "muss auch alles bei FHEM-Ausfall funktionieren". Es ist nicht so, dass ich ausnehmend arm bin, also da ginge schon was. Andererseits lernt man bei den Reichen das sparen: Ich würde ungern auf Verdacht hin sämtliche Stromschalter austauschen wollen (da fand ich auch noch nichts Sinnvolles).

Zitat von: KernSani am 18 März 2019, 20:34:15
ZitatDas da jemand einen vielleicht spannenden ersten Ansatz hat: https://forum.fhem.de/index.php/topic,95971.0.html
Schau ich mir definitiv genauer an

Der Kollege @Pythonf codet da offensichtlich was - hat aber noch nichts gezeigt. Dessen nur erzählter Ansatz könnte aber eine schlaue Ergänzung Deines Ansatzes sein - so jedenfalls mein erster Eindruck.

Zu mir: Ich habe Deinen derzeitigen Code nicht eingebunden, siehe oben. Zudem habe ich mich bisher erfolgreich vor dem doif-Konzept gedrückt. Ich selbst bin von der damaligen Ausbildung her Verfahrenstechniker mit Schwerpunkt Systemanalyse. Ein naher Verwandter ist Mathematiker mit Schwerpunkt Statistik.
RPI 4 - Jeelink HomeMatic Z-Wave

Pythonf

#44
ZitatDer Kollege @Pythonf codet da offensichtlich was - hat aber noch nichts gezeigt.

Ich möchte an dieser Stelle gerne mal mein Interesse zeigen. Ich schreib gerade an einem Python Programm, welches in erster Version Daten aus FHEM (aktuell nur dblog + mysql möglich) liest und diese einem Reinforcment Learning Modell übergibt. Vieles funktioniert schon, allerdings fehlt eine konkrete Einsatzmöglichkeit. Ich fände es sehr spannend, ein Modell hier zusammen zu entwickeln, was die Vorhersagen verbessert. Ob es die Ergebnisse dabei dann wirklich verbessern wird, müsste man testen und lässt sich schwer voraussagen. Da wir aber hier von Wahrscheinlichkeiten sprechen, stehen die Chancen einer deutlichen Verbesserung nicht schlecht. Ich bin allerdings an Python gebunden, zum einen, weil ich bisher nichts in Perl geschrieben habe und zum anderen weil die verwendeten Bibliotheken (Tensorflow, tf_agents) für Python geschrieben sind.

Wie könnte denn ein möglicher Ansatz aussehen?
Was für mich bzw. ein Modell wichtig wäre, dass sind 3 Dinge:

  • Observation: Der Zustand des smartHome (Sensoren, Zeit, etc.), die Hierarchie der Räume,
  • Aktion: Die Änderung der Anwesenheit
  • Reward: Eine Rückmeldung an das Modell, ob seine Vorhersage gut oder schlecht war

1. ist für dblog mit mysql relativ einfach umzusetzen, für sqlite etwas schwieriger aber ebenfalls möglich. FileLog wäre für mich mit der meisten Arbeit versehen, aber später auch möglich. Ich würde mich aber gerne erstmal auf dblog festlegen wollen. FileLog Reader für Python https://github.com/PythonFZ/FHEM-FileLog-Reader
2. Wäre im Optimalfall ein binärer Wert: Anwesend oder nicht Anwesend. Hier ist mir noch keine Idee eingefallen, wie sich das umsetzten ließe. In deinem Modul verwendest du ja soweit ich das verstanden habe zwei verschiedene Ansätze "Wasp-in-a-box Konzept" und eine Abnahme der Anwesenheitswahrscheinlichkeit mit der Zeit.
3. Hier verwendet man zumeist irgendwelche Integer, aber auch hier fällt mir noch nichts konkretes ein.

Die Voraussetzung wäre also eine Idee, wie man Daten über die Anwesenheit gewinnt, welche man eigentlich vorhersagen will. In verschiedenen Publikationen wurden die Bewohner gebeten, ihre Aktivitäten über Tage/Wochen zeitlich datiert aufzuschreiben und damit wurde dann trainiert. Das ist aber in dieser Form definitiv nicht alltagstauglich. Falls jemand Ideen oder auch Fragen hat, dann versuche ich die gerne zu beantworten. Da das ganze aber alles noch eher auf theoretischer Ebene abläuft, würde ich das gerne erstmal hier: https://forum.fhem.de/index.php/topic,95971.15.html besprechen wollen, damit sich dieser Thread auf das Modul konzentrieren kann.