Zonen-basierte Anwesenheitserkennung und -steuerung

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

Vorheriges Thema - Nächstes Thema

binford6000

Hallo Dorian,
das Event entnimmst du am besten aus dem Eventmonitor. Meine HUE-bwms reagieren auf
hz_occupancyEvent fl_bwm:motion

Hier mal eine Zone von mir.
Internals:
   FUUID      5c8bead4-f33f-0308-08a7-e01e244c7c0155f4
   FVERSION   98_homezone.pm:v0.0.13-s18522/2019-02-07
   NAME       fl_zone
   NR         279
   NTFY_ORDER 50-fl_zone
   STATE      absent
   TYPE       homezone
   VERSION    0.0.13
   HELPER:
     doors      0
   READINGS:
     2019-03-24 09:23:36   condition       open
     2019-09-06 19:45:33   lastDayTime     evening
     2019-09-06 19:45:33   lastLumi        16
     2019-09-06 19:45:33   lastZone        timer
     2019-09-06 19:45:33   lux             16
     2019-09-06 19:45:33   occupied        0
     2019-09-06 19:45:33   state           absent
     2019-08-20 10:58:22   targetlux       40
   helper:
     TIMER      1567791933
Attributes:
   cmdIcon    occupied0:radio_checked@red
   devStateIcon inactive:ios-NACK present:user_available@blue likely:user_available@lightgreen unlikely:user_unknown@orange absent:user_away@red
   eventMap   /occupied 0:occupied0/
   group      Homezone
   hz_absenceEvent Wohnung:presence:.absent
   hz_cmd_absent set fl_szene:FILTER=scene!=abwesend scene abwesend;
set fully:FILTER=STATE!=off off;
   hz_cmd_likely IF ([Wohnung] eq "asleep" && [fl_zone:lux] <= [fl_zone:targetlux]) (set fl_szene:FILTER=scene!=schlafen scene schlafen);
IF ([Wohnung] ne "asleep" && [fl_zone:lux] <= [fl_zone:targetlux]) (set fl_szene:FILTER=scene!=anwesend scene anwesend);
IF ([Wohnung] ne "asleep") (set fully:FILTER=STATE!=on on-for-timer 180);
   hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
   hz_decay   300
   hz_decay_evening 600
   hz_decay_night 120
   hz_luminanceReading fl_huesens_light:lux
   hz_occupancyEvent fl_bwm:motion
   hz_state   100:present 50:likely 1:unlikely 0:absent
   icon       floor
   room       50_Zonen
   userReadings lux {ReadingsNum('fl_huesens_light','lux',50);;},
targetlux
   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  :textField-long    :textField-long    :textField-long    :textField-long   hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent
   webCmd     occupied0


VG Sebastian

SeppiDeluxe

Guten Morgen,

@Eisix besteht dein Problem immer?

Ich habe seit ca. 1,5 Wochen das selbe Problem. Der Absturz von FHEM folgt dann aus einer OOM Aktion. Ich habe das in meinem System soweit debugt, das das Szenario sich aufbaut bis das System aufgibt. Heißt bis zum Absturz können Sekunden oder aber mehrere Minuten vergehen.

Trotz der aktuellen Möglichkeiten apptime / fhemdebug, könnte ich noch nicht eingrenzen, ob Homezone direkt oder das Zusammenspiel mit Konf oder anderen Modulen der Auslöser ist.

Ich werde Homezone leider deaktivieren müssen, da mein aktueller Mem Watchdog mit restart, keine akzeptable Lösung ist.

Wenn jemand noch Anregungen hat, gern

Danke Sebastian

2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::CallFn" at fhem.pl line 1892.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::apptime_getTiming" at ./FHEM/98_apptime.pm line 138.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::homezone_setOcc" at ./FHEM/98_homezone.pm line 427.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommandChain" at ./FHEM/98_homezone.pm line 330.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommand" at fhem.pl line 1091.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::CommandSet" at fhem.pl line 1238.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::DoSet" at fhem.pl line 1924.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::homezone_Set" at ./FHEM/98_apptime.pm line 178.
Out of memory!

binford6000

