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

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

Vorheriges Thema - Nächstes Thema

Bootscreen

Moin moin,

kann es sein das die Timer trotz rr_noDuration im Hintergrund noch laufen? Weil bei mir werden die lastDur* immernoch fleißig weiter erzeugt. Hätte erwartet das sie durch rr_noDuration ebenfalls deaktiviert werden. Falls das Verhalten so beabsichtigt ist, wäre es möglich ein Attribut zu bekommen welches alle Timer irgendwie abschaltet? Ich brauch die ganze Timer Geschichte z.B. nicht und es würde mir Ressourcen schonen.

Gruß
Oliver
Gruß
Oliver

FHEM 5.7 Hardware:
Raspberry PI B+ | HomeMatic USB 2 | 433Mhz Sender (pilight) | nanoCUL (433Mhz)

Loredo

Absolut, denn wenn man das Attribut wieder entfernte, dann soll der Timer ja wieder anlaufen. Das Attribut sorgt lediglich für einen sofortigen Ausstieg aus der entsprechenden Funktion. Dieses wiederum frisst so marginal Ressourcen, dass ich keinen Grund sehe es anders zu handhaben.
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

Bootscreen

Das heißt das Attribut unterbindet im Grunde nur dur* Readings? Wäre es dann möglich auch die lastDur* Readings zu unterbinden oder braucht er die intern?
Gruß
Oliver

FHEM 5.7 Hardware:
Raspberry PI B+ | HomeMatic USB 2 | 433Mhz Sender (pilight) | nanoCUL (433Mhz)

Loredo

Zitat von: Bootscreen am 24 November 2016, 14:18:53
Das heißt das Attribut unterbindet im Grunde nur dur* Readings?


Korrekt.


Zitat von: Bootscreen am 24 November 2016, 14:18:53
Wäre es dann möglich auch die lastDur* Readings zu unterbinden


Diese Readings sind vollkommen anders und werden sinnvollerweise nur eventbasiert berechnet, also zu dem Zeitpunkt, bei dem am Objekt ohnehin eine Statusänderung erfolgt. Ich werde auch sicherlich kein Cherry Picking für einzelne Readings implementieren, das macht einfach keinen Sinn. Wenn du mit einem Reading nichts anfangen kannst, dann kannst du es doch einfach ignorieren und nicht verwenden.
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

l2r

hallo,

so ganz rund läuft mein nextWakeup und nextWakeupDev immer noch nicht. Ich habe 4 WakeUpTimer, wobei für den konkreten Fall nur 2 wichtig sind. rr_Michael_wakeuptimer1 für werktags und rr_Michael_wakeuptimer2 für samstags.
Beide nutzen das gleiche notify für die Weckeraufgaben Macro_rr_Michael_wakeuptimer1

Der Wecker ist heute morgen durchgelaufen. Und wenn ich das richtig verstanden habe, dann wird sobald der Wecker gestartet wurde nextWakeup und nextWakeupDev  für den nächsten Wecker gesetzt. Als ich vorhin in rr_Michael geschaut habe, standen die beiden Readings allerdings noch auf 07:00 Uhr für wochentags und rr_Michael_wakeuptimer1, obwohl sie eigentlich auf 09:15 und rr_Michael_wakeuptimer2 stehen sollten.

Anschließend habe ich bei rr_Michael verbose auf 5 gesetzt und set rr_Michael_wakeuptimer start ausgeführt.

