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

[LarsMie]

Die wayhome-Logik ist bei Nutzung des r*_geofenceUUIDs Attributs noch nicht richtig, ich muss die noch überarbeiten.
Generell soll es so sein, dass eine Lokation mit Namen "wayhome" eine besondere Rolle spielt: Beim betreten des Radius wird wayhome auf 1 gesetzt, wenn man zu Hause angekommen ist wieder auf 0.


Alle anderen Lokationen, die in r*_locationWayhome gesetzt sind, wirken sich anders aus: Nur bei deren VERLASSEN wird wayhome auf 1 gesetzt. Man kann dort also zB das Büro reinschreiben, wenn man in der Regel von dort direkt nach Hause fährt.

Moin, ich habe mehrere Orte in meine geofancy app angelegt. Folgende Orte habe ich jetzt drin: Schule, Arbeit, wayhome und home. Ich habe die UUID jetzt aus dem geofancy gelöscht und dafür das ROOMMATE device angelegt. Als ich vorhin den Bereich "Arbeit" verlassen habe, ist die Location nicht automatisch auf "underway" und auch nicht auf "wayhome" gewechselt. In der App wurde mir auf jeden fall das betreten und verlassen der bereiche angezeigt.

Wird "wayhome" und "underway" generell (noch) nicht von ROOMMATE berücksichtigt?

"underway wäre jetzt nicht so wichtig, aber "wayhome" schon.

Für den Fall dass es (noch) nicht berücksichtigt wird, würde es vorerst reichen (bis zur richtigen implementierung der "wayhome"-funktionen in dem Modul), wenn ich den ort "wayhome" in meine Stadt umbenenne, dass das device dann meine Stadt als aktuelle location erkennt? Damit könnte ich zumindest schonmal solche Dinge wie Heizungssteuerung realisieren.

Was ich noch suche sind genaue beschreibungen der neuen Attribute, ich schaue mal den Thread hier durch.

Vielleicht liegt ja auch einfach ein Fehler meinerseits vor.

[Loredo]

Ich habe gerade ein Update eingecheckt, welches jetzt in Verbindung mit GEOFANCY ein verbessertes wayhome Handling beinhaltet.

@Lars: es gibt keine neuen Attribute, es sind nach wie vor die selben. Die Beschreibung steht in der Commandref zu ROOMMATE.


Gruß
Julian

[LarsMie]

Hmm okay!

Das heißt, ich kann mir jetzt in der App einen Bereich bon 15km um meine Wohnung einrichten. Der sollte dann wahrscheinlich am besten "wayhome" heissen?


Danke für deine mühen, dann kann ich ab morgen das ganze mal "live" testen. Habe das ganze bisher nur beobachtet um die verhaltensweise der Module kennenzulernen.

[Loredo]

Ab morgen, wenn du das Update installiert hast, ja.


Wenn du die Umkreis-Funktion nutzen möchtest, muss die Lokation "wayhome" heißen, ja.
Wenn du möchtest, dass bei Verlassen einer bestimmten Lokation auf wayhome geschaltet wird, kann sie beliebig heißen, muss aber dann im Attribut locationsWayhome definiert sein, damit das erkannt wird.


Neu ist insgesamt noch, dass wayhome auf 2 wechselt, sofern wayhome einmal auf 1 gesetzt wurde. Nämlich dann, wenn man auf dem Heimweg nochmals woanders hält (und dafür dann natürlich ein entsprechender Ort definiert ist). Beim verlassen dieses Ortes wird dann wieder auf 1 geschaltet. Erst bei der Ankunft zu Hause endet das wayhome-Tracing dann und wayhome wird wieder auf 0 gesetzt. Während des wayhome-Tracing bleibt wayhome beim RESIDENTS Device nach wie vor auf 1. Ich überlege noch ein weiteres Reading für das RESIDENTS Device, welches dann "sich verspätende" Bewohner anzeigt.


