GUEST nach timerablauf auf none anstatt auf gone

[ch.eick]

Hallo zusammen,
ich habe mir eine neuen Gast eingerichtet und nach der Abreise den Status absent gesetzt. Später ist dann der Timer abgelaufen und GUEST hat den Status "none" anstatt "gone" gesetzt.

Im rg_WO_Gast habe ich dann etwas gesehen, was mich etwas verunsichert.

- attr rg_WO_Gast eventMap  home:zuhause absent:abwesend gone:verreist gotosleep:bettfertig asleep:schläft awoken:aufgestanden
- Dadurch wurde dann mit stat none => zuhause angezeigt
- Wenn ich dann gone in none ändere scheint alles wieder richtig zu laufen.

Ich denke da ist irgendwo im GUEST, oder beim Anlegen von rg_WO_Gast ein Tippfehler.
In der Doku finde ich z.B. diesen Satz "Please note that individuals with current state 'gone' or 'none' (in case of guests) will not be touched.", aus dem ich dann ableite, dass beim Anlegen eines Gastes das Attribut eventMap mit none definiert werden müsste.

Aus dem Log

Code Auswählen Erweitern

2025.12.10 14:21:00.001 3: GUEST rg_WO_Gast: AutoGone timer changed state to 'gone'

List

Code Auswählen Erweitern

Internals:
   DEF        Bewohner
   DURATIONTIMER 1765446984.02892
   FUUID      692c2449-f33f-61a8-6f6f-a844c7b0146dba5e
   FVERSION   20_GUEST.pm:0.195330/2019-06-02
   NAME       rg_WO_Gast
   NOTIFYDEV  global,
   NR         894
   NTFY_ORDER 50-rg_WO_Gast
   READY      1
   RESIDENTGROUPS Bewohner
   STATE      verreist
   SUBTYPE    generic
   TYPE       GUEST
   eventCount 11537
   Helper:
     DBLOG:
       durTimerAbsence:
         LogDB:
           TIME       1765446924.03149
           VALUE      36:34:24
       durTimerAbsence_cr:
         LogDB:
           TIME       1765446924.03149
           VALUE      2194
       durTimerPresence:
         LogDB:
           TIME       1765315260.20787
           VALUE      00:00:00
       durTimerPresence_cr:
         LogDB:
           TIME       1765315260.20787
           VALUE      0
       durTimerSleep:
         LogDB:
           TIME       1765263966.40924
           VALUE      00:00:00
       durTimerSleep_cr:
         LogDB:
           TIME       1765263966.40924
           VALUE      0
       lastArrival:
         LogDB:
           TIME       1765372860.01255
           VALUE      -
       lastAwake:
         LogDB:
           TIME       1765372860.01255
           VALUE      -
       lastDeparture:
         LogDB:
           TIME       1765315260.20787
           VALUE      2025-12-09 22:21:00
       lastDurAbsence:
         LogDB:
           TIME       1765372860.01255
           VALUE      -
       lastDurAbsence_cr:
         LogDB:
           TIME       1765004403.83159
           VALUE      974
       lastDurPresence:
         LogDB:
           TIME       1765315260.20787
           VALUE      86:20:57
       lastDurPresence_cr:
         LogDB:
           TIME       1765315260.20787
           VALUE      5181
       lastDurSleep:
         LogDB:
           TIME       1765372860.01255
           VALUE      -
       lastDurSleep_cr:
         LogDB:
           TIME       1765263966.40924
           VALUE      470
       lastLocation:
         LogDB:
           TIME       1765372860.01255
           VALUE      -
       lastMood:
         LogDB:
           TIME       1765372860.01255
           VALUE      -
       lastSleep:
         LogDB:
           TIME       1765372860.01255
           VALUE      -
       lastState:
         LogDB:
           TIME       1765387162.81947
           VALUE      abwesend
       location:
         LogDB:
           TIME       1765372860.01255
           VALUE      -
       mood:
         LogDB:
           TIME       1765315260.20787
           VALUE      -
       presence:
         LogDB:
           TIME       1765315260.20787
           VALUE      abwesend
       state:
         LogDB:
           TIME       1765387162.81947
           VALUE      none
   READINGS:
     2025-12-11 10:55:24   durTimerAbsence 36:34:24
     2025-12-11 10:55:24   durTimerAbsence_cr 2194
     2025-12-09 22:21:00   durTimerPresence 00:00:00
     2025-12-09 22:21:00   durTimerPresence_cr 0
     2025-12-09 08:06:06   durTimerSleep   00:00:00
     2025-12-09 08:06:06   durTimerSleep_cr 0
     2025-12-10 14:21:00   lastArrival     -
     2025-12-10 14:21:00   lastAwake       -
     2025-12-09 22:21:00   lastDeparture   2025-12-09 22:21:00
     2025-12-10 14:21:00   lastDurAbsence  -
     2025-12-06 08:00:03   lastDurAbsence_cr 974
     2025-12-09 22:21:00   lastDurPresence 86:20:57
     2025-12-09 22:21:00   lastDurPresence_cr 5181
     2025-12-10 14:21:00   lastDurSleep    -
     2025-12-09 08:06:06   lastDurSleep_cr 470
     2025-12-10 14:21:00   lastLocation    -
     2025-12-10 14:21:00   lastMood        -
     2025-12-10 14:21:00   lastSleep       -
     2025-12-10 18:19:22   lastState       absent
     2025-12-10 14:21:00   location        -
     2025-12-09 22:21:00   mood            -
     2025-12-09 22:21:00   presence        absent
     2025-12-10 18:19:22   state           none
     2025-11-30 12:02:34   wayhome         0
   TIMER:
     rg_WO_Gast_DurationTimer:
       HASH       rg_WO_Gast
       MODIFIER   DurationTimer
       NAME       rg_WO_Gast_DurationTimer