hier das Log dazu:
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael: 00 - checking for next wake-up candidate rr_Michael_wakeuptimer1
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=0
2016.11.25 11:00:40 4: RESIDENTStk : 02rr_Michael_wakeuptimer1 - possible candidate found
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=06:43 wakeupOffset=17
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer1: 04 - this is a candidate for tomorrow
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer1: 05 - won't be running tomorrow based on weekday decision
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer1: 06 - won't be running tomorrow based on holiday decision (wakeupHolidays=andNoHoliday)
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael: 00 - checking for next wake-up candidate rr_Michael_wakeuptimer2
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 01 - Holidays to be considered - today=0 tomorrow=0
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 02 - possible candidate found
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 03 - considering at-device value wakeupAtNTM=08:58 wakeupOffset=17
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 04 - this is a candidate for tomorrow
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 05 - until now, will be NEXT WAKE-UP RUN tomorrow based on weekday decision
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 06 - won't be running tomorrow based on holiday decision (wakeupHolidays=andNoHoliday)
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael: 00 - checking for next wake-up candidate rr_Michael_wakeuptimer3
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer3: 01 - Holidays to be considered - today=0 tomorrow=0
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer3: 02 - possible candidate found
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer3: 03 - considering at-device value wakeupAtNTM=09:58 wakeupOffset=17
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer3: 04 - this is a candidate for tomorrow
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer3: 05 - won't be running tomorrow based on weekday decision
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer3: 06 - won't be running tomorrow based on holiday decision (wakeupHolidays=orHoliday)
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael: 00 - checking for next wake-up candidate rr_Michael_wakeuptimer4
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer4: 01 - Holidays to be considered - today=0 tomorrow=0
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer4: 02 - possible candidate found
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer4: 03 - considering at-device value wakeupAtNTM=05:43 wakeupOffset=17
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer4: 04 - this is a candidate for tomorrow
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer4: 05 - won't be running tomorrow based on weekday decision
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer4: 06 - won't be running tomorrow based on holiday decision (wakeupHolidays=andNoHoliday)
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael: 07 - next wake-up result: tomorrow at 09:15:00, wakeupDevice=rr_Michael_wakeuptimer2


und das list von rr_Michael_wakeuptimer2

Internals:
   NAME       rr_Michael_wakeuptimer2
   NR         276
   STATE      09:15
   TYPE       dummy
   Readings:
     2016-11-19 19:34:05   lastRun         19:51
     2016-11-19 19:34:06   nextRun         09:15
     2016-11-19 19:38:08   running         0
     2016-11-25 08:58:00   state           09:15
Attributes:
   alias      Wecker Samstag
   comment    Auto-created by ROOMMATE module for use with RESIDENTS Toolkit
   devStateIcon OFF:general_aus@red:reset running:general_an@blue:stop .*:general_an@green:nextRun%20OFF
   group      Michael
   icon       time_timer
   room       Residents
   setList    nextRun:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 reset:noArg trigger:noArg start:noArg stop:noArg end:noArg
   sortby     4
   userattr   wakeupOffset:slider,0,1,120 wakeupDefaultTime:OFF,00:00,00:15,00:30,00:45,01:00,01:15,01:30,01:45,02:00,02:15,02:30,02:45,03:00,03:15,03:30,03:45,04:00,04:15,04:30,04:45,05:00,05:15,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00,10:15,10:30,10:45,11:00,11:15,11:30,11:45,12:00,12:15,12:30,12:45,13:00,13:15,13:30,13:45,14:00,14:15,14:30,14:45,15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30,23:45 wakeupMacro wakeupUserdevice wakeupAtdevice wakeupResetSwitcher wakeupResetdays:multiple-strict,0,1,2,3,4,5,6 wakeupDays:multiple-strict,0,1,2,3,4,5,6 wakeupHolidays:andHoliday,orHoliday,andNoHoliday,orNoHoliday wakeupEnforced:0,1,2 wakeupWaitPeriod:slider,0,1,360
   wakeupAtdevice at_rr_Michael_wakeuptimer2
   wakeupDays 6
   wakeupDefaultTime 09:15
   wakeupEnforced 0
   wakeupHolidays andNoHoliday
   wakeupMacro Macro_rr_Michael_wakeuptimer1
   wakeupOffset 17
   wakeupResetdays 6
   wakeupUserdevice rr_Michael
   webCmd     nextRun


nach kurzer Zeit haben ich den Wecker dann mit
set rr_Michael_wakeuptimer end wieder beendet.

Interessanterweise stimmen jetzt die Readings in rr_Michael

beim durchsehen der Logs ist mir folgende Zeile aufgefallen als rr_Michael_wakeuptimer2 ausgewertet wurde:

2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 05 - until now, will be NEXT WAKE-UP RUN tomorrow based on weekday decision
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 06 - won't be running tomorrow based on holiday decision (wakeupHolidays=andNoHoliday)


morgen ist doch kein Feiertag? und in meiner Holiday-Definition habe ich auch nichts dergleichen eingetragen:

# Format für einzelne Tage: 1 MM
1 01-01 Neujahr
1 05-01 Tag der Arbeit
1 10-03 Tag der deutschen Einheit
1 11-01 Allerheiligen
1 12-25 1. Weihnachtstag
1 12-26 2. Weihnachtstag

# Osterbezogene Feiertage
# Format: 2 <relative Tage von Ostern> <Text>

2 -2 Karfreitag
2  1 Ostermontag
2 39 Christi Himmelfahrt
2 50 Pfingsten
2 60 Fronleichnam

# Intervall.
#Format: 4 <MM-TT> <MM-TT> <Feiertag-Name>

4 12-24 12-31 Weihnachtsurlaub


Und warum kommt er trotzdem zu dem Schluss, dass rr_Michael_wakeuptimer2 der richtige ist, obwohl laut Log dieser ja eig. verworfen wurde?
RESIDENTStk rr_Michael: 07 - next wake-up result: tomorrow at 09:15:00, wakeupDevice=rr_Michael_wakeuptimer2

Ich hoffe ich habe das jetzt einigermaßen verständlich erklärt. Außerdem schalte ich jetzt mal ein FileLog für weitere Analysen auf den passenden Devices ein.

@Loredo: Sollte ich dir damit auf die Nerven gehen, dann sag es und ich bin in Zukunft ruhig.

Gruß Michael
Wissen ist Macht.
Ich weiß nix.
Macht nix.

Loredo

Zitat von: l2r am 25 November 2016, 11:28:56
Der Wecker ist heute morgen durchgelaufen. Und wenn ich das richtig verstanden habe, dann wird sobald der Wecker gestartet wurde nextWakeup und nextWakeupDev  für den nächsten Wecker gesetzt. Als ich vorhin in rr_Michael geschaut habe, standen die beiden Readings allerdings noch auf 07:00 Uhr für wochentags und rr_Michael_wakeuptimer1, obwohl sie eigentlich auf 09:15 und rr_Michael_wakeuptimer2 stehen sollten.


Ja, die Vorhersage wann das nächste Mal ausgelöst werden wird ist da etwas wackelig und ich hatte noch keine Zeit/Muße mich da nochmals reinzudenken (der Code für Vorhersage und während der tatsächlichen Ausführung sind getrennt).
Das ist aber auch nur halb tragisch, denn es ist wie gesagt nur eine Vorhersage und zum Zeitpunkt des tatsächlichen Auslösens werden die Parameter korrekt beachtet. Es ist also derzeit mehr ein Schönheitsfehler, wenn man den Wert nicht gerade abends zur Ansage der nächsten Weckzeit über Sonos verwendet (so wie ich). Wenn man den Wecker übrigens neu stellt (auch auf die selbe Zeit), dann ist die Berechnung korrekt. Das tritt also aktuell nur so auf, wenn der Wecker nach beenden eines Zyklus die Voraussage gesetzt hat. Vermutlich ist es deshalb auch nur ein Timer-Problem, dass die Berechnung erst angeworfen werden kann, wenn der letzte Zyklus beendet wurde und das in der Reihenfolge im Code nicht ganz passt. Aber wie gesagt, die Muße war bisher dazu nicht da und du bist der erste, dem es auffällt :-)


Zitat von: l2r am 25 November 2016, 11:28:56
beim durchsehen der Logs ist mir folgende Zeile aufgefallen als rr_Michael_wakeuptimer2 ausgewertet wurde:

2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 05 - until now, will be NEXT WAKE-UP RUN tomorrow based on weekday decision
2016.11.25 11:00:40 4: RESIDENTStk rr_Michael_wakeuptimer2: 06 - won't be running tomorrow based on holiday decision (wakeupHolidays=andNoHoliday)



Dieses Finding ist in der Tat bemerkenswert, aber so konkret kann ich spontan da auch nichts drauf antworten.
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

l2r

Zitat von: Loredo am 25 November 2016, 12:14:33
Es ist also derzeit mehr ein Schönheitsfehler, wenn man den Wert nicht gerade abends zur Ansage der nächsten Weckzeit über Sonos verwendet (so wie ich).
Bei mir ist es ein Push mit der nächsten Weckerzeit, Sonos ist in Planung. Aber dann müsstest du das Problem ja auch haben?