Außerdem gibt es noch ein neues ROOMMATE Reading "locationPresence" welches "present" oder "absent" sein kann.
Bei Eintreffen an einer Lokation steht es auf "present", wenn man die Lokation verlassen hat auf "absent". Hintergrund ist, dass die anderen location-Readings nach wie vor bleiben, bis man eine andere Lokation erreicht hat. Mit locationPresence lässt sich dann also unterscheiden, ob das wirklich der aktuelle Aufenthaltsort ist oder nur der zuletzt bekannte Ort.


Ich betone nochmals, dass diese Verhalten nur bei direkter Nutzung mit GEOFANCY zutreffen. Wer in seiner Automation den location-Setter nutzt, um selbst die Lokation zu setzen, hat nach wie vor das alte Verhalten, da dabei keine Geo-Koordination übergeben werden und man immer davon ausgehen muss, dass es sich lediglich um die zuletzt bekannte Position handelt.




Gruß
Julian

[CoolTux]

Guten Morgen Loredo

Heute Nacht hat sich schon zum zweiten mal diese Woche mein Roommate auf 'home gesetzt. Dies wurde aber von keinem mehr bekannten Notify oder DOIF ausgelöst. Es hat nicht mit der presentserkennung zu tun weil ich keine Notify oder so habe was von asleep auf home setzt. Hier mal ein list.

Code Auswählen Erweitern


Internals:
   CHANGED
   DEF        AnniKraussStr
   NAME       rr_Marko
   NR         30
   NTFY_ORDER 50-rr_Marko
   RESIDENTGROUPS AnniKraussStr,
   STATE      home
   TYPE       ROOMMATE
   Readings:
     2016-01-08 22:45:25   durTimerAbsence 00:00:00
     2016-01-08 22:45:25   durTimerAbsence_cr 0
     2016-01-09 06:35:08   durTimerPresence 07:50:06
     2016-01-09 06:35:08   durTimerPresence_cr 470
     2016-01-09 02:12:02   durTimerSleep   00:00:00
     2016-01-09 02:12:02   durTimerSleep_cr 0
     2016-01-08 22:45:24   lastArrival     2016-01-08 22:45:24
     2016-01-09 02:12:02   lastAwake       2016-01-09 02:12:02
     2016-01-08 22:13:11   lastDeparture   2016-01-08 22:13:11
     2016-01-08 22:45:24   lastDurAbsence  00:32:01
     2016-01-08 22:45:24   lastDurAbsence_cr 32
     2016-01-08 22:13:11   lastDurPresence 05:24:00
     2016-01-08 22:13:11   lastDurPresence_cr 324
     2016-01-09 02:12:02   lastDurSleep    02:06:00
     2016-01-09 02:12:02   lastDurSleep_cr 126
     2016-01-08 22:13:11   lastLocation    home
     2016-01-08 07:14:55   lastLocationAddr -
     2016-01-08 07:14:55   lastLocationLat -
     2016-01-08 07:14:55   lastLocationLong -
     2016-01-09 00:06:08   lastMood        sleepy
     2016-01-09 00:06:08   lastSleep       2016-01-09 00:06:08
     2016-01-09 02:12:02   lastState       asleep
     2016-01-08 04:00:05   lastWakeup      05:00
     2016-01-08 04:00:05   lastWakeupDev   rr_Marko_wakeuptimer1
     2016-01-08 22:45:24   location        home
     2016-01-08 07:14:55   locationAddr    -
     2016-01-08 07:14:55   locationLat     -
     2016-01-08 07:14:55   locationLong    -
     2016-01-09 02:12:02   mood            calm
     2016-01-09 04:00:00   nextWakeup      OFF
     2016-01-09 04:00:00   nextWakeupDev   none
     2016-01-08 22:45:24   presence        present
     2016-01-09 02:12:02   state           home
     2016-01-08 05:00:11   wakeup          0
     2016-01-08 22:45:24   wayhome         0
   Timer:
     Rr_marko_durationtimer:
       HASH       rr_Marko
       MODIFIER   DurationTimer
       NAME       rr_Marko_DurationTimer
