Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST

Begonnen von Loredo, 19 Januar 2014, 23:12:34

Vorheriges Thema - Nächstes Thema

blade-of-fire

Hallo zusammen,
ich habe ein Problem mit den Residents bzw. mit der Benachrichtungsmöglichkeit.
Ich habe alle Familienmitglieder als Residents angelegt, aber nicht alle haben einen Pushdevice (msgContactPush) angehängt. Wenn ich nun ein Push Message per "msg push @[dev_residents:residentsTotalAbsentDevs] |FHEM| test" sende, kommt folgendes zurück:
ERROR: Could not find any Push contact for device rr_Name1 - set attributes: msgContactPush | msgRecipientPush | msgRecipient
ERROR: Could not find any Push contact for device rr_Name2 - set attributes: msgContactPush | msgRecipientPush | msgRecipient
ERROR: Could not find any Push contact for device rr_Name3 - set attributes: msgContactPush | msgRecipientPush | msgRecipient


Kann ich für die Bewohner, der keinen Pushdienst haben, den Aufruf unterbinden?
Ich hoffe, dass das Thema hier richtig ist  ???

Gruß
Patrick
VM mit Ubuntu und FHEM-Instanz (Hauptinstanz)
FHEM2FHEM
Raspberry Pi 3 B+ mit Eigenbau-Platine + Relais-Platine + Cul-Stick + FHEMDuino

Loredo

Nein, das geht nicht. Wenn du das Reading so wie es ist benutzen willst, dann müssen alle Empfänger bzw. deren Empfangsmöglichkeiten auch existieren.

Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Nestor

Hello Loredo, could you take a look at the following post?
https://forum.fhem.de/index.php/topic,84372.msg962588.html#msg962588

It seems tmr-RESIDENTStk_DurationTimer does not get cleaned up in defs::global::helper::bm and account for a daily memory increase in Fhem.

Loredo

Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Nestor

%defs{global}->{helper}->{bm} is created by 98_apptime so I guess the mem. leak is not with your module. I will post the issue in the apptime thread also.

mumpitzstuff

You should always restart fhem after using apptime. It is nothing which should run the whole time. It will definitly reduce your free memory. May be the command:

apptime clear

could help if you want to run a long time analysis. Analyse the data and clear it afterwards.

Nestor

Where is it the documentation that apptime can not run the whole time? (in the ref. is only stated that it adds about 1% CPU time).

The problem remains that RESIDENTStk_DurationTimer is aggregated incorrectly in 98_apptime. It creates a new entry for each RESIDENTStk_DurationTimer, instead it should increase the counter for the entry.

Also apptime clear clears the hash, but memory is not decreased. Only after Fhem restart.

Loredo

The reason you get to see the function name several times is simply because there are indeed several executions of it - one per defined device (and you probably have defined several ROOMMATE/GUEST/PET accounts).
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Nestor

Yes, but I don't have 2091 presence devices running. :)

I have 3 different presence devices (Rm_Heidi, Rm_Sen, Res_Landsroem) but they are not aggregated correctly. Apptime creates a new entry for every RESIDENTStk_DurationTimer instead of increasing the count for each of the 3 devices.

active-timers: 53; max-active timers: 60; max-timer-load: 8  min-tmrHandlingTm: 0.0ms; max-tmrHandlingTm: 347.1ms; totAvgDly: 0.5ms
------ apptime PAUSED data collection ----------

