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

[Phiolin]

Code Auswählen Erweitern

2017.04.22 13:45:00 4: dummy set rr_Andreas_wakeuptimer2 trigger
2017.04.22 13:45:00 4: RESIDENTStk rr_Andreas_wakeuptimer2: lastRun = nextRun = 14:00
2017.04.22 13:45:00 4: RESIDENTStk rr_Andreas_wakeuptimer2: holiday restriction orHoliday in use - not triggering wake-up program this time
2017.04.22 13:45:00 4: RESIDENTStk rr_Andreas_wakeuptimer2: Resetting based on wakeupDefaultTime

Angeblich wird der Wecker wegen dem "orHoliday" Attribut nicht ausgeführt.
Das ist aber nicht korrekt, oder?

WakeupDays 0,6 or Holiday müsste für heute "true" sein.

Der Check um Zeile 2797 in RESIDENTStk.pm scheint mir nicht korrekt zu sein.

Code Auswählen Erweitern

elsif (
        !$forceRun
        && (
            ( $wakeupHolidays eq "andHoliday" && !$holidayToday )
            || (   $wakeupHolidays eq "andNoHoliday"
                && $holidayToday )
            || ( $wakeupHolidays eq "orHoliday" && !$holidayToday )
            || (   $wakeupHolidays eq "orNoHoliday"
                && $holidayToday )
        )
      )

Hier wird ja offenbar dann ausgestiegen, wenn "orHoliday" gesetzt ist und heute kein Holiday ist. Hier fehlt glaube ich ein Check auf

Code Auswählen Erweitern

!$days{$today}

Der war in einer früheren Version an dieser Stelle noch drin.
Wenn ich den bei mir an dieser Stelle einfüge, wird der Wecker ordentlich ausgeführt:

Code Auswählen Erweitern

    elsif (
        !$forceRun
        && !$days{$today}
        && (
            ( $wakeupHolidays eq "andHoliday" && !$holidayToday )
            || (   $wakeupHolidays eq "andNoHoliday"
                && $holidayToday )
            || ( $wakeupHolidays eq "orHoliday" && !$holidayToday )
            || (   $wakeupHolidays eq "orNoHoliday"
                && $holidayToday )
        )
      )

[Loredo]

Ich hab ein normales FHEM update gemacht da wurde ja auch Residents und ResidentStk aktualisiert
Das Attribut habe ich im Roommate auf alias gesetzt

Ich kann das bei mir nicht nachvollziehen. Was steht denn im Attribut "alias" bei dir? Genau das wird übernommen, sofern rr_realname auf "alias" steht. Damit sich das Reading ändert, musst du aber auch einen Statuswechsel vornehmen. Die Module sind rein Event gesteuert, das einfache ändern des Attributs alleine bewirkt erstmal gar nichts, bis das nächste Event stattfindet.

Der Check um Zeile 2797 in RESIDENTStk.pm scheint mir nicht korrekt zu sein.

Danke, ich habe das mal so übernommen.

[l2r]

Das ist klar. Bei mir ist der roommate in der Gruppe Michael und Anwesenheit drin. Bei alias steht nur Michael.
Somit möchte ich gerne alias uns nicht group verwenden.
Dass das Reading nur bei Events aktualisiert wird ist klar.ich teste das immer in dem ich mich von absent auf Home setzte oder anders rum.

Ich werde das morgen bei mir nochmal genauer unter die Lupe nehmen und versuchen dir mehr Infos zu geben


Gruß Michael

[Phiolin]

Heute hat der Wecker fast wie geplant ausgelöst.
Fast, weil wir zu der Zeit schon wach und Status "Home" waren. Sollte der Wecker nicht eigentlich nur bei "asleep" auslösen? War das nicht ursprünglich mal so?🤔

[choenig]

Guten Morgen,

ich habe heute ein fhem-Update durchgeführt und leider ist danach fhem beim Starten hängen geblieben. Nachdem ich die verbosity von global auf 5 gesetzt hab, kam dann zu Tage, dass folgende Logzeile mein Logfile vollmüllt:

Code Auswählen Erweitern


2017.04.23 08:53:02 5: RESIDENTS [...]: device re-configuration completed


Code Auswählen Erweitern


# grep 'device re-configuration completed' fhem-2017-04-23.log |wc -l
58495


Ich habe jetzt zunächst mal die alte Version (ca. 2 Wochen) von 10_RESIDENTS.pm, 20_ROOMMATE.pm , 20_GUEST.pm und RESIDENTStk.pm eingespielt und jetzt startet fhem immerhin wieder.

Wie kann ich bei der Problemfindung weiterhelfen?

LG
Christian

[Loredo]

Heute hat der Wecker fast wie geplant ausgelöst.
Fast, weil wir zu der Zeit schon wach und Status "Home" waren. Sollte der Wecker nicht eigentlich nur bei "asleep" auslösen? War das nicht ursprünglich mal so?🤔

Das ist schon immer so, da davon ausgegangen wird, dass man auch mal vergisst sich explizit schlafend zu melden (bzw. dann damit explizit den Wecker zu stellen) und man ansonsten nicht geweckt würde. Das ist bei dir wohl der Fall gewesen, ansonsten hätte die wakeupWaitPeriod bei dir gegriffen, wenn du über Nacht "asleep" warst und dich morgens vor auslösen des Weckers auf "home" gesetzt hättest. So gibt es dann allerdings keine Möglichkeit zu erkennen, ob du am letzten Abend vergessen hast dich schlafend zu schalten oder ob du bereits vor dem Wecker aufgestanden bist. Es sei denn du hättest deinen Prozess so eingestellt, dass du nach dem aufstehen in jedem Fall auch von "home" auf "awoken" oder nochmals explizit auf "home" wechselst. Dann hat ein Statuswechsel stattgefunden und wakeupWaitPeriod kann erkennen, dass du früher aufgestanden bist als der Wecker dich geweckt hätte.

ich habe heute ein fhem-Update durchgeführt und leider ist danach fhem beim Starten hängen geblieben. Nachdem ich die verbosity von global auf 5 gesetzt hab, kam dann zu Tage, dass folgende Logzeile mein Logfile vollmüllt:

Code Auswählen Erweitern


2017.04.23 08:53:02 5: RESIDENTS [...]: device re-configuration completed


Code Auswählen Erweitern


# grep 'device re-configuration completed' fhem-2017-04-23.log |wc -l
58495


Das kann ich hier nicht nachvollziehen, auch nicht in meiner Produktivumgebung.
Ich vermute du setzt ein Modul ein, was auf das globale Event INITIALIZED triggert oder du hast selbst etwas dafür programmiert. Dabei wird das Event unsauber gefiltert und es wird nicht beachtet, dass das FHEM-globale Event mit dem Regex /^INITIALIZED$/ zu identifizieren ist und nicht mit /INITIALIZED/.
Mögliche Kandidaten, die ich sehe:


DUOFERNSTICK
pilight_ctrl
DOIFtools
weekprofile


Diese Modulautoren müssen ihren Code entsprechend korrigieren und die Events strikter trennen.

[Phiolin]

Das ist schon immer so, da davon ausgegangen wird, dass man auch mal vergisst sich explizit schlafend zu melden (bzw. dann damit explizit den Wecker zu stellen) und man ansonsten nicht geweckt würde. Das ist bei dir wohl der Fall gewesen, ansonsten hätte die wakeupWaitPeriod bei dir gegriffen, wenn du über Nacht "asleep" warst und dich morgens vor auslösen des Weckers auf "home" gesetzt hättest. So gibt es dann allerdings keine Möglichkeit zu erkennen, ob du am letzten Abend vergessen hast dich schlafend zu schalten oder ob du bereits vor dem Wecker aufgestanden bist. Es sei denn du hättest deinen Prozess so eingestellt, dass du nach dem aufstehen in jedem Fall auch von "home" auf "awoken" oder nochmals explizit auf "home" wechselst. Dann hat ein Statuswechsel stattgefunden und wakeupWaitPeriod kann erkennen, dass du früher aufgestanden bist als der Wecker dich geweckt hätte.