2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::CallFn" at fhem.pl line 1892.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::apptime_getTiming" at ./FHEM/98_apptime.pm line 138.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::homezone_setOcc" at ./FHEM/98_homezone.pm line 427.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommandChain" at ./FHEM/98_homezone.pm line 330.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::AnalyzeCommand" at fhem.pl line 1091.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::CommandSet" at fhem.pl line 1238.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::DoSet" at fhem.pl line 1924.
2019.09.28 08:43:55 1: PERL WARNING: Deep recursion on subroutine "main::homezone_Set" at ./FHEM/98_apptime.pm line 178.


Hmm das deutet doch auf eine Schleife hin...  :o

ZitatIch vermute es liegt an einem hz_occupancyEvent weil ich da einige verändert hatte, konnte aber noch nicht identifizieren welche Zone es ist. Oder habe ich einen Bug gefunden?

Du kannst doch mal alle Zonen auf inactive setzen und dann eine nach der anderen wieder aktivieren und schauen wann der Fehler auftritt.
Dann hast du zumindest schon mal die Zone und kannst dann weiter debuggen (hz_occupancyEvent...)  ;)

VG Sebastian

SeppiDeluxe


Eisix

Hallo,

Es liegt  bei mir am hz_occupancyEvent. Ich hatte vorher zwei Zonen verändert. Nachdem ich beide wieder entfernt habe ist alles wieder stabil. Zu weiteren Nachforschungen kam ich noch nicht.

Gruß
Eisix

Reinschki

Hallo, ich hatte zwei Zonen mal gegenseitig mit dem Attribut hz_children ausgestattet. Danach hatte ich auch Fhem Absturz und Einträge im Log wie "Deep recursion on subroutine "main::homezone_Set". Nach dem Entfernen des Attributs in einer der Zonen läuft das wieder stabil!

SeppiDeluxe

Danke für die zusätzlichen Erfahrungen. Ich teste gerade Zone für Zone. Fakt ist leider das 48h ohne aktive Zone keinen Absturz provoziert haben, so dass ich die Fehlersuche auf diesen Bereich einschränken kann. Aber die von euch beschriebenen DeadLocks leuchten mir ein.

SeppiDeluxe

Hallo,

ich habe meine Suche jetzt auf meine beiden Flure eingrenzen können. Wahrscheinlich hängt es mit der Art und Weise wie ich adjacent einsetze zusammen. Abhilfe scheint boxMode zu bringen. Da ich nichts weiterführendes finde und die .pm Aalyse nicht final Aufschluss gegeben hat, kann mir bitte jemand noch mal die beiden Attribut Multidoor und boxMode erläutern.

Ich muss intensiv mit den closed Evens arbeiten, da meine Aqara Sensoren mit Conbee nur alle 60min auf Erfassung schalten. Das muss ich kompensieren. Denn ohne closed löst die Zone sofort bei nomotion aus und ich tanze leider nicht permanent vor den Teilen .. also Nachlaufzeit (der Timer schluckt das in einer einfachen Konf leider nicht).

Danke euch

binford6000

Moin,
ich habe leider keine Türsensoren - kann dir leider nicht direkt helfen. ABER:

  • Die ZigBee Sensoren generieren doch EVENTS - unabhängig vom Aktualisierungsintervall...
  • Schau dir die Events im Eventmonitor an und trage sie im jeweiligen Attribut ein.

Damit sollten die jeweiligen CMDs via Attribut auch greifen. Ich habe closed/open Events im Wohnzimmer von der Anwesenheit des TVs eingestellt.
Mit dem passenden Event läuft das alles wie gewünscht.

Adjacent und Boxmode habe ich nicht im Betrieb. Da kann ich dir leider gar nichts zu sagen...

VG Sebastian

trinitywhm

Zitat von: KernSani am 15 März 2019, 19:06:04
hz_dayTimes: Leerzeichen-getrennt Liste von Uhrzeit:Text Paaren. Dient zur Steuerung tageszeitabhängiger decay-Werte. Für jeden "text" wird ein zugehöriges decay-Userattribut erzeugt, mit dem die korrespondierenden Decay-Werte gepflegt werden. Das Attribut wird beim Define automatisch gesetzt und - sofern vorhanden - mit dem Wert aus HOMEMODE gefüllt. Die variablen $SUNRISE und $SUNSET können anstatt Uhrzeit verwendet werden.