name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
tmr-freezemon_ProcessTimer               HASH(0x55ecadcf2650)                     0     1087     159.07     0.15    41.35     0.62 30.07. 14:40:59 HASH(freezemon)
tmr-VIERA_GetStatus                      HASH(0x55ecaf87cab0)                     7       18     122.13     6.79    13.46     1.42 30.07. 14:28:24 HASH(Viera)
tmr-Modbus_ProcessRequestQueue           queue                                    2     1728    2486.96     1.44    13.20     0.38 30.07. 14:30:24 queue:Modbus_USB
tmr-BlockingKill                         HASH_unnamed                             0       18       0.44     0.02     9.82     0.84 30.07. 14:33:34 HASH(0x55ecb01a7c90)
tmr-ModbusLD_GetUpdate                   update                                  13      108     997.91     9.24     8.87     0.56 30.07. 14:24:44 update:iEM3155
tmr-Unifi_DoUpdate                       HASH(0x55ecaf87bd00)                     1       18      24.73     1.37     0.92     0.49 30.07. 14:36:29 HASH(Unifi)
tmr-Aqicn::Timer_GetData                 HASH(0x55ecae3dc5d0)                     1        2       2.34     1.17     0.92     0.63 30.07. 14:32:52 HASH(Aqicn_Brussels)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb1a24428)                     0        1       0.48     0.48     0.81     0.81 30.07. 14:30:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb1da61a0)                     0        1       0.49     0.49     0.80     0.80 30.07. 14:27:42 HASH(Rm_Heidi_DurationTimer)
tmr-FW_closeInactiveClients              0                                        0       18       9.07     0.50     0.76     0.41 30.07. 14:28:21 0
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb1e98d78)                     0        1       0.52     0.52     0.75     0.75 30.07. 14:25:42 HASH(Rm_Sen_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb22d6aa0)                     0        1       0.52     0.52     0.71     0.71 30.07. 14:35:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb1262e78)                     0        1       0.48     0.48     0.70     0.70 30.07. 14:34:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb0231388)                     0        1       0.42     0.42     0.70     0.70 30.07. 14:25:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb19e4b48)                     0        1       0.53     0.53     0.69     0.69 30.07. 14:34:42 HASH(Rm_Sen_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb25fb180)                     0        1       0.60     0.60     0.68     0.68 30.07. 14:30:42 HASH(Rm_Sen_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb25c9b18)                     0        1       0.58     0.58     0.68     0.68 30.07. 14:27:42 HASH(Rm_Sen_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb23e0410)                     0        1       0.75     0.75     0.68     0.68 30.07. 14:25:42 HASH(Res_Landsroem_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb0fdcda0)                     0        1       0.75     0.75     0.68     0.68 30.07. 14:34:42 HASH(Res_Landsroem_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb25d8ce0)                     0        1       0.51     0.51     0.68     0.68 30.07. 14:35:42 HASH(Rm_Sen_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb04d7c00)                     0        1       0.50     0.50     0.66     0.66 30.07. 14:31:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb22748e0)                     0        1       0.57     0.57     0.66     0.66 30.07. 14:31:42 HASH(Rm_Sen_DurationTimer)
tmr-MQTT::Timer                          HASH(0x55ecaf648c90)                     1       18      29.29     1.63     0.64     0.57 30.07. 14:26:29 HASH(Mosquitto)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb25b20b0)                     0        1       0.74     0.74     0.64     0.64 30.07. 14:35:42 HASH(Res_Landsroem_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb229aad8)                     0        1       0.52     0.52     0.64     0.64 30.07. 14:28:42 HASH(Rm_Sen_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb21fd368)                     0        1       0.53     0.53     0.62     0.62 30.07. 14:38:42 HASH(Rm_Sen_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb25b67c0)                     0        1       0.75     0.75     0.62     0.62 30.07. 14:27:42 HASH(Res_Landsroem_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb259bed0)                     0        1       0.81     0.81     0.62     0.62 30.07. 14:31:42 HASH(Res_Landsroem_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb1915228)                     0        1       0.48     0.48     0.61     0.61 30.07. 14:38:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb25ad688)                     0        1       0.75     0.75     0.60     0.60 30.07. 14:32:42 HASH(Res_Landsroem_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb25ef5a8)                     0        1       0.76     0.76     0.59     0.59 30.07. 14:28:42 HASH(Res_Landsroem_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb2571418)                     0        1       0.51     0.51     0.58     0.58 30.07. 14:29:42 HASH(Rm_Sen_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb048b218)                     0        1       0.46     0.46     0.58     0.58 30.07. 14:29:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb13224e8)                     0        1       0.61     0.61     0.58     0.58 30.07. 14:37:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb25abd40)                     0        1       0.75     0.75     0.58     0.58 30.07. 14:29:42 HASH(Res_Landsroem_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb25ec2d0)                     0        1       0.52     0.52     0.56     0.56 30.07. 14:26:42 HASH(Rm_Heidi_DurationTimer)
tmr-Weather_GetUpdate                    HASH(0x55ecade83268)                     1        2       2.12     1.06     0.55     0.39 30.07. 14:41:43 HASH(Weather_Ganshoren)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb25b85b8)                     0        1       0.47     0.47     0.55     0.55 30.07. 14:28:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb1e6b700)                     0        1       0.51     0.51     0.55     0.55 30.07. 14:39:42 HASH(Rm_Heidi_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb209bc60)                     0        1       0.74     0.74     0.54     0.54 30.07. 14:30:42 HASH(Res_Landsroem_DurationTimer)
tmr-RESIDENTStk_DurationTimer            HASH(0x55ecb196b3c8)                     0        1       0.74     0.74     0.54     0.54 30.07. 14:38:42 HASH(Res_Landsroem_DurationTimer)

ch.eick

Hallo zusammen,

ich steige gerade neu mit dem Residence Modul ein und habe da eine Merkwürdigkeit bei meinen Gästen entdeckt. Okay, die sind merkwürdig, aber das ist ein anderes Thema :-)