Zitat von: Loredo am 25 November 2016, 12:14:33
Wenn man den Wecker übrigens neu stellt (auch auf die selbe Zeit), dann ist die Berechnung korrekt. Das tritt also aktuell nur so auf, wenn der Wecker nach beenden eines Zyklus die Voraussage gesetzt hat.
Kann ich auch so bestätigen. Falsch geweckt wurde ich noch nicht;)

Gruß Michael

Wissen ist Macht.
Ich weiß nix.
Macht nix.

l2r

Ich habe gerade mal mein Wecker für die Wochentage auf heute 18:00h gestellt. 17 Min offset.

Somit ist um 17:43 der wakeuptimer gestartet.

2016-11-25_17:43:21 rr_Michael nextWakeupDev: rr_Michael_wakeuptimer1
2016-11-25_17:43:21 rr_Michael nextWakeup: 18:00
2016-11-25_17:43:21 at_rr_Michael_wakeuptimer1 Next: 06:43:00
2016-11-25_17:43:21 rr_Michael nextWakeupDev: rr_Michael_wakeuptimer2
2016-11-25_17:43:21 rr_Michael nextWakeup: 09:15


Also das sieht so aus, dass die Prozedur zum setzten von nextWakeupDev und von dem Timer 2 mal aufgerufen wird. Am Ende, nachdem der Wecker durchgelaufen ist, wird die Prozedur wieder 2 mal ausgeführt:

2016-11-25_18:00:22 rr_Michael nextWakeupDev: rr_Michael_wakeuptimer2
2016-11-25_18:00:22 rr_Michael nextWakeup: 09:15
2016-11-25_18:00:22 rr_Michael nextWakeupDev: rr_Michael_wakeuptimer2
2016-11-25_18:00:22 rr_Michael nextWakeup: 09:15


Also jetzt scheint alles zu laufen. Bleibt die Frage, warum das heute morgen nicht der Fall war und warum die Prozedur 2Mal 2Mal ausgeführt wird.

Gruß Michael
Wissen ist Macht.
Ich weiß nix.
Macht nix.

Bootscreen

Ich hab da nochma ne Frage, ich hab ein ROOMMATE Device für meine Frau und ein GEOFANCY Device. Das presence, state und location reading werden auch auf present, home und home bei betreten der Home Zone gesetzt, bei verlassen werden presence und state ebenfalls korrekt auf absent gesetzt, nur die location bleibt auf home stehn. Setze ich den Status manuell auf absent wird auch location auf underway gesetzt. Jetzt ist die frage wo liegt da das Problem? Bekomm ich das selbst gefixt oder ist das ein Modul Problem?
Gruß
Oliver

FHEM 5.7 Hardware:
Raspberry PI B+ | HomeMatic USB 2 | 433Mhz Sender (pilight) | nanoCUL (433Mhz)

Loredo

Works as designed/ intended. Die Adresse aus GEOFANCY bleibt absichtlich erhalten, um den letzten bekannten Aufenthaltsort zu erinnern. Die Unterscheidung ob man dort noch anwesend ist oder es die zuletzt bekannte Stelle ist macht das Reading locationPresence.


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

Bootscreen

ok, aber dann versteh ich nicht warum dort Underway steht wenn ich den Status manuell auf absent setze und wo dann der Unterschied zwischen location / lastLocation ist. Doof ist halt auch das bei andFhem aufm Handy in der Übersicht die Location angezeigt wird und die ja dann bei verlassen durch geofancy die "falsche" Location enthält. Jemand eine Idee wie ich das dann am besten Löse?
Gruß
Oliver

FHEM 5.7 Hardware:
Raspberry PI B+ | HomeMatic USB 2 | 433Mhz Sender (pilight) | nanoCUL (433Mhz)

ThommyTom

Hallo,

ich habe auch seit längerem das Problem, dass der Status der Roommates nicht mehr gewechselt wird. Habe Geofancy eingerichtet, da funktioniert die Erkennung bzw. der Wechsel des Standortes ohne Probleme. Ich habe auch schon geofancy und Resident gelöscht und komplett neu eingerichtet. Aber es bleibt immer bei present=home.

Habe mal ein List von meinem Residentsmodul angehängt, vielleicht hilft das??

