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

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

Vorheriges Thema - Nächstes Thema

choenig

Zitat von: Loredo am 23 April 2017, 21:57:01
Ich habe alle Modulautoren per PM angeschrieben.

Und besonders Cool: Sie haben es alle schon gefixt :)

LG
Christian

ComputerZOO

Nabend,
nach dem heutigen Update deiner Module wird bei mir der Status vom GEOFANCY nicht mehr von RESIDENTS übernommen. Kann ich das selber irgendwie beheben, oder ist da etwas schiefgelaufen? GEOFANCY zeigt den richtigen Status an, der ihm vom iPhone übermittelt wird.

EDIT: "hold the horses"... Es könnte auch sein, dass das HomeMode-Modul den Status nicht übernimmt, ich schaue mir das mal etwas genauer an.

Loredo

Mea culpa, ich hatte das GEOFANCY Modul nicht auf eine interne Änderung bei ROOMMATE/GUEST angepasst. Patch ist eingecheckt.
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

cheanrod

Hallo loredo,

könntest Du evtl. mal kurz auf meinen Beitrag schauen und sagen, ob ich mit meiner Vermutung auf dem richtigen Weg bin? Oder muss ich ganz woanders schauen?

Danke und Gruß
Sven

Zitat von: cheanrod am 23 April 2017, 13:18:24
Hallo zusammen,

seit einem FHEM-Update am 21.04.2017 um 10:13 Uhr bekomme ich leider regelmäßig folgende Meldung im Log-File:
Use of uninitialized value $n in hash element at fhem.pl line 3970.

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

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
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:

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

Loredo

Zitat von: cheanrod am 27 April 2017, 07:10:50
könntest Du evtl. mal kurz auf meinen Beitrag schauen und sagen, ob ich mit meiner Vermutung auf dem richtigen Weg bin? Oder muss ich ganz woanders schauen?


Vielleicht habe ich was gefunden, habe eine Änderung eingecheckt.
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

cheanrod

Zitat von: Loredo am 27 April 2017, 09:45:44

Vielleicht habe ich was gefunden, habe eine Änderung eingecheckt.

Danke, ich probiere es heute Abend aus und gebe Rückmeldung.

Viele Grüße
Sven

cheanrod

ZitatDanke, ich probiere es heute Abend aus und gebe Rückmeldung.

Die Änderung scheint geholfen zu haben. Ich habe keine Warnings mehr im Log-File. Vielen Dank, loredo!

Viele Grüße
Sven

choenig

Guten Morgen,

heute morgen (1.Mai) hat mich mein Wecker geweckt, obwohl ich

wakeupHolidays andNoHoliday

gesetzt habe und mein FHEM auch korrekterweise heute einen Feiertag erkennt.

Darauf hin habe ich mir mal den Code angesehen und bin der Meinung, dass da ein Fehler drin ist.

Im Folgenden ist ein ungetesteter Patch (!) von mir, der meiner Meinung nach das Logik-Problem behen sollte.


--- /tmp/RESIDENTStk.pm 2017-05-01 08:43:32.530310503 +0200
+++ RESIDENTStk.pm      2017-05-01 08:51:41.747744202 +0200
@@ -2802,15 +2800,16 @@
     }
     elsif (
            !$forceRun
-        && !$days{$today}
-        && (
-            ( $wakeupHolidays eq "andHoliday" && !$holidayToday )
-            || (   $wakeupHolidays eq "andNoHoliday"
-                && $holidayToday )
-            || ( $wakeupHolidays eq "orHoliday" && !$holidayToday )
-            || (   $wakeupHolidays eq "orNoHoliday"
-                && $holidayToday )
-        )
+        && (( $days{$today} &&
+                (( $wakeupHolidays eq "andHoliday"   && !$holidayToday ) ||
+                 ( $wakeupHolidays eq "andNoHoliday" &&  $holidayToday ))
+            )
+            ||
+            ( !$days{$today} &&
+                (( $wakeupHolidays eq "orHoliday"   && !$holidayToday ) ||
+                 ( $wakeupHolidays eq "orNoHoliday" &&  $holidayToday ))
+            )
+           )
       )
     {
         Log3 $NAME, 4,


Im duplizierten Code im Bereich der Zeilen 3165ff sieht es richtig aus.

LG
Christian

P.S.: Ich habe den Patch auf Lesbarkeit optimiert, nicht auf die Perl-typische Kompaktheit ;-).