Tatsächlich hatte ich gestern zum testen bei diesem Wecker die wakeupWaitperiod auf 0 gesetzt und dann wohl vergessen wieder zu löschen.
Wir hatten uns gestern ordnungsgemäß "asleep" gemeldet. Heute morgen habe ich aber etwa 1 Stunde vor dem Wecker schon das "home" Setting eingestellt und der Wecker lief dann aber trotzdem planmäßig los. Hatte mich gewundert, weil ich meine, dass das früher nicht so war.
Habe jetzt das wakeupWaitPeriod Setting wieder gelöscht, bzw. auf Default gesetzt. Mal gucken, ob dass dann jetzt wieder wie vorher funktioniert.

[cheanrod]

Hallo zusammen,

seit einem FHEM-Update am 21.04.2017 um 10:13 Uhr bekomme ich leider regelmäßig folgende Meldung im Log-File:

Code Auswählen Erweitern

Use of uninitialized value $n in hash element at fhem.pl line 3970.

Seit ich

Code Auswählen Erweitern

attr global verbose 5 gesetzt habe, sieht die Umgebung der Log-Meldung wie folgt aus:

Code Auswählen Erweitern


2017.04.23 12:40:36 5: PRESENCE (G_Tag_Sven) - received data: present;device_name=Gigaset G-tag;rssi=-76;daemon=lepresenced V0.81
2017.04.23 12:40:36 5: Starting notify loop for G_Tag_Sven, 5 event(s), first is present
2017.04.23 12:40:36 5: statistics Statistik: Notify.266 Notification of 'G_Tag_Sven' received. Device not monitored.
Use of uninitialized value $n in hash element at fhem.pl line 3970.
2017.04.23 12:40:36 4: ROOMMATE rr_Sven: Syncing status with G_Tag_Sven = present
2017.04.23 12:40:36 5: Cmd: >set rr_Sven:FILTER=presence=absent home<
Use of uninitialized value $n in hash element at fhem.pl line 3970.
2017.04.23 12:40:36 4: ROOMMATE rr_Sven: Syncing status with G_Tag_Sven = present
2017.04.23 12:40:36 5: Cmd: >set rr_Sven:FILTER=presence=absent home<
Use of uninitialized value $n in hash element at fhem.pl line 3970.
2017.04.23 12:40:36 4: ROOMMATE rr_Sven: Syncing status with G_Tag_Sven = present
2017.04.23 12:40:36 5: Cmd: >set rr_Sven:FILTER=presence=absent home<
2017.04.23 12:40:36 5: End notify loop for G_Tag_Sven


Aufgrund der Nähe zu den ROOMMATE-Meldungen könnte man die Ursache der Meldung im ROOMMATE-Modul vermuten. Dieses wurde aber zu dem oben genannten Termin bei mir nicht aktuslisiert, sondern nur das damit in Zusammenhang stehende Modul RESIDENTStk.pm.

Ggf. liegt die Ursache der Meldung aber auch im PRESENCE-Modul, das ja im oben eingefügten Log-Abschnitt Quelle des Events ist.

Ich habe auch

Code Auswählen Erweitern

attr global stacktrace 1 gesetzt. Leider scheint das Attribut in diesem Fall nicht zu greifen. Vielleicht weiß ja jemand, warum das so ist oder hat einen Tipp wie ich die Ursache finden kann? Ich möchte zunächst gar nicht von einem Bug in einem der von mir verwendeten Module ausgehen, sondern kann mir vorstellen, dass evtl. auch ein Konfigurationsproblem in meiner gewachsenen FHEM-Installation besteht.

Hier ein Listing des Device rr_Sven:

Code Auswählen Erweitern