Im ersten Beitrag schreibst du das die DayTimes aus dem HOMEMODE-Device übernommen werden falls eins angelegt ist. Bei mir ist das nicht der Fall.
Daytimes aus Homemode
00:00|Mitternacht 03:00|Nacht 06:00|Morgen 08:00|Vormittag 13:00|Mittagsruhe 15:00|Nachmittag 18:30|Abend 23:00|Spätabend
DayTimes in homezone
05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night

Woran kann das liegen?

willib

Ich finde das Konzept super. Vielen Dank für das Modul.
Ich verstehe aber noch nicht wie ich es verwenden muss. Ich wollte es gestern mit meinem Gästeklo versuchen.
Internals:
   CFGFN     
   FUUID      5dfa876d-f33f-7452-4442-7fa8cdf93d7e3870
   NAME       KLO_Zone
   NR         32172
   NTFY_ORDER 50-KLO_Zone
   STATE      present
   TYPE       homezone
   VERSION    0.0.13
   HELPER:
     doors      1
   READINGS:
     2019-12-18 21:22:35   condition       closed
     2019-12-18 21:23:34   lastDayTime     evening
     2019-12-18 21:23:34   lastZone        self
     2019-12-18 21:23:34   occupied        100
     2019-12-18 21:23:34   state           present
Attributes:
   devStateIcon present:user_available@green likely:user_available@lightgreen unlikely:user_unknown@yellow absent:user_away
   hz_closedEvent KLO_Tuer:closed
   hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
   hz_occupancyEvent KLO.Motion:motion
   hz_openEvent KLO_Tuer:open
   hz_state   100:present 50:likely 1:unlikely 0:absent
   room       Gästeklo
   userattr   hz_cmd_present:textField-long hz_lumiThreshold_present hz_cmd_likely:textField-long hz_lumiThreshold_likely hz_cmd_unlikely:textField-long hz_lumiThreshold_unlikely hz_cmd_absent:textField-long hz_lumiThreshold_absent hz_decay_morning hz_decay_day hz_decay_afternoon hz_decay_evening hz_decay_night

Wenn nun jemand kurz die Tür aufmacht passiert im Eventmonitor folgendes (nicht beteiligte Devices habe ich entfernt):
2019-12-18 21:22:30 CUL_HM KLO_Tuer battery: ok
2019-12-18 21:22:30 CUL_HM KLO_Tuer contact: open (to VCCU)
2019-12-18 21:22:30 CUL_HM KLO_Tuer open
2019-12-18 21:22:30 CUL_HM KLO_Tuer trigger_cnt: 111
2019-12-18 21:22:32 homezone KLO_Zone occupied: 99
2019-12-18 21:22:32 homezone KLO_Zone likely
2019-12-18 21:22:32 homezone KLO_Zone lastZone: self
2019-12-18 21:22:32 homezone KLO_Zone occupied: 99
2019-12-18 21:22:32 homezone KLO_Zone likely
2019-12-18 21:22:32 homezone KLO_Zone lastZone: self
2019-12-18 21:22:32 homezone KLO_Zone occupied: 99
2019-12-18 21:22:32 homezone KLO_Zone likely
2019-12-18 21:22:32 homezone KLO_Zone lastZone: self
2019-12-18 21:22:32 CUL_HM KLO.Motion battery: ok
2019-12-18 21:22:32 CUL_HM KLO.Motion brightness: 33
2019-12-18 21:22:32 CUL_HM KLO.Motion motion: on (to VCCU)
2019-12-18 21:22:32 CUL_HM KLO.Motion motionCount: 35_next:60s
2019-12-18 21:22:32 CUL_HM KLO.Motion motion
2019-12-18 21:22:32 CUL_HM KLO.Motion trigger_cnt: 35
2019-12-18 21:22:35 homezone KLO_Zone condition: closed
2019-12-18 21:22:35 homezone KLO_Zone condition: closed
2019-12-18 21:22:35 CUL_HM KLO_Tuer battery: ok
2019-12-18 21:22:35 CUL_HM KLO_Tuer contact: closed (to VCCU)
2019-12-18 21:22:35 CUL_HM KLO_Tuer closed
2019-12-18 21:22:35 CUL_HM KLO_Tuer trigger_cnt: 112