Phiolin

Genau das ist mir heute auch passiert und ich bin auf genau die gleiche Anpassung gekommen wie du, hatte den Post auch schon fertig. :)
Werde das bei mir jetzt auch so testen.

ComputerZOO

Dito, 04:55 Uhr war die Nacht (vorerst) zu Ende.
Ich denke, dass ist nen Feature, ist ja schließlich "Tag der Arbeit", das hat das Modul wohl erkannt und automatisch auf Werktag geschaltet.

CoolTux

Hallo Julian,

Ich habe da noch ein Problem in Verbindung mit Presence. Wenn das Presence Device für eine Sekunde auf disconnected geht und danach korrekt wieder absent erkennt, wird der Status des Roommate dennoch auf home gestellt. Solltest Du da noch fragen haben, kann ich das gerne nachstellen.



Grüße
Leon
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Loredo

Zitat von: choenig am 01 Mai 2017, 09:22:34
Im Folgenden ist ein ungetesteter Patch (!) von mir, der meiner Meinung nach das Logik-Problem behen sollte.


Danke, ich habe den Patch so übernommen.


Zitat von: CoolTux am 01 Mai 2017, 11:30:54
Ich habe da noch ein Problem in Verbindung mit Presence. Wenn das Presence Device für eine Sekunde auf disconnected geht und danach korrekt wieder absent erkennt, wird der Status des Roommate dennoch auf home gestellt. Solltest Du da noch fragen haben, kann ich das gerne nachstellen.


Das müsste im PRESENCE Modul abgefangen werden. Dort gibt es ein Attribut, welches das Event verzögert. Offenbar funktioniert es dann wohl nicht richtig, wenn der Status auf disconnected wechselt. Die IMHO übermäßige und unnütze Event-Wut vom PRESENCE Modul begegnet man übrigens am besten mit dem Attribut "event-on-change-reading presence".




Gruß
Julian
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

oberlon

Hallo,

seitdem ich das letzte Mal upgedated habe ist mir aufgefallen das der STATE jede Minute neu gesetzt wird.
Das verträgt sich mit meinem DOIF nicht so richtig.
Gibt es einen Grund STATE neu zu setzten obwohl sich nichts geändert hat? Gibt es einen Workaround oder so?

Loredo

Zitat von: oberlon am 01 Mai 2017, 21:51:35
seitdem ich das letzte Mal upgedated habe ist mir aufgefallen das der STATE jede Minute neu gesetzt wird.
Das verträgt sich mit meinem DOIF nicht so richtig.
Gibt es einen Grund STATE neu zu setzten obwohl sich nichts geändert hat? Gibt es einen Workaround oder so?


Das Modul setzt STATE überhaupt gar nicht selbst. Die Readings werden außerdem nur bei einer Änderung aktualisiert. Es ist also vermutlich in deiner Automation ein Fehler, der den Status schnell hintereinander ändert.
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

oberlon

Am DOIF hat sich nichts geändert. Sieht ca so aus:
([rgr_Bewohner] eq 'home' and [?Twilight:twilight_weather] <= 60) (set lightscene scene lichtAn)
Im DOIF wird ein Reading mit dem Namen e_rgr_Bewohner_STATE erstellt und jede Minute aktualisiert.
Im Event-Monitor dazu
2017-05-01 22:57:58.354 RESIDENTS rgr_Bewohner durTimerPresence_cr: 594
2017-05-01 22:57:58.354 RESIDENTS rgr_Bewohner durTimerPresence: 09:54:03

Das DOIF löst also jedes mal aus wenn durTimerPresence_cr und durTimerPresence auftauchen.
Das war bis vor kurzem noch nicht so das STATE dadurch angefasst wird.
Sicher das es nicht an RESIDENTS liegt?