Internals:
   DEF        rgr_Residents
   DURATIONTIMER 1492945807.10855
   NAME       rr_Sven
   NOTIFYDEV  global,G_Tag_Sven
   NR         113
   NTFY_ORDER 40-rr_Sven
   RESIDENTGROUPS rgr_Residents
   STATE      home
   TYPE       ROOMMATE
   Readings:
     2017-04-23 12:05:06   durTimerAbsence 00:00:00
     2017-04-23 12:05:06   durTimerAbsence_cr 0
     2017-04-23 13:09:07   durTimerPresence 01:04:01
     2017-04-23 13:09:07   durTimerPresence_cr 64
     2017-01-07 12:18:24   durTimerSleep   00:00:00
     2017-01-07 12:18:24   durTimerSleep_cr 0
     2017-04-23 12:05:06   lastArrival     2017-04-23 12:05:06
     2017-04-23 09:25:47   lastDeparture   2017-04-23 09:25:47
     2017-04-23 12:05:06   lastDurAbsence  02:39:19
     2017-04-23 12:05:06   lastDurAbsence_cr 159
     2017-04-23 09:25:47   lastDurPresence 14:35:56
     2017-04-23 09:25:47   lastDurPresence_cr 876
     2017-04-23 09:25:47   lastLocation    home
     2017-04-23 09:25:47   lastMood        calm
     2017-04-23 12:05:06   lastState       absent
     2017-04-23 12:05:06   location        home
     2017-04-23 12:05:06   mood            calm
     2017-04-23 12:05:06   presence        present
     2017-04-23 12:05:06   state           home
     2017-01-07 12:18:24   wayhome         0
   Timer:
     Rr_sven_durationtimer:
       HASH       rr_Sven
       MODIFIER   DurationTimer
       NAME       rr_Sven_DurationTimer
Attributes:
   alias      Status
   devStateIcon .*home:user_available:absent .*absent:user_away:home .*gone:user_ext_away:home .*gotosleep:scene_toilet:asleep .*asleep:scene_sleeping:awoken .*awoken:scene_sleeping_alternat:home .*:user_unknown:home
   genericDeviceType switch
   group      Sven
   homebridgeMapping On=state,valueOn=/home|awoken|asleep|gotosleep/,valueOff=/gone|absent/,cmdOn=home,cmdOff=absent
   icon       people_sensor
   room       Homekit,Residents
   rr_presenceDevices G_Tag_Sven
   rr_realname group
   sortby     1
   webCmd     state


Falls weitere Listings gebraucht werden, liefere ich diese gerne nach.

Viele Grüße
Sven

[choenig]

Hey,

vielen Dank für die ausführliche Antwort!

Das kann ich hier nicht nachvollziehen, auch nicht in meiner Produktivumgebung.
Ich vermute du setzt ein Modul ein, was auf das globale Event INITIALIZED triggert oder du hast selbst etwas dafür programmiert. Dabei wird das Event unsauber gefiltert und es wird nicht beachtet, dass das FHEM-globale Event mit dem Regex /^INITIALIZED$/ zu identifizieren ist und nicht mit /INITIALIZED/.
Mögliche Kandidaten, die ich sehe:

DUOFERNSTICK
pilight_ctrl
DOIFtools
weekprofile

Diese Modulautoren müssen ihren Code entsprechend korrigieren und die Events strikter trennen.

Von den gelisteten Modulen nutze ich 50% .

Ich habe mal im FHEM-Verzeichnis nach INITIALIZED ge'grep't und habe da noch ein paar andere Kandidaten gefunden, die auch nicht nach ^INITIALIZED$ filtern.

Um das ganze zu verstehen und dann auch die anderen Autoren zu informieren: Kannst Du mir kurz erklären, was hier zu der (vermutlich) Endlosschleife bei Deinem Modul führt, wenn ein anderer Modulautor da 'nen Fehler macht?

LG
Christian

[l2r]

hi,

ich hab nach einem shutdown restart folgendes im Log stehen:

Code Auswählen Erweitern

main::RESIDENTStk_findDummySlaves() called too early to check prototype at FHEM/RESIDENTStk.pm line 3568, <$fh> line 712.