Attributes:
   alias      Marko
   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
   event-on-change-reading state,presence,wayhome,location
   group      Marko
   icon       people_sensor
   room       AnniKraussStr
   rr_locations atwork,home,wayhome,underway
   rr_passPresenceTo rr_Steven rg_Anna
   rr_realname alias
   rr_states  home,gotosleep,asleep,awoken,absent,gone
   rr_wakeupDevice rr_Marko_wakeuptimer1
   sortby     0
   webCmd     state:mood



Im log selber steht leider nur das gewechselt wird auf 'home und dann halt die damit in Verbindung stehenden Aktionen weil mein Roommate den Residents Status auf 'home gesetzt hat.

Vielleicht fällt Dir ja was auf.
Interessant ist noch das ich an beiden Tagen ein neu starten von FHEM gemacht habe. Also am Tag oder Abends. Beim ersten auftreffen schaltete sich mein Bewohner um 23:07 von asleep auf home und heute um 2:38.




Grüße

[ujaudio]

Der Wecker funktioniert nicht mehr!

Im Log steht:

Code Auswählen Erweitern

2016.01.08 22:09:09 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 21822) line 2.
2016.01.08 22:24:15 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 22109) line 2.

Genau zum ersten Zeitpunkt wurde das notify getriggert, dessen Code wie folgt ist:

Code Auswählen Erweitern

{
  my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
  if ($wday == 1 || $wday == 3) {
    fhem("set rr_Ursula state gotosleep; set wk_infoMP3 playTone 003,015,004")}
  elsif ($wday == 2 || $wday == 4) {
    fhem("set rr_Ursula state gotosleep; set wk_infoMP3 playTone 003,016,004")}
  else {
    fhem("set rr_Ursula state gotosleep; set wk_infoMP3 playTone 003,018,004")}
}
Genau zum ersten Zeitpunkt wurde das notify getriggert, dessen Code wie folgt ist:

Code Auswählen Erweitern

{if ($EVENT eq "toggle") {
  fhem("set rr_Ursula state asleep")
  } else {
  fhem("set rr_Ursula state asleep;
    sleep 5;
    set or_nachttischlampe on-for-timer 1")
  }
}
Bitte im zweiten Fall nicht wundern, das ist der Code und dieser soll später noch erweitert werden...

Ich habe an diesen Codes seit Monaten nichts mehr geändert, auch nicht an irgendetwas anderem der Residents/Roommates. Aktuell stehen die Verbosewerte alle auf 0 (es hat ja alles zur besten Zufriedenheit getan).

Mich würde interessieren, wo ich genauer hinschauen muss, sofern der Fehler bei mir liegt (davon ist erst einmal auszugehen). Vielleicht gibt die Warnung im Log einen Hinweise, der sich mir nicht erschließt.

Edit: gerade nochmals nachvollzogen:

Code Auswählen Erweitern

2016.01.09 13:03:37 2: ROOMMATE set rr_Ursula gotosleep
2016.01.09 13:03:38 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 35044) line 2.
2016.01.09 13:05:11 2: ROOMMATE set rr_Ursula asleep
2016.01.09 13:05:14 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 35085) line 2.
2016.01.09 13:05:49 2: ROOMMATE set rr_Ursula home
2016.01.09 13:05:50 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 35113) line 2.

Ich bekomme den Fehler auch, wennich den Status ohne notify manuell ändere:

Code Auswählen Erweitern

2016.01.09 13:09:08 2: ROOMMATE set rr_Ursula gotosleep
2016.01.09 13:09:09 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 35173) line 2.
2016.01.09 13:09:25 2: ROOMMATE set rr_Ursula home
2016.01.09 13:09:26 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 35195) line 2.

[ujaudio]

Also ich bekomme mittlerweile grundsätzlich bei jeder Änderung des "state" eines Roommate eine Warnung im log:

Code Auswählen Erweitern

2016.01.09 22:35:46 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 3363) line 2.
und eine Konsequenz ist, dass der Wecker nicht mehr funktioniert.

Ich habe gerade nochmals ein Update gemacht, inkl. Restart von FHEM: hat nicht geholfen!