ZitatInternals:
   CFGFN
   CHANGED
   NAME       Bielefeld
   NR         242
   NTFY_ORDER 50-Bielefeld
   ROOMMATES  rr_Tom
   STATE      home
   TYPE       RESIDENTS
   Readings:
     2016-12-13 11:26:10   lastActivity    home
     2016-12-13 11:26:10   lastActivityBy  Tom
     2016-12-13 11:26:10   lastActivityByDev rr_Tom
     2016-12-13 11:26:10   lastArrival     2016-12-13 11:26:10
     2016-12-13 11:26:10   lastState       initialized
     2016-12-13 11:26:10   presence        present
     2016-12-13 11:26:10   residentsAbsent 0
     2016-12-13 11:26:10   residentsAbsentDevs -
     2016-12-13 11:26:10   residentsAbsentNames -
     2016-12-13 11:26:10   residentsAsleep 0
     2016-12-13 11:26:10   residentsAsleepDevs -
     2016-12-13 11:26:10   residentsAsleepNames -
     2016-12-13 11:26:10   residentsAwoken 0
     2016-12-13 11:26:10   residentsAwokenDevs -
     2016-12-13 11:26:10   residentsAwokenNames -
     2016-12-13 11:26:10   residentsGone   0
     2016-12-13 11:26:10   residentsGoneDevs -
     2016-12-13 11:26:10   residentsGoneNames -
     2016-12-13 11:26:10   residentsGotosleep 0
     2016-12-13 11:26:10   residentsGotosleepDevs -
     2016-12-13 11:26:10   residentsGotosleepNames -
     2016-12-13 11:26:10   residentsHome   1
     2016-12-13 11:26:10   residentsHomeDevs rr_Tom
     2016-12-13 11:26:10   residentsHomeNames Tom
     2016-12-13 11:26:10   residentsTotal  1
     2016-12-13 11:26:10   residentsTotalAbsent 0
     2016-12-13 11:26:10   residentsTotalAbsentDevs -
     2016-12-13 11:26:10   residentsTotalAbsentNames -
     2016-12-13 11:26:10   residentsTotalGuests 0
     2016-12-13 11:26:10   residentsTotalGuestsAbsent 0
     2016-12-13 11:26:10   residentsTotalGuestsAbsentDevs -
     2016-12-13 11:26:10   residentsTotalGuestsAbsentNames -
     2016-12-13 11:26:10   residentsTotalGuestsPresent 0
     2016-12-13 11:26:10   residentsTotalGuestsPresentDevs -
     2016-12-13 11:26:10   residentsTotalGuestsPresentNames -
     2016-12-13 11:26:10   residentsTotalPresent 1
     2016-12-13 11:26:10   residentsTotalPresentDevs rr_Tom
     2016-12-13 11:26:10   residentsTotalPresentNames Tom
     2016-12-13 11:26:10   residentsTotalRoommates 1
     2016-12-13 11:26:10   residentsTotalRoommatesAbsent 0
     2016-12-13 11:26:10   residentsTotalRoommatesAbsentDevs -
     2016-12-13 11:26:10   residentsTotalRoommatesAbsentNames -
     2016-12-13 11:26:10   residentsTotalRoommatesPresent 1
     2016-12-13 11:26:10   residentsTotalRoommatesPresentDevs rr_Tom
     2016-12-13 11:26:10   residentsTotalRoommatesPresentNames Tom
     2016-12-13 11:26:10   residentsTotalWakeup 0
     2016-12-13 11:26:10   residentsTotalWakeupDevs -
     2016-12-13 11:26:10   residentsTotalWakeupNames -
     2016-12-13 11:26:10   residentsTotalWayhome 0
     2016-12-13 11:26:10   residentsTotalWayhomeDelayed 0
     2016-12-13 11:26:10   residentsTotalWayhomeDelayedDevs -
     2016-12-13 11:26:10   residentsTotalWayhomeDelayedNames -
     2016-12-13 11:26:10   residentsTotalWayhomeDevs -
     2016-12-13 11:26:10   residentsTotalWayhomeNames -
     2016-12-13 11:26:10   state           home
Attributes:
   alias      Residents
   devStateIcon .*home:status_available:absent .*absent:status_away_1:home .*gone:status_standby:home .*none:control_building_empty .*gotosleep:status_night:asleep .*asleep:status_night:awoken .*awoken:status_available:home .*:user_unknown:home
   group      Home State
   icon       control_building_filled
   room       Residents
   webCmd     state