Gruß Michael

[Loredo]

Ich habe mal im FHEM-Verzeichnis nach INITIALIZED ge'grep't und habe da noch ein paar andere Kandidaten gefunden, die auch nicht nach ^INITIALIZED$ filtern.

Um das ganze zu verstehen und dann auch die anderen Autoren zu informieren

Ich glaube ich habe in der Liste nur Damians 98_DOIF und Martins 98_HMinfo vergessen.
Ich habe alle Modulautoren per PM angeschrieben.

Kannst Du mir kurz erklären, was hier zu der (vermutlich) Endlosschleife bei Deinem Modul führt, wenn ein anderer Modulautor da 'nen Fehler macht?

Das lässt sich pauschal nicht sagen, da es vom jeweiligen Modul abhängt.
Grundsätzlich filtern die Module globale Events nicht streng genug.

[l2r]

hi Loredo,

schau dir mal bitte Zeile 1224-1230 im ResidentStk an.

Anscheinend bekommt er da das passende Attribut bzw. den Inhalt nicht korrekt ausgelesen und nimmt dann den Fallback. Wenn ich den Defaultwert auf alias setze, dann passt alles.

hier noch ein List vom meinem ROOMMATE:

Code Auswählen Erweitern

Internals:
   DEF        rgr_Bewohner
   DURATIONTIMER 1493020845.07472
   NAME       rr_Michael
   NOTIFYDEV  global,rr_Michael_wakeuptimer1,rr_Michael_wakeuptimer2,rr_Michael_wakeuptimer3,rr_Michael_wakeuptimer4,rr_Michael_wakeuptimer1_resetswitcher,rr_Michael_wakeuptimer1_resetswitcher
   NR         235
   NTFY_ORDER 40-rr_Michael
   READY      1
   RESIDENTGROUPS rgr_Bewohner
   STATE      home
   TYPE       ROOMMATE
   Readings:
     2017-04-24 09:58:45   durTimerAbsence 00:00:00
     2017-04-24 09:58:45   durTimerAbsence_cr 0
     2017-04-24 09:59:45   durTimerPresence 00:01:00
     2017-04-24 09:59:45   durTimerPresence_cr 1
     2017-04-24 07:16:05   durTimerSleep   00:00:00
     2017-04-24 07:16:05   durTimerSleep_cr 0
     2017-04-24 09:58:47   fhemMsgMail     Michael angemeldet. 3 Bewohner zuhause: Carolin, Michael, Ursula
     2017-04-24 09:58:47   fhemMsgMailGw    mail@mail.com:OK
     2017-04-24 09:58:47   fhemMsgMailPrio -1
     2017-04-24 09:58:47   fhemMsgMailState 1
     2017-04-24 09:58:47   fhemMsgMailTitle Anwesenheit
     2017-04-24 09:58:45   fhemMsgPush     Michael angemeldet. 3 Bewohner zuhause: Carolin, Michael, Ursula
     2017-04-24 09:58:45   fhemMsgPushGw    PushMichael:UNAVAILABLE
     2017-04-24 09:58:45   fhemMsgPushPrio -1
     2017-04-24 09:58:45   fhemMsgPushState 0
     2017-04-24 09:58:45   fhemMsgPushTitle Anwesenheit
     2017-04-24 09:58:47   fhemMsgState    1
     2017-04-24 09:58:47   fhemMsgStateTypes push:0 mail:1 forwards:push>mail
     2017-04-24 09:58:45   lastArrival     2017-04-24 09:58:45
     2017-04-24 07:16:05   lastAwake       2017-04-24 07:16:05
     2017-04-24 09:54:10   lastDeparture   2017-04-24 09:54:10
     2017-04-24 09:58:45   lastDurAbsence  00:04:35
     2017-04-24 09:58:45   lastDurAbsence_cr 5
     2017-04-24 09:54:10   lastDurPresence 00:00:08
     2017-04-24 09:54:10   lastDurPresence_cr 0
     2017-04-24 07:16:05   lastDurSleep    08:42:43
     2017-04-24 07:16:05   lastDurSleep_cr 523
     2017-04-24 09:54:10   lastLocation    home
     2017-04-24 09:54:10   lastMood        calm
     2017-04-23 22:33:22   lastSleep       2017-04-23 22:33:22
     2017-04-24 09:58:45   lastState       absent
     2017-04-24 06:43:04   lastWakeup      07:15
     2017-04-24 06:43:04   lastWakeupDev   rr_Michael_wakeuptimer1
     2017-04-24 09:58:45   location        home
     2017-04-24 09:58:45   mood            calm
     2017-04-23 22:33:27   nextWakeup      07:15
     2017-04-23 22:33:27   nextWakeupDev   rr_Michael_wakeuptimer1
     2017-04-24 09:58:45   presence        present
     2017-04-23 22:33:27   snooze          0
     2017-04-24 09:58:45   state           home
     2017-04-24 07:15:06   wakeup          0
     2017-03-22 15:38:18   wayhome         0
   Timer:
     Rr_michael_durationtimer:
       HASH       rr_Michael
       MODIFIER   DurationTimer
       NAME       rr_Michael_DurationTimer