2019-12-18 21:23:34 homezone KLO_Zone occupied: 100
2019-12-18 21:23:34 homezone KLO_Zone present
2019-12-18 21:23:34 homezone KLO_Zone lastZone: self
2019-12-18 21:23:34 homezone KLO_Zone occupied: 100
2019-12-18 21:23:34 homezone KLO_Zone present
2019-12-18 21:23:34 homezone KLO_Zone lastZone: self
2019-12-18 21:23:34 CUL_HM KLO.Motion motion: off
2019-12-18 21:23:34 CUL_HM KLO.Motion motionDuration: 62
2019-12-18 21:23:34 CUL_HM KLO.Motion noMotion 

Somit ist die Wahrscheinlichkeit auf 100 und bleibt auch da obwohl niemand im Raum ist.
Muss ich die Regex beim hz_occupancyEvent anpassen? Hat das Modul jetzt motion:off verwendet?
FHEM in Debian 10 LXC unter Proxmox auf NUC, Homematic, Hue, Intertechno, Jeelink, RFXTRX, Harmony Hub, VU+ Uno 4K, Sonos, AMAD

Eisix

Hallo,

da fehlt noch was:

hz_decay: "Verfallszeit" in Sekunden, also die Zeit, die vergehen soll bis der Timer nach erkannter Bewegung auf 0 runter gezählt hat. Wird ggf. überteuert von tageszeitabhängiger Steuerung (siehe hz_dayTimes)

Gruß
Eisix

willib

Ok Danke. Teste ich.
Ich dachte es würde einen default Wert geben. Außerdem habe ich das Attribut nicht verstanden. Für mich wäre das die Zeit die vergehen soll bis die Anwesenheits-Wahrscheinlichkeit auf null runter fällt.
Kannst du mir das Attribut genauer erklären?
Allerdings sehe ich das Problem in meinem Fall eher darin, dass homezone in einem verschlossenen Raum ohne eine Bewegung von 99 auf 100 springt. Das sollte so wie ich die Beschreibung verstanden habe nur passieren wenn eine Bewegung im verschlossenen Raum erkannt wird.
Vielen Dank
FHEM in Debian 10 LXC unter Proxmox auf NUC, Homematic, Hue, Intertechno, Jeelink, RFXTRX, Harmony Hub, VU+ Uno 4K, Sonos, AMAD

Eisix

Hallo,

mein Verständnis von dem Attribut ist identisch mit deinem.

Hier mal ein list unserer Küche.

   NAME       zKueche
   NR         484
   NTFY_ORDER 50-zKueche
   STATE      absent
   TYPE       homezone
   VERSION    0.0.13
   HELPER:
     doors      0
   READINGS:
     2019-12-19 16:58:28   lastDayTime     afternoon
     2019-12-19 16:58:28   lastZone        timer
     2019-12-19 16:58:28   occupied        0
     2019-12-19 16:58:28   state           absent
   helper:
     TIMER      1576771108
Attributes:
   devStateIcon present:user_available@green likely:user_available@lightgreen unlikely:user_unknown@yellow absent:user_away
   hz_adjacent zFlur_EG,zWZ
   hz_dayTimes 05:00|morning 10:00|day 14:00|afternoon 18:00|evening 23:00|night
   hz_decay   120
   hz_occupancyEvent Sensor_KUECHE:motion:.open
   hz_state   100:present 50:likely 1:unlikely 0:absent
   room       HOMEMODE
   userattr   hz_cmd_present hz_lumiThreshold_present hz_cmd_likely hz_lumiThreshold_likely hz_cmd_unlikely hz_lumiThreshold_unlikely hz_cmd_absent hz_lumiThreshold_absent hz_decay_morning hz_decay_day hz_decay_afternoon hz_decay_evening hz_decay_night



Warum der Wert bei dir von 99 auf 100 springt kann ich auch nicht erklären.

Gruß
Eisix

Reinschki

Hallo,

ich hatte das gleiche Problem und habe es so gelöst:

hz_occupancyEvent deCONZ_BM_AQ_05:[^no]motion

Probier doch mal aus, ob ein "nomotion-Event" deine Zone in Abwesenheit triggert.

Gruß
Reinschki