Attributes:
   alias      WO_Gast
   comment    Auto-created by Bewohner
   devStateIcon .*zuhause:user_available:absent .*anwesend:user_available:absent .*abwesend:user_away:home .*verreist:user_ext_away:home .*bettfertig:scene_toilet:asleep .*schlaeft:scene_sleeping:awoken .*schläft:scene_sleeping:awoken .*aufgestanden:scene_sleeping_alternat:home .*:user_unknown:home
   eventMap   home:zuhause absent:abwesend none:verreist gotosleep:bettfertig asleep:schläft awoken:aufgestanden
   group      Guests
   icon       scene_visit_guests
   rg_realname alias
   room       Residents
   sortby     3
   verbose    5
   webCmd     state
   widgetOverride state:zuhause,bettfertig,schläft,aufgestanden,abwesend,verreist

VG  Christian

[DeeSPe]

Soweit ich weiß ist dieses Verhalten so gewünscht. Jedenfalls benutze ich dieses Konstrukt bereits seit vielen Jahren genau so.
Ein Gast steht ja für einen generischen Benutzer der dann und wann mal da sein könnte, also ist der logische Schluss, dass er nach "abwesend/absent" halt auf "none/nicht vorhanden" wechselt. Wer weiß ob der jemals zurückkommt!?
Im Gegensatz dazu sind ROOMMATE eben Benutzer die irgendwann auch mal wiederkommen.

Gruß
Dan

[ch.eick]

Soweit ich weiß ist dieses Verhalten so gewünscht. Jedenfalls benutze ich dieses Konstrukt bereits seit vielen Jahren genau so.
Ein Gast steht ja für einen generischen Benutzer der dann und wann mal da sein könnte, also ist der logische Schluss, dass er nach "abwesend/absent" halt auf "none/nicht vorhanden" wechselt. Wer weiß ob der jemals zurückkommt!?
Im Gegensatz dazu sind ROOMMATE eben Benutzer die irgendwann auch mal wiederkommen.

Gruß
Dan

Hey Dan,
das hatte ich auch bereits so verstanden, jedoch müsste dann beim Anlegen des Gast devices das Attribut eventMap anstelle von gone mit none erzeugt werden.

VG   Christian