Attributes:
   alias      Michael
   devStateIcon .*home:user_available@green:gotosleep .*absent:user_away@red:home .*gone:user_ext_away@red:home .*gotosleep:scene_toilet@lightblue:asleep .*asleep:scene_sleeping@blue:awoken .*awoken:scene_sleeping_alternat@lightblue:home .*:user_unknown:home
   group      Anwesenheit,Michael
   homebridgeMapping clear
On=state,subtype=home,valueOn=/home/,valueOff=/awoken|asleep|gotosleep|gone|absent/,cmdOn=home,cmdOff=absent
On=state,subtype=asleep,valueOn=/asleep/,valueOff=/awoken|home|gotosleep|gone|absent/,cmdOn=asleep,cmdOff=absent
On=state,subtype=awoken,valueOn=/awoken/,valueOff=/home|asleep|gotosleep|gone|absent/,cmdOn=awoken,cmdOff=absent
On=state,subtype=gotosleep,valueOn=/gotosleep/,valueOff=/home|asleep|awoken|gone|absent/,cmdOn=gotosleep,cmdOff=absent
   icon       people_sensor
   msgContactAudio GALAXY_TAB,Sonos_Bad,Sonos_Raum,Sonos_Michael
   msgContactLight HUEDevice4
   msgContactMail mail@mail.com
   msgContactPush PushMichael
   room       Homekit,Residents
   rr_locationHome home 1.OG Raum Hof
   rr_locations home,1.OG,Raum,Hof,underway
   rr_realname alias
   rr_showAllStates 1
   rr_wakeupDevice rr_Michael_wakeuptimer1,rr_Michael_wakeuptimer2,rr_Michael_wakeuptimer3,rr_Michael_wakeuptimer4
   sortby     1
   userattr   presenceDevice
   webCmd     state:location

Gruß Michael

EDIT: setzte ich

Code Auswählen Erweitern

attr rr_realname group

dann wird dieses auch ignoriert und der Wert aus Zeile 1225 genommen. Da ich diesen von group auf alias geändert habe, wird bei mit alias genommen.

Also scheint es Probleme beim Auslesen der Werte zu geben.

[Loredo]

Danke, ich hatte irgendwie überlesen, dass es dir um lastActivityBy geht und nicht um die Listen in residentsTotal*.
Damit ist das nun auch gefixt

[l2r]

alles klar,

wollte dir gerade schreiben, dass ich herausgefunden habe, dass $prefix wohl den Wert rgr_ hatte und nicht rr_

Aber wenn du es gefixt hast, dann ist alles gut.

Besten Dank!

[choenig]

Hi,

Ich habe alle Modulautoren per PM angeschrieben.

Das lässt sich pauschal nicht sagen, da es vom jeweiligen Modul abhängt.
Grundsätzlich filtern die Module globale Events nicht streng genug.

Ok, vielen Dank