Der Status der guest devices ist nicht stabil.

set rg_<name> gone

Wird der Status gesetzt, so steht bei "state" ein "none"


define rg_<name> GUEST

erzeugt das device

Internals:
   CFGFN     
   DEF        Bewohner
   DURATIONTIMER 1565768259.85002
   FUUID      5d53b7e7-f33f-81e9-30d0-01d9a78003d7914b
   FVERSION   20_GUEST.pm:0.195330/2019-06-02
   NAME       rg_<name>
   NOTIFYDEV  global,gast_<name>
   NR         26039
   NTFY_ORDER 50-rg_<name>
   READY      1
   RESIDENTGROUPS Bewohner
   STATE      none
   SUBTYPE    generic
   TYPE       GUEST
   READINGS:
     2019-08-14 09:36:39   durTimerAbsence 00:07:22
     2019-08-14 09:36:39   durTimerAbsence_cr 7
     2019-08-14 09:27:50   durTimerPresence 00:00:00
     2019-08-14 09:27:50   durTimerPresence_cr 0
     2019-08-14 09:27:50   durTimerSleep   00:00:00
     2019-08-14 09:27:50   durTimerSleep_cr 0
     2019-08-14 09:29:17   lastDeparture   2019-08-14 09:29:17
     2019-08-14 09:29:17   lastLocation    -
     2019-08-14 09:29:17   lastState       initialized
     2019-08-14 09:29:17   location        -
     2019-08-14 09:29:17   presence        absent
     2019-08-14 09:29:17   state           none
     2019-08-14 09:29:17   wayhome         0
   TIMER:
     rg_<name>_DurationTimer:
       HASH       rg_<name>
       MODIFIER   DurationTimer
       NAME       rg_<name>_DurationTimer
Attributes:
   alias      <name>
   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 gone:verreist gotosleep:bettfertig asleep:schläft awoken:aufgestanden
   group      Gaeste
   icon       scene_visit_guests
   rg_presenceDevices gast_<name>:state
   rg_realname alias
   room       Residents,Rollos
   sortby     2
   webCmd     state
   widgetOverride state:zuhause,bettfertig,schläft,aufgestanden,abwesend,verreist


Der Besucher wird durch das rg_presenceDevice bei Anwesenheit erkannt und der Status "home" auch dem residence device übergeben. Dieser Status wird dann auch korrekt gehalten, jedoch erscheint dann nach der Abreise der Status "none", der sich auch nicht überschreiben lässt.
Dieses Symptom habe ich bei allen Type: GUEST .
Das Attribut rg_autoGoneAfter 12 habe ich bereits ebenfalls ausprobiert.

Die devices mit "Type: ROOMMATE" funktionieren indies korrekt.

Dann noch eine Frage zu den anderen Stati:
Wie schaltet Ihr zb. auf gotosleep, asleep oder awoken ? Für awoken habe ich schon mal etwas über einen Taster am Bett gelesen. Gibt es da auch noch andere Lösungen?

Viele Grüße
    Christian


RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

Loredo

Works as designed, das soll so sein bei Gästen.

Ansonsten schalte ich die Schlafstatus per Alexa.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

ch.eick

Zitat von: Loredo am 14 August 2019, 10:00:24
Works as designed, das soll so sein bei Gästen.

Okay, also gibt es bei Gästen nur den Status "home" oder "none" ?
Sollte man dann nicht die anderen Stati aus der device Definition bereinigen? Mich hat es so etwas verwirrt.

Viele Grüße
    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

Loredo

Es gibt alle Status, aber "gone" heißt hier eben sinnvollerweise "none", weil es keinen Gast gibt, der für längere Zeit verreist ist, sondern nur welche, die kurz mal außer Haus sind.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

ch.eick

Zitat von: Loredo am 14 August 2019, 10:35:44
Es gibt alle Status, aber "gone" heißt hier eben sinnvollerweise "none", weil es keinen Gast gibt, der für längere Zeit verreist ist, sondern nur welche, die kurz mal außer Haus sind.
Ahhh, jetzt wird nen Schuh draus. Vielen Dank für die Hilfestellung.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

flummy1978

#674
Hallöchen,

Zunächst einmal Danke für dieses tolle Modul. Die Möglichkeiten die sich hier ergeben, sind schon weitreichend :)

Ich hab jetzt zum ersten mal auf einer zweiten Istallation damit ein wenig rum gespielt und direkt mal zwei Fragen dazu:

- Sobald ich ein PET angebe, ändert sich die ReadingsGroup für anwesende Bewohner NIE auf absent - Außer eben man setzt das Tier auf Abwesend. Es ist später so gedacht, dass der kleine Flohtransporter keine Events Bewegungsmelder etc mehr auslösen soll, dafür wäre für mich die einfachste Erkennung wenn die RG - Residents tatsächlich auch anzeigen würde, dass die angegebenen Bewohner weg sind und nur noch Tiere zu Hause sind ? - Oder hab ich hier was falsch verstanden ?

- Gibt es eine Möglichkeit die Zeitspanne der An(ab)wesenheit etwas anzupassen ? Also zB 1-10 Min => jede Minute, 5-90 Min => alle 5 Min, danach alle => 30 Min (um das Ganze etwas übersichtlicher zu gestalten und auch ein mögliches Eventgespamme ein wenig zu verringern ? )


Zu guter Letzte (glaube ich) habe ich noch einen kleinen Bug gefunden:
Edith sagt: Doch kein Bug, nur n feature;)

Ich habe zwei identische Bewohner angelegt:
Internals:
   CFGFN     
   DEF        RESIDENT_ALL
   DURATIONTIMER 1568641594.22403
   FUUID      5d7f8a92-f33f-8d79-f56d-c0f56ca9bd77ac3c
   FVERSION   20_ROOMMATE.pm:0.195330/2019-06-02
   NAME       rr_Andreas
   NOTIFYDEV  global,
   NR         130
   NTFY_ORDER 50-rr_Andreas
   READY      1
   RESIDENTGROUPS RESIDENT_ALL
   STATE      zuhause
   SUBTYPE    adult
   TYPE       ROOMMATE
   READINGS:
     2019-09-16 15:33:38   durTimerAbsence 00:00:00
     2019-09-16 15:33:38   durTimerAbsence_cr 0
     2019-09-16 15:45:34   durTimerPresence 00:10:00
     2019-09-16 15:45:34   durTimerPresence_cr 10
     2019-09-16 15:13:55   durTimerSleep   00:00:00
     2019-09-16 15:13:55   durTimerSleep_cr 0
     2019-09-16 15:35:34   lastArrival     2019-09-16 15:35:34
     2019-09-16 15:35:08   lastDeparture   2019-09-16 15:35:08
     2019-09-16 15:35:34   lastDurAbsence  00:00:26
     2019-09-16 15:35:34   lastDurAbsence_cr 0
     2019-09-16 15:35:08   lastDurPresence 00:01:30
     2019-09-16 15:35:08   lastDurPresence_cr 2
     2019-09-16 15:35:08   lastLocation    home
     2019-09-16 15:35:08   lastMood        calm
     2019-09-16 15:35:34   lastState       absent
     2019-09-16 15:35:34   location        home
     2019-09-16 15:35:34   mood            calm
     2019-09-16 15:35:34   presence        present
     2019-09-16 15:35:34   state           home
     2019-09-16 15:13:55   wayhome         0
   TIMER:
     rr_Andreas_DurationTimer:
       HASH       rr_Andreas
       MODIFIER   DurationTimer
       NAME       rr_Andreas_DurationTimer
Attributes:
   alias      Andreas
   comment    Auto-created by RESIDENT_ALL
   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 gone:verreist gotosleep:bettfertig asleep:schläft awoken:aufgestanden
   group      Bewohner
   icon       people_sensor
   room       Residents
   rr_realname group
   sortby     1
   webCmd     state
   widgetOverride state:zuhause,bettfertig,schläft,aufgestanden,abwesend,verreist


Wie man sieht , ist der Alias: Andreas (bzw vom zweiten Anwesenden Yvonne). Ändere ich jetzt irgendwo den Status, dann steht im Eventlog:

2019-09-16 15:35:08 RESIDENTS RESIDENT_ALL residentsAbsentDevs: rr_Andreas,rr_Yvonne
2019-09-16 15:35:08 RESIDENTS RESIDENT_ALL residentsAbsentNames: Bewohner, Bewohner (statt Andreas,Yvonne)
oder
2019-09-16 15:35:08 RESIDENTS RESIDENT_ALL lastActivityBy: Bewohner(statt Andreas)
2019-09-16 15:35:08 RESIDENTS RESIDENT_ALL lastActivityByDev: rr_Andreas


Ich denke mal, dass es sich hier um einen kleinen Bug handelt und es wird das Attribut "Group" (die heißt nämlich bei mir Bewohner) statt des Attributes "Alias". Ursprünglich nach dem Erstellen der jeweiligen Bewohner hieß die Gruppe nämlich auch wie der Alias Name. Ich denke dadurch war es schwerer das zu entdecken oder habe ich auch hier was falsch gemacht ?

Vielen Dank für alle erdenklichen Antworten, schon im Voraus :)

viele Grüße
Andreas