Leider habe ich echt keine Plan was das falsch läuft. Eine Suche hier im Forum hat für mich auch keine wirkliche Lösung aufgezeigt...

Vielen Dank für die Hilfe

Gruß Thommy
Intel NUC
Harmony Smart Control
div. HUE Komponenten
div. HM-IP Komponenten
1x Kühlschrank voll mit Bier

Loredo

Es besteht derzeit noch die Abhängigkeit, dass die Reihenfolge in der fhem.cfg Datei so lauten müssen: Erst das RESIDENTS Device, dann die ROOMMATE Devices.
Bei dir sieht man jedoch am INTERNAL "ROOMMATES", dass rr_Tom erfolgreich erkannt wurde und somit berücksichtigt wird.
Ich kann an den Readings jetzt nicht erkennen, dass nicht alle korrekt aktualisiert würden, denn sie haben alle den gleichen Zeitstempel.
Ansonsten bitte beachten, dass es keinen Sinn macht die Events mittels event-on-* Attributen einzuschränken. Sie werden benötigt, damit die Updates richtig übermittelt werden und wenn man die falschen Events abdreht, geht es eben nicht mehr.
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

ThommyTom

Zitat von: Loredo am 13 Dezember 2016, 12:01:20
Es besteht derzeit noch die Abhängigkeit, dass die Reihenfolge in der fhem.cfg Datei so lauten müssen: Erst das RESIDENTS Device, dann die ROOMMATE Devices.
Bei dir sieht man jedoch am INTERNAL "ROOMMATES", dass rr_Tom erfolgreich erkannt wurde und somit berücksichtigt wird.
Ich kann an den Readings jetzt nicht erkennen, dass nicht alle korrekt aktualisiert würden, denn sie haben alle den gleichen Zeitstempel.
Ansonsten bitte beachten, dass es keinen Sinn macht die Events mittels event-on-* Attributen einzuschränken. Sie werden benötigt, damit die Updates richtig übermittelt werden und wenn man die falschen Events abdreht, geht es eben nicht mehr.


Danke Loredo  für Deine Hilfe.

Ich habe jetzt Geofancy, Residents und Roommates frisch eingepflegt. Habe auch darauf geachtet, dass zuerst Residents und dann Roommates in der fhem.cfg kommt. Leider passiert aber nichts...

Als ich das erste Mal Residents aktiviert habe, so vor ca. 10 Monaten, lief es auch ohne Probleme. Alles strikt nach Wiki eingerichtet!
Nur von jetzt auf gleich funktioniert es nicht mehr. Habe auch schon ein frisches FHEM versucht....

Hmm, was würdest du denn noch benötigen, um evtl einen Blick auf meine Config zu werfen? Vielleicht siehst Du ja was??

Gruß Thommy


Nachtrag: Keine Ahnung wieso und warum, aber jetzt läuft es wieder!? Komisch, komisch....
Intel NUC
Harmony Smart Control
div. HUE Komponenten
div. HM-IP Komponenten
1x Kühlschrank voll mit Bier

visionsurfer

Hallo,

ich habe alles wie im Beispiel der Weckautomation im WIKI beschrieben ist installiert. Alles funktioniert auch wie es sein soll und ich will nun immer mehr Dinge dazu bauen. Daher habe ich 2 Fragen:

1. Kann man in das Macro auch Code schreiben wie in einem DOIF ? Ich möchte z.B. gerne realisieren das Licht angeschaltet wird, aber nur wenn ein bestimmter LUX Wert von der Wetterstation unterschritten ist. Ich hab noch nicht ganz verstanden wie da dann der Code aufgebaut werden müsste ?

2. Gibt es eine geschickte Lösung Sonos einen Sleeptimer zu verpassen ? Nicht nur das die Box im Schlafzimmer nach XY aus geht, sondern das z.B. alle 3 Minuten die Lautstärke langsam runtergefahren wird, bis es dann ganz auf NULL ist ? So eine Art Fading über einen gewissen Zeitraum ? Sicherlich kann man das mit "Setze Lautstärke auf XY" und dann sleep 3 Minuten und den Befehl noch mal usw. Aber gibt es eine bessere Lösung ?

Ich wünsche einen guten Rutsch.

Visionsurfer