Ich ändere den Status direkt im Browser (siehe Screenshot) von gone auf gotosleep und wieder auf gone (ich bin gerade unterwegs, meine Frau ist aber zu Hause, da passiert das gleiche), das Ergebnis im Log:

Code Auswählen Erweitern

2016.01.09 22:45:39 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 176) line 2.
2016.01.09 22:45:58 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 193) line 2.

Ok, muss uns halt wieder der gute alte Tick-Tack wecken. Gut, dass man so etwas noch im Haus findet.

Was kann ich beitragen, damit wir das Problem lösen? Denn ansonsten ist das genial und wir würden nur ungern darauf verzichten.

[Loredo]

Solange die Fehler nicht auftreten, wenn ein ganz frisch angelegtes ROOMMATE Device nebst Wecker diese Warnungen produzieren, ist es wahrscheinlich, dass es einen Fehler in den selbst abgeänderten Notifies gibt. Ich bekomme das mit einem Dummy-Device zumindest nicht reproduziert.

[Loredo]

Heute Nacht hat sich schon zum zweiten mal diese Woche mein Roommate auf 'home gesetzt. Dies wurde aber von keinem mehr bekannten Notify oder DOIF ausgelöst. Es hat nicht mit der presentserkennung zu tun weil ich keine Notify oder so habe was von asleep auf home setzt. Hier mal ein list.

Ich kann mir nur vorstellen, dass du ein übrig gebliebenes at oder Watchdog Device hast, welches herrenlos ist und nicht mehr (richtig) einem ROOMMATE Device zugeordnet. Du solltest prüfen, ob alle involvierten Attribute für die Verweise zwischen den DUMMY, Notify, at und watchdog Devices und dem ROOMMATE Device stimmen.


Grundsätzlich gab es am Wakeuptimer seit Monaten keinerlei Änderungen. Die hier jüngst durchgeführten Verbesserungen können damit also nicht in Zusammenhang stehen, dass ein Status sich ändert.

[CoolTux]

Hallo Loredo,

Vielen Dank für Deine Antwort. Ich werde es mir mal genauer anschauen. Bis jetzt kam es nicht wieder vor. Ich werde das mal im Auge behalten und versuchen es näher zu analysieren. Kann schon sein das es eine nicht mehr korrekte Zuordnung ist. Bei mir ist in den letzten Wochen einiges dazu gekommen   



Grüße
Leon

[ujaudio]

Solange die Fehler nicht auftreten, wenn ein ganz frisch angelegtes ROOMMATE Device nebst Wecker diese Warnungen produzieren, Es ist wahrscheinlich, dass es einen Fehler in den selbst abgeänderten Notifies gibt. Ich bekomme das mit einem Dummy-Device zumindest nicht reproduziert.

Das heißt also löschen und komplett neu anlegen...ok, werde ich mal machen.

[Loredo]

Alternativ parallel eine Dummy-Familie aus RESIDENTS und ROOMMATE zum testen anlegen und dafür den Wakeuptimer anlegen. Wenn man das RESIDENTS Device zuerst anlegt und in einen Raum "Test" verlegt und anschließend über das set-Kommando die Bewohner anlegt, hat man auch alles in einem Testraum zusammen.


Gruß
Julian

[CoolTux]

@Loredo

Ich denke mal ich habe meinen Fehler gefunden. Hat was mit meinem presence notify zu tun. Hoffe mal das es das war.



Grüße

[ujaudio]

Das heißt also löschen und komplett neu anlegen...ok, werde ich mal machen.

Alles komplett gelöscght und wieder sorgfältigst angelegt - gleiches Fehlverhalten.

Morgen wieder, jetzt bin ich fertig.

[Loredo]

Für diejenigen, die die Location Funktion mit GEOFANCY via dem Attribut r*_geofenceUUIDs benutzen gibt es ab morgen einen neuen Setter, der auf einfache Weise einen Google Maps Weblink anlegt, damit die aktuelle Position in einer Karte angezeigt wird.