FHEM Forum

FHEM => Automatisierung => Thema gestartet von: Loredo am 19 Januar 2014, 23:12:34

Titel: Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 19 Januar 2014, 23:12:34
Hallo,

ich habe damit begonnen meine ganzen Dummy-Definitionen in eine Gruppe von Modulen zu gießen.
Die Module beziehen sich alle aufeinander, können teilweise aber auch unabhängig eingesetzt werden.

Vorgesehen sind:
00_HOMESTATE
10_RESIDENTS
20_ROOMMATE
20_GUEST

Anbei ein erster Wurf der Module 10_RESIDENTS, 20_ROOMMATE und 20_GUEST.
Damit kann man die Bewohner und deren Status auf einfache Weise definieren und verwalten.

EDIT: Die Module 10_RESIDENTS, 20_ROOMMATE und 20_GUEST sind ab sofort im SVN eingecheckt. Die hier ggf. ladbaren Versionen sind Betas zukünftiger Versionen.
Beispiel:
define SesamStreet19 RESIDENTS
set SesamStreet19 addRoommate Oscer
set SesamStreet19 addRoommate Tiffy
set SesamStreet19 addGuest Guest

Damit werden die Bewohnergruppe "SesamStreet19" und deren Bewohner Oscer und Tiffy jeweils als Device angelegt.
Die Bewohner Oscer und Tiffy können entsprechende (Anwesenheit)Stati und Gemütszustände haben:

home = generell Zuhause
gotosleep = auf dem Weg ins Bett
asleep = schlafend
awoken = aufgewacht
absent = nicht Zuhause
gone = längere Zeit weg

Außerdem wird das Reading "mood" beim Wechsel zwischen den Stati automatisch geändert, wo es sinnvoll erscheint. Ansonsten kann das mood-Reading nach Lust und Laune einfach benutzt werden, um eigene Schaltungen entsprechend davon abhängig zu machen.


Je nach Anwesenheitsstatus ändert sich der Status von "SesamStreet19" entsprechend und kann folgende Stati haben:

present = einer oder mehrere Bewohner sind Zuhause und mindestens einer davon schläft nicht
gotosleep = (die letzten) Bewohner sind auf dem Weg ins Bett, während andere ggf. schon schlafen
asleep = alle Bewohner schlafen
awoken = mindestens ein Bewohner ist aufgewacht, andere schlafen noch oder gehen gerade ins Bett
absent = kein Bewohner ist Zuhause, mindestens einer ist aber bald zurück
gone = kein Bewohner ist Zuhause und alle sind längere Zeit weg


Ich würde mich freuen, wenn Interessierte die Module schonmal vorab testen würden. Das Modul 00_HOMESTATE wird nachgereicht, sobald es soweit ist  ;)

Außerdem ist geplant, dass man für die Bewohner-Objekte durch einfache Befehle Vorlagen für sowas wie Wecker, Geolokation und generell Notifies und Watchdogs anlegen kann, die dann auch auf die Module entsprechend abgestimmt sind.


Gruß
Julian
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: justme1968 am 19 Januar 2014, 23:46:51
hallo julian,

die idee finde ich klasse.

was mich auf den ersten blick stört ist das die zustände nicht 'logisch' und hierarchisch aufeinander aufbauen.

ich bin mir aber nicht sicher wie sich das am besten erreichen lässt. vielleicht ist es geschickter nicht nur ein reading zu verenden sondern mehrere und statt dessen zugriffsfunktionen zu haben.

wenn ich wissen möchte ob jemand anwesend ist sollte das true liefern egal ob er wach ist oder schläft, erst wenn ich wissen möchte ob jemand schläft sollte das true liefern wenn er schläft. false immer sonst. auch wenn er gar nicht anwesend ist.

das gleiche für den 'zustand' der ganzen wohnung: niemand da, einer da, alle da. egal ob schlafend oder wach. none sleeping, some sleeping, all sleeping.

mit readings/funktionen die den zustand so zurückliefen ist es denke ich einfacher etwas zu steuern: heizung auf frostschutz bei gone, aber ein bei anwesend egal ob schlafend oder nicht. zirkulation aus bei gone und schlafend und sobald einer anwesend ist zeit oder temperaturgesteuert.

gruss
  andre
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Loredo am 19 Januar 2014, 23:49:01
Ich werde noch ein Reading "presence" wie bei dem Media Modulen hinzufügen. Das ist dann entsprechend konsistent, Der Status sollte entsprechend dynamisch bleiben, siehe devIconState etc.
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Loredo am 19 Januar 2014, 23:52:39
Achso noch als Nachtrag: Wieviele im jeweiligen Zustand sind, gibt es bereits als Reading. Dahinter steht eine Zahl 0 bis <Anzahl der Bewohner>. Darauf kann man auch Notifies setzen ;)
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: justme1968 am 19 Januar 2014, 23:54:55
hab grad die screenshots gesehen. die gab es noch nicht als ich geschrieben hatte :)

gruss
  andre
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Loredo am 19 Januar 2014, 23:55:33
hab grad die screenshots gesehen. die gab es noch nicht als ich geschrieben hatte :)


Tjaaaa Augen auf  8)
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Rince am 20 Januar 2014, 10:33:09
Finde die Idee auch klasse.

Ich überlege nämlich grade an der anderen Seite des Problems, nämlich wie man mit Zuständen übersichtlich die Schaltungen in der Wohnung ändern kann.

Äh, den Satz versteht jetzt keiner, gell ;)

So:
Anwesend, Tag
- Telefonanrufe laut mit TTS ansagen
- Bewegungen in der Hofeinfahrt laut ansagen
- Bewegungsmelder im Haus haben keine Funktion
- Lichtschalter im Haus schalten normal das Licht
- Heizung nach Wochenplan

Anwesend, Nacht
- Telefonanrufe TTS leise ansagen
- BewegungsmelderHofeinfahrt laut ansagen
- Bewegungsmelder im Haus machen gedimmtes Licht
- Lichtschalter schalten normal

Anwesend, Party
- Bewegungsmelder ohne Funktion,

Alarmanlage scharf
- Bewegungsmelder Hofeinfahrt startet Videoaufzeichnung
- Bewegungsmelder im Haus lösen Alarm aus
(- Schaltvorgänge im Haus lösen Alarm aus)
- Türklingel ohne Funktion
- Bewegungssimulation aktiv

Alarm
- Schalter lösen TTS Ansage aus, welcher Schalter betätigt wurde
- eMail wird verschickt
- Alle Lichter sind an
- Lichter lassen sich nicht ausschalten


So in etwa.

Was ich dazu brauche, ist eine gute Logik, wie man automatisch die Zustände umschalten kann.
Da wären deine Module vermutlich sehr praktisch :)


PS:
Du solltest evtl. oben deine Adresse entfernen?
So weiß ich, dass du 15 Autominuten weg wohnst ;)
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: det. am 20 Januar 2014, 17:28:52
Hallo Loredo,
Prima Sache! Wollte eigentlich Dein geofancy Modul loben und bin dabei auf Dein neues Projekt gestoßen.  Sitze schon in der Stube und sehe das meine Frau gerade WORK verlassen hat... wenn ich ihr das erzählen würde wäre der WAF von FHEM mal wieder ganz unten.... von wegen Dauerüberwachung.
Da warte ich mal mit der Auswertung der geofency Daten und teste Deine neuen Module.
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: UliM am 20 Januar 2014, 20:43:01
Ich überlege nämlich grade an der anderen Seite des Problems, nämlich wie man mit Zuständen übersichtlich die Schaltungen in der Wohnung ändern kann.
Hi,
ich hab mir diesbezüglich mal das Modul LightScene angeschaut - sieht sehr nach dem aus, was man dafür so bräuchte.
Man kann für eine Liste von Geräten unterschiedliche "Scenes" speichern und abrufen. Das muss sich ja nicht auf Lichter beziehen, können wohl auch Solltemperaturen etc sein.
Werd mal damit rumprobieren.
Grüßle,
Uli
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: justme1968 am 20 Januar 2014, 21:39:16
LightScene funktioniert für alles bei dem du mit einem get oder aus einem reading den aktuellen status abfragen und mit einem set wieder herstellen kannst.

im einfachsten fall ist es einfach state. aber du kannst konfigurieren welches reading oder welches get zum 'merken' und welches set zum wieder herstellen verwendet wird.

wenn das nicht reicht kannst du auch noch eine kleine funktion einhängen die den wert der gespeichert werden soll noch mal etwas aufbereitet (z.b. dim status aus einem reading holen, mit der funktion ein % zeichen entfernen damit es später bei set nicht im weg ist).

wenn auch das nicht reicht kannst du auch noch von hand das/die kommandos setzen die beim aktivieren einer szene für ein bestimmtest device verwendet werden sollen.

in der detail ansicht der szene kann man eigentlich auch in der ersten zeile den zustand zusammen klicken den man haben möchte und dann einfach save sagen und die näcshte szene zusammen klicken. da gibt es aber nach der letzten änderung von rudi leider gerade ein problem mit longpoll. das muss ich erst wieder reparieren.

gruss
  andre
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Rince am 20 Januar 2014, 23:28:06
Eine kreative Idee :)
Aber wir laufen Gefahr den Thread zu kapern ;)
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: UliM am 20 Januar 2014, 23:48:17
Hi,
stimmt - aber vielleicht verhinderts ja ne Doppelentwicklung.
Zu Lightscene also ggf weitere posts im Ordner "Automatisierung" - einen hab ich schon angelegt :)
=8-)
Titel: Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Loredo am 20 Januar 2014, 23:53:26
Nee Doppelentwicklung wird das hier nicht. ich merk schon, offenbar versteht ihr es noch nicht :-/

Dabei nehme ich an, dass das doch etwas ist, was wirklich jeder bei sich daheim haben will. Den Status der Bewohner möglichst automatisiert verfolgen und das Haus davon abhängig unterschiedlich zu steuern.
Die Module können hervorragend als Eingangsgröße verwendet werden, um dann bestimmte LightScenes (um die Brücke zu eurem Thema zu schlagen) zu schalten.
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: UliM am 25 Januar 2014, 12:55:22
offenbar versteht ihr es noch nicht :-/
Mag sein :)
Kannst ja mal querchecken: http://www.fhemwiki.de/wiki/Zuhause-Status#Umsetzung_mit_LightScene
Gruß, Uli
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: justme1968 am 25 Januar 2014, 13:05:38
ich weiss doch das es was anderes ist. ich hab es sogar probiert :)

und ich warte auf die fehlenden beiden.

gruss
  andre
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Loredo am 25 Januar 2014, 13:07:31
ich weiss doch das es was anderes ist. ich hab es sogar probiert :) 
Na Gott sei Dank  ;D  Das demotiviert nicht mehr ganz so stark  8)  Aber ich würde es so oder so für mich machen weil mir meine Konstruktion aus zusammengewürfelten Modulen viel zu instabil ist und langsam echt auf den Zeiger geht (besonders, wenn man mehr als nur ein Haus oder eine Wohnung zu administrieren hat).


und ich warte auf die fehlenden beiden.


Ich verbringe gerade jeden Wochentag 11-12h im Büro und komme leider nicht so voran, wie ich es manchmal gerne hätte  :-\
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Mitch am 25 Januar 2014, 14:26:26
So, nachdem ich Geofancy nun teste, habe ich auch Deine Module installiert und mal eingerichtet.
Muss noch einen Zusammenhang mit Geofancy "basteln".
Noch steige ich noch nicht ganz durch  ;)

Ich möchte mit Geofancy den HomeStatus auf Da oder weg tranken und dementsprechend eine Dinge schalten.
Im Moment mache ich das über WLAN und BT, ist aber nicht immer 100%tig.

Vielleicht magst Du mal eine kleine Doku zu Deinen Modulen schreiben und/oder ein paar Codeschnippsel dazu posten?
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Loredo am 25 Januar 2014, 14:30:58
So, nachdem ich Geofancy nun teste, habe ich auch Deine Module installiert und mal eingerichtet.
Muss noch einen Zusammenhang mit Geofancy "basteln".
Noch steige ich noch nicht ganz durch  ;)

Ich möchte mit Geofancy den HomeStatus auf Da oder weg tranken und dementsprechend eine Dinge schalten.
Im Moment mache ich das über WLAN und BT, ist aber nicht immer 100%tig.

Vielleicht magst Du mal eine kleine Doku zu Deinen Modulen schreiben und/oder ein paar Codeschnippsel dazu posten?


Wenn die Module mal fertig sind, gibts auch Doku  ;)
Grundsätzlich werde ich eine Verknüpfung zu GEOFANCY herstellen, um die Integration einfacher zu machen.


Gruß
Julian
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Rince am 25 Januar 2014, 18:11:54
Ich dachte ich hätte es genau so geschrieben wie du es siehst.
Deine Module sind schlau den Status zu erkennen, Lightscene dann damit Dinge schalten lassen. Wir haben es nie anders gesehen :)

Leider bin ich immer noch relativ netzlos, sonst hätte ich es bestimmt schon probiert.

Mein Problem ist, dass ich nicht im Apple Biotop bin und das auch nicht möchte. Drum halte ich mich aus Geofancy raus. Werde das wohl mit Tasker und dem Google Kalender lösen müssen für unterwegs. Aber das gehört hier nicht rein :)
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Loredo am 25 Januar 2014, 18:16:27

Ich dachte ich hätte es genau so geschrieben wie du es siehst.
Deine Module sind schlau den Status zu erkennen, Lightscene dann damit Dinge schalten lassen. Wir haben es nie anders gesehen :)


Ich hatte Uli da schon anders verstanden, dich hingegen richtig ;)

Mein Problem ist, dass ich nicht im Apple Biotop bin und das auch nicht möchte. Drum halte ich mich aus Geofancy raus. Werde das wohl mit Tasker und dem Google Kalender lösen müssen für unterwegs. Aber das gehört hier nicht rein :)


Der Schwenk zu Geofancy ist auch nur am Rande. Durch welche Ereignisse man den Status seiner Bewohner wiederrum ändert, das bleibt jedem selbst überlassen. Es kann direkt übers Webinterface sein, durch einen physischen Taster oder sonstwas. Ich benutze auch eine Kombination aus mehreren Sachen. Du kannst auch das PRESENCE Modul nehmen z.B., wenn es für dich gut funktioniert (ist ja u.U. so eine Sache).
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Rince am 25 Januar 2014, 18:40:06
Zitat
Durch welche Ereignisse man den Status seiner Bewohner wiederrum ändert, das bleibt jedem selbst überlassen

Tja, in einigen Jahren sind wir hier bestimmt weiter :)
Erkennung an Hand der Sprache oder Bilderkennung.
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Loredo am 25 Januar 2014, 18:42:02
Tja, in einigen Jahren sind wir hier bestimmt weiter :)
Erkennung an Hand der Sprache oder Bilderkennung.


Aus FHEM Sicht fände ich das sicher gut  ;)
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: extraem am 25 Januar 2014, 22:38:04
Hallo

ich habe es jetzt auch einmal getestet und mir ist aufgefallen das ich nur folgende Statu habe

home = generell Zuhause
gotosleep = auf dem Weg ins Bett
absent = nicht Zuhause
gone = längere Zeit weg

hast du da etwas geändert oder ist da bei mir etwas falsch gelaufen

Danke
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Loredo am 25 Januar 2014, 22:50:25
Hallo

ich habe es jetzt auch einmal getestet und mir ist aufgefallen das ich nur folgende Statu habe

home = generell Zuhause
gotosleep = auf dem Weg ins Bett
absent = nicht Zuhause
gone = längere Zeit weg

hast du da etwas geändert oder ist da bei mir etwas falsch gelaufen



Das ist Absicht.
In der Webansicht werden nicht alle Stati angezeigt. Es fehlen die Zwischenstati "asleep" und "awoken", weil es für diese keinen Sinn macht, diese direkt auswählen zu können, wenn man nicht zuvor "gotosleep" als Status hatte. Man kann sie per Kommandozeile trotzdem setzen, das bleibt erhalten. Aber über die Weboberfläche ist quasi ein kleiner "Workflow" vorgesehen: Setzt man den Status auf "gotosleep", dann kann man den nächsten sinnvollen Status per Klick auf das Status-Icon erreichen (ist über das Attribut devStateIcon auch einsehbar).

Ich lade gleich mal eine neue Version hoch. Dort kann man alle Stati einblenden oder auch nur ganz bestimmte anzeigen lassen.


Gruß
Julian
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Loredo am 25 Januar 2014, 23:05:41

Ich habe jetzt gerade im ersten Post http://forum.fhem.de/index.php/topic,19040.msg127329.html#msg127329 (http://forum.fhem.de/index.php/topic,19040.msg127329.html#msg127329) eine neue Version der Module 10_RESIDENTS und 10_ROOMMATE sowie die erste Version von 10_GUEST hochgeladen.


Unter der Haube hat sich eine ganze Menge getan:

Die create-Funktionen funktionieren noch nicht. Auch sind einige Attribute noch ohne Funktion.
Ich mache mich jetzt zunächst ans 10_HOMESTATE Modul, um die Familie zu komplettieren.
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Mitch am 27 Januar 2014, 08:06:50
Also irgendwie läuft es bei mir noch nicht rund.

Ich erhalten alle paar Stunden folgene Logmeldung üfr alle Anwohner:
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'alias'
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'rr_autoGoneAfter'
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'devStateIcon'
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'group'
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'icon'
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'rr_locationHome'
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'rr_locationOffice'
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'room'
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'sortby'
2014.01.27 07:24:03 3: ROOMMATE rr_Markus: created new attribute 'webCmd'

kurz danach startet FHEM neu.
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Loredo am 27 Januar 2014, 08:35:46
Das klingt jetzt eher nach einer lokalen Besonderheit deiner FHEM Installation.
Es gibt keine Funktion in den Modulen, die zeitgesteuert alle Bewohner löscht und wieder anlegt. Danach sieht es allerdings aus, denn die Attribute werden nur angelegt, wenn sie noch nicht vorhanden sind (was wiederum nur bei einem ganz frisch angelegten Bewohner der Fall ist).
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Loredo am 29 Januar 2014, 09:15:12
Nachdem heute der 29. Januar und es dieses Jahr keinen 29. Februar gibt, habe ich gerade eine neue Version der Module hochgeladen  ;D


(wer diese Nachricht entschlüsseln kann weiß, wovon er spricht  ;) )
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: der-Lolo am 02 Februar 2014, 12:26:33
Hallo Loredo,
ich bin gerade damit beschäftigt einige Schaltzustände zu automatisieren bezogen auf die Anwesenheit..
Ich habe bereits zwei Dummys die mitsamt watchdog und Bluetooth Anwesenheit present und absent sauber arbeiten.

Deine Module habe ich eingefügt und die Wohnung RESIDENTS definiert.
Die beiden Dummys habe ich per addRoommate hinzugefügt…

Der Raum Residents wurde erstellt, soweit alles toll - aber…

sollte jetzt nicht wenn sich der state des Dummys ändert von present auf absent oder umgekehrt eine Reaktion innerhalb Residents kommen?
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Loredo am 02 Februar 2014, 12:31:40
Hallo Loredo,
ich bin gerade damit beschäftigt einige Schaltzustände zu automatisieren bezogen auf die Anwesenheit..
Ich habe bereits zwei Dummys die mitsamt watchdog und Bluetooth Anwesenheit present und absent sauber arbeiten.

Deine Module habe ich eingefügt und die Wohnung RESIDENTS definiert.
Die beiden Dummys habe ich per addRoommate hinzugefügt…

Der Raum Residents wurde erstellt, soweit alles toll - aber…

sollte jetzt nicht wenn sich der state des Dummys ändert von present auf absent oder umgekehrt eine Reaktion innerhalb Residents kommen?


Dummy ist nicht der richtige Ausdruck, das sind auch eigene Module. Und ja, wenn sich an den Objekten vom Typ GUEST oder ROOMMATE etwas ändert, dann spiegelt sich das im zugewiesenen Eltern-Objekt (RESIDENTS) wieder und umgekehrt. Ob die Module sich gegenseitig richtig registriert haben, siehst du über den Readings in den Internals. Dort steht, welche Eltern- bzw. Kindobjekte registriert sind.




Gruß
Julian




PS: Notifies funktionieren gerade in der Version noch nicht. Ich habe gestern aber extrem lange daran getüftelt, um Beschränkungen von FHEM zu umgehen. Ich denke ich habe es jetzt soweit und werde später eine neue Version hochladen.
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: der-Lolo am 02 Februar 2014, 12:46:47
Hm - haben wir aneinander vorbei geredet?

Ich habe bereits zwei dummys gesetzt -

define wd_iPhone_away watchdog iPhone:absent 00:03 iPhone:present setstate wd_iPhone_here defined ;; setstate Micha absent ;; {Log 1, "Micha ist gegangen..."}
attr wd_iPhone_away regexp1WontReactivate 1

define wd_iPhone_here watchdog iPhone:present 00:00 iPhone:absent setstate wd_iPhone_away defined ;; setstate Micha present ;; {Log 1, "Micha ist nach Hause gekommen..."}
attr wd_iPhone_here regexp1WontReactivate 1

define Micha dummy
attr Micha event-on-change-reading state
attr Micha room develop

Roommate Micha reagiert aber nicht auf Änderung des Bluetooth Zustandes.
Als schnellschuss versuchte ich gerade setstate Micha in setstate rr_Micha zu ändern - aber auch das brachte keine Veränderung in der Ansicht Residents
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 10_ROOMMATE 10_GUEST 10_HOMESTATE
Beitrag von: Loredo am 02 Februar 2014, 12:50:37
Dein Dummy musst du durch ein ROOMMATE Objekt ersetzen, denn es ist überflüssig. rr_Micha wurde ja bei dir schon angelegt. Änderungen dort werden im RESIDENTS Objekt wiedergegeben.


Notifies kann man in der aktuell öffentlichen Version noch nicht zuverlässig auf die RESIDENTS/ROOMMATE/GUEST Objekte setzen (siehe http://forum.fhem.de/index.php/topic,19518.0.html). Ich habe in meiner Entwicklerversion das Problem schon gelöst, muss aber noch ein paar Bugs fixen, bevor ich die hoch lade.
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 02 Februar 2014, 13:00:19
Ok - wie gebe ich den Bluetooth zustand an das Roommate Objekt weiter?
setstate rr_Micha present funktioniert nicht - setpresence kann ich ja sicher nicht verwenden - oder?
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 02 Februar 2014, 13:01:55
Ok - wie gebe ich den Bluetooth zustand an das Roommate Objekt weiter?
setstate rr_Micha present funktioniert nicht - setpresent kann ich ja sicher nicht verwenden - oder?


Ganz einfach:


set rr_Micha home
set rr_Micha absent


Es ist ein eigenes, richtiges Modul und so will es auch behandelt werden. Es ist kein doofes Dummy Device ;-)
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 02 Februar 2014, 13:26:04
ok - das funktioniert…
gibst Du hier kurz bescheid wenn ich auf abwesend beider Bewohner per notify die Heizung regeln kann?

Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 02 Februar 2014, 14:05:27
Ich habe jetzt Version 0.0.5 hochgeladen:
http://forum.fhem.de/index.php/topic,19040.msg127329.html#msg127329 (http://forum.fhem.de/index.php/topic,19040.msg127329.html#msg127329)


Neuerungen überschlagen:
Die Statistiken lastDur* kann man sicherlich gut loggen und einen entsprechenden Plot daraus bauen. Da bin ich aber nicht so der Experte. Wer also Lust hat, darf hier sehr gerne unterstützen!


Gruß
Julian
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 02 Februar 2014, 14:09:27
ok - das funktioniert…
gibst Du hier kurz bescheid wenn ich auf abwesend beider Bewohner per notify die Heizung regeln kann?


Bescheid.
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 02 Februar 2014, 14:26:45
Achso:

Wer das Geofancy-Modul einsetzt, braucht jetzt nur noch ein ganz einfaches Notify - z.B.


define n_rr_Julian notify geofancy:currLoc_Julian.* set rr_Julian location $EVTPART1


Ich habe meine Heimat-Lokation in der Geofancy.app mit dem ID-Namen "home" versehen. Der Status wird dann automatisch auf "home" gesetzt, wenn ich diese Lokation erreiche. Das Geofancy-Modul schickt als Lokation beim Verlassen "underway" und auch damit wird der Status automatisch auf "absent" gesetzt.


Über das Attribut r*_locationHome kann man mehrere Orte durch Leerzeichen getrennt eingeben, bei dessen erreichen der Status automatisch auf "home" gesetzt werden soll.
Über das Attribut r*_locationUnderway kann man mehrere Orte durch Leerzeichen getrennt eingeben, bei dessen verlassen der Status automatisch auf "absent" gesetzt werden soll.
Titel: Antw:Neue Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 08 Februar 2014, 23:06:38
Hallo zusammen,


ich habe mich entschieden, die aktuellen Versionen von 10_RESIDENTS, 20_ROOMMATE und 20_GUEST ins SVN als Version 1.0 einzuchecken  8)


Momentan überlege ich mir noch viele Details für das HOMESTATE Modul und ich dachte mir, vielleicht kommt auch noch mehr Input von euch, wenn ich die anderen Module schonmal offiziell bereit stelle. Sie sind ja auch in der aktuellen Form bereits sehr nützlich wie ich finde  ;)




Gruß
Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: det. am 09 Februar 2014, 11:10:29
Hallo Loredo,
Habe gestern Dein GEOFANCY mit Deinen neuen Modulen gekoppelt. Ist wirklich sehr gelungen und klappt auf Anhieb - erster live Test heute morgen beim Brötchen holen. Vorteil sehe ich u.a. im Wegfall der Bluetooth Lösung zur Ermittlung der iPhone Anwesenheit, die ja ohne Verrenkungen durch mailcheck über Freunde App oder zusätzlichen Einsatz von GEOFANCY erst merkt dass man daheim ist, wenn man bereits drin ist. D.h. Mail kommt, da die Eingangstür geöffnet wurde ( nervig ).
Was meinem Spieltrieb noch Grenzen setzt, sind die mood Attribute und der gotosleep State. Kannst Du bitte dazu mal ein Beispiel geben, wie das zu verwenden ist - speziell eine Idee wie FHEM merkt, dass ich auf dem Weg ins Bett bin. Was ich mit Letzterem schalten könnte ist mir klar, aber einen Drucksensor unter ein Bettbein konnte ich meiner Frau noch nicht unterschieben ( Schlafzimmer ist bei uns sensorfreie Zone ).
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 09 Februar 2014, 13:22:40
...aber einen Drucksensor unter ein Bettbein konnte ich meiner Frau noch nicht unterschieben ( Schlafzimmer ist bei uns sensorfreie Zone ).


Ich konnte mir ein Grinsen nicht verkneifen  ;D

Habe gestern Dein GEOFANCY mit Deinen neuen Modulen gekoppelt. Ist wirklich sehr gelungen und klappt auf Anhieb - erster live Test heute morgen beim Brötchen holen. Vorteil sehe ich u.a. im Wegfall der Bluetooth Lösung zur Ermittlung der iPhone Anwesenheit, die ja ohne Verrenkungen durch mailcheck über Freunde App oder zusätzlichen Einsatz von GEOFANCY erst merkt dass man daheim ist, wenn man bereits drin ist. D.h. Mail kommt, da die Eingangstür geöffnet wurde ( nervig ).


Ich überlege auch grad, ob ich die wackelige WLAN Konstruktion bei mir ganz abschaffe (nutze keine Fritzbox als AP und frage daher meinen TomatoUSB AccessPoint via SNMP ab und leider verschwindet das iPhone trotz aktiviertem WLAN Sync viel zu häufig und zu lange, so dass selbst Watchdog statt Notify als Trigger oftmals nicht genügt). Hab mich bisher nicht getraut, weil die Geofancy.app so unzuverlässig war. Die Geofency.app muss ich erstmal noch länger testen. Es kommt beispielsweise häufiger vor, dass ich beim Verlassen oder Betreten der Zone telefoniere und je nach Netzempfang bin ich dann ggf. im GSM Netz eingebucht, so dass parallel keine Internetverbindung via EDGE möglich ist und der Webhook in dem Moment nicht abgesetzt werden kann. Dem Entwickler von Geofancy.app hatte ich das bereits gesagt, er wollte Abhilfe schaffen, hat aber alles nur verschlimmbessert. Dem Geofency.app Entwickler muss ich das erst noch sagen  ;)
Aber ich schweife ab...


Was meinem Spieltrieb noch Grenzen setzt, sind die mood Attribute und der gotosleep State. Kannst Du bitte dazu mal ein Beispiel geben, wie das zu verwenden ist - speziell eine Idee wie FHEM merkt, dass ich auf dem Weg ins Bett bin. Was ich mit Letzterem schalten könnte ist mir klar, aber einen Drucksensor unter ein Bettbein konnte ich meiner Frau noch nicht unterschieben ( Schlafzimmer ist bei uns sensorfreie Zone ).


Also gedacht habe ich mir bisher folgendes:

Mood kann man eigentlich als universelles Leerfeld ansehen. Es muss nicht zwingend den Gemütszustand widergeben, man kann die Liste ja anpassen und da alles reinschreiben, was man möchte.
Die Grundidee war die, dass jeder Mitbewohner dem Haus mitteilen kann, wie es zum aktuellen Zeitpunkt auf ihn reagieren soll. Der Gemütszustand erschien mir da sinnvoll. Beispielsweise könnten die HUE LED Lampen entsprechend andere Farben annehmen, wenn ich gestresst bin oder wenn ich mich entspannen möchte. Ebenso wäre es denkbar, dass die Farben sich entsprechend verändern, wenn ich einen bestimmten Raum betrete oder verlasse (wobei das automatische Tracking da wohl noch schwierig ist; iBeacons könnten hier die Lösung sein, aber ich hab noch nichts damit probiert). Man kann aber auch die Heizung unterschiedlich warm stellen; wenn mir kalt ist, wird die Heizung eben höher gestellt und die LEDs werden etwas 'wärmer' gestellt oder so  8)
Wenn ein Mitbewohner noch "sleepy" ist könnte man genauso das Licht anders dimmen, als wenn er bereits voll wach ist. Ich glaub da kann man noch lange drüber nachdenken und irgendwem wird immer etwas Neues einfallen. Ich bin da sehr gespannt auf die Kreativität anderer!


Der State gotosleep ist sinnvollerweise nicht automatisch zu setzen (mir fällt keine zuverlässige Methode ein; Drucksensoren sind wirklich extremer overkill und außerdem bin ich ja dann schon am/im Bett...).
Gedacht ist, dass man den Status gotosleep manuell dann setzt (über Handy, Tablet, gekoppelte Fernbedienung, Taster oder whatever), wenn man beispielsweise im Wohnzimmer sitzt und sich bettfein machen will. Die technischen Geräte (TV etc) könnten ausgeschaltet werden und eine bettfreundliche Lichtstimmung könnte abgerufen werden (bei mir wird die HUE Lampe am Nachttisch auf 2000 Kelvin gestellt), die einen zunächst ins Bad und anschließend ins Bett weiter trägt. Je nach Lebensgewohnheit kann man das unterschiedlich handhaben; wenn man immer zusammen ins Bett geht, kann man das auf Grundlage einer RESIDENTS Gruppe schalten, man kann aber auch pro Mitbewohner entsprechend etwas schalten. Der TV sollte vielleicht an bleiben, wenn man schonmal vor geht und die Lichtstimmung sollte nur außerhalb vom Wohnzimmer angepasst werden etc....
Im Bett angekommen habe ich rechts und links jeweils einen Funk-Taster installiert. Die obere Taste steuert die HUE Nachttischlampe (welche mich morgens auch mit 5300 Kelvin weckt). Die untere Taste schaltet vom Status gotosleep weiter zu asleep. Danach geht per Watchdog nach 5 Sekunden das Licht aus und der MP3 Funkgong wünscht mir eine gute Nacht. Morgens wird der gleiche Schalter betätigt, sobald ich am Aufwachen bin und der Status wechselt zu "awoken". Das wäre der Zeitpunkt Kaffeemaschine zu starten, die Lichtstimmung etwas vom Aufwachlicht anzupassen, Musik einzuschalten oder was auch immer. Nach 75 Minuten wechselt der Status bei mir dann automatisch nach "home" weil ich annehme, dass ich dann "betriebsbereit" bin  ;)


Darin hinein spielt bei mir auch noch der Haus-Status. Das Modul dafür schreibe ich gerade noch, es wird wohl umfangreicher als ich zunächst dachte. Grundsätzlich unterscheide ich bei mir jetzt schon zwischen Morgen, Tag, Abend und Nacht. Die Stati werden teilweise durch Weckprogramme beeinflusst. Das erkläre ich aber ein andermal und vor allem dann, wenn ich das HOMESTATE Modul entsprechend so habe. Mein eigener Workflow wird sich da wohl auch nochmal ändern. Wie das so ist, man muss sich erstmal selbst klar werden, bevor man es dann in ein Modul (was ja auch andere Wünsche als nur meine berücksichtigen können muss) gießt und es der Weltöffentlichkeit preis gibt  ;D
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: justme1968 am 09 Februar 2014, 13:28:23
das mit dem drucksensor ist gar nicht zum grinsen. ich denke das ist eine sehr einfache methode automatisch rauszufinden ob jemand im bett liegt. ich hab schon ein paar mal gelesen das dazu z.b. eine sitzbelegungsmatte aus einem autositz verwendet wird.

gruss
  andre
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: fhainz am 09 Februar 2014, 13:30:08
Sowas hab ich mir auch schon überlegt. Ich denke da eher an einen endschalter der an den lattenrost montiert wird.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 09 Februar 2014, 13:31:47

das mit dem drucksensor ist gar nicht zum grinsen. ich denke das ist eine sehr einfache methode automatisch rauszufinden ob jemand im bett liegt. ich hab schon ein paar mal gelesen das dazu z.b. eine sitzbelegungsmatte aus einem autositz verwendet wird.


Das kommt wohl drauf an, ob man sich im Schlafzimmer nur zum Schlafen aufhält (und ich meine nichtmals unbedingt zwischenmenschliche Aktivitäten  ;) ). In meinem Münchner Apartment nutze ich effizienterweise das Schlafzimmer tagsüber auch als Arbeitszimmer. Da kommt es auch mal vor, dass man sich einfach so aufs Bett setzt oder dort Dinge ablegt. Eine Druckmatte ist also nicht für jeden etwas denke ich  8)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: justme1968 am 09 Februar 2014, 13:37:50
nicht alleine. aber mit fhem zusammen. ich mache z.b. nachts meine handy aus. mit der matte und dem handyzustand könnte ich perfekt zwischen nicht zu hause und schlafen unterscheiden.

alleine nützt es also nicht unbedingt aber in kombination mit tageszeit oder helligkeit.

und mir fällt noch einiges ein. von licht/radio im bad einschalten beim aufstehen, ...

gruss
  andre

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 09 Februar 2014, 13:49:31
Die Anwesenheit funktioniert bei uns mit Bluetooth sehr gut, der watchdog steht auf 4 Minuten und es gibt keine unberechtigten schaltvorgänge... Problematisch ist vielleicht wenn mal der Akku leer geht...

Als nächstes möchte ich die Heizung mit ins Spiel bringen, mir per Speak verpasste Anrufe sagen lassen und den Anrufbeantworter aktiv schalten wenn ich nicht da bin. Ein Mood Sport wäre noch toll, wenn ich nach dem joggen oder Radfahrern heimkomme kann das Bad ja schon dusch temperiert sein.

Unterschiedlich playlisten je nachdem wer heimkommt... Tolle Möglichkeiten gibt es...

Wenn André eh gerade mitliest... Gibt es eine Möglichkeit HUE Dummys zu erstellen? Ich habe eine logitech harmony ultimate - die kann HUE schalten - jeder Aktion einen Dummy zuweisen um FHEM darüber zu informieren was Multimedial gerade läuft wäre cool.
Ich glaube aber ich komme einfach nicht drumrum in irgendeiner weise noch IR schalten ins FHEM zu bringen. Dann könnte ich ja auch direkt auf die harmony lauschen und die Aktionen mitlesen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 09 Februar 2014, 13:52:30
nicht alleine. aber mit fhem zusammen. ich mache z.b. nachts meine handy aus. mit der matte und dem handyzustand könnte ich perfekt zwischen nicht zu hause und schlafen unterscheiden.

alleine nützt es also nicht unbedingt aber in kombination mit tageszeit oder helligkeit.


Mein Leben ist da leider nicht so geregelt, als dass ich alle Eventualitäten in FHEM einprogrammieren könnte  ;)
Ich arbeite eben selbst und ständig, wie man so schön sagt...
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: justme1968 am 09 Februar 2014, 14:08:29
eben weil es nicht geregelt ist reicht ja ein input nicht. aber wenn man mehrere zusammen fasst kann man doch einiges abdecken. mal so als gedankenanstoss weil es mir gerade einfällt: vielleicht wäre das überhaupt noch etwas für diese module. meherer solcher inputs für eine person zusammen fassen. vielleicht mit gewichtung und daraus einen gesamt zustand zu machen. also z.b. die matte und das handy und den taster an der wand plus tageszeit plus zustand in der nacht davor.

@der-Lolo: das mit dem dummy verstehe ich nicht. wenn die harmony deine hue lampen schaltet kannst du das über notifys an den ganz normalen hue devices feststellen. devices die nicht wirklich vorhanden sind kann auch die harmony nicht schalten. der knackpnkt ist aber das die rückmeldung von der bridge asynchron ist. es dauert also immer das polling intervall bis du den status in fhem siehst.

das mit ir ist nicht so schwierig: das geht z.b. auch mit einem panstamp.

gruss
  andre
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 09 Februar 2014, 14:31:20
Die ultimate triggert Aktionen, Fernsehen z.b. Ist tv an Verstärker an, dreambox an hdmi2 wählen.
Bluray ist z.b. TV an Verstärker an, dreambox an HDMI 3 wählen.

Jeder Aktion kann hue zugeordnet werden - wenn ich nun bluray wähle und hue Dummyxx dieser Aktion hinzufüge wüsste fhem was gerade abgeht.
Ok, beim Fernsehen oder bluray ist es nicht relevant weil ich ja auf PRESENCE der Geräte gehen kann...
Aber bei cd oder lp hören bekommt fhem davon nichts mit...

IR ist mir zu bastellastig - oder hast du etwas verkaufsbereites in der Schublade? ;-)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: justme1968 am 09 Februar 2014, 15:08:47
das mit dem dummy verstehe ich immer noch nicht. fhem kann keine events für nicht vorhandene hue geräte empfangen. und die vorhandenen kannst du ganz normal per notify überwachen.

gruss
  andre
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: det. am 09 Februar 2014, 15:51:13
Hallo Loredo,
Danke für Deine ausführliche Antwort. Eines ist mir da erneut klar geworden, die Menschen sind verschieden. Ich stamme noch von der Sorte ab, wo Weckerklingeln bedeutet, rausspringen - waschen - schwarzen Kaffee hinterkippen und spätestens 10 min nach dem Klingeln im Auto auf Arbeit fahren. Snozzeln kam Jahrzehnte später und Umwelt hatten wir da auch keine, da hieß das noch einfach Natur. (O.T.)
Ich denke aber, hier entspinnt sich eine interessante Diskussion, was man alles machen kann. Bin sehr gespannt, da fällt mir gerade ein - die Nutzung der Withings Waage nach 22 Uhr ist ein sicheres. Indiez, dass es nach einem ausgiebigen Wannenbad gotosleep geht. Kann ich in meiner Familie also doch automatisch schalten und wenn GUEST ( zB. die Kinder ) da sind deaktivieren.
Ich habe die PRESENCE übrigens nicht auf der FB, sondern mit Bluetooth 4 Stick im Cubie2. Funktioniert bis auf die Erkennungshysterese beim Heimkommen prima. Das Problem mit gleichzeitigem Telefonieren beim Zonenwechsel hatte ich noch nicht, mglw. weil ich im Auto über Multicard mit dem Autotelefon telefoniere. Kann sein, das iPhone sendet da parallel.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 09 Februar 2014, 16:05:47
Die ultimate triggert Aktionen, Fernsehen z.b. Ist tv an Verstärker an, dreambox an hdmi2 wählen.
Bluray ist z.b. TV an Verstärker an, dreambox an HDMI 3 wählen.

Jeder Aktion kann hue zugeordnet werden - wenn ich nun bluray wähle und hue Dummyxx dieser Aktion hinzufüge wüsste fhem was gerade abgeht.
Ok, beim Fernsehen oder bluray ist es nicht relevant weil ich ja auf PRESENCE der Geräte gehen kann...
Aber bei cd oder lp hören bekommt fhem davon nichts mit...

IR ist mir zu bastellastig - oder hast du etwas verkaufsbereites in der Schublade? ;-)


Klingt aber ehrlich gesagt eher ein wenig so, als wolltest du die Harmony bald mal durch FHEM ersetzen  ;)
(ok, zugegeben, dafür muss optimaler Weise alles per Netzwerk erreichbar sein...)


Danke für Deine ausführliche Antwort. Eines ist mir da erneut klar geworden, die Menschen sind verschieden. Ich stamme noch von der Sorte ab, wo Weckerklingeln bedeutet, rausspringen - waschen - schwarzen Kaffee hinterkippen und spätestens 10 min nach dem Klingeln im Auto auf Arbeit fahren. Snozzeln kam Jahrzehnte später und Umwelt hatten wir da auch keine, da hieß das noch einfach Natur. (O.T.)


Naja, wenn auf mich ein 12h Stresstag wartet (und das ist momentan täglich der Fall...), dann will ich wenigstens noch angenehm geweckt werden und mich nicht schon am frühen morgen stressen lassen  :D
Wenn ich den Status "awoken" setze heißt das ja nicht, dass ich da nicht aufstehe. Es ist bei mir der Status "ich bin jetzt aufgestanden, Haus mach mal was!". Da ich aber nicht fix und fertig wie aus dem Ei gepellt aufstehe, bleibt der Status bei mir noch eine Weile auf "awoken", während ich Kaffee trinke und News lese. Auch bleibt der Rollladen solange noch halb geschlossen, damit ich mich unbeobachtet von der Dusche zum Schrank bewegen kann  ;D
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: HolyMoly am 11 Februar 2014, 17:34:12
Zitat
Über das Attribut r*_locationHome kann man mehrere Orte durch Leerzeichen getrennt eingeben, bei dessen erreichen der Status automatisch auf "home" gesetzt werden soll.
Über das Attribut r*_locationUnderway kann man mehrere Orte durch Leerzeichen getrennt eingeben, bei dessen verlassen der Status automatisch auf "absent" gesetzt werden soll.

Kann diese Attribute im Webinterface weder bei Geofancy noch bei Residents finden...gibts die noch?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: det. am 11 Februar 2014, 17:50:42
(http://forum.fhem.de/webkit-fake-url://9FADD6CA-ADC8-4C14-B006-36A83AE1DC3F/imagejpeg)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 11 Februar 2014, 22:49:32
Kann diese Attribute im Webinterface weder bei Geofancy noch bei Residents finden...gibts die noch?


Die Attribute machen nur bei ROOMMATE und GUEST Objekten Sinn, daher gibt es sie in RESIDENTS nicht.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: HolyMoly am 12 Februar 2014, 08:31:58
Hallo Julian,

ich hab gedacht ROOMMATE ist für Mitbewohner d.h. weniger Rechte, weniger Daten sammeln etc. und GUESTS noch eine Stufe drunter.
Daher habe ich keine Roommates angelegt, nur Residents=Bewohner. Dabei macht es eigentlich nur Sinn eine Residents Instanz zu haben pro Haushalt. Irgendwie ist da die Namensgebung nicht intuitiv. Vielleicht sollte Residents Household heißen und Roommate Resident.

Lg Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 12 Februar 2014, 09:36:12
ich hab gedacht ROOMMATE ist für Mitbewohner d.h. weniger Rechte, weniger Daten sammeln etc. und GUESTS noch eine Stufe drunter.
Daher habe ich keine Roommates angelegt, nur Residents=Bewohner. Dabei macht es eigentlich nur Sinn eine Residents Instanz zu haben pro Haushalt. Irgendwie ist da die Namensgebung nicht intuitiv. Vielleicht sollte Residents Household heißen und Roommate Resident.


Das geht eigentlich aus der Dokumentation klar hervor. RESIDENTS heißt übersetzt Bewohner und stellt somit die Summe aller Bewohner dar (bzw. eine Bewohnergruppe). ROOMMATE heißt Mitbewohner und ist also die tatsächliche Person, die dauerhaft hier wohnt. Sie kann Mitglied einer oder mehrerer Bewohnergruppen sein. GUEST Objekte sind ähnlich zu ROOMMATE Objekten, verhalten sich aber in einigen Punkten unterschiedlich.


Die Verwirrung kommt wohl auch daher, dass wir im Deutschen nicht so genau zwischen Bewohner und Mitbewohner und deren Ein- und Mehrzahl unterscheiden... ich hoffe aber es ist nun klarer :-)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: svenson08 am 15 Februar 2014, 15:06:42
Wenn ich die nächsten Tage mal dazu komme wollte ich deine Module mal für meinen Gebrauch testen, das könnte genau das sein was ich suche/benötige.

Eine Bitte, oder eine Idee von mir. Könntest du evtl eine Muster Konfiguration bauen die in die Fhem.Demo.cfg übernommen werden könnte? Das macht es viele nicht nur transparenter.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 15 Februar 2014, 15:10:10

Eine Bitte, oder eine Idee von mir. Könntest du evtl eine Muster Konfiguration bauen die in die Fhem.Demo.cfg übernommen werden könnte? Das macht es viele nicht nur transparenter.



Meinst du zusätzlich zu den Beispielen in der Kommando-Referenz?
http://fhem.de/commandref.html#ROOMMATE (http://fhem.de/commandref.html#ROOMMATE)


Was schwebt dir denn vor?


Das Beispiel "Complex family structure" sollte eigentlich schon alles abdecken (zusätzlich zum Beispiel aus dem RESIDENTS Modul, aber das sollte wohl jeder hinbekommen). Oder sprichst du vom Zusammenspiel mit GEOFANCY? Auch da muss man eigentlich nur Copy&Paste das Beispiel kopieren und ggf. mal den Wiki Artikel dazu lesen ;-)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 15 Februar 2014, 15:42:35
Das folgende Beispiel zeigt eine 4-köpfige (potentiell durchschnittliche) Familie :-)

#----------------------
# Define groups Residents, Parents, Children and Guests
define rgr_Residents RESIDENTS
attr rgr_Residents alias Residents
attr rgr_Residents sortby 1

define rgr_Parents RESIDENTS
attr rgr_Parents alias Parents
attr rgr_Parents sortby 2

define rgr_Children RESIDENTS
attr rgr_Children alias Children
attr rgr_Children sortby 3

define rgr_Guests RESIDENTS
attr rgr_Guests alias Guests
attr rgr_Guests sortby 4


#----------------------
# Add residents to groups
define rr_Manfred ROOMMATE rgr_Residents,rgr_Parents
attr rr_Manfred rr_locationHome Living Bedroom Kitchen Bathroom
attr rr_Manfred rr_locationWayhome Work Sport Parents herParents
attr rr_Manfred rr_passPresenceTo rg_Guest1


define rr_Lisa ROOMMATE rgr_Residents,rgr_Parents
attr rr_Lisa rr_locationHome Living Bedroom Kitchen Bathroom
attr rr_Lisa rr_locationWayhome Work Sport Parents hisParents
attr rr_Lisa rr_passPresenceTo rg_Guest2

define rr_Rick ROOMMATE rgr_Residents,rgr_Children
attr rr_Rick rr_locationHome Living Kitchen Bathroom myroom
attr rr_Rick rr_locationWayhome School Sport GrandparentsMom GrandparentsDad

define rr_Alex ROOMMATE rgr_Residents,rgr_Children
attr rr_Alex rr_locationHome Living Kitchen Bathroom myroom
attr rr_Alex rr_locationWayhome School Sport GrandparentsMom GrandparentsDad

define rg_Guest1 GUEST rgr_Residents,rgr_Guests

define rg_Guest2 GUEST rgr_Residents,rgr_Guests


#----------------------
# Define geofancy device and rename iPhone UUIDs to Usernames
# Geofency Webhhook address: http://myhome.dyndns.org:8083/fhem/geodefine geofancy GEOFANCY geo
attr geofancy devAlias A1234567-1234-ABCD-FFFF-123456789ABC:Manfred B1234567-1234-ABCD-FFFF-123456789ABC:Lisa C1234567-1234-ABCD-FFFF-123456789ABC:Rick D1234567-1234-ABCD-FFFF-123456789ABC:Alex
attr geofancy room System

#----------------------
# Notifies for roommate location updates via GEOFANCY
define n_rr_Manfred.location notify geofancy:currLoc_Manfred.* set rr_Manfred location $EVTPART1
define n_rr_Lisa.location notify geofancy:currLoc_Lisa.* set rr_Lisa location $EVTPART1
define n_rr_Rick.location notify geofancy:currLoc_Rick.* set rr_Rick location $EVTPART1
define n_rr_Alex.location notify geofancy:currLoc_Alex.* set rr_Alex location $EVTPART1


#----------------------
# iPhone Geofency.app webhook definitions:

#
# Manfred:
# - home > home address with low radius 100m
# - wayhome > home address with high radius of 5000m
# - Work > work address with low radius 200m
# - Sport > sport club address with low radius 100m
# - Parents > parents home address with low radius 100m
# - herParents > home address of Lisa's parents with low radius 100m
# - Living > Living room's iBeacon (with webhook for entry only)
# - Bedroom > Bedroom's iBeacon (with webhook for entry only)
# - Kitchen > Kitchen's iBeacon (with webhook for entry only)
# - Bathroom > Bathroom's iBeacon (with webhook for entry only)
#
# Lisa:
# - home > home address with low radius 100m
# - wayhome > home address with high radius of 5000m
# - Work > work address with low radius 200m
# - Sport > sport club address with low radius 100m
# - Parents > parents home address with low radius 100m
# - hisParents > home address of Manfred's parents with low radius 100m
# - Living > Living room's iBeacon (with webhook for entry only)
# - Bedroom > Bedroom's iBeacon (with webhook for entry only)
# - Kitchen > Kitchen's iBeacon (with webhook for entry only)
# - Bathroom > Bathroom's iBeacon (with webhook for entry only)
#
# Rick:
# - home > home address with low radius 100m
# - wayhome > home address with high radius of 5000m
# - School > School address with low radius 200m
# - Sport > sport club address with low radius 100m
# - GrandparentsMom > mom's parents home address with low radius 100m
# - GrandparentsDad > dad's parents home address with low radius 100m
# - Living > Living room's iBeacon (with webhook for entry only)
# - Bedroom > Bedroom's iBeacon (with webhook for entry only)
# - Kitchen > Kitchen's iBeacon (with webhook for entry only)
# - Bathroom > Bathroom's iBeacon (with webhook for entry only)
# - myroom > Rick's room iBeacon (with webhook for entry only)
#
# Alex:
# - home > home address with low radius 100m# - wayhome > home address with high radius of 5000m# - School > School address with low radius 200m# - Sport > sport club address with low radius 100m# - GrandparentsMom > mom's parents home address with low radius 100m# - GrandparentsDad > dad's parents home address with low radius 100m# - Living > Living room's iBeacon (with webhook for entry only)# - Bedroom > Bedroom's iBeacon (with webhook for entry only)# - Kitchen > Kitchen's iBeacon (with webhook for entry only)# - Bathroom > Bathroom's iBeacon (with webhook for entry only)# - myroom > Alex' room iBeacon (with webhook for entry only)


Folgende Annahmen sind darin berücksichtigt:
Über den Status der Gruppen-Objekte rgr_Residents, rgr_Parents, rgr_Children und rgr_Guests lassen sich dann über entsprechende Trigger verschiedene Aktionen in FHEM anstoßen. Beispielsweise kann die Heizung heruntergefahren werden, wenn rgr_Residents auf absent ist bzw. wieder hochgefahren werden, sobald das Reading "wayhome" auf 1 springt. Auch könnte der Fernseher nur funktionieren, wenn die Eltern zu Hause sind. Die Heizung könnte wärmer eingestellt sein, wenn Gäste im Haus sind, damit sich diese wohler fühlen. Etc etc ...

Außerdem werden über die Readings natürlich auch verschiedene Statistiken bereitgestellt wie Dauer der Abwesenheit (pro Person, pro Personengruppe und generell wie lange das Haus verlassen war). Umgekehrt das gleiche für die Anwesenheitsdauer. Wenn die Bewohner zusätzlich (z.B. über einen Taster oder eben übers iPhone per Weboberfläche) anzeigen, wann sie schlafen gehen und wann sie aufgewacht sind, steht auch die Schlafdauer entsprechend zur Verfügung. Die ganzen Statistiken können natürlich per Plot ausgewertet werden (wobei ich das noch nicht gemacht habe).
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: svenson08 am 15 Februar 2014, 16:02:48
Sehr schön. So was in der Richtung hab ich gemeint. Kannst evtl. Mal Rudi darauf ansprechen eine solche Musterkonfiguration in die fhem.Demo.cfg zu übernehmen. Das halte ich für wichtig, da sich damit anderen, Neulingen, leicht zeigen lässt was mit fhem alles möglich ist.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 15 Februar 2014, 16:31:27
Ich habe mal drauf hingewiesen.

Was das gerade noch in Vorbereitung befindliche Modul HOMESTATE dann z.B. noch bieten wird ist, dass man sehen kann, welche Person sich in welchem Raum aufhält bzw. wie viele Personen sich in dem jeweiligen Raum aufhalten.

Ansonsten habe ich gerade noch folgendes für HOMESTATE gesammelt:


# season:spring,summer,autumn,winter
# mode:morning,day,evening,night
# shadowing:auto,on,manual,off
# heating:auto,on,manual,off
# ventilation:auto,on,manual,off
# cooling:auto,on,manual,off
# presenceSim:auto,on,off
# durPresence:TIME
# durAbsence:TIME
# durSleep:TIME
# roomXYZ: NUMBER
# roomXYZ_presence: present|absent
# roomXYZ_residents: Res1,Res2,Res3
# secSmoke:alarm,none
# secBurglary:alarm,none
# secDoors:secure,insecure
# secWindows:secure,insecure
# secShutters:secure,insecure
# secLights:on,off
# residentsPresence:present,absent
# residentsState:home,gotosleep,asleep,awoken,absent,gone
# state:?


Wie ich den Status aus diesen Werten berechne weiß ich noch nicht genau.
Sicher ist aber schon, dass ich wohl für die bessere Darstellung und Bedienbarkeit einzelne Readings direkt mit einem normalen Dummy-Device verknüpfen werde. Man kann dann in der Webdarstellung unter dem eigentlichen HOMESTATE Eintrag auch die einzelnen Punkte wie Modus etc. einzeln sehen und einstellen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: justme1968 am 15 Februar 2014, 18:14:20
schau dir mal readingsProxy an. vielleicht ist das besser geeignet als ein dummy. das von hand hin und her kopieren per notify entfällt damit.

gruss
  andre
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 15 Februar 2014, 18:17:44
schau dir mal readingsProxy an. vielleicht ist das besser geeignet als ein dummy. das von hand hin und her kopieren per notify entfällt damit.


Ja, readingsGroup und readingsProxy wollte ich mir dafür anschauen. Bin aber nicht sicher, ob sich das so direkt eignet, damit es sich optisch auch so einbindet, wie ich mir das vorstelle (ohne es mir angesehen zu haben). Externe Notifies brauche ich auch bei den Dummies nicht; die kann ich zentral aus dem HOMESTATE Modul beobachten und entsprechend fernsteuern. Ich würde sie quasi nur als leere Hülle missbrauchen ;-)
Ähnlich würde ich wenn dann auch mit readingsProxy/readingsGroup verfahren wollen, damit es sich gut integriert. Wenn das nicht so geht, werde ich es lieber anders umsetzen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: rudolfkoenig am 16 Februar 2014, 10:37:13
Zitat
Ich habe mal drauf hingewiesen.

Stimmt.
Fuer fhem.demo.cfg brauche ich etwas, was ohne Hardware und zusaetzlichen Perl-Modulen auskommt, und idealerweise Lampen/Raeume/etc der bisherigen demo Konfiguration verwendet. Und dem Benutzer im Frontend ausser der puren Definition irgendetwas zeigt.
Idealerweise koennte diese Konfiguration auf fhem.de laufen, so dass jeder ein bisschen damit herumspielen kann.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 16 Februar 2014, 13:27:51

Stimmt.


Das war vielleicht etwas forsch es über die Moderator-Funktion zu tun, andererseits wollte ich dich nicht privat anschreiben. Ein Dilemma, dass es keinen roten "Rudi" Knopf gibt (und ja, er würde sicherlich missbraucht werden  :-\ )


Fuer fhem.demo.cfg brauche ich etwas, was ohne Hardware und zusaetzlichen Perl-Modulen auskommt, und idealerweise Lampen/Raeume/etc der bisherigen demo Konfiguration verwendet. Und dem Benutzer im Frontend ausser der puren Definition irgendetwas zeigt.
Idealerweise koennte diese Konfiguration auf fhem.de laufen, so dass jeder ein bisschen damit herumspielen kann.


Mein Beispiel funktioniert ohne Hardware und auch ohne zusätzliche Perl-Module. Bleibt vielleicht dann nur noch die Verknüpfung mit den anderen Demo-Devices.
Was man leider nicht simulieren kann ist die Schaltung über ein iPhone, das man mit sich herum trägt. Aber man kann natürlich die Anwesenheit der Bewohner verändern und schauen was passiert. Ich würde folgendes einbauen:

- alles ausschalten, sobald kein Bewohner mehr zuhause ist
- einschalten einer Lampe, sobald einer der Bewohner nach Hause kommt

Das zweite Beispiel ist natürlich nicht wirklich aus der Praxis. Wenn wir noch eine Heizung hätten, die an und aus ginge, dann wäre das wohl etwas näher an der Wirklichkeit. Ich weiß aber nicht, ob man das sinnvoll simuliert bekommt ???


Vorschlag: Ich erweitere die fhem.demo.cfg einmal und du schaust dir hinterher an, ob du das Beispiel für sinnvoll hältst?




Gruß
Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 16 Februar 2014, 14:28:58
Im Zusammenhang mit dem Callmonitor ist mir noch was eingefallen - wenn der Nachwuchs schläft - blinken statt klingeln...
Schade das unsere Sprechanlage nicht in FHEM integriert ist...
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: svenson08 am 16 Februar 2014, 23:04:27
Ich bin fleißig mit deinen Modulen am experimentieren. Eins finde ich nicht ganz so schön. Dem Umstand geschuldet das nicht alle in meinem Haushalt Englisch können, wäre es schön es gäbe ein Attribut mit dem eigene Übersetzungen möglich wären um den Status entsprechend einzudeutschen. Schließlich möchte das alle Bewohner etwas von FHEM haben und nicht nur ich....

Mein Nachbar, den ich zu meinem leidwesen von FHEM begeistern konnte, hat das Problem das dessen Frau kein Englisch kann und dort wäre auch eine rein deutsche Übersetzung nicht zielführend.

Ich finde es allgemein schade das in FHEM keine Übersetzungsmöglichkeiten in andere Sprachen vorhanden sind, aber das gehört hier nicht hin.

Gruß Svenson
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Zephyr am 28 Februar 2014, 11:33:15
Ich bin begeistert! Gestern die Modulgruppe entdeckt und gleich damit rumgespielt. Bisher hatte ich das alles über Dummys, Notifier und LightScene gemacht. War ziemlich umständlich und alles andere als praktikabel.

Ein fettes Danke für die Arbeit!
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 28 Februar 2014, 11:35:03
Freut mich, wenn es auch andere nützlich finden :-)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: betateilchen am 28 Februar 2014, 11:37:04
jetzt musst Du nur noch die commandref zu Deinen Modulen in Ordnung bringen ;)

http://forum.fhem.de/index.php/topic,20752.0.html
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 28 Februar 2014, 11:38:10
Ich bin fleißig mit deinen Modulen am experimentieren. Eins finde ich nicht ganz so schön. Dem Umstand geschuldet das nicht alle in meinem Haushalt Englisch können, wäre es schön es gäbe ein Attribut mit dem eigene Übersetzungen möglich wären um den Status entsprechend einzudeutschen. Schließlich möchte das alle Bewohner etwas von FHEM haben und nicht nur ich....

Mein Nachbar, den ich zu meinem leidwesen von FHEM begeistern konnte, hat das Problem das dessen Frau kein Englisch kann und dort wäre auch eine rein deutsche Übersetzung nicht zielführend.

Ich finde es allgemein schade das in FHEM keine Übersetzungsmöglichkeiten in andere Sprachen vorhanden sind, aber das gehört hier nicht hin.

Ja, für meine zweite Installation bei meinen Eltern hätte ich auch gerne möglichst viel eingedeutscht. Bei den Stati scheitert es allerdings, ja. Ich überlege mir bei Gelegenheit mal, wie man das am klügsten löst. Ich denke ich werde schauen, ob ich global für alle Module etwas direkt in FHEM hinzufügen kann, so dass man bei jedem Modul ein Attribut hat, mit dem man Aliase verwalten kann (ähnlich dem, wie sich die Kanal-Eingänge beim ONKYO_AVR Modul umbenennen lassen).
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 28 Februar 2014, 11:39:03
jetzt musst Du nur noch die commandref zu Deinen Modulen in Ordnung bringen ;)

http://forum.fhem.de/index.php/topic,20752.0.html (http://forum.fhem.de/index.php/topic,20752.0.html)


Oh, danke. Darüber habe ich gar keine Mail-Benachrichtigung bekommen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Zephyr am 28 Februar 2014, 22:29:36
Puuuh. Also nach vielem Herumprobieren komme ich nicht weiter. Eigentlich wollte ich mit einem Notify eine bestimmet Lichtszene setzen, wenn sich der STATE einer Residentsgroop geändert hat.
Im Moment probiere es mit diesem Code:

#damit ich überprüfen kann, ob der Statusänderung wirklich kam, erst mal ein Dummy anlegen
define Testdummy dummy

#Residentgroop
define rgrBewohner RESIDENTS

#einen Bewohner anlegen
define Karsten ROOMMATE

#nun das Notify
define notiWohnungStatus rgrBewohner:state.* set Testdummy $EVTPART1

Allerdings kommt das Event scheinbar gar nicht an...

Das hier funktioniert auch nur bedingt. Es liefert nämlich alles mögliche zurück, aber nicht den state:
define notiWohnungStatus rgrBewohner.*:.* set Testdummy $EVENT
Wo liegt denn hier mein Fehler?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 01 März 2014, 16:15:45

Ich fürchte du hast die Kommando-Referenz nicht genau gelesen  :)

Daraus ist ersichtlich, dass du einem ROOMMATE Device auch sagen musst, ob und in welche Gruppe(n) es denn dazu gehört. Das fehlt bei dir, deshalb wird der Status auch nicht hoch aggregiert und dein RESIDENTS Device ist nutzlos.
Der Sinn dahinter ist, dass man ROOMMATE autark betreiben kann (machst du gerade), oder aber das Device auch Mitglied in mehreren Gruppen gleichzeitig sein kann. Dazu gibt es weiter oben auch ein komplexes Beispiel einer Familie.

#Residentgroop
define rgrBewohner RESIDENTS

#einen Bewohner anlegen
define Karsten ROOMMATE rgrBewohner


Das RESIDENTS Modul macht es dir eigentlich einfach, über die Oberfläche direkt einen neuen Bewohner hinzuzufügen. Schau mal nach dem Befehl addRoommate.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Zephyr am 01 März 2014, 17:26:58
Verzeih, diesen Schritt hatte ich nicht gepostet, ihn aber durchgeführt. In der FHEM Config ist er eingetragen. Und das RESIDENTS Modul zeigt mir seine Kindobjekte auch an. Das RESIDENTS Modul bekommt auch den Status in Abhängigkeit des Bewohners den Status korrekt gesetzt. Es sieht nur so aus als ob ich ihn nicht auslesen kann.

So sieht es bei mir aus:

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 01 März 2014, 17:44:27
Ich glaube du möchtest nochmals die Kommando-Referenz für das NOTIFY Modul lesen ;)


define n_rgrBewohner.present notify rgrBewohner:presence:.present set Testdummy "Bewohner sind da!"

oder


define n_rgrBewohner notify rgrBewohner:state:.* set Testdummy $EVTPART1

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: fh168 am 01 März 2014, 17:52:31
Hallo Loredo,

darf ich fragen, wo man die iBeacons kaufen kann? Im Code Antwort #60 ist davon die Rede.

LG
/robin
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Zephyr am 01 März 2014, 18:06:13
Hallo Loredo,

ich hatte auch den Wikiartikel zum Notify-Modul "verspeist" und war mir relativ sicher, dass ich das richtig mache.
Leider funktionieren auch Deine beiden Vorschläge nicht. Was ich durch Herumprobieren herausgefunden habe ist, dass zum Beispiel der Status "lastState" sehr wohl an das Dummyobjekt übergeben wird. Wohl aber nicht der "state". Nun bin ich vollends verwirrt. Haut bei mir in der Installation einfach etwas nicht hin?

define n_rgrBewohner notify rgrBewohner:lastState:.* set Testdummy %EVTPART1
Ich bin völlig ratlos.

Zusatz:

Mit einer einfachen ReadingsGroup bekomme ich den Status von rgrBewohner allerdings zuverlässig ausgelesen.

define rgBewohner readingsgroup rgrBewohner:state
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Spezialtrick am 01 März 2014, 21:34:14
Vielen Dank für dieses geniale Modul! Zu Beginn dachte ich, dass es für mich zu speziell und zu sehr in die Tiefe geht, aber seit gestern weiß ich, dass es fast genau das ich was ich für mich realisieren wollte. ^^

Habe gestern und heute ein wenig rum probiert und es funktioniert wirklich gut. Ich habe die Anwesenheit von 2 Personen per Bluetooth gekloppt und schalte damit die Alarmanlage scharf sobald der Home State von "home" auf "absent" umspringt. Das klappt soweit sehr gut. Ich würde dies jedoch noch ein wenig erweitern. Die Alarmanlage sollte nämlich auch scharf sein, wenn der Status auf "gone" übergeht.

Außerdem sollte sich Abends zu einer bestimmten Uhrzeit der Status automatisch auf "gotosleep" stellen und damit wieder die Alarmanlage scharf stellen.

Hier ist ein Auszug meines Code:

define Alarmanlage dummy
attr Alarmanlage group Status der Alarmanlage
attr Alarmanlage room Alarmanlage
define Alarmanlage_Scharf notify Home:absent.* { fhem ("set Alarmanlage on") if (Value("Alarmanlage") ne "on") }
attr Alarmanlage_Scharf room Alarmanlage
define Alarmanlage_Unscharf notify Home:home.* { fhem ("set Alarmanlage off") }
attr Alarmanlage_Unscharf room Alarmanlage

Muss ich nun für jeden einzelne Status des Home States einen neues Notify anlegen oder lässt sich das irgendwie eleganter lösen?

Kurzer Zusammenfassung der Schaltstände:

home          -   Schaltung per Bluetooth   -   Alarmanlage AUS
gotosleep    -   Schaltung per Uhrzeit       -   Alarmanlage AN
absent        -   Schaltung per Bluetooth   -   Alarmanlage AN
gone           -   Schaltung per Uhrzeit       -   Alarmanlage AN
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: marvin78 am 02 März 2014, 08:44:24
Vorab. Das Modul ist sehr hilfreich und erspart mir einiges an Ärger mit Dummys. Danke dafür.

Aus welchem Grund können Gäste nicht den Status "gone" haben? Es gibt jedoch das AutoGoneAfter Attribut. Schon dass ein Gast nicht "gone" sein kann ist in sich unlogisch, oder verstehe ich das falsch?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Zephyr am 02 März 2014, 20:45:59
Kann es sein, dass der state nicht korrekt gemeldet wird?
Ich habe mal auf der Telnetkonsole ein inform on gemacht und vom Roommate Karsten den Status nach gotosleep, absent und home verändert.

Folgendes wirft inform on aus:
inform on
RESIDENTS rgrBewohner residentsHome: 0
RESIDENTS rgrBewohner residentsGotosleep: 1
RESIDENTS rgrBewohner lastState: home
RESIDENTS rgrBewohner gotosleep
RESIDENTS rgrBewohner lastActivity: gotosleep
RESIDENTS rgrBewohner lastActivityBy: Karsten
ROOMMATE rr_Karsten lastState: home
ROOMMATE rr_Karsten gotosleep
ROOMMATE rr_Karsten lastMood: calm
ROOMMATE rr_Karsten mood: sleepy
dummy Testdummy "Keiner da!"
RESIDENTS rgrBewohner residentsTotalPresent: 0
RESIDENTS rgrBewohner residentsTotalAbsent: 1
RESIDENTS rgrBewohner residentsGotosleep: 0
RESIDENTS rgrBewohner residentsAbsent: 1
RESIDENTS rgrBewohner lastState: gotosleep
RESIDENTS rgrBewohner absent
RESIDENTS rgrBewohner presence: absent
RESIDENTS rgrBewohner lastDeparture: 2014-03-02 20:37:31
RESIDENTS rgrBewohner lastDurPresence: 00:01:35
RESIDENTS rgrBewohner lastActivity: absent
RESIDENTS rgrBewohner lastActivityBy: Karsten
ROOMMATE rr_Karsten lastState: gotosleep
ROOMMATE rr_Karsten absent
ROOMMATE rr_Karsten lastMood: sleepy
ROOMMATE rr_Karsten mood: -
ROOMMATE rr_Karsten presence: absent
ROOMMATE rr_Karsten lastLocation: home
ROOMMATE rr_Karsten location: underway
ROOMMATE rr_Karsten lastDeparture: 2014-03-02 20:37:31
ROOMMATE rr_Karsten lastDurPresence: 00:01:35

Die Zeilen
RESIDENTS rgrBewohner gotosleep
RESIDENTS rgrBewohner absent
ROOMMATE rr_Karsten absent
fallen mir auf.

In allen anderen Zeilen steht immer das Attribut des Objektes vor der Eigenschaft. Ist das so korrekt?


Ich nehme nun statt des Attributes "state" das  Attribut "lastActivity". Das hat die gleichen Werte und tut's auch.

Viele Grüße
Zephyr
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 02 März 2014, 21:55:27

Die Zeilen
RESIDENTS rgrBewohner gotosleep
RESIDENTS rgrBewohner absent
ROOMMATE rr_Karsten absent

fallen mir auf.

In allen anderen Zeilen steht immer das Attribut des Objektes vor der Eigenschaft. Ist das so korrekt?

Ja, ist es. Das ist eine Besonderheit von FHEM selbst, das Reading "state" wird gleichzeitig auch als STATE interpretiert, also der Gesamtstatus, den du oben in den Internals siehst. Keine Ahnung, warum Rudi das so umgesetzt hat, er hat sicher seine Gründe.
Du kannst ein Notify deshalb nicht auf das Reading "state" setzen, sondern nur direkt auf den Objekt-Status. Insofern war mein Beispiel nicht ganz akkurat.
Das ist verwirrend, ich weiß. Kannst das ja mal in einem separaten Thread erfragen.

Aus welchem Grund können Gäste nicht den Status "gone" haben? Es gibt jedoch das AutoGoneAfter Attribut. Schon dass ein Gast nicht "gone" sein kann ist in sich unlogisch, oder verstehe ich das falsch?


Das ist schon logisch. Bei einem Gast macht es keinen Sinn, dass er längere Zeit abwesend ist, denn dann ist er tatsächlich einfach nicht vorhanden.
Ganz im Gegensatz zu einem dauerhaften Bewohner, der irgend wann auch wieder zurück kommt, wird ein Gast nicht notwendigerweise zurück kehren. Vielleicht wird es dir klarer, wenn du einmal die Beschreibung in der Kommando-Referenz für die beiden Stati "absent" und "gone" liest. Das Attribut AutoGoneAfter heißt bei allen Module so, damit es konsistent ist.


Habe gestern und heute ein wenig rum probiert und es funktioniert wirklich gut. Ich habe die Anwesenheit von 2 Personen per Bluetooth gekloppt und schalte damit die Alarmanlage scharf sobald der Home State von "home" auf "absent" umspringt. Das klappt soweit sehr gut. Ich würde dies jedoch noch ein wenig erweitern. Die Alarmanlage sollte nämlich auch scharf sein, wenn der Status auf "gone" übergeht.

Außerdem sollte sich Abends zu einer bestimmten Uhrzeit der Status automatisch auf "gotosleep" stellen und damit wieder die Alarmanlage scharf stellen.

Hier ist ein Auszug meines Code:

define Alarmanlage dummy
attr Alarmanlage group Status der Alarmanlage
attr Alarmanlage room Alarmanlage
define Alarmanlage_Scharf notify Home:absent.* { fhem ("set Alarmanlage on") if (Value("Alarmanlage") ne "on") }
attr Alarmanlage_Scharf room Alarmanlage
define Alarmanlage_Unscharf notify Home:home.* { fhem ("set Alarmanlage off") }
attr Alarmanlage_Unscharf room Alarmanlage

Muss ich nun für jeden einzelne Status des Home States einen neues Notify anlegen oder lässt sich das irgendwie eleganter lösen?

Kurzer Zusammenfassung der Schaltstände:

home          -   Schaltung per Bluetooth   -   Alarmanlage AUS
gotosleep    -   Schaltung per Uhrzeit       -   Alarmanlage AN
absent        -   Schaltung per Bluetooth   -   Alarmanlage AN
gone           -   Schaltung per Uhrzeit       -   Alarmanlage AN


Ich bin ehrlich gesagt nicht ganz sicher, ob ich das so sinnvoll fände. Der Sinn dahinter, einfach zu einer bestimmten Uhrzeit auf "gotosleep" zu schalten, nur weil deine Alarmanlage eingeschaltet werden soll, erscheint mir falsch.
Ich fände es prima, wenn du für dieses Thema einen eigenen Thread aufmachst, denn im Grunde geht es hier um eine spezielle Automation, die mit den Modulen nichts zu tun hat.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 02 März 2014, 21:58:07

darf ich fragen, wo man die iBeacons kaufen kann? Im Code Antwort #60 ist davon die Rede.


Wir haben uns diese hier bestellt:
http://estimote.com
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: marvin78 am 03 März 2014, 06:41:30
Das ist schon logisch. Bei einem Gast macht es keinen Sinn, dass er längere Zeit abwesend ist, denn dann ist er tatsächlich einfach nicht vorhanden.
Ganz im Gegensatz zu einem dauerhaften Bewohner, der irgend wann auch wieder zurück kommt, wird ein Gast nicht notwendigerweise zurück kehren. Vielleicht wird es dir klarer, wenn du einmal die Beschreibung in der Kommando-Referenz für die beiden Stati "absent" und "gone" liest. Das Attribut AutoGoneAfter heißt bei allen Module so, damit es konsistent ist.


Natürlich habe ich gelesen. Das macht es aber nicht logischer. Das Wort "gone" beschreibst genau das, was der Gast ist, wenn er nicht wieder kommt, nämlich "gone". Sollte er doch wieder kommen, war jedoch der Status "gone" auch richtig. Im Grunde ist es auch egal. Für mich bleibt es jedoch unlogisch und es beinhaltet eine gewisse inkonsistenz. Und logisch wird es nicht, weil man es als logisch definiert ;)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 03 März 2014, 08:29:45
Natürlich habe ich gelesen. Das macht es aber nicht logischer. Das Wort "gone" beschreibst genau das, was der Gast ist, wenn er nicht wieder kommt, nämlich "gone". Sollte er doch wieder kommen, war jedoch der Status "gone" auch richtig. Im Grunde ist es auch egal. Für mich bleibt es jedoch unlogisch und es beinhaltet eine gewisse inkonsistenz. Und logisch wird es nicht, weil man es als logisch definiert ;)


Letztendlich eine Frage der Definition. Ich habe sie eben so festgelegt. Dafür musst du meine Logik nicht nachvollziehen können, nur eben akzeptieren  :)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Urga am 04 März 2014, 21:19:32
Hallo Loredo,

ich möchte mich auch erst mal für das tolle Modul bedanken, habe aber auch ein Problem mit einem Notify.
Du schreibst als Beispiel:

Zitat
define n_rgrBewohner notify rgrBewohner:state:.* set Testdummy $EVTPART1

Damit funktioniert bei mir das Notify nicht.

Bei mir hatte ich es geändert in
define n_ANWESEND_R notify rgrResidents:presence:.* set ANWESEND_R $EVTPART1

Hinbekommen habe ich es jetzt weniger elegant mit
define n_ANWESEND_R notify rgr_Residents.presence.* {my $temp=ReadingsVal("rgr_Residents", "presence", "unknown");; fhem("set ANWESEND_R $temp") ;;}

Hast du eine Idee, warum das Notify nach deinem Beispiel nicht funktioniert? Zephyr scheint da ja auch ein Problem mit zu haben.

Gruß
Urga
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 04 März 2014, 21:27:02
Ja, es ist eine Eigenart von FHEM, dass für state kein Trigger ausgelöst wird.
Mein Beispiel war nicht ganz richtig, siehe oben.


Probiert


define n_rgrBewohner notify rgrBewohner:.(absent|gone) set Testdummy $EVTPART1
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: justme1968 am 04 März 2014, 21:43:06
state erzeugt sehr wohl events. aber ohne reading namen und somit ohne ':'.

wenn man die regex anpasst kann man sehr wohl notifys darauf definieren. man muss nur aufapssen das diese nicht so generell sind das sie auch auf andere readings matchen.

gruss
  andre
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 04 März 2014, 21:44:57

state erzeugt sehr wohl events. aber ohne reading namen und somit ohne ':'.

wenn man die regex anpasst kann man sehr wohl notifys darauf definieren. man muss nur aufapssen das diese nicht so generell sind das sie auch auf andere readings matchen.


Das versteht aber kein Mensch, der nicht Modul-Maintainer ist. Das Beispiel gerade macht aber genau das, was du beschreibst :D
Ich für meine Begriffe habe schon oft gedacht, dass es eigentlich so UND so gehen müsste bei State. Weiß wieder nur Rudi, was er sich da gedacht hat.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: justme1968 am 04 März 2014, 22:00:50
der ärgert sich glaube ich das er vielleicht nicht genug gedacht hat und es nicht mehr ändern kann ohne das es kompatibilitätsprobleme gibt :)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Urga am 04 März 2014, 22:01:59
Ok. Das ist mir für heute Abend zu kompliziert. ;)

Das obige Beispiel funktioniert bei mir leider auch nicht. Vielleicht mach ich mich da noch mal dran wenn ich etwas Ruhe habe. Mein Code macht ja das, was er soll.

Trotzdem danke.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 04 März 2014, 22:02:31

der ärgert sich glaube ich das er vielleicht nicht genug gedacht hat und es nicht mehr ändern kann ohne das es kompatibilitätsprobleme gibt :)

Das ist die typische MS Denke, die wir Mac Jünger so gar nicht verstehen ^^
Altlasten gehören raus, auf Teufel komm raus. Scheiß auf die Abwärtskompatibilität ^^
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Zephyr am 05 März 2014, 21:17:31
Puuuuhh, ich fühle mich so langsam wie die Nervensäge vom Dienst...
Ich habe hier 'ne Konfiguration, die reproduzierbar zu einem Absturz von FHEM führt.

Zuerst einmal meine Config:

# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
define rgrBewohner RESIDENTS
attr rgrBewohner alias Residents
attr rgrBewohner 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
attr rgrBewohner group Home State
attr rgrBewohner icon control_building_filled
attr rgrBewohner room Residents
attr rgrBewohner webCmd state
define rr_Karsten ROOMMATE rgrBewohner
attr rr_Karsten alias Karsten
attr rr_Karsten 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
attr rr_Karsten group Karsten
attr rr_Karsten icon people_sensor
attr rr_Karsten room Residents
attr rr_Karsten rr_showAllStates 1
attr rr_Karsten sortby 0
attr rr_Karsten webCmd state:mood
define rg_Dominik GUEST rgrBewohner
attr rg_Dominik alias Dominik
attr rg_Dominik devStateIcon .*home:user_available:absent .*absent:user_away:home .*none:control_building_empty:home .*gotosleep:scene_toilet:asleep .*asleep:scene_sleeping:awoken .*awoken:scene_sleeping_alternat:home .*:user_unknown
attr rg_Dominik group Guests
attr rg_Dominik icon scene_visit_guests
attr rg_Dominik rg_realname alias
attr rg_Dominik rg_showAllStates 1
attr rg_Dominik room Residents
attr rg_Dominik sortby 1
attr rg_Dominik webCmd state:mood
define logLastDurSleep FileLog ./log/logLastDurSleep.log rr_.*:lastDurSleep:.*
define notiKarstenLastDurSleep notify rr_Karsten:lastDurSleep.* {Log 1, $NAME.":".$EVENT}

Mir ist klar, dass es eigentlich so gedacht ist, dass die Guests in eine eigene RESIDENTSGROUP gehören. Mir kam es aber darauf an, dass ich Licht und Heizung in Abhängigkeit des Status der gesamten Wohnung -in diesem Fall der rgrBewohner- schalten kann. Und wenn alle Gäste und so im Bett sind, geht die Wohnung in einen bestimmten Status über.

Der Fehler tritt immer dann auf, wenn ich beim GUEST Dominik den Status auf "asleep" umstelle.

Im Terminal des Linuxservers erhalte ich dann folgende Fehlermeldung:

Month '-1' out of range 0..11 at ./FHEM/20_GUEST.pm line 839
Und zwar zum einen auf meinem Produktivsystem und zum anderen auf meiner Debian Testinstallation.

Hab ich was kaputt gemacht? ^^
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 06 März 2014, 12:16:42
Mir ist klar, dass es eigentlich so gedacht ist, dass die Guests in eine eigene RESIDENTSGROUP gehören.


Keineswegs, wie kommst du denn darauf?


Der Fehler tritt immer dann auf, wenn ich beim GUEST Dominik den Status auf "asleep" umstelle.Im Terminal des Linuxservers erhalte ich dann folgende Fehlermeldung:Month '-1' out of range 0..11 at ./FHEM/20_GUEST.pm line 839


Ich kann den Fehler bei mir nicht reproduzieren. Sicher, dass du die aktuelle Version aus dem SVN verwendest?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Zephyr am 06 März 2014, 21:38:44
Hmmmmm... Auf dem Debian Testrechner sollte sie aktuell sein.
1.0.2 steht in dem Perldateien der Module.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 07 März 2014, 11:31:49
Hmmmmm... Auf dem Debian Testrechner sollte sie aktuell sein.
1.0.2 steht in dem Perldateien der Module.


Ich kann nur vermuten, dass es mit deiner Perl Version zu tun hat.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Zephyr am 07 März 2014, 23:24:32
An Zeile 839 findet sich folgende. Prozedur:

sub GUEST_Datetime2Timestamp($) {                                                                                                                                                                       
    my ($datetime) = @_;                                                                                                                                                                               
                                                                                                                                                                                                       
    my ( $date, $time, $y, $m, $d, $hour, $min, $sec, $timestamp );                                                                                                                                     
                                                                                                                                                                                                       
    ( $date, $time ) = split( ' ', $datetime );                                                                                                                                                         
    ( $y,    $m,   $d )   = split( '-', $date );                                                                                                                                                       
    ( $hour, $min, $sec ) = split( ':', $time );                                                                                                                                                       
    $m -= 01;                                                                                                                                                                                           
    $timestamp = timelocal( $sec, $min, $hour, $d, $m, $y );                                                                                                                                           
                                                                                                                                                                                                       
    return $timestamp;                                                                                                                                                                                 
}

Ich habe mit ein paar Zeilen Perl mal nachgestellt, was passiert:
my ($datetime) = @_;
my ( $date, $time, $y, $m, $d, $hour, $min, $sec, $timestamp );
( $date, $time ) = split( ' ', $datetime );
( $y,    $m,   $d )   = split( '-', $date );
print "Datum: ".$date."\n";
print "Vorher: ".$m."\n";
$m -= 01;
print "nachher: ".$m."\n";

Als Ergebnis bekomme ich folgendes:

Datum:
Vorher:
nachher: -1

Sieht mir verdächtig nach dem "Month '-1'" aus der Fehlermeldung aus. Kann es sein, dass die Variable $date nicht gesetzt worden ist?

Meine Perlversion ist 5.14.2 auf dem Debian.


P.S. Die Rechtschreibkorrektur von OS X macht aus "Perlversion" konsequent "Perversion". :D
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 07 März 2014, 23:32:50

Ich habe mit ein paar Zeilen Perl mal nachgestellt, was passiert:
my ($datetime) = @_;
my ( $date, $time, $y, $m, $d, $hour, $min, $sec, $timestamp );
( $date, $time ) = split( ' ', $datetime );
( $y,    $m,   $d )   = split( '-', $date );
print "Datum: ".$date."\n";
print "Vorher: ".$m."\n";
$m -= 01;
print "nachher: ".$m."\n";


Als Ergebnis bekomme ich folgendes:

Datum:
Vorher:
nachher: -1

Dein Test ist fehlerhaft.

Mach es so und du stellst wirklich nach, was passiert:

my ($datetime) = "2014-03-07 23:31:23";
my ( $date, $time, $y, $m, $d, $hour, $min, $sec, $timestamp );
( $date, $time ) = split( ' ', $datetime );
( $y,    $m,   $d )   = split( '-', $date );
print "Datum: ".$date."\n";
print "Vorher: ".$m."\n";
$m -= 01;
print "nachher: ".$m."\n";
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Zephyr am 08 März 2014, 00:21:45
Ah, ich verstehe. :)

Jetzt wo $datetime einen Wert erhalten hat, funktioniert's natürlich. An der Funktion an sich scheint alles gut zu sein.
Heißt das nicht im Umkehrschluss, dass $datetime innerhalb der Funktion keinen Wert hat, wenn als Monat "-1" herauskommt? Da muss doch irgendwo das Problem liegen, oder?

Versteh mich nicht falsch, ich möchte hier nicht klugscheißen oder so.
Ich habe von Programmieren im Allgemeinen nur noch Informatikunterrichtskenntnisse und versuche so gut wie es geht mein Problem einzukreisen.

Woher bekommt denn $datetime seinen Wert, wenn der Status eines Gastes von "home" auf "asleep" wechselt?
Vielleicht  finde ich dort ja das Problem.

Verzeih, wenn ich so nervig bin. :-/
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 08 März 2014, 00:27:59

Woher bekommt denn $datetime seinen Wert, wenn der Status eines Gastes von "home" auf "asleep" wechselt?
Vielleicht  finde ich dort ja das Problem.


Zeile 778-790 wird der Sleeptimer gesetzt.


Ich bin mir eigentlich ganz sicher, dass kein Fehler im Code ist. Vielleicht ist deine Datei nur irgendwie korrupt. Lade sie doch mal neu von hier:
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/20_GUEST.pm?format=raw
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Zephyr am 09 März 2014, 11:28:15
Hallo,

ich habe die Datei nochmal runtergeladen. Leider besteht das Problem nach wie vor.

Ich schätze, dass die Zeilen, in denen der Sleeptimer gesetzt wird nicht ausschlaggebend sind.
Nach wie vor gehe ich davon aus, dass die Variable $datetime in der Funktion Datetime2Timestamp keinen Wert erhält und daher die gesamte Funktion als Monatsangabe "-1" ausspuckt.
In den Zeilen 778-790 keinen Wert.
Die Variable $datetime erhält nur ein einziges Mal im gesamten Script einen Wert zugewiesen.
Und zwar so:
my $datetime = TimeNow();
Ich habe versucht diese Funktion in einer Testdatei zu benutzen. Aber Perl bricht mit der Fehlermeldung ab, dass es die Subroutine nicht kennt:
Undefined subroutine &main::TimeNow called at
Vermutlich wird TimeNow an einer ganz anderen Stelle in FHEM definiert und daher funktioniert es in einem Testscript nicht.

Na ich suche mal weiter...

Viele Grüße
Zephyr
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Zephyr am 09 März 2014, 11:50:19
Man möge mich bitte steinigen.
Aus welchem Grund auch immer funktioniert es inzwischen auf der Debiantestinstallation. Nach noch zweimaligem Herunterladen der 20_GUEST.pm, einfügen von Logzeilen in der Hoffnung, zu erfahren was genau im Script passiert, versauen der 20_GUEST.pm und so weiter und so fort... funktioniert es einfach.  ???

Entschuldige den Aufwand.

#edit vom 09.03.2014, 14:06

Nein, zu früh gefreut. Auch die Debiantestinstallation hat immernoch die gleichen Probleme. :(

In VirtualBox erhalte ich stattdessen beim Login die Absturzmeldung von unten:
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 09 März 2014, 16:54:59
Nein, zu früh gefreut. Auch die Debiantestinstallation hat immernoch die gleichen Probleme. :(


Auch wenn das von dir beschriebene Verhalten bei mir absolut nicht reproduzierbar ist, so habe ich nach langem Suchen doch noch was entdeckt. Ich lade es gleich als Update ins SVN.


Gruß
Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Zephyr am 09 März 2014, 21:42:13
Ist es der fehlende Start des sleep timers bei den Guests? :D
Bei Roommate die Zeilen 400 - 416 und bei Guest fehlt der Teil ab Zeile 405? ;)

Das habe ich nämlich gerade in diesen Minuten bei mir hinzugefügt. Und im Moment funktioniert es erst mal. Aber mal abwarten.

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 09 März 2014, 21:43:51
Ist es der fehlende Start des sleep timers bei den Guests? :D
Bei Roommate die Zeilen 400 - 416 und bei Guest fehlt der Teil ab Zeile 405? ;)

Das habe ich nämlich gerade in diesen Minuten bei mir hinzugefügt. Und im Moment funktioniert es erst mal. Aber mal abwarten.


Exakt.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Zephyr am 09 März 2014, 22:34:40
Oh wow! Und das hast du rausbekommen ohne meine Probleme direkt bei Dir nachvollziehen zu können?
Respekt!  :D

Herzlichen Dank!
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 09 März 2014, 23:39:45
Oh wow! Und das hast du rausbekommen ohne meine Probleme direkt bei Dir nachvollziehen zu können?
Respekt!  :D


Naja, ist ja mein Modul. Da kenn ich mich schon ein wenig aus was da wo an welcher Stelle ist  ;)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 17 März 2014, 12:36:11
Hallo Loredo,
danke erstmal für Dein Modul, ich finde es toll und benutze es zur erkennung der anwesenheit mithilfe unsere handys (bluetooth) - ich möchte nun erweitern, im zimmer vom nachwuchs wird ein taster installiert, dieser soll erstmal den state schläft - oder ist wach einstellen... hierüber möchte ich die anrufbeantworter steuern und evtl. Sonos in der lautstärke begrenzen... ein asleep und woke up gibt es so aber ja noch nicht... wie würdest du das integrieren?

eine kleine frage noch - ich kämpfe eh schon mit freeze meldungen vom perfmon <3sek. , wenn aber jemand von uns das haus betritt oder verlässt sind es teilweise >12sek.
hängt das ausschliesslich mit Max zusammen - die heizköroer sind zur zeit das einzige was geschaltet wird in verbindung mit anwesenheit... oder liegt es auch vielleicht am Modul - verarbeitung und loggen der infos..?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 18 März 2014, 20:49:05
ein asleep und woke up gibt es so aber ja noch nicht...


Doch, die Stati gibt es so wie auch in der CommandRef beschrieben!
Sie werden im Webinterface per Default ausgeblendet, können aber trotzdem gesetzt werden. Mit dem Attribut r*_showAllStates kann man im Webinterface auch asleep und awoken einblenden.


Der Hintergrund ist ganz einfach: Normalerweise geht man in einer bestimmten Reihenfolge schlafen ;-)
Und dieser Prozess soll dadurch unterstützt werden, dass nur gotosleep als Start im Webinterface angezeigt wird. Danach kann man mit einem Klick auf das devIcon den jeweils nächsten Status setzen (also asleep > awoken > home).


Das wird aber irrelevant, wenn man den Status ohnehin über einen Taster setzen möchte, so wie du es vor hast.
Ich mache das bei mir auch über einen Taster und kann es daher nur empfehlen.


eine kleine frage noch - ich kämpfe eh schon mit freeze meldungen vom perfmon <3sek. , wenn aber jemand von uns das haus betritt oder verlässt sind es teilweise >12sek.
hängt das ausschliesslich mit Max zusammen - die heizköroer sind zur zeit das einzige was geschaltet wird in verbindung mit anwesenheit... oder liegt es auch vielleicht am Modul - verarbeitung und loggen der infos..?


Das hängt wohl nur mit deinen Max Devices zusammen. Die RESIDENTS Modulgruppe verbraucht keine nennenswerten Ressourcen. Ich vermute, du hast bei keinem deiner Max Devices bisher das Attribut event-on-change-reading auf ".*" gesetzt. Das würde ich dir unbedingt empfehlen, es mindert die Last bei Trigger Events enorm.




Gruß
Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Kakaomonster am 20 März 2014, 11:43:05
Hallo zusammen,

erstmal ein Dankeschön für das klasse Modul, mir gefällt es sehr gut und wenn ich dies nun noch mit meiner Bluetooth Abfrage verbunden bekomme, dann habe ich fast das was ich gesucht habe :-)

Nun sitze ich jedoch seit Tagen an einem Problem. Ich habe fast alles in eigene XX.cfg s ausgelagert. Nach anlegen der resident.cfg und übernehmen vom Beispielcode im ersten Post ist fhem nach einem rereadconfig.cfg nicht mehr gestartet. Ich bin also hingegangen und habe einen Teilvode irgendwann dann direkt in die fhem.cfg eingetragen um zu schauen was los ist. Erst dachte ich es liegt an der resident.cfg, weil wenn ich das include auskommentiert habe lief alles wieder.

Soeben bemerkte ich das follgender Code mein FHEM "tötet"

# Standalone
define rgr_Bewohner RESIDENTS
attr rgr_Bewohner alias Bewohner
attr rgr_Bewohner 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
attr rgr_Bewohner group Home State
attr rgr_Bewohner icon control_building_filled
attr rgr_Bewohner room Residents
attr rgr_Bewohner webCmd state
set rgr_Bewohner addRoommate Ralf
set rgr_Bewohner addRoommate Nina
set rgr_Bewohner addGuest Gast

nehme ich hier nun follgendes RAUS:

set rgr_Bewohner addRoommate Ralf
set rgr_Bewohner addRoommate Nina
set rgr_Bewohner addGuest Gast

kann ich fhem nach einem reboot von meinem BBB (wheezy) wieder starten bzw startet wieder automatisch. Updates sind auf dem aktuellen Stand. Aus der log erhalte ich lediglich als letzten Einträge:

2014.03.20 11:34:17 3: WEBhook: port 8088 opened
2014.03.20 11:34:17 1: Including FHEM/licht.cfg
2014.03.20 11:34:17 1: Including FHEM/light_scene.cfg
2014.03.20 11:34:17 1: Including FHEM/structure.cfg
2014.03.20 11:34:17 1: Including FHEM/bluetooth.cfg
2014.03.20 11:34:17 1: Including FHEM/radio.cfg
2014.03.20 11:34:17 1: Including FHEM/viewControl.cfg
2014.03.20 11:34:17 1: Including FHEM/ttsRec.cfg
2014.03.20 11:34:17 2: RESIDENTS set rgr_Bewohner addRoommate Ralf
2014.03.20 11:40:20 1: Including FHEM/licht.cfg
2014.03.20 11:40:20 1: Including FHEM/light_scene.cfg
2014.03.20 11:40:20 1: Including FHEM/structure.cfg
2014.03.20 11:40:20 1: Including FHEM/bluetooth.cfg
2014.03.20 11:40:21 1: Including FHEM/radio.cfg
2014.03.20 11:40:21 1: Including FHEM/viewControl.cfg
2014.03.20 11:40:21 1: Including FHEM/ttsRec.cfg
2014.03.20 11:40:21 1: Including ./log/fhem.save

da ich hier von einem Denkfehler bei mir ausgehe, hoffe ich auf Hilfe, denn so fit bin ich immer noch nicht mit fhem und so langsam auch am verzweifeln :-(

Hoffe doch das an so einem Sonnigen Tag jemand hier rein schaut :-)

Grüsse, Ralf
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 20 März 2014, 11:48:44
nehme ich hier nun follgendes RAUS:set rgr_Bewohner addRoommate Ralfset rgr_Bewohner addRoommate Ninaset rgr_Bewohner addGuest Gast


Set-Befehle gehören niemals direkt in eine cfg-Datei. Die Befehle müssen nur einmalig über das Web-Frontend ausgeführt werden und erzeugen dann die eigentlichen Objekte, die bei einem "save" auch ordnungsgemäß in der fhem.cfg abgespeichert werden. Natürlich kannst du sie anschließend von dort auch in deine gesonderte Datei verschieben. Wichtig dabei ist nur, dass die Reihenfolge der Objekte so bestehen bleibt (erst RESIDENTS Objekt, dann ROOMMATE und GUEST Objekte).

Das wäre dir nicht passiert, wenn du die Config-Dateien nicht manuell editiert hättest. Dabei muss man schon genau wissen, was man tut. Ansonsten lautet die Empfehlung, alles ausschließlich über das Web-Frontend zu machen.


Gruß
Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Kakaomonster am 20 März 2014, 11:55:06
Hallo Julian,

danke für die schnelle Hilfe... UND...

MAAAANNNNN wie dumm kann man sein. Ist ja logisch  :o ich glaube das wäre mir in den nächsten Tagen genau so wenig aufgefallen wie jetzt das ich die set Befehle drinnen hatte wo sie nicht hingehören :-( *grrrrrr*

Danke erst mal. Nun kann ich mir wieder an mein Bluetooth dran geben, damit dadurch der Status geändert wird :-)
Ich wünsche Dir noch einen schönen Tag,

Grüsse, Ralf
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Kakaomonster am 20 März 2014, 12:33:56
Hallo zusammen,

nach meinem dummen Fehler von oben komme ich nun auch weiter und natürlich, wie soll es anders sein hänge ich da auch wieder. Aber naja, learning by doing, so kam ich wenigstens zum aktuellen stand :-)

Vielleicht kann mir hier auch jemand schnell behilflich sein.

Aktuell ist es so, wenn mein BT nicht mehr erreichbar ist, geht mein Status auf "gone", wenn es daheim ist dann auf "Home", dass klappt auch super, auch wenn die Anzeige leider nicht automatisch aktualisiert, so klappt es jedenfalls.

Dies habe ich mit diesem Code hinbekommen:

define BT_abwesend notify BT_Anwesenheit:0 set rr_Ralf state gone;; set androidTablet ttsSay Ralf ist Abwesend, Licht wurde ausgeschaltet. Bitte manuelle Schaltung übernehmen!
define BT_anwesend notify BT_Anwesenheit:1 set rr_Ralf state home;; set androidTablet ttsSay Hallo Ralf, willkommen zurück

Sicherlich nicht die beste Lösung so wie ich bisher lesen konnte, aber anders konnte ich es aus eigener Kraft noch (NOCH) nicht umsetzen :-)

Nun möchte ich aber, dass von Status "Home" erstmal auf "Absent" gesetzt wird. Bin ich dann x Minuten später immer noch absent, dann soll es auf "gone" gesetzt werden. Ich bin der Meinung das schon gesehen zu haben, aber ich habe das Forum nun 2 mal hoch und runter gesucht, ich finde es nicht mehr.

Jemand einen schnellen Tip? Mit sleep geht es wohl scheinbar nicht (sleep und erneut prüfen) Habe auch diverse schnippsel aus der Anwesenheitserkennung versucht "umzubasteln" aber auch da komme ich nicht weiter.

Grüsse, Ralf
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Alex_E am 21 März 2014, 07:22:16
Hallo zusammen,

ich hab da mal ne Frage zum Roommate Modul.. Generell funktioniert das Modul ziemlich gut bei mir, der Status wird über Geofency aktualisiert und ich hab ein Reading gesetzt, was auf die Änderung in Status auf Home eine Lampe einschaltet. Soweit, so gut. Was ich aber gerne zusätzlich integrieren würde ist eine weitere Bedingung welche das Licht nur dann schaltet, wenn es dunkel ist.
Sprich: Wenn Home UND Dunkel dann an.
Was hätten wir auf Verfügung:
- das Twilight Modul mit den einzelnen Statu
- einen Dummy der dunkel bzw. hell ausgibt und auf 2 weitere Dummys referenziert welche aufgrund von sunrise / sunset die Ausgabe des Dummy´s auf Hell/dunkel stellt
Leider will das Roommate Modul aber leider keine Bedingung akzeptieren und weigert sich, die 2.te Bedingung neben dem Home status zu akzeptieren..

Jemand eine Idee wie ich das umsetzen kann bzw. ob das Roommate Modul das vllt. einfach garnicht kann?

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Kakaomonster am 21 März 2014, 08:39:37
Hallo Alex,

vielleicht hilft Dir hier mein Code weiter. Erklärung darunter.

define BT_Anwesenheit dummy
attr BT_Anwesenheit room BT_Anwesenheit
define BT_Anwesendcheck at +*00:00:01 {\
\
    if (Value("BT_iPhone5") eq "absent" && Value("BT_iPhone5") eq "absent") {\
    fhem("set BT_Anwesenheit 0") if (Value("BT_Anwesenheit") ne "0")\
    }\
    else {\
    fhem ("set BT_Anwesenheit 1") if (Value("BT_Anwesenheit") eq "0");;;;\
    }\
    }
attr BT_Anwesendcheck room BT_Anwesenheit

#define BT_abwesend notify BT_Anwesenheit:0 set rr_Ralf state gone;; set androidTablet ttsSay Ralf ist Abwesend, Licht wurde ausgeschaltet. Bitte manuelle Schaltung übernehmen!

# Schaltung auf Abwesend und Anwesend WENN Tag oder Nacht mit Sprachnaricht

define BT_abwesend_Say_Tag notify BT_Anwesenheit:0 { if (isday()) { fhem("set androidTablet ttsSay Ralf ist verschwunden.") }}
define BT_abwesend_Say_Abend notify BT_Anwesenheit:0 { if (!isday()) { fhem("set androidTablet ttsSay Ralf ist weg.Licht wird ausgeschaltet.") }}
define BT_abwesend_liAus notify BT_Anwesenheit:0 set rr_Ralf state gone ;; set ambiEG_Wohnzimmer off

define BT_anwesend_Say_Tag notify BT_Anwesenheit:1 { if (isday()) { fhem("set androidTablet ttsSay Willkommen Ralf.Guten Tag.") }}
define BT_anwesend_Say_Abend notify BT_Anwesenheit:1 { if (!isday()) { fhem("set androidTablet ttsSay Willkommen Ralf.Guten Abend. Ambiente Licht eingeschaltet.") }}
define BT_anwesend_liAus notify BT_Anwesenheit:1  { if (!isday()) { fhem("set ambiEG_Wohnzimmer on") }}
define BT_anwesend_BTda notify BT_Anwesenheit:1 set rr_Ralf state home

Erklärung:
Ich komme nach Hause, per Bluetooth wird festgestellt das ich anwesend bin. Der Status wird auf HOME gesetzt, Sprachansage begrüsst mich je nach Tageszeit, ebenso wird Ambiente Licht eingeschaltet, aber nur wenn es dunkel ist. Umgestzt mit isday und !isday.

Ebenso wird beim verlassen eine Ansage durchgeführt und alles wird ausgeschaltet, egal ob Tag oder Nacht, da man ja ab und an auch am Tage Licht an macht und es vergisst auszumachen. Der Status wechselt auf GONE

Was mir fehlt ist, dass der Status ERSTMAl für x Minuten auf ABSENT wechselt und danach dann wenn ich nicht zurück komme auf gone.

Es wurde halt mit presence BT und isday bzw !isday umgesetzt. mit Sunrise/Twighlight bin ich noch dran, dass hat bei mir noch nicht so geklappt wie es soll.

Ich hoffe es ist das was Du meinst und es hilft ein wenig.
Grüsse, Ralf

PS: Das der Code nicht der schönste ist, weiß ich. Auch sicherlich nicht der Sinnvollste, aber erstmal funktioniert es. Vielleicht erbarmt sich ja einer der developer das in Kurzform SINNVOLL zu ändern :-)

Da fällt mir ein, wäre es nicht sogar eine möglichkeit sowas in ein eigenes Modul zu packen, indem man sowas als ungeübter per Dropdown lösen könnte? Ich habe mich mal daran versucht, es jedoch schnell wieder verworfen, da ich davon noch mehr als nur lichtjahre entfernt bin. Als Idee fände ich dies jedoch ganz gut, denn ich denke auch nicht coder sollten fhem doch in Zukunft einsetzen können. Dies ist im moment ja fast unmöglich. Also für jemanden der code noch niemals gesehen hat oder soll fhem auf dieser Basis auch in Zukunft laufen?

Das wäre eine Sinnvolle Frage an rudolf ob da schon was in Planung ist, wie es später weiter geht oder ob ich hier viel zu weit denke.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Alex_E am 21 März 2014, 11:39:28
Oha, das ist irgendwie deutlich mehr als ich eigentlich möchte. Und um ehrlich zu sein ist der Code fast nicht umschreibbar da einfach zu viele Dinge enthalten sind, die bei mir nicht so umgesetzt sind.


aktuell sieht mein Code so aus:


rr_Alex:home set ku_Lampe_gross on-for-timer 576
[/size]
Das Thema ist halt die zweite Prüfung mit einzubauen, also z.B. Tageslicht:dunkel
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Kakaomonster am 21 März 2014, 11:57:31
Hallo Alex,

ok, ich habe grade wenig Zeit um es selbst durchzuspielen.

Da ich aktuell auch noch nicht so erfahren bin, würde ich es nun auf 2 Abfragen referenzieren, einmal das Du daheim bist mit Geaofancy Status auf Home setzen und dann dieses hier, wenn Status home UND NICHT TAG, dann lampe an. Keine Garantie!!!

define rr_Alex_home HomeStatus:home  { if (!isday()) { fhem("set ku_Lampe_gross on-for-timer 576") }}
Ein Versuch ist es evtl,. Wert
Viel Glück, Ralf
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 21 März 2014, 12:44:06
@Alex : als alternative zur oft irre führenden syntax kannst du dir mal hier im forum unter automatisierung das IF-modul anschauen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Alex_E am 21 März 2014, 15:40:17
Danke für die Tips, ich probier das heute mal aus.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Alex_E am 21 März 2014, 19:52:26
mit dem syntax funktioniert es schon einmal nicht...
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Kakaomonster am 21 März 2014, 21:08:02
hm schade, aber ok ... ich schaue morgen auch noch mal bei mir nach, da ich es ähnlich möchte. Bin aber grade noch dabei es hin zu biegen, dass die gone zeit verlängert wird auf X minuten bis es von away auf gone springt, da hier mein licht im mom noch an und aus geht, wenn mal BT beim prüfen versagt... passiert ab und an, wenn ich das hinbekommen habe schaue ich noch mal nach Deinem Problem. Scheint ja im moment niemand Hilfestellung sonst zu geben

Schönen Abend erstmal, Grüsse, Ralf
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 23 März 2014, 13:21:36

Aktuell ist es so, wenn mein BT nicht mehr erreichbar ist, geht mein Status auf "gone", wenn es daheim ist dann auf "Home"

Das wäre aber nicht ganz korrekt. Es sei denn du fährst ständig für längere Zeit in den Urlaub. Wenn du nur ins Büro gehst oder zum Einkaufen, dann wäre eher der Status "absent" der richtige. Durch das autoGone wird ohnehin nach (unvorhergesehener) längerer Abwesenheit nach "gone" gewechselt. Man sollte "gone" nur direkt setzen, wenn man von vornherein weiß, dass man länger weg ist.

dass klappt auch super, auch wenn die Anzeige leider nicht automatisch aktualisiert

Das ist ein FHEM Problem. Lässt sich laut Rudi auch nicht lösen, genaueres kann ich dazu aber auch nicht ausführen.

Nun möchte ich aber, dass von Status "Home" erstmal auf "Absent" gesetzt wird. Bin ich dann x Minuten später immer noch absent, dann soll es auf "gone" gesetzt werden. Ich bin der Meinung das schon gesehen zu haben, aber ich habe das Forum nun 2 mal hoch und runter gesucht, ich finde es nicht mehr.

Das ist wie gesagt schon von Haus aus eingebaut. Du musst oben in deinem Code einfach nur auf "absent" setzen statt auf "gone". Über das Attribut r*_autoGoneAfter kannst du beeinflussen, wann auf "gone" gegangen wird. Bei ROOMMATE ist der Default Wert 36h, bei GUEST 16h.


Was ich aber gerne zusätzlich integrieren würde ist eine weitere Bedingung welche das Licht nur dann schaltet, wenn es dunkel ist.
Sprich: Wenn Home UND Dunkel dann an.
Was hätten wir auf Verfügung:
- das Twilight Modul mit den einzelnen Statu
- einen Dummy der dunkel bzw. hell ausgibt und auf 2 weitere Dummys referenziert welche aufgrund von sunrise / sunset die Ausgabe des Dummy´s auf Hell/dunkel stellt
Leider will das Roommate Modul aber leider keine Bedingung akzeptieren und weigert sich, die 2.te Bedingung neben dem Home status zu akzeptieren..

Jemand eine Idee wie ich das umsetzen kann bzw. ob das Roommate Modul das vllt. einfach garnicht kann?

Diese Bedingungen gehören auch nicht in das ROOMATE Modul, sondern sind eine Bedingung, die du im Notify mit abfragen musst.
Es macht keinen Sinn dein ROOMMATE Objekt nur auf "home" zu setzen, wenn es dunkel ist, nur damit deine Lampe sich nur dann schaltet. Das ist falsch gedacht. Du willst eigentlich immer, wenn du zu Hause bist, dein Objekt auf "home" setzen und das Notify, was dann auslöst, muss prüfen, ob es dunkel ist oder nicht.

Ich möchte hier eine Hilfestellung für die Definition zu einem Notify geben, da es eher themenfremd ist. Falls ihr mit der komplexen Definition von Bedingungen bei Notifies noch nicht fit seid, macht doch bitte einen separaten Thread im Forum "Anfängerfragen" auf.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Kakaomonster am 23 März 2014, 13:38:52
Das wäre aber nicht ganz korrekt. Es sei denn du fährst ständig für längere Zeit in den Urlaub. Wenn du nur ins Büro gehst oder zum Einkaufen, dann wäre eher der Status "absent" der richtige. Durch das autoGone wird ohnehin nach (unvorhergesehener) längerer Abwesenheit nach "gone" gewechselt. Man sollte "gone" nur direkt setzen, wenn man von vornherein weiß, dass man länger weg ist.

Das ist ein FHEM Problem. Lässt sich laut Rudi auch nicht lösen, genaueres kann ich dazu aber auch nicht ausführen.

Das ist wie gesagt schon von Haus aus eingebaut. Du musst oben in deinem Code einfach nur auf "absent" setzen statt auf "gone". Über das Attribut r*_autoGoneAfter kannst du beeinflussen, wann auf "gone" gegangen wird. Bei ROOMMATE ist der Default Wert 36h, bei GUEST 16h.

Hallo Loredo,

danke erstmal für die richtige definition :-) Ich habe in der Tat gone und absent völlig falsch verstanden, so kann mein Vorhaben dann ja auch nicht funktionieren, auch wenn ich es inzwischen über andere notifys gelöst hatte.

Nun werde ich dies erstmal ändern, dass ich absent und nicht gone bin, dann sollte alles so laufen wie ich mir das vorstelle.
Jedoch noch eine kurze Frage zu dem AutoGone, ich habe zwar meinen Freund google befragt und auch das Forum, zur comandref bin ich grade unterwegs

attr r*_autoGoneAfter 20
Sind das 20 sekunden, minuten oder Stunden? Laut Deiner Ausführung wie es default ist, gehe ich von Stunden aus. Wie kann ich dann als Beispiel 20 Minuten angeben`?

Grüsse und schönen Sonntag, Ralf

EDIT: Glaube es gefunden zu haben. Es sind Stunden, dennoch bleibt die Frage, ist es dennoch möglich als Beispiel die 20 Minuten irgendwie einzutragen?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 23 März 2014, 14:01:54
Jedoch noch eine kurze Frage zu dem AutoGone, ich habe zwar meinen Freund google befragt und auch das Forum, zur comandref bin ich grade unterwegs

attr r*_autoGoneAfter 20
Sind das 20 sekunden, minuten oder Stunden? Laut Deiner Ausführung wie es default ist, gehe ich von Stunden aus. Wie kann ich dann als Beispiel 20 Minuten angeben`?

Grüsse und schönen Sonntag, Ralf

EDIT: Glaube es gefunden zu haben. Es sind Stunden, dennoch bleibt die Frage, ist es dennoch möglich als Beispiel die 20 Minuten irgendwie einzutragen?


Die Kommando-Referenz gibt die Größe in Stunden an, ja :-)
Auch wenn ich finde, dass ein "gone" keinen Sinn nach 20 Minuten macht... du kannst natürlich auch 0.333 angeben. Das entspricht annähernd 20 Minuten ;-)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Kakaomonster am 23 März 2014, 14:15:17

Die Kommando-Referenz gibt die Größe in Stunden an, ja :-)
Ich wenn ich finde, dass ein "gone" keinen Sinn nach 20 Minuten macht... du kannst natürlich auch 0.333 angeben. Das entspricht annähernd 20 Minuten ;-)

Super, danke für die schnelle Hilfe, ich werde es sofort testen.

Der Sinn dahinter... Sicherlich habe ich noch einen denkfehler, aber wenn ich nur mein BT überwache und ich absent bin, dann wird sofort das Licht ausgeschaltet. Da es aktuell im Test ist nur das Ambiente Licht.

Dies nerft, da ab und an BT absent ist für einen testzyklus, dass Licht dann aus und kurz drauf wieder an geht (wenn es bereits dunkel ist, soweit konnte ich es schon umsetzen)

absent ist für mich nur ein moment wie mal zum Auto gehen, schnell mal bei den Nachbarn Hallo sagen, brötchenholfunktion (da soll ja alles so bleiben wie es ist :-) )usw... nach in diesem Fall 20 Minuten ist aber entweder was dazwischen gekommen das es länger dauert oder ich bin bewust wirklich gegangen. In dem Fall wird erst wenn ich gone bin überprüft ob sich noch jemand mit precence im haus aufhält ODER der TV an ist (wenn der an ist bin ich daheim oder jemand schaut fern, sodass sich auf jedenfall noch jemand oder etwas im haus befindet :-) und wenn es nur ein gast ist, den ich nicht eingetragen habe (bin haltvergesslich). Ist TV noch an, alles ok, ist er aus und ich bin nach 20 min auf gone, dann schalte alles im haus ab.

Schaut der Gast nun kein TV, nundenn... dann sitzt er eben im dunkeln :-)

Eigentlich wollte ich es ursprünglich mit meiner BT abfrage lösen, dass ich erst nach 20 min auf absent gesetzt werde, wenn ich innerhalb von 20 Min nach dem ersten absent nicht wieder present bin, aber da komme ich bis jetzt nicht weiter das es funktioniert.

Bitte dabei bedenken, so fit bin ich ja noch nicht und daher suche ich auch andere wege um das umsetzen zu können wwas ich benötige :-)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 23 März 2014, 17:25:48

Der Sinn dahinter... Sicherlich habe ich noch einen denkfehler, aber wenn ich nur mein BT überwache und ich absent bin, dann wird sofort das Licht ausgeschaltet. Da es aktuell im Test ist nur das Ambiente Licht.

Dies nerft, da ab und an BT absent ist für einen testzyklus, dass Licht dann aus und kurz drauf wieder an geht (wenn es bereits dunkel ist, soweit konnte ich es schon umsetzen)


Ich würde deshalb eher empfehlen, dass du statt Notify einen Watchdog nimmst. Damit kannst du dann den Status erst nach einer bestimmten Auszeit wirklich setzen. Wenn also einmal eine BT Abfrage bei dir "abwesend" ergibt, ist das dann nicht mehr so schlimm. Erst wenn wenn du dann wirklich beim 2. oder 3. Zyklus immer noch nicht wieder per BT auffindbar bist, dann löst der Watchdog wirklich aus (und setzt den Status auf "absent" und löst entsprechend die Folgeaktionen aus).

Das ist die Standard-Empfehlung, wenn man ein Gerät zur Anwesenheitserkennung benutzt, was gepollt werden muss.
Alternativ kann man mit dem GEOFANCY Modul (bei Besitz eines iPhones) das Verlassen genauer veranlassen (wobei das Definitionssache ist; bei mir ist ein 5min beim Tengelmann nebenan ne Kleinigkeit holen nicht wirklich weg, da muss das Geofencing gar nicht unbedingt auslösen; ähnliches Beispiel wie du mit deinem Nachbarn ;))
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Kakaomonster am 23 März 2014, 17:29:52


Ich würde deshalb eher empfehlen, dass du statt Notify einen Watchdog nimmst. Damit kannst du dann den Status erst nach einer bestimmten Auszeit wirklich setzen. Wenn also einmal eine BT Abfrage bei dir "abwesend" ergibt, ist das dann nicht mehr so schlimm. Erst wenn wenn du dann wirklich beim 2. oder 3. Zyklus immer noch nicht wieder per BT auffindbar bist, dann löst der Watchdog wirklich aus (und setzt den Status auf "absent" und löst entsprechend die Folgeaktionen aus).

Das ist die Standard-Empfehlung, wenn man ein Gerät zur Anwesenheitserkennung benutzt, was gepollt werden muss.
Alternativ kann man mit dem GEOFANCY Modul (bei Besitz eines iPhones) das Verlassen genauer veranlassen (wobei das Definitionssache ist; bei mir ist ein 5min beim Tengelmann nebenan ne Kleinigkeit holen nicht wirklich weg, da muss das Geofencing gar nicht unbedingt auslösen; ähnliches Beispiel wie du mit deinem Nachbarn ;))

Wie war das? Vor lauter Bäume sieht man den Wald nicht mehr? Hm ... stimmt mit dem Watchdog hätte ich ja dann letztendlich alles was ich möchte. Darauf kam ich mal wieder nicht. Ist wohl zu einfach gewesen in meinen Augen oder weiß der Geier warum ich da nicht drauf kam.

Danke Dir noch mal für die Idee, werde mich da mal dran machen.

Grüsse, Ralf
PS: Das Geofancy Modul habe ich auch bereits drinnen, aber ich bin aktuell der einzige mit iPhone von daher habe ich da noch nicht weiter gemacht, da ich am Anfang nicht wirklich damit klar gekommen bin. Nun mache ich mich aber wieder zurück zum Residents und Roommate Module :-)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Kakaomonster am 25 März 2014, 09:05:12

Die Kommando-Referenz gibt die Größe in Stunden an, ja :-)
Auch wenn ich finde, dass ein "gone" keinen Sinn nach 20 Minuten macht... du kannst natürlich auch 0.333 angeben. Das entspricht annähernd 20 Minuten ;-)

Guten Morgen Loredo,

so nun läuft mein fhem wieder, watchdog eingebaut und alles umgebastelt nach Deinen Tips. Also annähernd, bin noch dran :-)
Nun habe ich aber immer noch das Problem mit dem autogone atribute. Kannst Du mir da weiterhelfen? Irgendwie verstehe ich nicht ganz, wie ich das einbauen soll.

Ein einfaches
attr r*_autoGoneAfter 20reagiert nicht
Ein
attr rr_Ralf_autoGoneAfter 20funktioniert auch nicht

und ein paar andere Ideen hatte ich auch noch die nicht funktioniert haben. Also lediglich fehlermeldungen habe ich erhalten beim neu einlesen der fhem.cfg Was mache ich hier falsch oder habe ich das ganze falsch verstanden? In der commandref konnte ich auch kein Beispiel dafür finden das ich meinen Fehler erkennen kann.

Danke erste mal,
Grüsse, Ralf

PS: Mit Deinen Tips klappt es nun wirklich viel besser :-) *freu*

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: marvin78 am 25 März 2014, 09:09:43
Warum setzt du das Attribut rr_autoGoneAfter nicht einfach im Frontend?

Einfach in der Kommandozeile eingeben:

attr rr_.* autoGoneAfter 20
Noch einfacher geht es im Device selbst.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Kakaomonster am 25 März 2014, 09:13:40
Warum setzt du das Attribut rr_autoGoneAfter nicht einfach im Frontend?

Einfach in der Kommandozeile eingeben:

attr rr_.* autoGoneAfter 20
Noch einfacher geht es im Device selbst.

Guten Morgen Marvin,

danke für die schnelle Antwort.

wenn ich Deinen Code von oben so übernehme, erhalte ich den Fehler

rr_Ralf: unknown attribute autoGoneAfter. Type 'attr rr_.* ?' for a detailed list.Ich habe wie Du geschrieben hast
attr rr_.* autoGoneAfter 20 eingegeben
Auch
attr rr.* autoGoneAfter 20 oder
attr rr_Ralf* autoGoneAfter 20
gibt mir die Fehlermeldung zurück. Stimmt da vielleicht was mit meiner fhem.cfg nicht?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: marvin78 am 25 März 2014, 09:15:35
Mein Fehler. Das Attribut heißt

rr_autoGoneAfter
Also:

attr rr_.* rr_autoGoneAfter 20
Wenn du es in den Devices machst (Dropdownbox) kannst du aber auch bei der Schreibweise nichts falsch machen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Kakaomonster am 25 März 2014, 09:17:40
Super, danke das hat so fubnktioniert.

In den devices finde ich es irgendwie nicht. SCheinbar habe ich da noch was falsch, aber das macht ja nun erstmal NOCH nichts. Da ich alles am umbauen bin, finde ich es vielleicht später wieder. Jetzt hat es zumindest geklappt, dass ich dies so eingeben konnte

Danke noch mal,
Grüsse, Ralf
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: marvin78 am 25 März 2014, 09:20:18
Kleiner Tipp:

Mit den Grundlagen von FHEM beschäftigen!
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Kakaomonster am 25 März 2014, 09:24:57
Habe ich viel bevor ich begonnen habe :-)

ABER Du hast recht, sollte ich noch ein bisschen (viel,viel) mehr und alles mal wiederholen :-) Scheint nur die hälfte hängen geblieben zu sein :-)
Mein Problem dabei war wohl, dass ich dies gemacht habe, bevor ich fhem installiert und die nötige HW hatte. Danach habe ich mich erst dazu entschossen es zu versuchen. Und ohne ab und an direkt etwas umsetzen zu können, vergisst man schnell wieder. Nun sollte ich es mir aber so langsam wirklich nochmal zu gemüte führen ;-)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: RoBra81 am 27 März 2014, 10:07:46
Hallo,

ich bin FHEM-Einsteiger und habe zugegebenermaßen vermutlich eine Anfängerfrage. Da diese sich jedoch auf die Roommates bezieht, stelle ich sie einmal hier in der Hoffnung, nicht zu sehr beschimpft zu werden. Zunächst möchte ich jedoch einmal meinen Respekt für die Arbeit an den Modulen für Bewohne und dem GEOFANCY-Modul zum ausdruck bringen: Vielen Dank für die Arbeit, ich werde darauf wohl meine Anweisenheitsauswertung aufbauen.

Nun zu meiner Frage: Ich möchte jeweils eine andere Aktion ausführen, wenn ein ROOMMATE (z.B. rr_Ronny) home (oder einen anderen Ort) erreicht bzw. verlässt. Aktuell habe ich Notifies auf mein Handy, welches die Positionsänderung meldet:

define nf.Ronny.Abwesend notify geofancy.*HandyRonny.*left.home.* "wget -O /dev/nul -q 'adresse1'"
attr nf.Ronny.Abwesend room Handys
define nf.Ronny.Anwesend notify geofancy.*HandyRonny.*arrived.home.* set Test Anwesend;;"wget -O /dev/nul -q 'adresse2'"

Da das GEOFANCY-Modul auch den ROOMMATE rr_Ronny auf home bzw. absent setzt, würde ich das Notify lieber darauf setzen, um auch auf Änderungen der location von rr_Ronny zu reagieren, die nicht von GEOFANCY kommen. Irgendwie bekomme ich das aber nicht hin :-(

Könnte mir jemand auf die Sprünge helfen, wie die Notifies für nach Hause kommen und zu Hause verlassen für einen ROOMMATE auszusehen haben?

Viele Dank
Ronny


[EDIT:] Ich hab's hinbekommen :-)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 07 April 2014, 16:35:18
Mit Verweis auf den Thread
Zeitdauern der RESIDENTS-Module in der Form HH:MM:ss plotten (http://forum.fhem.de/index.php/topic,22204.msg156147.html#msg156147)

habe ich gerade eine neue Version eingecheckt.

# -- new readings in computer readable format (*_cr)
# -- format of readings durTimer readings changes from minutes to HH:MM:ss

Neue Readings:
durTimerAbsence_cr
durTimerPresence_cr
durTimerSleep_cr
lastDurAbsence_cr
lastDurPresence_cr
lastDurSleep_cr

Die neuen Readings geben die Dauer in Minuten an (Sekunden erschien mir für's Plotten dann doch zu fein).Wie man sieht habe ich auch die DurationTimer angepasst. Um die Benennung einheitlich zu haben, musste deshalb das Format der vorhandenen Readings durTimerAbsence und durTimerPresence von Minuten auf HH:MM:ss umgeändert werden.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: RoBra81 am 11 April 2014, 10:47:21
Hallo,

ich möchte gerade mein FHEM ein bisschen erweitern und für die neue "Funktion" die Modulfamilie für Bewohner nutzen:

Wenn wir unseren Sohn ins Bett gebracht haben, möchte ich dessen Status auf asleep setzen und damit eine Art Babyalarm scharfschalten: wenn der Bewegungsmelder auf dem Flur vor dem Kinderzimmer eine Bewegung erfasst, wollen wir solange wir nicht schlafen im Wohnzimmer und wenn wir dann schlafen im Schlafzimmer durch eine blinkende Lampe benachrichtigt werden.

Soweit zur Rahmengeschichte. Mein Problem ist nun, dass der Status der Residents auf asleep gesetzt wird, sobald der erste Bewohner (unser Sohn) schläft. Mir wäre es lieber, wenn der Status der Residents asleep wird, sobald alle schlafen - gibt es da eine Möglichkeit?


Vielen Dank
Ronny
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 11 April 2014, 10:55:16

ich möchte gerade mein FHEM ein bisschen erweitern und für die neue "Funktion" die Modulfamilie für Bewohner nutzen:

Wenn wir unseren Sohn ins Bett gebracht haben, möchte ich dessen Status auf asleep setzen und damit eine Art Babyalarm scharfschalten: wenn der Bewegungsmelder auf dem Flur vor dem Kinderzimmer eine Bewegung erfasst, wollen wir solange wir nicht schlafen im Wohnzimmer und wenn wir dann schlafen im Schlafzimmer durch eine blinkende Lampe benachrichtigt werden.

Soweit zur Rahmengeschichte. Mein Problem ist nun, dass der Status der Residents auf asleep gesetzt wird, sobald der erste Bewohner (unser Sohn) schläft. Mir wäre es lieber, wenn der Status der Residents asleep wird, sobald alle schlafen - gibt es da eine Möglichkeit?



Genau so sollte auch das Standardverhalten sein (wird in der Doku ja auch so beschrieben).
Ich kann es gerade nicht nachvollziehen, aber hast du mal geschaut, ob das bei dir wirklich so ist oder ob nicht andere Umstände dazu führen?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: RoBra81 am 11 April 2014, 11:00:01
Kompliment: Das ging ja schnell!

Ich habe den "Fehler" (meinen) gefunden und muss noch ein Kompliment aussprechen: Du hast bei der Logik ja wirklich an alles gedacht: Ich bin zur Zeit nicht zu Hause und test remote. Da meine Frau auch nicht zu Hause ist, sind wir beide absent und nur unser Sohn ist virtuell zu Hause. Und wenn der einzige anwesende Bewohner auf asleep geht, geht auch Residents auf asleep. Ist noch jemand anderes zu Hause, bleibt der Status auf home.

Super!!

Vielen Dank
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 11 April 2014, 11:00:39
Ganz genau ;-)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 04 Mai 2014, 14:02:35
Hallo Loredo,
ich spiele gerade mit einem nagelneuem feature welches Andre heute nacht Programmiert hat.
Das ganze nennt sich readingsHistory der thread dazu ist hier http://forum.fhem.de/index.php/topic,23148.0.html (http://forum.fhem.de/index.php/topic,23148.0.html)

Ich möchte nun gerne in diesem Monitor eine Ausgabe haben wenn niemand mehr zuhause ist.
Ich habe auf das Residents Modul gesetzt und versucht per
define EventAnwesend notify XXXXX IF ([XXXXX] eq "home") (set Events add es ist jemand zuhause…)
ELSE (set Events add es ist niemand mehr zuhause…)
einen sinnvollen Eintrag zu bekommen. IF triggert wenn nichts weiter angegeben ist auf das Internal STATE. Ausserdem habe ich schon versucht auf das Reading presence zu triggern - beide male bekomme ich eine menge an einträgen in den Monitor. 

Zitat
13:49:21  Micha ist gegangen...
13:49:21  es ist niemand mehr zuhause…
13:49:20  es ist niemand mehr zuhause…
13:49:20  es ist niemand mehr zuhause…
13:49:20  es ist niemand mehr zuhause…
13:49:20  es ist niemand mehr zuhause…
13:49:20  es ist niemand mehr zuhause…
13:49:20  es ist niemand mehr zuhause…
13:49:20  es ist niemand mehr zuhause…
13:49:20  es ist niemand mehr zuhause…
13:49:20  es ist niemand mehr zuhause…
13:49:20  es ist niemand mehr zuhause…
13:41:56  Micha ist nach Hause gekommen...
13:41:56  es ist jemand zuhause…
13:41:56  es ist jemand zuhause…
13:41:56  es ist jemand zuhause…
13:41:56  es ist jemand zuhause…
13:41:56  es ist jemand zuhause…
13:41:56  es ist jemand zuhause…
13:41:56  es ist jemand zuhause…
13:41:56  es ist jemand zuhause…
13:41:56  es ist jemand zuhause…
13:41:56  es ist jemand zuhause…
13:41:56  es ist jemand zuhause…
13:39:19  Micha ist gegangen...
13:39:19  es ist niemand mehr zuhause…
13:39:19  es ist niemand mehr zuhause…
13:39:19  es ist niemand mehr zuhause…
13:39:19  es ist niemand mehr zuhause…
13:39:19  es ist niemand mehr zuhause…
13:39:19  es ist niemand mehr zuhause…
13:39:19  es ist niemand mehr zuhause…
13:39:19  es ist niemand mehr zuhause…
13:39:19  es ist niemand mehr zuhause…
13:39:18  es ist niemand mehr zuhause…
13:39:18  es ist niemand mehr zuhause…
13:39:18  es ist niemand mehr zuhause…

event-on-change-reading have ich aug .* gesetzt.

Was kann ich tun um nur einen Eintrag zu bekommen?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: fhainz am 04 Mai 2014, 14:04:21
event-on-change-reading have ich aug .* gesetzt.
Versuch mal *.*
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 04 Mai 2014, 14:06:45
Danke fhainz - gerade versucht… Es hilft nicht…
Zitat
14:05:38  Micha ist nach Hause gekommen...
14:05:38  es ist jemand zuhause…
14:05:38  es ist jemand zuhause…
14:05:38  es ist jemand zuhause…
14:05:38  es ist jemand zuhause…
14:05:38  es ist jemand zuhause…
14:05:38  es ist jemand zuhause…
14:05:38  es ist jemand zuhause…
14:05:38  es ist jemand zuhause…
14:05:38  es ist jemand zuhause…
14:05:38  es ist jemand zuhause…
14:05:38  es ist jemand zuhause…
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: fhainz am 04 Mai 2014, 14:07:58
Ok komisch.. *.* funktioniert bei mir bei einigen devices problemlos.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 04 Mai 2014, 16:05:24
*.* hat aber nix mit Regex zu tun, da kommt wohl noch die DOS Erinnerung bei dir hoch ;-)

Die Module lösen kein Event aus, ohne dass sich ein Status tatsächlich ändert. Demnach wird die Notify Schleife auch nur dann entsprechend aufgerufen. Was aktualisiert wird, ist das Reading für den An-/Abwesenheitscounter.

Leider hast du den entscheidenden Part deines Notify verstümmelt. ich kann daher nur vermuten, dass du dein Notify nicht auf das Reading "state" beschränkt hast und es daher dauernd auslöst.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 04 Mai 2014, 16:14:59
Danke Loredo - fhainz und Andre haben mir gerade gewaltig auf die Sprünge geholfen, nun habe ich schon fast ein Jahr FHEM aktiv - aber REGEX und wie man sauber in ein notify hineintriggert hatte ich nie verstanden…
Jetzt gerade in der letzten viertel Stunde habe ich deutlich mehr verstanden als im ganzem letztem Jahr…
Das ist mir schon fast peinlich.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 04 Mai 2014, 16:30:15
Da empfehle ich:
http://www.regexr.com/

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: fhainz am 04 Mai 2014, 16:42:50
Nette Seite, danke!
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 04 Mai 2014, 16:43:57
Danke auch von mir…
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: matzel am 16 September 2014, 11:58:37
Hallo,

ich komme endlich dazu das Modul RESIDENTS einmal auszuprobieren. In Kombination mit dem GEOFANCY-Modul klappt die Anwesenheitserkennung ja hervorragend!!! Danke dafür!!!!!!!

Meine Frage:
Kann man den ROOMATES eine Sublocation zuordnen? Also z.B. location ist home; sublocation ist kitchen, bedroom...
Wäre doch im Zusammenhang mit den iBeacons ne tolle Sache.

Liebe Grüsse
Matzel
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 16 September 2014, 12:04:15

Kann man den ROOMATES eine Sublocation zuordnen? Also z.B. location ist home; sublocation ist kitchen, bedroom...
Wäre doch im Zusammenhang mit den iBeacons ne tolle Sache.


Dafür brauchst du keine Sub-Lokation. Du kannst einfach die Location wie sie ist auf "Bedroom" oder was auch immer setzen (über Geof[e|a]ncy auch via iBeacon, klappt problemlos). Wenn zuvor einmal die Location "home" gesetzt wurde, bleibt der Status ja solange darauf, bis der home-Radius verlassen wird. Wenn du sicher sein willst, auch im Bedroom etc auf "Zuhause" zu bleiben, dann kannst du das Attribut rr_locationHome setzen (mehrere Locations dort einfach mit Komma trennen, siehe Kommando-Referenz). Der erste Eintrag dort sollte allerdings "home" bleiben, wenn du das als Schlüsselwort in der Geo-App eingetragen hast, um das Standardverhalten zu behalten.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: matzel am 16 September 2014, 12:19:05
Oh je!!!
DANKE!!!

Hab das völlig überlesen - sorry ;P
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: geek am 04 Dezember 2014, 22:40:49
Hallo Loredo,

vielen Dank Für die Module - die machen das Leben wirklich einfacher.

Allerdings hätte ich ein paar Wünsche:

Das sind eigentlich alles Kleinigkeiten... aber ... Wünschen kann man ja mal ;)

danke
 Rainer
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 05 Dezember 2014, 13:47:35

vielen Dank Für die Module - die machen das Leben wirklich einfacher.


Danke. Freut mich, dass sie auch für andere hilfreich sind
;) 

Allerdings hätte ich ein paar Wünsche:
  • Im define werden die Attribute alias und sortby gesetzt. Der check auf "exists( $attr{$name}{$name_attr}" zieht da aber leider nicht: Attribute werden ja erst nach dem define gesetzt. Damit ist es unmöglich, diese Attribute zu löschen: Spätestens nach dem nächsten Start von fhem sind die wieder da.

Das ist wahr. Ich sehe allerdings auch keine andere Möglichkeit, da ich gerne die Einfachheit für die Nutzung der Module so erhalten wollen würde.
Aus der Praxis heraus sehe ich aber auch kein wirkliches Problem, denn auch wenn man die Attribute nicht löschen kann, so kann man deren Wert sehr wohl anpassen. Wer (aus mir unerfindlichen Gründen) kein Alias setzen möchte, kann den Alias ja auch auf den gleichen Namen wie das Device selbst setzen. Von der Anzeige her ist es dann identisch.
Das sortby Attribut sollte ebenso wenig stören. Wer bei der Sortierreihenfolge keinen besonderen Wert darauf legt, ignoriert es einfach. Und wer die Sortierung ändern möchte, der ändert eben den Wert entsprechend ab.


   
  • die residents* readings von RESIDENTS erzeugen keine events - die kann man also auch nicht per notify oder userReadings abfrühstücken


Die entsprechenden FHEM Funktionen, um die Trigger auszulösen, werden entsprechend benutzt. Entweder liegt hier dann ein Problem mit der Notify-Definition vor oder es ist ein FHEM eigenes Problem. Das kann ich so aus dem Bauch heraus nicht sagen. Hast du eine Beispiel-Definition, um das nachzustellen, was du erreichen wolltest?

   
  • anders herum nerven die dur* events der ROOMMATES - besonders weil man mit event-on-$something nicht einfach nur "dur.*" verbieten kann (oder doch???)

Eigentlich sollten sie nur wenig stören. Für's Logging kann man entsprechende Ausnahmen definieren genauso wie für Trigger ansich auch. Wie du richtig schreibst kann man es entweder über event-on-* lösen oder aber einfach seine Notifies entsprechend korrekt definieren, so dass sie nicht bei dur* anspringen.
Du könntest mal probieren, das Attribut event-on-change-reading so zu setzen, dass es eine explizite Lister aller Readings enthält, für die du einen Trigger erhalten möchtest. Alles andere wird dann ignoriert. Die Readings werden natürlich weiterhin aktualisiert, lösen eben halt nur kein Event mehr aus. So ist es dann auch gedacht.


   
  • damit sich ROOMMATES + RESIDENTS gleich behandeln lassen können wäre cool, wenn auch RESIDENTS ein "wayhome" reading hätten das auch events erzeugt.

Es hat einen Grund, weshalb die Readings hier unterschiedlich benannt sind. Es macht keinen Sinn die zwei Module über einen Kamm zu scheren, denn sie haben beide unterschiedliche Funktionen.
Beim Beispiel "wayhome" ist es so, dass das Reading bei einem ROOMMATE Device nur 0 oder 1 sein kann. Das RESIDENTS Modul bildet jedoch eine Summe über alle seine zugeordneten ROOMMATE Devices. Daher kann das Reading "residentsTotalWayhome" dort nicht nur 0 oder 1 sein, sondern auch 2, 3, 4 usw... Da hier ein unterschiedliches Verhalten besteht, sind die Readings entsprechend auch deutlich anders benannt, um sich absichtlich entsprechend abzusetzen.


Gruß
Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: geek am 05 Dezember 2014, 17:10:26
Hi,

so, habe noch ein bischen geschaut gehabt und meine Wunschliste mal abgearbeitet. Anbei ist ein Patch der alles addressiert - nur als Beispiel - ich erwarte nicht, daß du den (komplett) übernimmst. Wie gesagt - waren nur Wünsche - und die werden nicht immer erfüllt. Kann Deine Argumentation auch voll verstehen und akzeptieren. :D

Bei den fehlenden Events von RESIDENTS fehlte ein readingsEndUpdate am Ende von RESIDENTS_UpdateReadings.

Danach konnte ich mir auch ein wayhome reading mittels userReadings bauen... der Vollständigkeit halber ist aber auch die Alternative im Patch. Mir ist klar, daß die Module was anderes beschreiben - aber handlicher ist schon, wenn state und wayhome bei beiden existieren ... zb. um mit dem gleichen Satz von Funktionen Status LEDs ohne weitere Sonderbehandlung zu setzen.

alias hatte ich schon wie vorgeschlagen gelöst... sortby ist lästig, weil ich normal nach den Namen sortiere.

mittels event-on-* nur die gewünschten readings filtern geht... ist aber etwas das potentiell bei jedem update angefasst werden muss. Deswegen hab' ich mir das periodischen Berechnen der Durations abschaltbar gemacht mit "attr $name noDuration 1".

Rainer
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 05 Dezember 2014, 17:49:57

Bei den fehlenden Events von RESIDENTS fehlte ein readingsEndUpdate am Ende von RESIDENTS_UpdateReadings.


Vielen Dank für den wertvollen Hinweis! Habe ich soeben korrigiert und eingecheckt.

Deswegen hab' ich mir das periodischen Berechnen der Durations abschaltbar gemacht mit "attr $name noDuration 1".


Habe ich in abgewandelter Form in 20_ROOMMATE und 20_GUEST übernommen und eingecheckt.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: volschin am 09 Januar 2015, 12:50:42
Hallo zusammen,
ich habe bisher bereits ROOMMATE genutzt und wollte jetzt auch RESIDENTS nutzen. Ich bekomme es allerdings nicht hin.
Ich habe Residents mit
define rgr_Residents RESIDENTSangelegt.
dann habe ich versucht mittels addRoommate einen existierenden Roommate hinzuzufügen. Leider meckert er immer, das er bereits existiert und packt ihn auch nicht rein. Einen nicht existierenden kann ich anlegen und der ist auch eingebunden, aber das hilft mir grade mal nicht weiter.

Mache ich was falsch?

Gruß
Veit
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 09 Januar 2015, 12:55:15
Du musst das existierenden ROOMMATE Device einfach editieren und gemäß der Commrandref das Define so abändern, dass sich das Gerät beim RESIDENTS Gerät entsprechend anmeldet.


Aus


define rr_Veit ROOMMATE


wird dann also z.B.



define rr_Veit ROOMMATE rgr_Residents




Alternativ: ROOMMATE Device einfach löschen und mit gleichem Namen wieder anlegen ;)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: volschin am 09 Januar 2015, 13:16:56
Das hat es getan. Manchmal muss man eben rückwärts denken.  ;)

Variante 2 wäre bei rund 30 existierenden Notify's und Watchdogs nicht so toll gewesen.

Danke für die schnelle Hilfe.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 09 Januar 2015, 13:19:56

Variante 2 wäre bei rund 30 existierenden Notify's und Watchdogs nicht so toll gewesen.


Die bleiben dabei doch erhalten und sind davon vollkommen unberührt. Während des kurzen Moments, wo das ROOMMATE Gerät nicht mehr existiert, triggern die Notifies und Watchdogs halt nur nicht, das ist alles 8)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 10 Januar 2015, 19:41:45
Hallo Loredo,
ich habe GUESTs definiert und frage mich gerade wo ich auf Anwesenheit einer dieser Gäste triggern kann, um das GästeWlan zu schalten.
Ich hatte vermutet das das reading von RESIDENTS residentsGuests hier hilft, das reading scheint aber "nur" eine summe aller definierten GUEST Devices zu sein. Ein GuestsHome gibt es nicht - oder übersehe ich was?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: marvin78 am 10 Januar 2015, 19:45:32
Wenn du Gäste definiert hast, dann kannst du doch einfach auf die guest-Devices triggern. Sowas wie:

define guestWlan notify GASTDEVICEREGEX:.home {schalteGastWlanan()}
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 10 Januar 2015, 20:09:50
richtig, aber so muss ich da jeder Gast seinen eigenen Namen hat ne ganze menge Devices eingeben..
Ich würde gerne wissen ob irgendein Gast da ist, egal welcher und nicht alle Namen im REGEX auflisten.

Edit:
ich könnte ja die Gäste in eine structure packen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 10 Januar 2015, 21:16:58
du kannst auch einfach die Gäste in ein einzelnes Residents Device packen ;-)
Die können nämlich auch in mehreren Residents Gruppen gleichzeitig Mitglied sein. Siehe Beispiel in der Commandref.

Ich nehme es aber mal als Anregung einen generellen Gäste-Indikator in die Readings mit aufzunehmen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 10 Januar 2015, 22:09:21
Ich glaube mit der structure habe ich das jetzt ganz gut hinbekommen
- das ein weiteres Residents genauso geholfen hätte war mir klar. Für mich stellt Residents aber die Wohnung da, und wir haben nunmal "nur" eine Wohnung ;-)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: volschin am 15 Januar 2015, 20:01:44
Hallo zusammen,
mein rgr_Residents verliert anscheinend nach jedem Restart den ROOMMATES-Eintrag in den Internals. Im ROOMMATE selbst ist der Eintrag im define für die Residents-Group aber vorhanden. Wenn ich einfach ein modify im ROOMMATE mache wird er auch sofort wieder hinzugefügt. Ich habe sowohl ein save der config gemacht als auch ein halbstündliches Sichern der fhem.save per at eingebaut. Daran liegt es also nicht.

Jemand eine Idee?

Gruß
Veit
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 15 Januar 2015, 20:07:56
Stimmt die Reihenfolge in der gespeicherten Config Datei? Zuerst alle RESIDENTS Devices, erst dann die ROOMMATE Devices.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: volschin am 15 Januar 2015, 20:13:39
Nein, der ROOMMATE steht zuerst. Das hat FHEM selbst so eingetragen. Ich halte meine Finger da typischerweise raus.
Es war aber auch die Anlagereihenfolge, da ich zuerst ROOMMATE ohne RESIDENTS benutzt habe. Soll ich die Reihenfolge manuell ändern?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 15 Januar 2015, 20:34:51
Ja. Es ist normalerweise vorgesehen erst ein RESIDENTS Device anzulegen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: volschin am 15 Januar 2015, 23:26:09
Wenn man einmal ans Sortieren kommt, wird's interessant. Ich habe jetzt rund eine Stunde gebraucht, meine config so umzustellen, dass sie lauffähig ist.

Aber jetzt funktioniert es so, wie es soll.

Scheint so, dass mit zunehmender Komplexität der fhem.cfg die Probleme durch die vernetzten Abhängigkeiten der Initialisierungsreihenfolge exponentiell zunehmen.

Danke für den Hinweis.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 17 Januar 2015, 14:24:34
Ich versuchte nun mehrfach das Icon des Resident devices zu löschen - dann passt es für mich optisch besser.
Allerdings kommt das Icon immer wieder ?
@Loredo: kannst Du das Icon attr von Residents nicht einfach dem Nutzer überlassen?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: marvin78 am 17 Januar 2015, 14:34:14
Diese Nutzer bevormundenen Module scheinen in Mode zu kommen...
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 18 Januar 2015, 16:19:54
Du kannst das icon-Attribut nach belieben abändern, jedoch nicht löschen.
Wenn jemand eine Möglichkeit kennt, Voreinstellungen mitzugeben, die nur beim initialen/manuellen define wirken, so bin ich offen für Änderungen. Ansonsten möchte ich es aus Convenience Gründen so beibehalten, wie es ist.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 18 Januar 2015, 16:21:11
Zur not hilft mir sicher ein delattr nach global:Ini.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: marvin78 am 18 Januar 2015, 16:21:59
Oder ein Icon mit 1x1 Pixel Transparent.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: marvin78 am 18 Januar 2015, 16:25:04
"Convenience" ist im Übrigen nicht FHEM. Und das ist gut so. FHEM zeichnet sich dadurch aus, dass ich alle Möglichkeiten habe, meine Hausautomation zusammen zu stellenwie ich es möchte. Aus diesem Grund sollten ALLE Module den Usern die Möglichkeit geben, Dinge selbst zu entscheiden. Die einzig sinnvolle Maßnahme wäre also, keine Icons vorzugeben. Aber ich weiß, dass ich hier gegen eine Wand rede...
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 18 Januar 2015, 16:32:00
Aber ich weiß, dass ich hier gegen eine Wand rede...


Ich bin eben anderer Ansicht. Ich möchte gerne eine Voreinstellung mitgeben, die der Nutzer dann nach seinem Gusto abändern kann, wenn er möchte (aber eben nicht muss). Dass man die Voreinstellung nur abändern, nicht aber löschen kann, liegt am Design von FHEM.


Diese Module hier wurden (und werden) von vielen sowieso als überflüssig bezeichnet, da man sich eine ähnliche Funktionalität auch mit Boardmitteln zusammenschustern kann. Die Module ansich sind deshalb ohnehin insgesamt schon der Convenience gewidmet.
Die Möglichkeit die gleiche Funktionalität mit Dummys, Structures oder sonstwie nachzubauen, steht dir natürlich auch offen; schließlich ist FHEM wie du sagst ein offenes System, was es dir ermöglicht deine Hausautomation so zu gestalten, wie du es möchtest.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 19 Januar 2015, 01:23:05
Ich habe jetzt einen Weg gefunden, wie sich die Attribute dauerhaft löschen lassen. Im morgigen Update ist der entsprechende Code enthalten.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: KernSani am 21 Januar 2015, 21:48:37
Hi zusammen,

seit zwei Tagen nutze ich nun auch - testweise - RESIDENTS und ROOMMATE und habe einen interessanten Effekt (höchstwahrscheinlich ein dummer Zufall, aber wer weiss):
Geofancy nutze ich schon länger (allerdings ohne irgendwas damit zu schalten)
Montag abends habe ich RESIDENTS und ROOMMATES defined, ein bisschen herumgespielt. Um den "wayhome" Status zu testen habe ich zusätzlich einen neuen Geofence in Geofancy definiert und in das wayHome Attribut geschrieben:
attr rr_oli rr_locationWayhome officeAls ich gestern dann wiede aus dem Büro nach Hause kam, war mein FHEM tot. Letzter Log-Eintrag:
2015.01.20 08:45:59 3: GEOFANCY geofancy: Oli arrived at office
2015.01.20 08:46:00 2: ROOMMATE set rr_Oli location office

Komisch denke ich mir, aber kann schonmal vorkommen, heute:
2015.01.21 08:41:12 3: GEOFANCY geofancy: Oli arrived at office
2015.01.21 08:41:12 2: ROOMMATE set rr_Oli location office

danach... nichts mehr, FHEM tot bis zum Neustart. Irgendjemand eine Idee, wieso FHEM stirbt, wenn ich im Office ankomme? Mir ist klar, dass die Wahrscheinlichkeit, dass es mit ROOMMATES zusammenhängt eher gering ist, aber wer weiss... Location auf "home" lässt FHEM übrigens am Leben.
Grüße,

Oli
 
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: noanda am 01 Februar 2015, 12:37:56
Ich habe ein Problem mit "mood". Wenn ich versuche über diesen Reading etwas zu steuern, z.B. die beleuchtung wird er einfach nicht ausgelesen. Erscheint auch nicht im Log. oder Event Monitor.

Um sicher zu sein das ich nichts falsch mache, habe ich das Notify mit Reasings anderer Sensoren probiert. Da kein Problem. habe es mit DOIF IF usw versucht, keine Reaktion. Hat jemand eine Lösung?

probiert habe ich:

(rr_Sommer)
IF ([rr_Sommer:rr_mood] = "relaxed") (set test off)

(rr_Sommer)
IF ([rr_Sommer:rr_mood] eq "relaxed") (set test off)

(rr_Sommer)
IF ([rr_Sommer:mood] = "relaxed") (set test off)


(rr_Sommer)
IF ([rr_Sommer:mood] eq "relaxed") (set test off)

Wieso geht das nicht?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Andy89 am 01 Februar 2015, 12:48:49
ich machs sowas mit ReadingsVal, zB.:

define nt_test notify rr_Andy:.* {if (ReadingsVal("rr_Andy","mood",0) eq "happy") {fhem("set WZ_Stehlampe on")}}
Das Beispiel funktioniert bei mir^^
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: noanda am 01 Februar 2015, 13:00:51
bei mir leider nicht

    
define nt_test notify rr_Sommer:.* {if (ReadingsVal("rr_Sommer","mood",0) eq "happy") {fhem("set test off")}}
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Andy89 am 01 Februar 2015, 13:02:03
bei mir leider nicht
so kann dir wohl keiner helfen :D
was sagt denn das logfile dazu?^^
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: noanda am 01 Februar 2015, 13:07:05
sorry ist der Frust .-)

2015.02.01 13:05:02 2: ROOMMATE set rr_Sommer mood happy
2015.02.01 13:05:02 5: ROOMMATE rr_Sommer: called function ROOMMATE_Set()

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 10 Februar 2015, 16:55:08
sorry ist der Frust .-)

2015.02.01 13:05:02 2: ROOMMATE set rr_Sommer mood happy
2015.02.01 13:05:02 5: ROOMMATE rr_Sommer: called function ROOMMATE_Set()


Das ist sicherlich ein Problem mit deiner Notify-Deklaration. Du solltest in dieser Hinsicht einmal schauen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 10 Februar 2015, 16:56:25
Ein Hinweis für diejenigen, die das Modul gerne in deutscher Sprache in der Oberfläche haben möchten:
http://forum.fhem.de/index.php/topic,33613.msg259937.html#msg259937


Dort ist beschrieben, wie man das mit Hilfe von eventMap und widgetOverride erreichen kann.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Bernd D. am 30 März 2015, 09:25:52
Hallo zusammen,

ist im Modul Residents eine einfache Möglichkeit vorgesehen festzustellen, ob Bewohner im Haus oder nicht im Haus sind?

Ein bewohntes Haus kann ja die Stati home, gotosleep, asleep und awoken haben.
Ein umbewohntes Haus die Stati absent und gone.

Wenn ich nun wissen möchte, ob das Haus unbewohnt ist, muss ich dann immer auf (absent oder gone) testen, oder gibt es dafür ein eigenes Attribut?

Ich bin darauf gestoßen, weil ich in meiner Rolladensteuerung bisher immer nur auf "absent" getestet habe, aber das Modul Residents ja nach einiger Zeit automatisch auf "gone" wechselt. Das hat meine Rolladenlogik dann durcheinander gebracht.

Vielen Dank für die Hilfe!

Gruß,
Bernd
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 30 März 2015, 09:46:14
Du kannst ja einfach auf Residents total Home triggern…

Zitat
2015-03-27 09:31:21   lastState       absent
     2015-03-27 09:31:21   presence        present
     2015-03-30 07:47:50   residentsAbsent 1
     2014-10-11 18:47:19   residentsAsleep 0
     2014-10-11 18:47:19   residentsAwoken 0
     2015-02-26 17:15:46   residentsGone   0
     2014-10-11 18:48:34   residentsGotosleep 0
     2015-03-18 01:02:44   residentsGuests 0
     2015-03-30 07:47:50   residentsHome   1
     2015-03-18 01:02:44   residentsTotal  2
     2015-03-30 07:47:50   residentsTotalAbsent 1
     2015-03-30 07:47:50   residentsTotalPresent 1
     2014-10-11 18:47:19   residentsTotalWayhome 0
     2015-03-27 09:31:21   state           home
so mache ich es jedenfalls.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Bernd D. am 30 März 2015, 09:58:17
Residents total home gibt es nicht. Meinst Du residentsTotalPresent?
Das müsste klappen, probiere ich mal aus.
Vielen Dank!
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 30 März 2015, 11:38:14
da gibt es mehrere Wege.


Bei der Frage "anwesend" oder "nicht anwesend", also einer Schwarz/Weiß Sicht, macht das Reading "presence" Sinn, denn es kann nur 2 Status haben.
Wenn man aber genauer differenzieren möchte, ob eine kurze oder längere Abwesenheit vorliegt, dann ist das Reading "state" genau dafür da und man wertet dort eben die Values "absent" bei kurzer und "gone" bei längerer Abwesenheit aus.


Auf die Total-Werte zu triggern kann man machen, ist aber nicht unbedingt zielführend in diesem Fall, weil euch die eigentliche Anzahl der anwesenden Personen ja egal ist.


Übrigens ist es nicht unbedingt richtig auf "totalHome" zu triggern, denn man kann auch zuhause sein und nicht den Status "home" haben, sondern z.B. "gotosleep,asleep,awoken". Man gilt dann natürlich immer noch als zuhause. Kommt aber drauf an, ob ihr diesen Workflow verwendet (siehe neuer Wiki Artikel Weckautomation (http://www.fhemwiki.de/wiki/Weckautomation)). Richtiger wäre da das Reading residentsTotalPresent oder residentsTotalAbsent. Aber wie gesagt, ganz korrekt sind nur "presence" und "state".
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Bernd D. am 30 März 2015, 12:25:37
Vielen Dank Loredo!
Dann ist presence genau das wonach ich gesucht hatte.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Bademeister am 11 April 2015, 16:33:27
Hallo zusammen,

ich habe versucht über die PING Erkennung meines Handys die Anwesenheit festzustellen. Dies habe ich mit dem Module PRESENCE gemacht - die Rückmeldung present und absent ist erfolgreich. Diesen State möchte ich gerne an den Roommate rr_Markus übergeben.

Dazu habe ich einen Watchdog wie folgt angelegt

setstate rr_Markus absent; setstate wd.rr.Markus.presence defined

Def: Markus.Handy:absent 00:03:15 Markus.Handy:present setstate rr_Markus absent; setstate wd.rr.Markus.presence defined

Dieser Watchdog erkennt wenn die Bedingung "absent" des Handys zutrifft, jedoch ändert sich der State von rr_Markus nicht.

Was mache ich falsch?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 11 April 2015, 16:36:05
Der Befehl muss nicht


setstate rr_Markus absent

heißen, sondern stattdessen


set rr_Markus absent
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Bademeister am 11 April 2015, 17:33:59
Cmd angepasst aber es tut sich immer noch nichts. :(

Markus.Handy:absent 00:03:15 Markus.Handy:present set rr_Markus absent;; setstate wd.rr.Markus.presence defined
attr wd.rr.Markus.presence regexp1WontReactivate 1

Das Log habe ich auf verbose=4 gesetzt; dennoch kommt keine Hinweismeldung

Markus.Handy = absent
wd.rr.Markus.presence = Next: 17:35:15
state von rr_Markus = home

Gebe ich den Befehl set rr_Markus absent  in der Kommandzeile ein wird der Status erfolgreich umgesetzt.


Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Bademeister am 12 April 2015, 10:13:55
Ich habe eben mal den Teil set rr_Markus absent auf set 44.sz.RO.Rolladen down geändert... auch dieser Befehl wird nach Erkennung der Abwesenheit nicht durchgeführt. Woran könnte das liegen? Hier nochmal der komplette String:

Markus.Handy:absent 00:01:00 Markus.Handy:present set 44.sz.RO.Rolladen down ;; setstate wd.rr.Markus.presence defined
attr wd.rr.Markus.presence regexp1WontReactivate 1
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 12 April 2015, 12:01:06
Ich kann nur vermuten, dass es am doppelten ;; liegt. Eigentlich müsste es wohl eher so aussehen:


define wd.rr.Markus.presence watchdog Markus.Handy:absent 00:01:00 Markus.Handy:present set rr_Markus absent; setstate wd.rr.Markus.presence defined


Ansonsten empfehle ich dir einen eigenen Thread dafür zu eröffnen, es scheint eher ein Watchdog Problem zu sein.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 15 August 2015, 08:39:43
Diese Module sind eine tolle Sache!!!

Aber ein paar Fragen habe ich noch zum Status und dem Wechsel desselben. Beispiel:
Sobald ich "mich" da richtig implementiert habe, werde ich es auch für meine Ehefrau tun - dann wird es spannend. Wenn dann etwas schief geht... :'(
Was sich mir noch nicht erschlossen hat, ist wie man mit den Gästen umgeht und was da Sinn macht. Und "Homestatus" habe ich noch nicht gelesen, kommt jetzt als nächstes.

Nachtrag: wie kann ich genau die Grafik (das Icon) des Homestatus anzeigen?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 16 August 2015, 03:29:29

Das sind aber eine Menge...


Ich bin weit (und damit längere Zeit) weg von Zuhause und mein Zustand ist "gone"
Auf meinem Android-Telefon ist Egigeozone installiert und wenn ich in den Umkreis von einem Kilometer meines Hauses komme, setze ich den Zustand auf "absent"


Warum? Also du meinst wenn du den 1km Radius verlässt? 1km ist ein sehr großer Radius für den Homestatus.
Hast du den Wiki Artikel gelesen? Vorgesehen ist eher, dass du die location über "set rr_Juergen location ..." setzt, den Rest erledigt das Modul und setzt dann je nach Location verlassen oder ankommen den Status entsprechend.


Zitat
Wenn ich dann wirklich zu Hause bin (aktuell noch über einen Taster neben der Haustüre manuell ausgelöst), setze ich den Zustand auf "home"


Wenn man nur mit Taster arbeitet, die richtige Vorgehensweise. Zusammen mit Geofencing ist es falsch, dort wird nur die Location gesetzt, nicht der Status.
Dein Status wird über die Geofencing Location bereits vor Betreten des Hauses auf "home" gesetzt, also je nach Radius wenn du im 100m Umkreis bist.


Zitat
Wenn ich dann wieder weggehe, drücke ich den Taster und der Zustand wechselt auf "absent". Über Egigeozone will ich dann auf "gone" wechseln.


Gedacht ist das so nicht. Du kannst die Events, die in GEOFANCY aber so auswerten und verwenden, wie du sie möchtest.


Zitat
Der 36-Stunden-Timer wäre dann nur noch für den Fall, dass das Mobiltelefon ausfällt, richtig?


In deinem Fall wohl ja.


Zitat
"gotosleep" setze ich (wie auch immer) explizit.


Ich mache das über einen mehrfach belegten Homematic Taster neben meinem Bett:
Lange den Ausschaltknopf nach unten gedrückt halten heißt "gotosleep", lange den Ausschaltknopf nach oben gedrückt halten heißt "asleep". Wenn der Status bereits auf "gotosleep" ist, genügt auch ein einfaches Licht ausschalten mit kurzem Druck auf den oberen Taster, um auf "asleep" zu schalten. Fürs aufwachen ist es ähnlich, je nachdem ob das Weckprogramm schon/noch läuft oder nicht.


Zitat
Muss ich "asleep" auch explizit setzen? Das kann ich ja ggf. über einen Timer von 10 Minuten machen - oder über den oben erwähnten Drucksensor unter dem Bett


Die Frage haben wohl viele. Ich finde ja immer ich weiß selbst am besten, wann ich die Augen zumachen will und ein Buch, das iPhone oder was auch immer zur Seite lege (siehe oben). Aber da hat jeder andere Gewohnheiten, auch das mit einem 10min Timer kann praktikabel sein. Muss jeder selbst für sich überlegen.


Zitat
Wenn der Wecker klingelt, setze ich wieder händisch auf "awoken", richtig? Wenn ich den integrierten Wecker nutze funktioniert das dann automatisch?


Ja. Auch ohne so ein Weckprogramm würdest du ja sehr wahrscheinlich auch irgend ein Licht als erstes einschalten. Hier schaltest du mit dem Taster eben den Status auf "awoken" und dadurch wird indirekt dein Licht (und alles andere) geschaltet. Praktikabel wie ich finde.


Zitat
Der Wechsel von "awoken" nach "home" muss auch händisch erfolgen. Gibt es einen integrierten Timer wie bei "absent"?


Jaein. Im Beispiel-Weckprogramm ist es so vorgestellt, dass es nach wenigen Sekunden automatisch passiert. Dafür ist das Notify, welches auf "awoken" triggert, zuständig.


Zitat
Was passiert, wenn (warum auch immer) ein Wechsel von "asleep" nach "gone" erfolgt? Oder irgendein anderer inkonsistenter Wechsel.


Das kommt einzig auf deine Automation drum herum an. Von Modulseite aus passiert da nichts inkonsistentes oder unerwartetes. Der Presence-State wird auf "absent" gesetzt und das wars. Ein Wecker würde nicht mehr auslösen. FHEM ist grundsätzlich ja Event gesteuert: Ist nichts für das Event "gone" definiert, passiert auch nix weiter.


Ich würde vorschlagen du spielst deine Fälle einfach mal durch und schaust was passiert. Ich kann dir hier nicht sämtliche Vorgänge aufzählen, denke aber sie passieren so wie man es erwarten darf.
An den Modulen ist da nix weiter unerwartet, es werden hauptsächlich die Status kumuliert und die abhängigen Readings aktualisiert.


Zitat
Ist "mood" zur freien Verwendung oder sollen da auch noch Funktionen kommen?


Es war/ist dafür vorgesehen, dass jemand händisch (oder durch eine was-auch-immer-Steuerung) angeben kann, wie der Gemütszustand gerade ist. Davon abhängig kann dann z.B. die Farbe einer Leuchte bestimmt werden o.ä., da ist der Kreativität keine Grenze gesetzt. In gewisser Weise kann man das auch zweckentfremden, da man die Moods ja selbstständig festlegen kann. Ist aber auch nichts anderes als das, was man mit einem Dummy nicht auch machen könnte. Ist hier halt nur mit im gleichen Device mit drin. Das einzige ist halt, dass der Mood beim Schlafengehen entsprechend wechselt, das ist alles.


Zitat
Was sich mir noch nicht erschlossen hat, ist wie man mit den Gästen umgeht und was da Sinn macht.


Das kommt auf deine Fantasie an. Sie könnten ihren Status manuell über ein Tablet setzen oder übers Gäste WLAN oder über einen Handsender... up to you.
Das ist vor allem Sinnvoll, wenn Gäste ein eigenes Weckprogramm bekommen sollen oder sie z.B. im Wohnzimmer übernachten, was du sonst aber in deinem eigenen Weckprogramm komplett ausschaltest. Bei Anwesenheit eines Gastes könnte das dann von deinem Zubettgeh-Programm ausgenommen werden. Etc etc... da muss man selbst drüber nachdenken, jeder hat andere Umstände.


Zitat
Und "Homestatus" habe ich noch nicht gelesen, kommt jetzt als nächstes.


Keine Ahnung, was du mit Homestatus meinst. Das Modul HOMESTATE gibt es noch nicht bisher, daran tüftel ich noch.


Zitat
Nachtrag: wie kann ich genau die Grafik (das Icon) des Homestatus anzeigen?


Wie ist Homestatus jetzt hier gemeint/definiert?
Welche Grafik meinst du? Das Attribut devIconState ist entsprechend vorbelegt und kann nach belieben geändert werden.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 16 August 2015, 08:20:21
Zuerst einmal VIELEN DANK für die ausgiebigen Antworten.

Hast du den Wiki Artikel gelesen? Vorgesehen ist eher, dass du die location über "set rr_Juergen location ..." setzt, den Rest erledigt das Modul und setzt dann je nach Location verlassen oder ankommen den Status entsprechend.

Welchen Wiki-Artikel? Der über Anwesenheitserkennung hilft mir hier irgendwie nicht so recht. Wo kann ich genauer erfahren wie der Zusammenhang location - status ist? Momentan setze ich den Status, nicht die Location.
Mein Verständnis:
home = ich bin im Haus
absent = ich bin im Umkreis von ca. 1km, ich muss ja nicht jedesmal das WLAN ausschalten, blos weil ich in die Garage gehe  :)
gone = ich bin weg und WLAN, alle Lichter und die Stereoanlage sind aus
Und aus der Commandref entnehme ich:
Zitat
Unter bestimmten Umständen führt der Wechsel des Status auch zu einer Änderung des Readings 'location'.
Also ich ändere den Status und die Location wechslt automatisch mit. Unter Location könnte ich mir ja auch Haus, Garten, Balkon, ggf. sogar die Zimmer vorstellen - oder auch die Koordination, wo ich mich befinde.

Keine Ahnung, was du mit Homestatus meinst. Das Modul HOMESTATE gibt es noch nicht bisher, daran tüftel ich noch.
...
Welche Grafik meinst du? Das Attribut devIconState ist entsprechend vorbelegt und kann nach belieben geändert werden.
Es geht um das Device Residents in der Gruppe Home State. Das Device hat ein festes Icon (blaues, ausgefülltes Haus), der Status wird mit weiteren Icons angezeigt. Letztere meinte ich.
Wenn ich die SVG durch PNG ersetze, dann bekomme ich im Floorplan eine Anzeige - das habe ich mittlerweile herausbekommen. Muss mal suchen, ob ich dazu etwas finde, denn im FHEM Webfrontend ist ja alles bestens, warum es im Floorplan nicht geht??!?

Kannst du bitte nochmals erklären, was es mit dem Attribut "wakeupResetdays" auf sich hat? Ich habe wohl einen Knoten im Hirn, aber der Reset eines Weckers ist mir einfach nicht klar. DIe Erklärung aus dem Wiki habe ich einfach nicht verstanden. Und was bedeutet ein deaktiviertes, resp. ein aktiviertes Reset?

Ich habe zwar noch mehr Fragen, aber das reicht für's erste.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: kjmEjfu am 16 August 2015, 12:40:53
Keine Ahnung, was du mit Homestatus meinst. Das Modul HOMESTATE gibt es noch nicht bisher, daran tüftel ich noch.

vielleicht ist da ja http://siio.de/lichtschatten/die-perfekte-lichtsteuerung-mit-fibaro-lua-teil-1/ eine Inspiration für
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 16 August 2015, 12:42:39
Welchen Wiki-Artikel? Der über Anwesenheitserkennung hilft mir hier irgendwie nicht so recht. Wo kann ich genauer erfahren wie der Zusammenhang location - status ist?


Genau den Artikel. Der Zusammenhang location<>state und state<>location wird in der Commandref erklärt.
"Zusammenhang zwischen Anwesenheit/Presence und Aufenthaltsort/Location" beschreibt dabei das Verhalten, dass man manuell den Status ändert. "Zusammenhang zwischen Aufenthaltsort/Location und Anwesenheit/Presence" beschreibt den Fall, dass man über die Änderung der Location steuert.
Eine Mischung daraus ist explizit vorgesehen. Bei Nutzung des GEOFANCY Moduls macht es aber keinen Sinn, über GEOFANCY den Status zu ändern; es ist dafür vorgesehen die Location zu ändern.


Ansonsten findest du das Verhalten entweder durch lesen des Source-Code oder durch ausprobieren und beobachten der Readings heraus.


home = ich bin im Haus
absent = ich bin im Umkreis von ca. 1km, ich muss ja nicht jedesmal das WLAN ausschalten, blos weil ich in die Garage gehe  :)
gone = ich bin weg und WLAN, alle Lichter und die Stereoanlage sind aus


Die Bedeutung von "absent" wird beschrieben als:
"Mitbewohner ist momentan nicht zu Hause, wird aber bald zurück sein".


Damit ist keine räumliche Nähe wie 1km Radius gemeint, sondern ganz einfach, dass du in der Regel am gleichen Tag wieder zurück bist. Trotzdem sollten nach meinem Verständnis bei diesem Status alle Verbraucher (wo es Sinn macht) ausgeschaltet werden (bezogen auf den Gesamtstatus über alle Bewohner im RESIDENTS Device natürlich, sprich also wenn wirklich alle Bewohner auf der Arbeit, in der Schule, beim Einkauf, etc sind.).


"gone" bedeutet eine längere Abwesenheit im Sinne von ich bin verreist, ich mache Urlaub, ich bin auf Geschäftsreise und ich komme nicht am gleichen oder nächsten Tag zurück. Hier könnte man z.B. die Heizung deutlich weiter runterregeln oder die Alarmanlage anders schalten. Bei mir ist es so, dass ich da alle Rollläden dauerhaft nach unten fahre und keine Beschattungsprogramme mehr laufen, die aber ansonsten bei "absent" noch während meiner kurzen Abwesenheit aktiv werden können.
Ich gehöre nicht zu denjenigen, die WLAN oder sowas ausschalten, sowas halte ich für nicht sinnvoll (Infrastruktur ist Infrastruktur; ich drehe ja auch nicht den Wasser-Haupthahn zu oder schalte alle Sicherungen aus, wenn ich das Haus verlasse ;-)). Aber was man alles wann schaltet, das bleibt jedem selbst überlassen. Das schreibt einem kein Modul vor.


Zusammengefasst: "absent" sagt generell aus, dass man nicht da ist. "gone" sagt aus, dass das Haus nicht damit rechnen muss, dass man am gleichen oder darauf folgenden Tag wieder zu Hause sein wird.


Wie groß dein "Anwesen" ist und was du als Radius einstellst, ist natürlich individuell. Wenn deine Garage fast 1km weit weg ist, kann das Sinn machen. Ansonsten sollten auch 100m gut funktionieren. Wenn da schon ausgelöst wird, obwohl deine Garage 10m neben der Haustür ist, stimmt was mit dem Geofency Nachbau deiner Android App nicht und der Entwickler sollte sich an die Nase fassen.


Und aus der Commandref entnehme ich:Also ich ändere den Status und die Location wechslt automatisch mit. Unter Location könnte ich mir ja auch Haus, Garten, Balkon, ggf. sogar die Zimmer vorstellen - oder auch die Koordination, wo ich mich befinde.


Das ist richtig. Die Location nimmt auf den Status so Einfluss, wie es über die Attribute rr_location* eingestellt ist. Alle Locations, die dort nicht konfiguriert sind, ändern auch den Status nicht und können dann z.B. für Schaltungen innerhalb des Hauses genutzt werden. Ich setze dazu iBeacons ein und kann daraufhin bei betreten oder verlassen eines Raumes etwas schalten. Aktuell entwickle ich darauf basierend ein Routing für Audio-Benachrichtigungen, so dass mir Mitteilungen über Sonos immer in dem Raum "zugestellt" werden, in dem ich mich gerade befinde, statt sie im ganzen Haus durchzusagen (siehe hier (http://forum.fhem.de/index.php/topic,39983.0.html)).


Es geht um das Device Residents in der Gruppe Home State. Das Device hat ein festes Icon (blaues, ausgefülltes Haus), der Status wird mit weiteren Icons angezeigt. Letztere meinte ich.
Wenn ich die SVG durch PNG ersetze, dann bekomme ich im Floorplan eine Anzeige - das habe ich mittlerweile herausbekommen. Muss mal suchen, ob ich dazu etwas finde, denn im FHEM Webfrontend ist ja alles bestens, warum es im Floorplan nicht geht??!?


Ich nutze den Floorplan nicht. Das ist eine reine Floorplan Geschichte, bitte dazu im Floorplan Thread nachfragen.


Kannst du bitte nochmals erklären, was es mit dem Attribut "wakeupResetdays" auf sich hat? Ich habe wohl einen Knoten im Hirn, aber der Reset eines Weckers ist mir einfach nicht klar. DIe Erklärung aus dem Wiki habe ich einfach nicht verstanden. Und was bedeutet ein deaktiviertes, resp. ein aktiviertes Reset?


Das Attribut ist dafür da automatisch auf eine bestimmte Weckzeit zu stellen (=Reset auf eine Standard Weckzeit).
Bei mir steht die Zeit auf 07:30. Wenn ich dann mal zu einer früheren Zeit geweckt werden will/muss, dann stelle ich sie am Abend individuell über die Auswahlbox entsprechend. Ich möchte aber in der Regel am übernächsten Tag nicht wieder so früh geweckt werden. Bei gesetztem Attribut wakeupResetdays kann ich dann steuern, an welchen Wochentag nach dem Wecken wieder auf 07:30 gestellt werden soll. Bei meinem Mo-Fr Wecker steht das Reading auch auf Mo-Fr, sprich der wird immer sofort zurückgesetzt. Für diesen Wecker habe ich auch den Reset-Switcher konfiguriert, damit ich das Zurücksetzen des Weckers auch mal für ein paar Tage ausschalten kann, falls ich weiß, dass ich doch ein paar Tage hintereinander früher aufstehen muss. Jeden Sonntag morgen setze ich dann diesen Reset Switcher auf "auto", da ich bei mir davon ausgehe, dass ich in einer neuen Woche wieder zur gewohnten Zeit aufstehen kann. Ansonsten stelle ich Sonntag Abend ohnehin den Wecker für Montag früh anders. Es ist doch so: An Ausnahmen der Regel denkt man immer, aber wenn alles so ist wie immer denkt man nicht daran, das man den Wecker wieder auf die gewohnte Zeit stellen muss und ärgert sich, plötzlich 2h früher geweckt zu werden (vor allem, weil Samstag und Sonntag andere Wecker zu einer anderen Zeit geweckt haben und man dort noch nicht bemerkt hat, dass der Wecker noch so früh eingestellt ist).
Das hängt bei mir auch damit zusammen, dass die Wecker generell immer wecken, wenn ich zuhause bin. Egal ob ich vorher den Status auf "asleep" gesetzt habe oder nicht. "asleep" steuert bei mir nur das ausschalten der Geräte, nicht wie das Weckprogramm läuft. Hintergrund: Wenn ich mal auf dem Sofa einschlafe oder aus sonst einem Grund nicht auf "asleep" schalte, dann möchte ich trotzdem geweckt werden. Sonst brauche ich kein Weckprogramm, wenn ich mich nicht darauf verlassen kann, dass ich auch immer zuverlässig geweckt werde...


Bei meinem Samstag oder Sonntags Wecker steht der Wert nur auf jeweils Samstag oder Sonntag. So kann ich auch während der Woche schon eine Weckzeit vorher einstellen, bin aber trotzdem sicher, dass an dem darauf folgenden Wochenende wieder zu meiner gewohnten Zeit geweckt wird, ohne dass ich daran denken müsste die Weckzeit zuvor einmal verändert zu haben.


Diese Funktion ist generell ein Angebot (wie so vieles), man kann seine Automation drum herum auch selbst so schreiben, wie man es will. Niemand wird gezwungen es zu verwenden, darf aber überlegen, ob er es für sich sinnvoll einsetzen oder erweitern kann.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 16 August 2015, 12:45:19
vielleicht ist da ja http://siio.de/lichtschatten/die-perfekte-lichtsteuerung-mit-fibaro-lua-teil-1/ (http://siio.de/lichtschatten/die-perfekte-lichtsteuerung-mit-fibaro-lua-teil-1/) eine Inspiration für


Die Tageszeit spielt beim geplanten HOMESTATE Modul eine Rolle, ja.
Ich habe die Modulfunktion auch schon in Dummys und jeder Menge DOIFs nachgebaut, feile aber noch an Details bevor ich weiß, wie ich das in ein Modul gießen möchte. Es kann sogar sein, dass es ähnlich wie der Wecker auch nur als eine Art Vorlage mit in das RESIDENTS Modul kommt, mal sehen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 16 August 2015, 13:42:10
Danke, jetzt habe ich wohl die wsentliche Philosophie dahinter verstanden!
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: rrr am 22 August 2015, 22:17:56
Wie kann ich bspw. einen zusätzlichen Status "returnToHome" einstellen?

Ich möchte wenn ich auf dem Weg nach Hause bin, bereits die Klimaanlage und/oder Heizung laufen lassen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 23 August 2015, 07:20:31
Wie kann ich bspw. einen zusätzlichen Status "returnToHome" einstellen?

Ich möchte wenn ich auf dem Weg nach Hause bin, bereits die Klimaanlage und/oder Heizung laufen lassen.

In der commandref (http://fhem.de/commandref.html#ROOMMATE (http://fhem.de/commandref.html#ROOMMATE)) steht:
Whenever location is set to 'wayhome', the reading 'wayhome' is set to '1' if current presence state is 'absent'. If attribute rr_locationWayhome was defined, LEAVING one of those locations will set reading 'wayhome' to '1' as well. So you actually have implicit and explicit options to trigger wayhome.
Arriving at home will reset the value of 'wayhome' to '0'.
Damit müsste deine Anforderung doch erfüllbar sein.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 01 September 2015, 13:36:38
Darf ich noch eine Frage stellen?

Es gibt vordefinierte notify für gotosleep, asleep und awoken. Warum (nur) diese? Ich werde mir nun auch notify für home, gone und absent erstellen... Und warum gibt es die zusätzlichen watchdogs?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 01 September 2015, 14:46:19
Du spricht von der Wecker Vorlage?


Ganz einfach, weil die Vorlage eben nur ein Beispiel sein kann und man es ohnehin anpassen muss. Daher ist es minimal gehalten, erweitern kann man immer ;)
Die definierten Watchdogs sind Teil der Weckautomations-Vorlage und dienen dazu, dass die Ausführung der Macro-Notifies verzögert wird, um z.B. bei einem versehentlichen Statuswechsel (und wieder zurück) nicht direkt auszulösen.


Die Status home, gone und absent haben nichts mit dem Weckprogramm zu tun, sondern sind Teil der generell immer individuelle Automatisierung, die jeder für sich und seine Anforderungen/Vorstellungen selbst in FHEM definiert.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 01 September 2015, 17:57:35
Ok, soweit klar, jetzt habe ich mir eine LightScene erstellt, deren Szenen genau so heißen, wie der Status von Residents (bei mir heißt das Device "menschen") sein kann. Insbesondere eben home, abesnt und gone. Die LightScene funktioniert perfekt, solange ich sie über die Kommandozeile anspreche, z.B. set myLS scene home

Nun wollte ich ein einfaches notify mit folgender Definition machen:
menschen set myLS scene $EVENTImmer wenn sich der Status von menschen ändert, wird das notify getriggert und myLS gesetzt. Leider funktioniert das nicht, ich bekomme in myLS als Status nicht die neue Szene sondern "lastActivityBy:"

Anfängerdoku sagt mir aber, dass das so richtig sein sollte -  oder habe ich einen Knoten im Kopf?

Wenn hier falsch aufgehängt, dann bitte kurze Info, dann poste ich es an anderer Stelle und lösche es hier.

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 01 September 2015, 18:00:38
du musst das Event auf :state einschränken. Es werden mehrere Events zusammen ausgelöst, wenn du menschen veränderst. oder du setzt hei menschen das Attribut event-on-change-reading=state. Sind aber alles FHEM Basics, da solltest du dich nochmals einlesen ;-)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 02 September 2015, 18:20:49
Dein Weckprogramm hat mir schon jede Menge Arbeti erspart, Dinge selbst auszutüfteln. Für eine Kleinigkeit suche ich noch einen eleganten Weg: Es kommt ein paar Mal im Jahr vor, dass ich am nächsten tag keinen Wecker haben will. Ich möchte demzufolge am Vorabend, wenn ich schlafen gehe, einmalig den Wecker ausschalten, am nächsten Morgen kann ich dann bis in ide Puppen schlafen - aber am Folgetag soll er wieder ganz normal klingeln. Hast du eine gute Idee? Ich würde ihn über Tastendruck ganz ausschalten und mit dem nächsten "gotosleep" wieder einschalten.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 03 September 2015, 16:12:39
Genau dafür ist eigentlich die Reset-Funktion gedacht.
Der Wecker wird dann am Folgetag zu der Zeit, zu der er zuletzt aktiv war, automatisch wieder mit der im Attribut wakeupDefaultTime hinterlegten Zeit aktiviert. Die Funktion ist also sowohl für das Zurücksetzen kurzzeitig veränderter Wecker gedacht als auch für das erneute Aktivieren kurzzeitig deaktivierter Wecker. Wenn das Attribut wakeupResetdays nicht gesetzt ist, wird der Wecker täglich entsprechend auf die Default-Zeit gesetzt.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 14 September 2015, 21:49:15
Das Modul funktioniert erstklassig (DANKE!), auch der Wecker!

Aber gestern ist bei uns folgendes passiert: weil Sonntag ist, klingelt der Wecker um 9 Uhr. Allerdings sind wir um 8 Uhr aufgestandenund haben den Status der Person auf Home gestellt. Die Erwartung war, dass der Wecker nicht klingelt, wenn man nicht "asleep" ist. Er hat aber dennoch "geklingelt" - und man konnte ihn nicht wie gewohnt durch Druck auf die Taste, die den Staus der Person auf "Home" stellt, abschalten. Mhm ??!?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 16 September 2015, 15:44:41
Es ist absicht, dass der Wecker "klingelt", egal wie der Status des Bewohners dabei ist (beispielsweise weil man aus welchem Grund auch immer abends vergessen sollte sich "schlafend" zu stellen). Ansonsten würde man Gefahr laufen, dass der Wecker nicht klingelt und man verschläft. Für ein früheres Aufstehen ist das grundsätzlich noch ein Problem. Zwar wird bereits berücksichtigt, dass bei Nutzung der Reset Funktion der Wecker bei einer späteren Default-Zeit nicht erneut auslöst. Für ein früheres Aufstehen fehlt allerdings eine Abfrage noch, wann der Status des Bewohners sich zuletzt geändert hat. Ich schaue mal, dass ich das bei Gelegenheit mit einbaue.


Ansonsten ist für das explizite Unterbrechen eines Weckprogramms nicht vorgesehen, dass man den Status des Bewohners wechselt (auch wenn das implizit beim aufstehen passiert). Vielmehr soll beim entsprechenden Wecker ein stop-Befehl geschickt werden. devStateIcon ist dafür bereits so vordefiniert, dass der Wecker ein blaues Icon hat, wenn er gerade aktiv ist und man nur dort drauf drücken muss, um ihn zu unterbrechen (entspricht einem set-Befehl "stop").




Gruß
Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: LeoSum am 19 September 2015, 03:26:27
Hallo Leute,
ersteinmal danke für dieses tolle Modul.

Leider schaffe ich es bislang noch nicht, den Status von Geräten die ich mit PRESENCE erfolgreich überwache an die Residents weiter zu geben. Wie mache ich das? Mit notifies oder watchdogs? Bislang werden folgende Geräte mit PRESENCE überwacht:

mako_bluetooth
Wlan_Device_klte
Wlan_Device_mako

mako_bluetooth und Wlan_Device_mako sollen dem Resident rr_Leo zugeordnet werden, Wlan_Device_klte dem Resident rr_Peter.

Bislang habe ich foldendes probiert aber es klappt einfach nicht:

define mako_WLAN_home notify Wlan_Device_mako:present set rr_Leo home
define mako_Bluetooth_home notify Bluetooth_Device_mako:present set rr_Leo home
define mako_WLAN_absent notify Wlan_Device_mako:absent set rr_Leo absent
define klte_WLAN_home notify Wlan_Device_klte:present set rr_Peter home
define klte_WLAN_absent notify Wlan_Device_klte:absent set rr_Peter absent

Leider tut sich da aber nix. Die PRESENCE devices spiegeln den Status korrekt wieder, aber die Residents bleiben immer auf dem Status "home".

Die PRESENCE devices haben alle das attribut "event-on-change-reading state"

Weiß jemand Rat?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 19 September 2015, 11:10:46
es muss heißen
set rr_Peter state absentusw.

Da bin ich auch darüber gestolpert  ;)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 19 September 2015, 12:03:55
Wie ich ein notify baue, welches triggert, sobald der Status auf "home" geht, weiß ich. Aber ich möchte unterscheiden ob es von "absent nach home" gewechselt hat oder ob es von "asleep nach home" gewechselt hat. Kann mir bitte jemand mal einen Tipp geben?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: LeoSum am 19 September 2015, 14:22:30
Danke ujaudio! Jetzt klappt es!

Als nächstes möchte ich natürlich basierend auf den Stati der Residents Aktionen durchführen. Alles ausschalten wenn keiner zu Hause ist ist glaub ich einfach (Wohnung1 ist mein Residents device):

define watchdog_Anwesenheit watchdog Wohnung1:absent 00:15 Wohnung1:home set Gesamte_Wohnung off ;; setstate watchdog_Anwesenheit defined
attr watchdog_Anwesenheit regexp1WontReactivate 1

Aber wie kann ich lösen, dass wenn Leo nach hause kommt, das Licht in der Küche angeht, aber nur wenn Peter nicht da ist? Kann das Event für das Notify irgendwie eine "&"-Verknüpfung sein oder kann man das ganze in eine If bedingung packen? Wie würde so ein Notify aussehen?

Zitat
Aber ich möchte unterscheiden ob es von "absent nach home" gewechselt hat oder ob es von "asleep nach home" gewechselt hat. Kann mir bitte jemand mal einen Tipp geben?

Kann man hierzu nicht irgendwie das Reading "lastState" über eine "&" Verknüpfung mit einbeziehen? Ich blicke leider durch die FHEM/Perl Syntax nicht durch, sodass das Programmieren hier eher zum Ratespiel wird. Irgendwie gibt es zu den Residents auch keine "get" Methode...
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 19 September 2015, 14:43:09
schau Dir mal das DOIF Modul an...
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: LeoSum am 19 September 2015, 17:35:49
Danke für den Hinweis. Es funtkioniert schon fast:

define Leo_coming_home_di DOIF ([rr_Peter] eq "absent" and [rr_Leo] eq "home") (set SqueezeKueche volume 90; sleep 0.5; set SqueezeKueche playlists Metal; sleep 0.5; set SqueezeKueche shuffle song; sleep 0.5; set SqueezeKueche play)
lässt die Squeezebox losspielen wenn Leo heimkommt und Peter weg ist. Allerdings spielt sie auch los, sobald Peter das Haus verlässt. Das möchte ich nicht. Wie setze ich das mit DOIF um?

Normalerweise würde ich zwei verschachtelte If-Bedinungen verwenden, wobei der trigger die äußere wäre. Mit DOIF geht das aber scheinbar nicht.

Die Definition:

define Leo_coming_home_di DOIF ([rr_Leo] eq "home") DOIF ([rr_Peter] eq "absent") (set SqueezeKueche volume 90; sleep 0.5; set SqueezeKueche playlists Metal; sleep 0.5; set SqueezeKueche shuffle song; sleep 0.5; set SqueezeKueche play)
gibt den Fehler im Logfile:
2015.09.19 17:11:59 2: Leo_coming_home_di: DOIF (home eq "absent") (set SqueezeKueche volume 90; sleep 0.5; set SqueezeKueche playlists Metal; sleep 0.5; set SqueezeKueche shuffle song; sleep 0.5; set SqueezeKueche play): Unknown command DOIF, try help.
Jemand eine Idee wie ich das hinbekommen kann?

EDIT:
In Anlehnung hieran habe ich es jetzt hinbekommen: http://www.fhemwiki.de/wiki/Schalten_mit_mehreren_Bedingungen#Script

define Leo_coming_home_notify rr_Leo:home {if ($value{rr_Peter} eq "absent") {fhem "set SqueezeKueche volume 80; sleep 0.5; set SqueezeKueche playlists Metal; sleep 0.5; set SqueezeKueche shuffle song; sleep 0.5; set SqueezeKueche play"}}
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: der-Lolo am 19 September 2015, 18:20:41
Nur auf den Zustand eines devices zu reagieren und beim umschalten nicht zu triggern funktioniert mit dem ? Schau Dir mal die Comandref an, DOIF ist ausgezeichnet dokumentiert - ansonsten hilft Dir sicher der zugehörige Support Thread...
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 28 September 2015, 11:34:43
Ich habe gerade eine neue Version des RESIDENTS Moduls eingecheckt, welches nun neben den nummerischen Readings auch welche mit den Device und Alias Namen erzeugt. Hilfreich, wenn man den Klarnamen z.B. in einer Audio Ansage verwenden oder die Devices anderweitig im Code weiterverarbeiten möchte.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: r_knipp am 31 Oktober 2015, 13:00:17
Moin,

ich habe mich jetzt mal etwas intensiver mit dem Residents Tool Kit beschäftigt und habe etwas Probleme damit, die ich bisher nicht lösen konnte.
Zum einen sind die einzigen Modi, die ich für einen Roommate auswählen kann home, gotosleep, absent und gone. Asleep oder awoken werden in dem Dropdown nicht angezeigt.
Zum anderen wird mir der Resetswitcher nicht angezeigt, obwohl ich im Wakeuptimer das Attribut definiert habe.
Mein FHEM ist auf dem aktuellen Stand. Hat jemand nen Tip wo der Fehler liegen kann? Oder habe ich vielleicht eine Einstellung vergessen? (Wahrscheinlich sitzt der Fehler wieder vor dem Monitor  ;))
Besten Dank.

Gruß
Robert
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 31 Oktober 2015, 13:15:33
Hallo Robert,


du meinst nicht das RESIDENTStoolkit, dieser Begriff ist anders belegt  ;)
Du sprichst von der RESIDENTS Modulfamilie (also RESIDENTS, ROOMMATE, GUEST).


Wie in der Commandref beschrieben werden die Status asleep und awoken nur dann aufgeführt, wenn der aktuelle Status entweder gotosleep oder asleep ist. Der Grund ist einfach, dass hier eine Art Mini-Prozess abgebildet ist: Du wachst vermutlich nicht auf, wenn du nicht vorher geschlafen hast... Die Status direkt anzuspringen macht daher eigentlich keinen Sinn. Wenn du anderer Meinung bist, kannst du die Status über das Attribut "rr_showAllStates" einblenden. Alternativ kannst du auch nur ganz gezielte Status über das Attribut "rr_states" einblenden (widgetOverride sollte auch funktionieren, wer es bevorzugt).


Der Resetswitcher ist wiederrum korrekterweise Teil des RESIDENTStoolkit  :D
Der Resetswitcher wird automatisch angelegt, wenn du im Wecker-Device ein Attribut mit dem Namen wakeupResetSwitcher anlegst. Das Attribut muss den Namen des Gerätes enthalten, welches als Resetswitcher angelegt werden soll. Es darf unter dem Namen kein anderes Gerät geben und es darf kein Leerzeichen oder so im Namen geben.
Du kannst das Attribut auch nochmals löschen und wieder neu anlegen. Ein ggf. bereits erzeugtes Device muss zuvor manuell wieder gelöscht werden.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: r_knipp am 31 Oktober 2015, 15:47:47
Wie in der Commandref beschrieben werden die Status asleep und awoken nur dann aufgeführt, wenn der aktuelle Status entweder gotosleep oder asleep ist.

Sowas dachte ich mir schon. Allerdings wird mir asleep auch nicht angezeigt wenn ich gotosleep ausgewählt habe.

Der Resetswitcher wird automatisch angelegt, wenn du im Wecker-Device ein Attribut mit dem Namen wakeupResetSwitcher anlegst. Das Attribut muss den Namen des Gerätes enthalten, welches als Resetswitcher angelegt werden soll. Es darf unter dem Namen kein anderes Gerät geben und es darf kein Leerzeichen oder so im Namen geben.

Habe ihn nochmal neu angelegt. Tut trotzdem nicht.
Der Wecker heißt rr_Robert_wakeuptimer1 und der Resetswitcher dazu heißt rr_Robert_wakeuptimer1_ResetSwitcher.
Sollte doch so richtig sein. Oder habe ich das doch falsch verstanden?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 31 Oktober 2015, 15:53:04
Sowas dachte ich mir schon. Allerdings wird mir asleep auch nicht angezeigt wenn ich gotosleep ausgewählt habe.


Das liegt daran, dass FHEMWEB das Auswahlmenü nicht aktualisiert, dafür musst du die Seite manuell neu laden. Rudi hatte das glaube ich mal irgendwann gefixt, ist vermutlich dann wieder kaputt gegangen bei irgend einer Änderung in FHEMWEB.
Was aber aktualisiert wird ist das devStateIcon, weshalb darüber ein Wechsel vom Status "gotosleep" zu "asleep" dann problemlos funktioniert. Die Bedienung über das Icon ist ohnehin bequemer.


Habe ihn nochmal neu angelegt. Tut trotzdem nicht.
Der Wecker heißt rr_Robert_wakeuptimer1 und der Resetswitcher dazu heißt rr_Robert_wakeuptimer1_ResetSwitcher.
Sollte doch so richtig sein. Oder habe ich das doch falsch verstanden?


Du kannst das Device nennen wie du willst. Wenn das automatische Anlegen nicht funktioniert ist es wahrscheinlich, dass  rr_Robert_wakeuptimer1 nicht richtig vom Vatergerät rr_Robert überwacht wird. In diesem Fall fehlt in rr_Robert dann der Verweis auf rr_Robert_wakeuptimer1 im Attribut "rr_wakeupDevice".
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: r_knipp am 01 November 2015, 13:52:58
Was aber aktualisiert wird ist das devStateIcon, weshalb darüber ein Wechsel vom Status "gotosleep" zu "asleep" dann problemlos funktioniert. Die Bedienung über das Icon ist ohnehin bequemer.
Danke für den Hinweis. Über das Icon funktioniert es.

Du kannst das Device nennen wie du willst. Wenn das automatische Anlegen nicht funktioniert ist es wahrscheinlich, dass  rr_Robert_wakeuptimer1 nicht richtig vom Vatergerät rr_Robert überwacht wird. In diesem Fall fehlt in rr_Robert dann der Verweis auf rr_Robert_wakeuptimer1 im Attribut "rr_wakeupDevice".
Das Attribut in rr_Robert ist angelegt und verweist definitiv auch auf den richtigen timer. Der ResetSwitcher wird trotzdem nicht angelegt.
Kann man den auch manuell anlegen?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 01 November 2015, 14:11:51
Das Attribut in rr_Robert ist angelegt und verweist definitiv auch auf den richtigen timer. Der ResetSwitcher wird trotzdem nicht angelegt.
Kann man den auch manuell anlegen?


rr_Robert und rr_Robert_wakeuptimer1 sind dann richtig verbunden, wenn du in rr_Robert beim Attribut rr_wakeupDevice den Namen rr_Robert_wakeuptimer1 mit einem Link versehen hast, auf den du drauf klicken und dann zu dem Gerät gelangen kannst.


Du kannst den Dummy auch manuell anlegen. Es ist aber wahrscheinlich, dass er nicht beachtet wird, wenn das automatische Anlegen schon nicht funktioniert.


define rr_Robert_wakeuptimer1_resetswitcher dummy
attr rr_Robert_wakeuptimer1_resetswitcher alias Wake-up time Reset
attr rr_Robert_wakeuptimer1_resetswitcher devStateIcon auto:time_automatic:off off:time_manual_mode:auto
attr rr_Robert_wakeuptimer1_resetswitcher icon refresh
attr rr_Robert_wakeuptimer1_resetswitcher setList state:auto,off
attr rr_Robert_wakeuptimer1_resetswitcher webCmd state
set rr_Robert_wakeuptimer1_resetswitcher auto
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: r_knipp am 02 November 2015, 13:41:04
rr_Robert und rr_Robert_wakeuptimer1 sind dann richtig verbunden, wenn du in rr_Robert beim Attribut rr_wakeupDevice den Namen rr_Robert_wakeuptimer1 mit einem Link versehen hast, auf den du drauf klicken und dann zu dem Gerät gelangen kannst.
Genau so sieht es aus und das wurde ja auch automatisch angelegt.

Hast Du noch eine Idee woran es liegen kann?
Ich habe auch mal im global device und im Timer verbose auf 5 gestellt. Habe im Log aber nichts gefunden, was auf einen Fehler hinweist.
Das Device jetzt manuell anzulegen, wenn es dann nicht beachtet wird, macht dann ja auch keinen Sinn.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 02 November 2015, 15:26:54
Hast Du noch eine Idee woran es liegen kann?
Ich habe auch mal im global device und im Timer verbose auf 5 gestellt. Habe im Log aber nichts gefunden, was auf einen Fehler hinweist.
Das Device jetzt manuell anzulegen, wenn es dann nicht beachtet wird, macht dann ja auch keinen Sinn.


Habe sonst keine Idee. Was sagt das Log bei verbose=5 sowohl beim Wakeuptimer als auch beim RESIDENTS-Device, wenn du da das Attribut wakeupResetSwitcher beim Wakeuptimer löscht und wieder hinzufügst?


Mit dem manuellen anlegen solltest du trotzdem probieren.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: r_knipp am 02 November 2015, 19:31:29
Hier erstmal der Log bei verbose auf 5 im global und timer device mit Löschen und gleich darauf wieder Anlegen des Attributs.

[code]
2015.11.02 19:26:05 5: Triggering global (1 changes)
2015.11.02 19:26:05 5: Notify loop for global ATTR global verbose 5
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 GET /fhem?detail=global; BUFLEN:0
2015.11.02 19:26:05 4: name: /fhem?detail=global / RL:3305 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 GET /fhem/pgm2/style.css; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50018 GET /fhem/pgm2/jquery.min.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50018 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/jquery-ui.min.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50018 GET /fhem/pgm2/defaultCommon.css; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50018 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_modernbluefeatures.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:05 4: Connection accepted from FHEMWEB:192.168.1.123:50020
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_readingsHistory.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 GET /fhem/pgm2/fhemweb_colorpicker.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50018 GET /fhem/pgm2/fhemweb_knob.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50018 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_readingsGroup.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_sortable.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 GET /fhem/pgm2/fhemweb_fbcalllist.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/dashboard_style.css; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50018 GET /fhem/pgm2/fhemweb_uzsu.js; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50018 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 GET /fhem/images/default/icoEverything.png; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50014 GET /fhem/images/default/fhemicon.png; BUFLEN:0
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 GET /fhem?cmd={AttrVal(%22global%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2015.11.02 19:26:05 5: Cmd: >{AttrVal("global","room","")}<
2015.11.02 19:26:05 4: name: /fhem?cmd={AttrVal(%22global%22,%22room%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 /
2015.11.02 19:26:05 4: FHEMWEB:192.168.1.123:50013 GET /fhem?XHR=1&inform=type=status;filter=global;since=1446488764;fmt=JSON×tamp=1446488765827; BUFLEN:0
2015.11.02 19:26:08 4: FHEMWEB:192.168.1.123:50014 POST /fhem?cmd=save&XHR=1; BUFLEN:0
2015.11.02 19:26:08 5: Cmd: >save<
2015.11.02 19:26:08 5: Triggering global (1 changes)
2015.11.02 19:26:08 5: Notify loop for global SAVE
2015.11.02 19:26:08 4: name: /fhem?cmd=save&XHR=1 / RL:52 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 /
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_GetStatus()
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: REQ powerstate
2015.11.02 19:26:12 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/powerstate (noshutdown=1)
2015.11.02 19:26:12 4: HttpUtils url=http://192.168.1.40:80/web/powerstate
2015.11.02 19:26:12 4: http://192.168.1.40:80/web/powerstate: HTTP response code 200
2015.11.02 19:26:12 4: HttpUtils http://192.168.1.40:80/web/powerstate: Got data, length: 106
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: RCV powerstate
2015.11.02 19:26:12 5: ENIGMA2 VUUno: RES powerstate
<?xml version="1.0" encoding="UTF-8"?>
<e2powerstate>
   <e2instandby>
false   </e2instandby>
</e2powerstate>

2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: REQ getservices/?sRef=1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet&
2015.11.02 19:26:12 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/getservices?sRef=1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet& (noshutdown=1)
2015.11.02 19:26:12 4: HttpUtils url=http://192.168.1.40:80/web/getservices?sRef=1%3a7%3a2%3a0%3a0%3a0%3a0%3a0%3a0%3a0%3aFROM%20BOUQUET%20%22userbouquet%2eradio%5f%5fff%5f%5frechtl%5f%2eradio%22%20ORDER%20BY%20bouquet&
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: REQ getcurrent
2015.11.02 19:26:12 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/getcurrent (noshutdown=1)
2015.11.02 19:26:12 4: HttpUtils url=http://192.168.1.40:80/web/getcurrent
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: REQ timerlist
2015.11.02 19:26:12 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/timerlist (noshutdown=1)
2015.11.02 19:26:12 4: HttpUtils url=http://192.168.1.40:80/web/timerlist
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: REQ vol
2015.11.02 19:26:12 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/vol (noshutdown=1)
2015.11.02 19:26:12 4: HttpUtils url=http://192.168.1.40:80/web/vol
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: REQ signal
2015.11.02 19:26:12 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/signal (noshutdown=1)
2015.11.02 19:26:12 4: HttpUtils url=http://192.168.1.40:80/web/signal
2015.11.02 19:26:12 4: http://192.168.1.40:80/web/getcurrent: HTTP response code 200
2015.11.02 19:26:12 4: HttpUtils http://192.168.1.40:80/web/getcurrent: Got data, length: 3260
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: RCV getcurrent
2015.11.02 19:26:12 5: ENIGMA2 VUUno: RES getcurrent
<?xml version="1.0" encoding="UTF-8"?>
<e2currentserviceinformation>
   <e2service>
      <e2servicereference>1:0:1:D175:2718:F001:FFFF0000:0:0:0:</e2servicereference>
      <e2servicename>ProSieben</e2servicename>
      <e2providername>Digital Free</e2providername>
      <e2videowidth>720</e2videowidth>
      <e2videoheight>576</e2videoheight>
      <e2servicevideosize>720x576</e2servicevideosize>
      <e2iswidescreen>
1      </e2iswidescreen>
      <e2apid>2202</e2apid>
      <e2vpid>2201</e2vpid>
      <e2pcrpid>2201</e2pcrpid>
      <e2pmtpid>101</e2pmtpid>
      <e2txtpid>2204</e2txtpid>
      <e2tsid>10008</e2tsid>
      <e2onid>61441</e2onid>
      <e2sid>53621</e2sid>
   </e2service>
   <e2eventlist>
      <e2event>
         <e2eventservicereference>1:0:1:D175:2718:F001:FFFF0000:0:0:0:</e2eventservicereference>
         <e2eventservicename>ProSieben</e2eventservicename>
         <e2eventprovidername>Digital Free</e2eventprovidername>
         <e2eventid>25698</e2eventid>
         <e2eventname>Galileo</e2eventname>
         <e2eventtitle>Galileo</e2eventtitle>
         <e2eventdescription>Thema u. a.: "Galileo"-Trip zur NSA-Zentrale, Information, D 2015</e2eventdescription>
         <e2eventstart>1446487511</e2eventstart>
         <e2eventduration>4149</e2eventduration>
         <e2eventremaining>2890</e2eventremaining>
         <e2eventcurrenttime>1446488770</e2eventcurrenttime>
         <e2eventdescriptionextended>Moderation: Stefan Gödde

Edward Snowden gilt als der bekannteste Whistleblower unserer Zeit. Bis zu seinen Enthüllungen im Jahr 2013 wusste kaum jemand über die Machenschaften der NSA Bescheid. Jetzt ist der amerikanische Abhördienst in aller Munde. Doch was macht die National Security Agency genau? "Galileo" ist nach Washington gereist, um einen Einblick in die Arbeit des größten Auslandsgeheimdienstes zu bekommen.</e2eventdescriptionextended>
      </e2event>
      <e2event>
         <e2eventservicereference>1:0:1:D175:2718:F001:FFFF0000:0:0:0:</e2eventservicereference>
         <e2eventservicename>ProSieben</e2eventservicename>
         <e2eventprovidername>Digital Free</e2eventprovidername>
         <e2eventid>25699</e2eventid>
         <e2eventname>The Big Bang Theory</e2eventname>
         <e2eventtitle>The Big Bang Theory</e2eventtitle>
         <e2eventdescription>Über Nacht im Fort, Sitcom, USA 2014</e2eventdescription>
         <e2eventstart>1446491660</e2eventstart>
         <e2eventduration>1757</e2eventduration>
         <e2eventremaining>4647</e2eventremaining>
         <e2eventcurrenttime>1446488770</e2eventcurrenttime>
         <e2eventdescriptionextended>Penny wird von Will Wheaton für seinen Podcast interviewt. Während der Show ruft der Regisseur Kevin Smith an und möchte sie für seinen neuen Film casten. Leonard ist von der Idee wenig begeistert ... Howard steht kurz davor, das Haus seiner Mutter zu erben, es fehlt nur noch eine Formalität. Dann taucht plötzlich sein bislang unbekannter Halbbruder Josh auf ...

Gast: Wil Wheaton
Regie: Mark Cendrowski
Drehbuch: Steven Molaro
Kamera: Steven V. Silver
Schnitt: Peter Chakos

Darsteller:
Johnny Galecki (Leonard Hofstadter)
Jim Parsons (Sheldon Cooper)
Simon Helberg (Howard Wolowitz)
Kunal Nayyar (Rajesh Koothrappali)
Kaley Cuoco (Penny)
Mayim Bialik (Amy Farrah Fowler)
Melissa Rauch (Bernadette Rostenkowski)
Matt Bennett (Josh Wolowitz)</e2eventdescriptionextended>
      </e2event>
   </e2eventlist>
</e2currentserviceinformation>

2015.11.02 19:26:12 5: Triggering VUUno (8 changes)
2015.11.02 19:26:12 5: Notify loop for VUUno eventremaining: 2890
2015.11.02 19:26:12 4: http://192.168.1.40:80/web/signal: HTTP response code 200
2015.11.02 19:26:12 4: HttpUtils http://192.168.1.40:80/web/signal: Got data, length: 179
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: RCV signal
2015.11.02 19:26:12 5: ENIGMA2 VUUno: RES signal
<?xml version="1.0" encoding="UTF-8"?>
<e2frontendstatus>
   <e2snrdb> 65 dB </e2snrdb>
   <e2snr> 65 % </e2snr>
   <e2ber> -1245813 </e2ber>
   <e2acg> 76 % </e2acg>
</e2frontendstatus>

2015.11.02 19:26:12 5: Triggering VUUno (4 changes)
2015.11.02 19:26:12 5: Notify loop for VUUno snrdb: 65
2015.11.02 19:26:12 4: http://192.168.1.40:80/web/getservices?sRef=1%3a7%3a2%3a0%3a0%3a0%3a0%3a0%3a0%3a0%3aFROM%20BOUQUET%20%22userbouquet%2eradio%5f%5fff%5f%5frechtl%5f%2eradio%22%20ORDER%20BY%20bouquet&: HTTP response code 200
2015.11.02 19:26:12 4: HttpUtils http://192.168.1.40:80/web/getservices?sRef=1%3a7%3a2%3a0%3a0%3a0%3a0%3a0%3a0%3a0%3aFROM%20BOUQUET%20%22userbouquet%2eradio%5f%5fff%5f%5frechtl%5f%2eradio%22%20ORDER%20BY%20bouquet&: Got data, length: 72
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: RCV getservices/?sRef=1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet&
2015.11.02 19:26:12 5: ENIGMA2 VUUno: RES getservices/?sRef=1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet&
<?xml version="1.0" encoding="UTF-8"?>
<e2servicelist>
</e2servicelist>

2015.11.02 19:26:12 4: ENIGMA2 VUUno: ERROR: Unable to read radio bouquet '1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet' from device
2015.11.02 19:26:12 4: http://192.168.1.40:80/web/timerlist: HTTP response code 200
2015.11.02 19:26:12 4: HttpUtils http://192.168.1.40:80/web/timerlist: Got data, length: 68
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: RCV timerlist
2015.11.02 19:26:12 5: ENIGMA2 VUUno: RES timerlist
<?xml version="1.0" encoding="UTF-8"?>
<e2timerlist>
</e2timerlist>

2015.11.02 19:26:12 4: http://192.168.1.40:80/web/vol: HTTP response code 200
2015.11.02 19:26:12 4: HttpUtils http://192.168.1.40:80/web/vol: Got data, length: 184
2015.11.02 19:26:12 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:12 4: ENIGMA2 VUUno: RCV vol
2015.11.02 19:26:12 5: ENIGMA2 VUUno: RES vol
<?xml version="1.0" encoding="utf-8"?>
<e2volume>
   <e2result>True</e2result>
   <e2resulttext>Status</e2resulttext>
   <e2current>30</e2current>
   <e2ismuted>False</e2ismuted>   
</e2volume>

2015.11.02 19:26:17 5: HMLAN_Send:  hmusb I:K
2015.11.02 19:26:17 5: HMLAN/RAW: /HHM-LAN-IF,03C4,KEQ1111221,2633D6,ABC123,01786608,0003

2015.11.02 19:26:17 5: HMLAN_Parse: hmusb V:03C4 sNo:KEQ1111221 d:2633D6 O:ABC123 t:01786608 IDcnt:0003 L:0 %
2015.11.02 19:26:17 5: Triggering hmusb (1 changes)
2015.11.02 19:26:17 5: Notify loop for hmusb loadLvl: low
2015.11.02 19:26:21 4: Connection closed for FHEMWEB:192.168.1.123:50013: EOF
2015.11.02 19:26:21 4: FHEMWEB:192.168.1.123:50014 GET /fhem?room=all; BUFLEN:0
2015.11.02 19:26:21 5: ENIGMA2 VUUno: called function ENIGMA2_Set()
2015.11.02 19:26:21 5: GEOFANCY geofancy: called function GEOFANCY_Set()
2015.11.02 19:26:21 5: RESIDENTS rgr_Bewohner: called function RESIDENTS_Set()
2015.11.02 19:26:21 5: ROOMMATE rr_Robert: called function ROOMMATE_Set()
2015.11.02 19:26:21 5: SYSMON sysmon_Main: Set.744 sysmon_Main ?
2015.11.02 19:26:21 5: ROOMMATE rr_Sandra: called function ROOMMATE_Set()
2015.11.02 19:26:21 4: name: /fhem?room=all / RL:13595 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/style.css; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/jquery-ui.min.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50018 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50018 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/jquery.min.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/defaultCommon.css; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50018 GET /fhem/pgm2/fhemweb_modernbluefeatures.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50018 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_colorpicker.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:22 4: Connection accepted from FHEMWEB:192.168.1.123:50021
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_readingsHistory.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/fhemweb.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_knob.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50018 GET /fhem/pgm2/fhemweb_readingsGroup.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50018 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_fbcalllist.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_sortable.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/dashboard_style.css; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_uzsu.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/svg.js; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 GET /fhem/images/default/icoEverything.png; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 GET /fhem/images/default/Zoom-in.png; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50021 GET /fhem/icons/weather/cloudy; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 GET /fhem/images/default/fhemicon.png; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50018 GET /fhem/images/default/Zoom-out.png; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50018 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 GET /fhem/icons/weather/partly_cloudy; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50019 GET /fhem/images/default/Prev.png; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50021 GET /fhem/SVG_showLog?dev=SVG_log_temps_Aquarium_1&logdev=log_temps_Aquarium&gplotfile=SVG_log_temps_Aquarium_1&logfile=CURRENT&pos=; BUFLEN:0
2015.11.02 19:26:22 5: plotcommand: get log_temps_Aquarium CURRENT INT 2015-11-01_19:30:00 2015-11-02_19:30:01  4:temp_Aquarium.T\x3a::
2015.11.02 19:26:22 5: Cmd: >get log_temps_Aquarium CURRENT INT 2015-11-01_19:30:00 2015-11-02_19:30:01 4:temp_Aquarium.T\x3a::<
2015.11.02 19:26:22 4: log_temps_Aquarium get: Input file ./log/log_temps_Aquarium_11.log, from:2015-11-01_19:30:00  to:2015-11-02_19:30:01
2015.11.02 19:26:22 4: log_temps_Aquarium get: line 1, regexp:temp_Aquarium.T\x3a, col:3, output lines:undef
2015.11.02 19:26:22 5: Cmd: >{ "log_temps_Aquarium_11.log" }<
2015.11.02 19:26:22 4: name: /fhem/SVG_showLog?dev=SVG_log_temps_Aquarium_1&logdev=log_temps_Aquarium&gplotfile=SVG_log_temps_Aquarium_1&logfile=CURRENT&pos= / RL:2071 / image/svg+xml / Content-Encoding: gzip
 /
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 GET /fhem/icons/weather/mostly_sunny; BUFLEN:0
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:22 4: FHEMWEB:192.168.1.123:50018 GET /fhem?XHR=1&inform=type=status;filter=room=all;since=1446488780;fmt=JSON×tamp=1446488782322; BUFLEN:0
2015.11.02 19:26:33 5: SYSMON sysmon_Main: updateReadings.1053
2015.11.02 19:26:33 5: Triggering sysmon_Main (4 changes)
2015.11.02 19:26:33 5: Notify loop for sysmon_Main cpu_freq: 700
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Set.744 sysmon_Main ?
2015.11.02 19:26:33 4: BlockingCall created child (11997), uses telnetForBlockingFn to connect back
2015.11.02 19:26:33 5: Triggering rr_Sandra (2 changes)
2015.11.02 19:26:33 5: Notify loop for rr_Sandra durTimerAbsence_cr: 6836
2015.11.02 19:26:33 5: SYSMON sysmon_Main: blockingCall.947 sysmon_Main,
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute '[ -d /proc/ ] && echo 1 || echo 0'
2015.11.02 19:26:33 5: RESIDENTS rr_Sandra: processing change durTimerAbsence_cr: 6836
2015.11.02 19:26:33 5: RESIDENTS rr_Sandra: processing change durTimerAbsence: 113:55:55
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '1'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'cat /proc/uptime'
2015.11.02 19:26:33 5: ROOMMATE rr_Sandra: called function ROOMMATE_Set()
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '8572124.67 8483884.66'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute '[ -f /sys/devices/system/cpu/kernel_max ] && echo 1 || echo 0'
2015.11.02 19:26:33 5: Triggering rr_Robert (2 changes)
2015.11.02 19:26:33 5: Notify loop for rr_Robert durTimerPresence_cr: 149
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '1'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'cat /sys/devices/system/cpu/kernel_max'
2015.11.02 19:26:33 5: RESIDENTS rr_Robert: processing change durTimerPresence_cr: 149
2015.11.02 19:26:33 5: RESIDENTS rr_Robert: processing change durTimerPresence: 02:29:25
2015.11.02 19:26:33 5: ROOMMATE rr_Robert: called function ROOMMATE_Set()
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '0'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'cat /sys/class/thermal/thermal_zone0/temp 2>&1'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '43312'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute '[ -f /sys/class/hwmon/hwmon0/device/temp1_input ] && echo 1 || echo 0'
2015.11.02 19:26:33 4: Connection closed for FHEMWEB:192.168.1.123:50018: EOF
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 GET /fhem?detail=rr_Robert_wakeuptimer1; BUFLEN:0
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '0'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'cat /proc/loadavg'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '0.03 0.03 0.05 3/71 12004'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'cat /proc/stat'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4095 Result '$VAR1 = 'cpu  4639549 0 3780298 842181125 264461 3267 71154 0 0 0
';
$VAR2 = 'cpu0 4639549 0 3780298 842181125 264461 3267 71154 0 0 0
';
$VAR3 = 'intr 3207117959 0 0 0 157343914 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3036804125 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 91013 1 0 0 0 0 0 0 0 0 1 0 1013428 0 0 0 0 0 64 11865413 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
';
$VAR4 = 'ctxt 405764610
';
$VAR5 = 'btime 1437916668
';
$VAR6 = 'processes 1698077
';
$VAR7 = 'procs_running 2
';
$VAR8 = 'procs_blocked 0
';
$VAR9 = 'softirq 204954440 81924887 95149086 1700286 3590363 0 0 13087054 0 87935 9414829
';
'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'free'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4095 Result '$VAR1 = '             total       used       free     shared    buffers     cached
';
$VAR2 = 'Mem:        188284     165112      23172          0      30928      67380
';
$VAR3 = '-/+ buffers/cache:      66804     121480
';
$VAR4 = 'Swap:       102396          0     102396
';
'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: getNetworkInfo.2650 get eth0
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'ifconfig eth0 2>&1'
2015.11.02 19:26:33 4: name: /fhem?detail=rr_Robert_wakeuptimer1 / RL:3335 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4095 Result '$VAR1 = 'eth0      Link encap:Ethernet  HWaddr b8:27:eb:4d:76:a7 
';
$VAR2 = '          inet addr:192.168.1.20  Bcast:192.168.1.255  Mask:255.255.255.0
';
$VAR3 = '          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
';
$VAR4 = '          RX packets:1551178 errors:0 dropped:0 overruns:0 frame:0
';
$VAR5 = '          TX packets:1893449 errors:0 dropped:0 overruns:0 carrier:0
';
$VAR6 = '          collisions:0 txqueuelen:1000
';
$VAR7 = '          RX bytes:409157070 (390.2 MiB)  TX bytes:312638533 (298.1 MiB)
';
$VAR8 = '
';
'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: getNetworkInfo.2662 SYSMON_getNetworkInfo>>>>>>>>>>>>>>>>$VAR1 = 'eth0      Link encap:Ethernet  HWaddr b8:27:eb:4d:76:a7 
';
$VAR2 = '          inet addr:192.168.1.20  Bcast:192.168.1.255  Mask:255.255.255.0
';
$VAR3 = '          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
';
$VAR4 = '          RX packets:1551178 errors:0 dropped:0 overruns:0 frame:0
';
$VAR5 = '          TX packets:1893449 errors:0 dropped:0 overruns:0 carrier:0
';
$VAR6 = '          collisions:0 txqueuelen:1000
';
$VAR7 = '          RX bytes:409157070 (390.2 MiB)  TX bytes:312638533 (298.1 MiB)
';
$VAR8 = '
';

2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute '[ -f /sys/class/net/eth0/statistics/rx_bytes ] && echo 1 || echo 0'
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/style.css; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/jquery-ui.min.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '1'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'cat /sys/class/net/eth0/statistics/rx_bytes'
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/jquery.min.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_colorpicker.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '409161772'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'cat /sys/class/net/eth0/statistics/tx_bytes'
2015.11.02 19:26:33 4: Connection accepted from FHEMWEB:192.168.1.123:50022
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '312643803'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute '[ -f /sys/class/net/eth0/speed ] && cat /sys/class/net/eth0/speed 2>/dev/null || echo not available'
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/defaultCommon.css; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_modernbluefeatures.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result '100'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: getNetworkInfo.2650 get wlan0
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4090 Execute 'ifconfig wlan0 2>&1'
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_fbcalllist.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_uzsu.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50022 GET /fhem/pgm2/fhemweb.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50022 => 304 Not Modified
2015.11.02 19:26:33 5: SYSMON sysmon_Main: Exec_Local.4103 Result 'wlan0: error fetching interface information: Device not found'
2015.11.02 19:26:33 5: SYSMON sysmon_Main: getNetworkInfo.2662 SYSMON_getNetworkInfo>>>>>>>>>>>>>>>>$VAR1 = 'wlan0: error fetching interface information: Device not found';

2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/fhemweb_knob.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_readingsGroup.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_readingsHistory.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/dashboard_style.css; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_sortable.js; BUFLEN:0
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:33 4: Connection accepted from telnet:127.0.0.1:34250
2015.11.02 19:26:33 5: Cmd: >{SYSMON_blockingFinish('name|sysmon_Main|eth0|RX: 390.21 MB, TX: 298.16 MB, Total: 688.37 MB|eth0_rx|409161772|cpu_temp_stat|40.08 54.07 43.42|starttime|1437916668|swap|Total: 100.00 MB, Used: 0.00 MB,  0.00 %, Free: 100.00 MB|cpu_temp_avg|43.5|uptime|8572124|cpu_temp|43.31|stat_cpu|4639549 0 3780298 842181125 264461 3267 71154|stat_cpu_diff|437 0 53 6028 0 0 9|eth0_ip|192.168.1.20|stat_cpu_percent|6.70 0.00 0.81 92.35 0.00 0.00 0.14|fhemstarttime_text|31.10.2015 12:34:48|cpu_core_count|1|eth0_tx|312643803|ram|Total: 183.87 MB, Used: 65.24 MB, 35.48 %, Free: 118.63 MB|starttime_text|26.07.2015 15:17:48|fhemuptime|197505|fhemstarttime|1446291288|eth0_diff|RX: 0.08 MB, TX: 0.09 MB, Total: 0.17 MB|uptime_text|99 days, 05 hours, 08 minutes|idletime_text|98 days, 04 hours, 38 minutes (98.97 %)|wlan0_diff|not available|stat_cpu_text|user: 6.70 %, nice: 0.00 %, sys: 0.81 %, idle: 92.35 %, io: 0.00 %, irq: 0.00 %, sirq: 0.14 %|cpu_idle_stat|0.00 99.16 96.42|swap_used_stat|0.00 0.00 0.00|wlan0|not available|loadavg|0.03 0.03 0.05|idletime|8483884 98.97 %|fhemuptime_text|2 days, 06 hours, 51 minutes|eth0_speed|100|ram_used_stat|56.73 83.19 64.73')}<
2015.11.02 19:26:33 5: SYSMON sysmon_Main: blockingFinish.1034 name|sysmon_Main|eth0|RX: 390.21 MB, TX: 298.16 MB, Total: 688.37 MB|eth0_rx|409161772|cpu_temp_stat|40.08 54.07 43.42|starttime|1437916668|swap|Total: 100.00 MB, Used: 0.00 MB,  0.00 %, Free: 100.00 MB|cpu_temp_avg|43.5|uptime|8572124|cpu_temp|43.31|stat_cpu|4639549 0 3780298 842181125 264461 3267 71154|stat_cpu_diff|437 0 53 6028 0 0 9|eth0_ip|192.168.1.20|stat_cpu_percent|6.70 0.00 0.81 92.35 0.00 0.00 0.14|fhemstarttime_text|31.10.2015 12:34:48|cpu_core_count|1|eth0_tx|312643803|ram|Total: 183.87 MB, Used: 65.24 MB, 35.48 %, Free: 118.63 MB|starttime_text|26.07.2015 15:17:48|fhemuptime|197505|fhemstarttime|1446291288|eth0_diff|RX: 0.08 MB, TX: 0.09 MB, Total: 0.17 MB|uptime_text|99 days, 05 hours, 08 minutes|idletime_text|98 days, 04 hours, 38 minutes (98.97 %)|wlan0_diff|not available|stat_cpu_text|user: 6.70 %, nice: 0.00 %, sys: 0.81 %, idle: 92.35 %, io: 0.00 %, irq: 0.00 %, sirq: 0.14 %|cpu_idle_stat|0.00 99.16 96.42|swap_used_stat|0.00 0.00 0.00|wlan0|not available|loadavg|0.03 0.03 0.05|idletime|8483884 98.97 %|fhemuptime_text|2 days, 06 hours, 51 minutes|eth0_speed|100|ram_used_stat|56.73 83.19 64.73
2015.11.02 19:26:33 5: SYSMON sysmon_Main: updateReadings.1053
2015.11.02 19:26:33 5: Triggering sysmon_Main (32 changes)
2015.11.02 19:26:33 5: Notify loop for sysmon_Main eth0: RX: 390.21 MB, TX: 298.16 MB, Total: 688.37 MB
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50021 GET /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2015.11.02 19:26:33 5: Cmd: >{AttrVal("rr_Robert_wakeuptimer1","room","")}<
2015.11.02 19:26:33 4: name: /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22room%22,%22%22)}&XHR=1 / RL:33 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 /
2015.11.02 19:26:33 4: FHEMWEB:192.168.1.123:50020 GET /fhem?cmd={ReadingsVal(%22rr_Robert_wakeuptimer1%22,%22end%22,%22%22)}&XHR=1; BUFLEN:0
2015.11.02 19:26:33 5: Cmd: >{ReadingsVal("rr_Robert_wakeuptimer1","end","")}<
2015.11.02 19:26:34 4: name: /fhem?cmd={ReadingsVal(%22rr_Robert_wakeuptimer1%22,%22end%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 /
2015.11.02 19:26:34 4: FHEMWEB:192.168.1.123:50014 GET /fhem/images/default/icoEverything.png; BUFLEN:0
2015.11.02 19:26:34 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:34 4: FHEMWEB:192.168.1.123:50019 GET /fhem/images/default/fhemicon.png; BUFLEN:0
2015.11.02 19:26:34 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:34 4: FHEMWEB:192.168.1.123:50022 GET /fhem?XHR=1&inform=type=status;filter=rr_Robert_wakeuptimer1;since=1446488792;fmt=JSON×tamp=1446488793976; BUFLEN:0
2015.11.02 19:26:41 4: Connection closed for FHEMWEB:192.168.1.123:50022: EOF
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 GET /fhem?cmd.rr_Robert_wakeuptimer1=deleteattr%20rr_Robert_wakeuptimer1%20wakeupResetSwitcher&detail=rr_Robert_wakeuptimer1; BUFLEN:0
2015.11.02 19:26:41 5: Cmd: >deleteattr rr_Robert_wakeuptimer1 wakeupResetSwitcher<
2015.11.02 19:26:41 5: Triggering global (1 changes)
2015.11.02 19:26:41 5: Notify loop for global DELETEATTR rr_Robert_wakeuptimer1 wakeupResetSwitcher
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 GET /fhem?detail=rr_Robert_wakeuptimer1; BUFLEN:0
2015.11.02 19:26:41 4: name: /fhem?detail=rr_Robert_wakeuptimer1 / RL:3322 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/style.css; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/jquery-ui.min.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/jquery.min.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:41 4: Connection accepted from FHEMWEB:192.168.1.123:50023
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50023 GET /fhem/pgm2/fhemweb.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50023 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/defaultCommon.css; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_modernbluefeatures.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_colorpicker.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_readingsHistory.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50023 GET /fhem/pgm2/fhemweb_uzsu.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50023 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/fhemweb_knob.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_readingsGroup.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 GET /fhem/pgm2/fhemweb_fbcalllist.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_sortable.js; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50023 GET /fhem/pgm2/dashboard_style.css; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50023 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 GET /fhem/images/default/icoEverything.png; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50019 GET /fhem/images/default/fhemicon.png; BUFLEN:0
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 GET /fhem?cmd={ReadingsVal(%22rr_Robert_wakeuptimer1%22,%22end%22,%22%22)}&XHR=1; BUFLEN:0
2015.11.02 19:26:41 5: Cmd: >{ReadingsVal("rr_Robert_wakeuptimer1","end","")}<
2015.11.02 19:26:41 4: name: /fhem?cmd={ReadingsVal(%22rr_Robert_wakeuptimer1%22,%22end%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 /
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50019 GET /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2015.11.02 19:26:41 5: Cmd: >{AttrVal("rr_Robert_wakeuptimer1","room","")}<
2015.11.02 19:26:41 4: name: /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22room%22,%22%22)}&XHR=1 / RL:33 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 /
2015.11.02 19:26:41 4: FHEMWEB:192.168.1.123:50014 GET /fhem?XHR=1&inform=type=status;filter=rr_Robert_wakeuptimer1;since=1446488800;fmt=JSON×tamp=1446488801775; BUFLEN:0
2015.11.02 19:26:42 5: HMLAN_Send:  hmusb I:K
2015.11.02 19:26:42 5: HMLAN/RAW: /HHM-LAN-IF,03C4,KEQ1111221,2633D6,ABC123,0178C7A9,0003

2015.11.02 19:26:42 5: HMLAN_Parse: hmusb V:03C4 sNo:KEQ1111221 d:2633D6 O:ABC123 t:0178C7A9 IDcnt:0003 L:0 %
2015.11.02 19:26:42 5: Triggering hmusb (1 changes)
2015.11.02 19:26:42 5: Notify loop for hmusb loadLvl: low
2015.11.02 19:26:43 4: FHEMWEB:192.168.1.123:50019 POST /fhem?cmd=save&XHR=1; BUFLEN:0
2015.11.02 19:26:43 5: Cmd: >save<
2015.11.02 19:26:43 5: Triggering global (1 changes)
2015.11.02 19:26:43 5: Notify loop for global SAVE
2015.11.02 19:26:43 4: name: /fhem?cmd=save&XHR=1 / RL:52 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 /
2015.11.02 19:26:55 4: FHEMWEB:192.168.1.123:50019 GET /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22wakeupResetSwitcher%22,%22%22)}&XHR=1; BUFLEN:0
2015.11.02 19:26:55 5: Cmd: >{AttrVal("rr_Robert_wakeuptimer1","wakeupResetSwitcher","")}<
2015.11.02 19:26:55 4: name: /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22wakeupResetSwitcher%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 /
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_GetStatus()
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: REQ powerstate
2015.11.02 19:26:57 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/powerstate (noshutdown=1)
2015.11.02 19:26:57 4: HttpUtils url=http://192.168.1.40:80/web/powerstate
2015.11.02 19:26:57 4: http://192.168.1.40:80/web/powerstate: HTTP response code 200
2015.11.02 19:26:57 4: HttpUtils http://192.168.1.40:80/web/powerstate: Got data, length: 106
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: RCV powerstate
2015.11.02 19:26:57 5: ENIGMA2 VUUno: RES powerstate
<?xml version="1.0" encoding="UTF-8"?>
<e2powerstate>
   <e2instandby>
false   </e2instandby>
</e2powerstate>

2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: REQ getservices/?sRef=1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet&
2015.11.02 19:26:57 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/getservices?sRef=1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet& (noshutdown=1)
2015.11.02 19:26:57 4: HttpUtils url=http://192.168.1.40:80/web/getservices?sRef=1%3a7%3a2%3a0%3a0%3a0%3a0%3a0%3a0%3a0%3aFROM%20BOUQUET%20%22userbouquet%2eradio%5f%5fff%5f%5frechtl%5f%2eradio%22%20ORDER%20BY%20bouquet&
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: REQ getcurrent
2015.11.02 19:26:57 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/getcurrent (noshutdown=1)
2015.11.02 19:26:57 4: HttpUtils url=http://192.168.1.40:80/web/getcurrent
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: REQ timerlist
2015.11.02 19:26:57 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/timerlist (noshutdown=1)
2015.11.02 19:26:57 4: HttpUtils url=http://192.168.1.40:80/web/timerlist
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: REQ vol
2015.11.02 19:26:57 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/vol (noshutdown=1)
2015.11.02 19:26:57 4: HttpUtils url=http://192.168.1.40:80/web/vol
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_SendCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: REQ signal
2015.11.02 19:26:57 5: ENIGMA2 VUUno: GET http://192.168.1.40:80/web/signal (noshutdown=1)
2015.11.02 19:26:57 4: HttpUtils url=http://192.168.1.40:80/web/signal
2015.11.02 19:26:57 4: http://192.168.1.40:80/web/timerlist: HTTP response code 200
2015.11.02 19:26:57 4: HttpUtils http://192.168.1.40:80/web/timerlist: Got data, length: 68
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: RCV timerlist
2015.11.02 19:26:57 5: ENIGMA2 VUUno: RES timerlist
<?xml version="1.0" encoding="UTF-8"?>
<e2timerlist>
</e2timerlist>

2015.11.02 19:26:57 4: http://192.168.1.40:80/web/getservices?sRef=1%3a7%3a2%3a0%3a0%3a0%3a0%3a0%3a0%3a0%3aFROM%20BOUQUET%20%22userbouquet%2eradio%5f%5fff%5f%5frechtl%5f%2eradio%22%20ORDER%20BY%20bouquet&: HTTP response code 200
2015.11.02 19:26:57 4: HttpUtils http://192.168.1.40:80/web/getservices?sRef=1%3a7%3a2%3a0%3a0%3a0%3a0%3a0%3a0%3a0%3aFROM%20BOUQUET%20%22userbouquet%2eradio%5f%5fff%5f%5frechtl%5f%2eradio%22%20ORDER%20BY%20bouquet&: Got data, length: 72
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: RCV getservices/?sRef=1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet&
2015.11.02 19:26:57 5: ENIGMA2 VUUno: RES getservices/?sRef=1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet&
<?xml version="1.0" encoding="UTF-8"?>
<e2servicelist>
</e2servicelist>

2015.11.02 19:26:57 4: ENIGMA2 VUUno: ERROR: Unable to read radio bouquet '1:7:2:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.radio__ff__rechtl_.radio" ORDER BY bouquet' from device
2015.11.02 19:26:57 4: http://192.168.1.40:80/web/vol: HTTP response code 200
2015.11.02 19:26:57 4: HttpUtils http://192.168.1.40:80/web/vol: Got data, length: 184
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: RCV vol
2015.11.02 19:26:57 5: ENIGMA2 VUUno: RES vol
<?xml version="1.0" encoding="utf-8"?>
<e2volume>
   <e2result>True</e2result>
   <e2resulttext>Status</e2resulttext>
   <e2current>30</e2current>
   <e2ismuted>False</e2ismuted>   
</e2volume>

2015.11.02 19:26:57 4: http://192.168.1.40:80/web/signal: HTTP response code 200
2015.11.02 19:26:57 4: HttpUtils http://192.168.1.40:80/web/signal: Got data, length: 178
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: RCV signal
2015.11.02 19:26:57 5: ENIGMA2 VUUno: RES signal
<?xml version="1.0" encoding="UTF-8"?>
<e2frontendstatus>
   <e2snrdb> 65 dB </e2snrdb>
   <e2snr> 65 % </e2snr>
   <e2ber> 1643001 </e2ber>
   <e2acg> 76 % </e2acg>
</e2frontendstatus>

2015.11.02 19:26:57 5: Triggering VUUno (4 changes)
2015.11.02 19:26:57 5: Notify loop for VUUno snrdb: 65
2015.11.02 19:26:57 4: http://192.168.1.40:80/web/getcurrent: HTTP response code 200
2015.11.02 19:26:57 4: HttpUtils http://192.168.1.40:80/web/getcurrent: Got data, length: 3260
2015.11.02 19:26:57 5: ENIGMA2 VUUno: called function ENIGMA2_ReceiveCommand()
2015.11.02 19:26:57 4: ENIGMA2 VUUno: RCV getcurrent
2015.11.02 19:26:57 5: ENIGMA2 VUUno: RES getcurrent
<?xml version="1.0" encoding="UTF-8"?>
<e2currentserviceinformation>
   <e2service>
      <e2servicereference>1:0:1:D175:2718:F001:FFFF0000:0:0:0:</e2servicereference>
      <e2servicename>ProSieben</e2servicename>
      <e2providername>Digital Free</e2providername>
      <e2videowidth>720</e2videowidth>
      <e2videoheight>576</e2videoheight>
      <e2servicevideosize>720x576</e2servicevideosize>
      <e2iswidescreen>
1      </e2iswidescreen>
      <e2apid>2202</e2apid>
      <e2vpid>2201</e2vpid>
      <e2pcrpid>2201</e2pcrpid>
      <e2pmtpid>101</e2pmtpid>
      <e2txtpid>2204</e2txtpid>
      <e2tsid>10008</e2tsid>
      <e2onid>61441</e2onid>
      <e2sid>53621</e2sid>
   </e2service>
   <e2eventlist>
      <e2event>
         <e2eventservicereference>1:0:1:D175:2718:F001:FFFF0000:0:0:0:</e2eventservicereference>
         <e2eventservicename>ProSieben</e2eventservicename>
         <e2eventprovidername>Digital Free</e2eventprovidername>
         <e2eventid>25698</e2eventid>
         <e2eventname>Galileo</e2eventname>
         <e2eventtitle>Galileo</e2eventtitle>
         <e2eventdescription>Thema u. a.: "Galileo"-Trip zur NSA-Zentrale, Information, D 2015</e2eventdescription>
         <e2eventstart>1446487511</e2eventstart>
         <e2eventduration>4149</e2eventduration>
         <e2eventremaining>2844</e2eventremaining>
         <e2eventcurrenttime>1446488816</e2eventcurrenttime>
         <e2eventdescriptionextended>Moderation: Stefan Gödde

Edward Snowden gilt als der bekannteste Whistleblower unserer Zeit. Bis zu seinen Enthüllungen im Jahr 2013 wusste kaum jemand über die Machenschaften der NSA Bescheid. Jetzt ist der amerikanische Abhördienst in aller Munde. Doch was macht die National Security Agency genau? "Galileo" ist nach Washington gereist, um einen Einblick in die Arbeit des größten Auslandsgeheimdienstes zu bekommen.</e2eventdescriptionextended>
      </e2event>
      <e2event>
         <e2eventservicereference>1:0:1:D175:2718:F001:FFFF0000:0:0:0:</e2eventservicereference>
         <e2eventservicename>ProSieben</e2eventservicename>
         <e2eventprovidername>Digital Free</e2eventprovidername>
         <e2eventid>25699</e2eventid>
         <e2eventname>The Big Bang Theory</e2eventname>
         <e2eventtitle>The Big Bang Theory</e2eventtitle>
         <e2eventdescription>Über Nacht im Fort, Sitcom, USA 2014</e2eventdescription>
         <e2eventstart>1446491660</e2eventstart>
         <e2eventduration>1757</e2eventduration>
         <e2eventremaining>4601</e2eventremaining>
         <e2eventcurrenttime>1446488816</e2eventcurrenttime>
         <e2eventdescriptionextended>Penny wird von Will Wheaton für seinen Podcast interviewt. Während der Show ruft der Regisseur Kevin Smith an und möchte sie für seinen neuen Film casten. Leonard ist von der Idee wenig begeistert ... Howard steht kurz davor, das Haus seiner Mutter zu erben, es fehlt nur noch eine Formalität. Dann taucht plötzlich sein bislang unbekannter Halbbruder Josh auf ...

Gast: Wil Wheaton
Regie: Mark Cendrowski
Drehbuch: Steven Molaro
Kamera: Steven V. Silver
Schnitt: Peter Chakos

Darsteller:
Johnny Galecki (Leonard Hofstadter)
Jim Parsons (Sheldon Cooper)
Simon Helberg (Howard Wolowitz)
Kunal Nayyar (Rajesh Koothrappali)
Kaley Cuoco (Penny)
Mayim Bialik (Amy Farrah Fowler)
Melissa Rauch (Bernadette Rostenkowski)
Matt Bennett (Josh Wolowitz)</e2eventdescriptionextended>
      </e2event>
   </e2eventlist>
</e2currentserviceinformation>

2015.11.02 19:26:58 5: Triggering VUUno (8 changes)
2015.11.02 19:26:58 5: Notify loop for VUUno eventremaining: 2844
2015.11.02 19:27:02 4: Connection closed for FHEMWEB:192.168.1.123:50014: EOF
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 POST /fhem&detail=rr_Robert_wakeuptimer1&dev.attrrr_Robert_wakeuptimer1=rr_Robert_wakeuptimer1&cmd.attrrr_Robert_wakeuptimer1=attr&arg.attrrr_Robert_wakeuptimer1=wakeupResetSwitcher&val.attrrr_Robert_wakeuptimer1=ResetOff; BUFLEN:0
2015.11.02 19:27:02 5: Cmd: >attr rr_Robert_wakeuptimer1 wakeupResetSwitcher ResetOff<
2015.11.02 19:27:02 5: Triggering global (1 changes)
2015.11.02 19:27:02 5: Notify loop for global ATTR rr_Robert_wakeuptimer1 wakeupResetSwitcher ResetOff
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 GET /fhem?detail=rr_Robert_wakeuptimer1; BUFLEN:0
2015.11.02 19:27:02 4: name: /fhem?detail=rr_Robert_wakeuptimer1 / RL:3344 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/style.css; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50023 GET /fhem/pgm2/jquery-ui.min.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50023 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/jquery.min.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:27:02 4: Connection accepted from FHEMWEB:192.168.1.123:50024
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_colorpicker.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50023 GET /fhem/pgm2/defaultCommon.css; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50023 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/fhemweb_modernbluefeatures.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_readingsHistory.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50024 GET /fhem/pgm2/fhemweb.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50024 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_fbcalllist.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50023 GET /fhem/pgm2/fhemweb_knob.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50023 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/fhemweb_readingsGroup.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_sortable.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50024 GET /fhem/pgm2/dashboard_style.css; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50024 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 GET /fhem/pgm2/fhemweb_uzsu.js; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 GET /fhem/images/default/icoEverything.png; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50020 GET /fhem/images/default/fhemicon.png; BUFLEN:0
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 GET /fhem?cmd={ReadingsVal(%22rr_Robert_wakeuptimer1%22,%22end%22,%22%22)}&XHR=1; BUFLEN:0
2015.11.02 19:27:02 5: Cmd: >{ReadingsVal("rr_Robert_wakeuptimer1","end","")}<
2015.11.02 19:27:02 4: name: /fhem?cmd={ReadingsVal(%22rr_Robert_wakeuptimer1%22,%22end%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 /
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50020 GET /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2015.11.02 19:27:02 5: Cmd: >{AttrVal("rr_Robert_wakeuptimer1","room","")}<
2015.11.02 19:27:02 4: name: /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22room%22,%22%22)}&XHR=1 / RL:33 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 /
2015.11.02 19:27:02 4: FHEMWEB:192.168.1.123:50019 GET /fhem?XHR=1&inform=type=status;filter=rr_Robert_wakeuptimer1;since=1446488821;fmt=JSON×tamp=1446488822479; BUFLEN:0
2015.11.02 19:27:04 4: FHEMWEB:192.168.1.123:50020 POST /fhem?cmd=save&XHR=1; BUFLEN:0
2015.11.02 19:27:04 5: Cmd: >save<
2015.11.02 19:27:04 5: Triggering global (1 changes)
2015.11.02 19:27:04 5: Notify loop for global SAVE
2015.11.02 19:27:04 4: name: /fhem?cmd=save&XHR=1 / RL:52 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 /
2015.11.02 19:27:07 5: HMLAN_Send:  hmusb I:K
2015.11.02 19:27:07 5: HMLAN/RAW: /HHM-LAN-IF,03C4,KEQ1111221,2633D6,ABC123,0179295D,0003

2015.11.02 19:27:07 5: HMLAN_Parse: hmusb V:03C4 sNo:KEQ1111221 d:2633D6 O:ABC123 t:0179295D IDcnt:0003 L:0 %
2015.11.02 19:27:07 5: Triggering hmusb (1 changes)
2015.11.02 19:27:07 5: Notify loop for hmusb loadLvl: low
2015.11.02 19:27:12 4: FHEMWEB:192.168.1.123:50020 GET /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22verbose%22,%22%22)}&XHR=1; BUFLEN:0
2015.11.02 19:27:12 5: Cmd: >{AttrVal("rr_Robert_wakeuptimer1","verbose","")}<
2015.11.02 19:27:12 4: name: /fhem?cmd={AttrVal(%22rr_Robert_wakeuptimer1%22,%22verbose%22,%22%22)}&XHR=1 / RL:22 / text/plain; charset=UTF-8 / Content-Encoding: gzip
 /
2015.11.02 19:27:16 4: Connection closed for FHEMWEB:192.168.1.123:50019: EOF
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 POST /fhem&detail=rr_Robert_wakeuptimer1&dev.attrrr_Robert_wakeuptimer1=rr_Robert_wakeuptimer1&cmd.attrrr_Robert_wakeuptimer1=attr&arg.attrrr_Robert_wakeuptimer1=verbose&val.attrrr_Robert_wakeuptimer1=3; BUFLEN:0
2015.11.02 19:27:16 5: Cmd: >attr rr_Robert_wakeuptimer1 verbose 3<
2015.11.02 19:27:16 5: Triggering global (1 changes)
2015.11.02 19:27:16 5: Notify loop for global ATTR rr_Robert_wakeuptimer1 verbose 3
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 GET /fhem?detail=rr_Robert_wakeuptimer1; BUFLEN:0
2015.11.02 19:27:16 4: name: /fhem?detail=rr_Robert_wakeuptimer1 / RL:3345 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/style.css; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50023 GET /fhem/pgm2/jquery.min.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50023 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_colorpicker.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:27:16 4: Connection accepted from FHEMWEB:192.168.1.123:50025
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50024 GET /fhem/pgm2/jquery-ui.min.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50024 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50023 GET /fhem/pgm2/defaultCommon.css; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50023 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/fhemweb_modernbluefeatures.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_fbcalllist.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50025 GET /fhem/pgm2/fhemweb.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50025 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50024 GET /fhem/pgm2/fhemweb_uzsu.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50024 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50023 GET /fhem/pgm2/fhemweb_knob.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50023 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50021 GET /fhem/pgm2/fhemweb_readingsGroup.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50021 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_readingsHistory.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50025 GET /fhem/pgm2/dashboard_style.css; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50025 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 GET /fhem/pgm2/fhemweb_sortable.js; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 => 304 Not Modified
2015.11.02 19:27:16 4: FHEMWEB:192.168.1.123:50020 GET /fhem/images/default/icoEverything.png; BUFLEN:0
2015.11.02 19:27:16 4: FHEMWEB:19
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 02 November 2015, 19:42:03
Die Funktion wird beim Anlegen des Attributs tatsächlich nicht aufgerufen.
Dafür gibt es wohl nur den Grund, dass bei dir das Dummy-Modul nicht "gehighjackt" werden konnte, da schon ein anderes Modul für das DUMMY-Modul eine Funktion für das Überwachen von Attributen registriert hat.
In diesem Fall kann der ResetSwitcher nicht automatisch angelegt werden, eine entsprechende Meldung siehst du auch beim Neustart, wenn für ein ROOMMATE Device verbose=5 gesetzt ist:


"concurrent AttrFn already defined for dummy module. Some attribute based functions like auto-creations will not be available."


Heißt dann aber, dass ein manuelles anlegen des Dummys genügt und es dann auch entsprechend ausgewertet werden kann.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: r_knipp am 02 November 2015, 20:13:37
Ich habe es jetzt mal manuell angelegt und dann das entsprechende Attribut im Timer gesetzt. Nun hat es auch einen Link auf den ResetSwitcher. Habe dann mal die Weckzeit von Standard 0600 auf 0630 gestellt, den ResetSwitcher auf Off gestellt und das Weckprogramm durchlaufen lassen.

Hier der Log.
2015.11.02 19:39:36 4: dummy set rr_Robert_wakeuptimer1 nextRun 06:30
2015.11.02 19:39:36 4: RESIDENTStk rr_Robert_wakeuptimer1: New wake-up time: 06:30
2015.11.02 19:39:36 4: RESIDENTStk rr_Robert_wakeuptimer1: wakeupGetBegin source: nextRun
2015.11.02 19:39:36 4: RESIDENTStk rr_Robert_wakeuptimer1: wakeupGetBegin result: 06:30 = 22500 s - 15 m = 06:15:00
2015.11.02 19:39:36 4: RESIDENTStk rr_Robert_wakeuptimer1: wakeupGetBegin source: nextRun
2015.11.02 19:39:36 4: RESIDENTStk rr_Robert_wakeuptimer1: wakeupGetBegin result: 06:30 = 22500 s - 15 m = 06:15:00
2015.11.02 19:40:24 4: dummy set rr_Robert_wakeuptimer1 start
2015.11.02 19:40:24 4: RESIDENTStk rr_Robert_wakeuptimer1: lastRun != nextRun = 19:55
2015.11.02 19:40:24 4: RESIDENTStk rr_Robert_wakeuptimer1: trigger Macro_rr_Robert_wakeuptimer1 (running=1)
2015.11.02 19:40:24 3: Macro_rr_Robert_wakeuptimer1: Wake-up program started for rr_Robert with target time 19:55. Current state: home
2015.11.02 19:40:24 3: CUL_HM set sz_Dimmer_channel_01 pct 50 0 900
2015.11.02 19:40:24 4: RESIDENTStk rr_Robert_wakeuptimer1: created at-device at_rr_Robert_wakeuptimer1_stop to stop wake-up program in 15 minutes
2015.11.02 19:40:31 3: CUL_HM set sz_Dimmer_channel_01 statusRequest
2015.11.02 19:42:32 3: CUL_HM set sz_Dimmer_channel_01 statusRequest
2015.11.02 19:44:33 3: CUL_HM set sz_Dimmer_channel_01 statusRequest
2015.11.02 19:46:34 3: CUL_HM set sz_Dimmer_channel_01 statusRequest
2015.11.02 19:48:36 3: CUL_HM set sz_Dimmer_channel_01 statusRequest
2015.11.02 19:50:37 3: CUL_HM set sz_Dimmer_channel_01 statusRequest
2015.11.02 19:52:39 3: CUL_HM set sz_Dimmer_channel_01 statusRequest
2015.11.02 19:54:46 3: CUL_HM set sz_Dimmer_channel_01 statusRequest
2015.11.02 19:55:25 4: dummy set rr_Robert_wakeuptimer1 stop triggerpost
2015.11.02 19:55:25 4: RESIDENTStk rr_Robert_wakeuptimer1: stopping wake-up program
2015.11.02 19:55:25 4: dummy set rr_Robert_wakeuptimer1 nextRun 06:30
2015.11.02 19:55:25 4: RESIDENTStk rr_Robert_wakeuptimer1: trigger Macro_rr_Robert_wakeuptimer1 stop 19:55 15 1 rr_Robert home
2015.11.02 19:55:25 3: Macro_rr_Robert_wakeuptimer1: Wake-up program ended for rr_Robert with target time 19:55. Current state: home

heißt nextRun 06:30 dann, dass es jetzt funktioniert?

Was hat es denn mit Dummy-Modul highjacken auf sich? Das sagt mir leider gar nichts.

Zitat
Some attribute based functions like auto-creations will not be available.
Kann man da etwas gegen tun? Das könnte in anderen Fällen doch bestimmt auch zu Problemen führen, oder?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 03 November 2015, 10:54:37
heißt nextRun 06:30 dann, dass es jetzt funktioniert?


Sieht danach aus.
Testen kannst du das am besten so:


1. Standard-Weckzeit auf 06:30 definieren.
2. Weckzeit manuell auf etwas anderes stellen.
3. Den ResetSwitcher aus und wieder einschalten.


Danach sollte der Wecker von der manuell verstellten Weckzeit auf die vordefinierte Standard-Weckzeit wechseln.
Mit Hilfe des ResetSwitchers kannst du nun komfortabel einstellen, ob tatsächlich ein Reset der Weckzeit gemacht werden soll oder nicht.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 03 November 2015, 10:59:55
Was hat es denn mit Dummy-Modul highjacken auf sich? Das sagt mir leider gar nichts.


Das bedeutet nur, dass ich dort in Code eingreife, der eigentlich zum DUMMY Modul gehören müsste, damit ich das DUMMY-Modul soweit "fernsteuern" kann, dass ich auf das Event beim Anlegen des Attributes reagieren kann.
Das mache ich aber "gentle": Wenn irgendwer oder irgendwas bereits das gleiche tut, gebe ich dem den Vortritt. Um zu wissen wer oder was das ist, habe ich das Logging erweitert. Bei einem Neustart mit verbose=4 kann man in der Meldung jetzt auch sehen welche Funktion sich hier bereits vorher registriert hat.


Kann man da etwas gegen tun? Das könnte in anderen Fällen doch bestimmt auch zu Problemen führen, oder?


Nein man kann und soll nichts dagegen tun. Das automatische Anlegen des DUMMY Devices in der richtigen Konfiguration ist lediglich ein "Service", um einem etwas Arbeit abzunehmen, spielt aber ansonsten keine große Rolle.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: r_knipp am 03 November 2015, 11:06:37
Dann ist ja so alles in Ordnung   :)

Hab vielen Dank für Deine Hilfe und Erklärungen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 08 November 2015, 11:49:59
Nachdem ich jetzt in den letzten Wochen einige Erweiterungen auch bei der RESIDENTS Modulfamilie vorgenommen habe und das (noch als Beta zu betrachtende) msg-Kommando (http://forum.fhem.de/index.php/topic,39983.0.html) nun per Update ausgerollt wurde, kann ich hier einmal ein kurzes Anwendungsbeispiel geben.

Wenn ein Bewohner das Haus betritt oder verlässt, soll er/sie per Push eine Nachricht darüber bekommen (bei mir kommt diese entsprechend unauffällig auf meine Apple Watch mit Taptic Engine  ;) ), dass er/sie erfolgreich am Haus an- bzw abgemeldet wurde. Außerdem soll dabei genannt werden, wer schon bzw. noch zu Hause ist. Das kann man nun mit einem sehr simplen DOIF sehr übersichtlich lösen, anstatt hier Unmengen an eigenem Code zu fabrizieren:

define di_Residents_presence_push DOIF
(
   [rgr_Residents:?lastActivity] and
   [?rgr_Residents:lastActivity] eq "home" and
   [?rgr_Residents:residentsGotosleep:sec] > 1 and
   [?rgr_Residents:residentsAsleep:sec] > 1 and
   [?rgr_Residents:residentsAwoken:sec] > 1
)
(
   (msg push @[rgr_Residents:lastActivityByDev] |Anwesenheit| [rgr_Residents:residentsTotalPresent] Bewohner zuhause: [rgr_Residents:residentsTotalPresentNames])
)

DOELSEIF
(
   [rgr_Residents:?lastActivity] and
   [?rgr_Residents:lastActivity] eq "absent" and
   [?rgr_Residents:presence] eq "present"
)
(
   (msg push @[rgr_Residents:lastActivityByDev] -1 |Anwesenheit| [rgr_Residents:lastActivityBy] erfolgreich abgemeldet. [rgr_Residents:residentsTotalPresent] Bewohner verblieben: [rgr_Residents:residentsTotalPresentNames])
)

DOELSEIF
(
   [rgr_Residents:?lastActivity] and
   [?rgr_Residents:lastActivity] eq "absent" and
   [?rgr_Residents:presence] eq "absent" and
   [?rgr_Residents:presence:sec] < 1
)
(
   (msg push @[rgr_Residents:lastActivityByDev] |Anwesenheit| [rgr_Residents:lastActivityBy] erfolgreich abgemeldet. Alle Bewohner sind nun abwesend. Sicherheitsprotokolle werden etabliert.)
)

Gesetzte Attribute:
attr di_Residents_presence_push do always


Zusätzlich muss natürlich bei jedem ROOMMATE (oder GUEST) Device, welche ein kommen und gehen auslösen können, ein msgContactPush Attribut vorhanden sein, damit das msg-Kommando weiß wie es den ROOMMATE Bewohner erreichen kann. Bei mir ist das einfach ein Verweis auf ein Pushover Device, da am schicksten auf der Apple Watch darstellbar. Es kann aber auch ein Telegram Kontakt sein (dann muss das Attribut neben dem Devicenamen für den TelegramBot auch noch mit Doppelpunkt getrennt den Empfängernamen im Telegram Format enthalten; also z.B. "Telegram:@@USERNAME").


Für das automatische kommen und gehen wird bei mir das GEOFANCY Modul (http://www.fhemwiki.de/wiki/Anwesenheitserkennung#Das_GEOFANCY_Modul) zusammen mit der iOS-App Geofency (http://www.geofency.com/) verwendet.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: MichaelO am 14 November 2015, 15:30:11
Moin,

ich wollte heute ein DOIF programmieren, welches mir eine Pushnachricht sendet, wenn meine Frau und ich das Haus verlassen und noch Fenster offen sind. Dabei sollte es egal sein, wenn bei unserem Verlassen noch Gäste da sind.

Irgendwie hab ich mich zu blöd angestellt, mit den gegebenen Readings eines zu identifizieren, welches die An-/Abwesenheit der Roommates von den Guests unterscheidet. Die residents - Readings werden immer gemeinsam angegeben (Roommates + Guests). Möglicherweise habe ich da was übersehen, bis dahin habe ich per userReadings folgende Ergänzungen vorgenommen und die Roomates als Owner betitelt.

residentsTotalOwners { ReadingsVal("Mittelstr","residentsTotal",0) - ReadingsVal("Mittelstr","residentsTotalGuests",0); },

residentsTotalOwnersPresent { ReadingsVal("Mittelstr","residentsTotalOwners",0) - ReadingsVal("Mittelstr","residentsTotalAbsent",0) + ReadingsVal("Mittelstr","residentsTotalGuestsAbsent",0); }

Die übrigen Reading wie Geräte oder Anwesenheit hab ich nicht gebraucht und deswegen nicht angelegt.
Vielleicht kann sowas (anders benannt?) ins Modul übernommen werden.

Gruß
Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 14 November 2015, 15:32:17
Ich habe gerade folgendes DOIF bei mir im Test, welches auch zwischen Bewohnern und Gästen unterscheidet:



## ROOMMATE arrives at home
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
$devType eq "ROOMMATE" and
($lastState eq "absent" or $lastState eq "gone")
)
(
(msg push @[rgr_Residents:lastActivityByDev] |Anwesenheit| [rgr_Residents:residentsTotalPresent] Bewohner zuhause: [rgr_Residents:residentsTotalPresentNames])
)


## ROOMMATE leaves home but residents are still present
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
[?rgr_Residents:presence] eq "present" and
$devType eq "ROOMMATE"
)
(
(msg push @[rgr_Residents:lastActivityByDev] |Anwesenheit| [rgr_Residents:lastActivityBy] abgemeldet. [rgr_Residents:residentsTotalPresent] Bewohner verblieben: [rgr_Residents:residentsTotalPresentNames])
)


## ROOMMATE is absent for longer period but others are still nearby
DOELSEIF
(
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "gone" and
[?rgr_Residents:state] ne "gone"
)
(
(msg push @[rgr_Residents:lastActivityByDev]! -2 |Anwesenheit| Längere Abwesenheit für [rgr_Residents:lastActivityBy] wurde vermerkt.)
)


## all residents are absent for longer period
DOELSEIF
(
[rgr_Residents:?state] and
[?rgr_Residents:state] eq "gone"
)
(
(msg push @rgr_Residents! -1 |Anwesenheit| Längere Abwesenheit aller Bewohner registriert. Erweitere Sicherheitsprotokolle wurden etabliert.)
)


## ROOMMATE leaves home and all residents are absent now
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
[?rgr_Residents:state] eq "absent" and
$devType eq "ROOMMATE"
)
(
(msg push @[rgr_Residents:lastActivityByDev] |Anwesenheit| [rgr_Residents:lastActivityBy] abgemeldet. Alle Bewohner sind abwesend, Sicherheitsprotokolle wurden etabliert.)
)


## GUEST control enabled
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
(([?rgr_Residents:lastActivity] ne "absent" and [?rgr_Residents:residentsHome] > 1) or ([?rgr_Residents:lastActivity] eq "absent" and [?rgr_Residents:residentsHome] == 0)) and
$devType eq "GUEST" and
$lastState eq "none"
)
(
(msg push @rgr_Residents -1 |Anwesenheit| Steuerung für [rgr_Residents:lastActivityBy] wurde aktiviert)
)


## GUEST control enabled while no resident present (EXCEPTION!)
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] ne "absent" and
[?rgr_Residents:residentsHome] == 1 and
$devType eq "GUEST" and
$lastState eq "none"
)
(
(msg push @rgr_Residents! 2 |Anwesenheit| Steuerung für [rgr_Residents:lastActivityBy] wurde aktiviert, obwohl kein Bewohner zuhause ist!)
)


## GUEST control was disabled
DOELSEIF
(
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "none" and
[?rgr_Residents:state] ne "gone"
)
(
(msg push @rgr_Residents -1 |Anwesenheit| Steuerung für [rgr_Residents:lastActivityBy] wurde deaktiviert)
)


## GUEST arrives at home while residents are present
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:residentsHome] > 1 and
$devType eq "GUEST" and
$lastState eq "absent"
)
(
(msg push @rgr_Residents -2 |Anwesenheit| [rgr_Residents:lastActivityBy] ist jetzt zuhause. Anwesende Bewohner: [rgr_Residents:residentsTotalPresentNames])
)


## GUEST arrives at home while he is the only one (EXCEPTION!)
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:residentsHome] == 1 and
$devType eq "GUEST" and
$lastState eq "absent"
)
(
(msg push @rgr_Residents! 2 |Anwesenheit| [rgr_Residents:lastActivityBy] ist jetzt alleine zuhause!)
)


## GUEST leaves home while others are still at home
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
[?rgr_Residents:presence] eq "present" and
$devType eq "GUEST"
)
(
(msg push @rgr_Residents -2 |Anwesenheit| [rgr_Residents:lastActivityBy] abgemeldet. [rgr_Residents:residentsTotalPresent] Bewohner verblieben: [rgr_Residents:residentsTotalPresentNames])
)


## GUEST leaves home after all residents
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
[?rgr_Residents:presence] eq "absent" and
$devType eq "GUEST"
)
(
(msg push @rgr_Residents! |Anwesenheit| [rgr_Residents:lastActivityBy] abgemeldet. Alle Bewohner sind jetzt abwesend, Sicherheitsprotokolle werden etabliert.)
)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: MichaelO am 14 November 2015, 15:37:12
Ich habe gerade folgendes DOIF bei mir im Test, welches auch zwischen Bewohnern und Gästen unterscheidet:

Ja, das geht auch. Ich wollte es in der Nutzung in weiteren DOIF aber lieber übersichtlicher haben und deswegen das Reading dahin packen, wohin es gehört (und universell nutzbar ist). Im Ergebnis verwende ich es dann zb so:

## wenn die Hoftuer geoeffnet wird und außer Gästen keiner zu Hause ist
([AU_FK_Hoftuer:?contact] and [?AU_FK_Hoftuer] eq "open" and [?Mittelstr:residentsTotalOwnersPresent] == 0)

     ## Nachricht per pushmsg
     (set pushmsg msg 'ACHTUNG!' 'Die Hoftür wurde geöffnet!' '' 2 'siren' 30 3600)

Ich finde dann den Code des DOIF auch wesentlich lesbarer. Kann aber auch Geschmackssache sein.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 14 November 2015, 15:39:47
Aber noch der Nachtrag genereller Natur:


residentsTotalGuestsPresent gibt an wieviele Gäste gerade anwesend sind.
residentsTotalPresent gibt an wieviele Bewohner insgesamt anwesend sind.
Gäste werden auch gastlich behandelt und entsprechend während ihrer Anwesenheit als vollwertige Bewohner gezählt.
 ;)
Es ist also richtig, dass man über ([rgr_Residents:residentsTotalPresent] eq [rgr_Residents: residentsTotalGuestsPresent]) erkennen kann, wenn nur noch Gäste zu Hause sind.


In meinem DOIF habe ich das allerdings etwas komplexer gelöst. Warum kann man denke ich bei genauerem hinsehen auch verstehen.




EDIT: Ich ergänze bei Gelegenheit mal residentsTotalOwners*.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 14 November 2015, 17:17:14
Habe gerade eine aktualisierte Version mit residentsTotalOwners* Readings eingecheckt.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: MichaelO am 14 November 2015, 17:20:33
Danke für's Einchecken, dann fliegen meine userReadings morgen raus. Es führen sicherlich viele Wege nach Rom und bei der ganzen Programmiererei übersieht man auch einige Möglichkeiten.

Danke nochmal!
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ralfix am 19 November 2015, 22:39:38
Hallo
ich bin seit ein paar Wochen begeisterter FHEM-Bastler. Meine ROOMMATE's schalte ich mit 2 IT-Fernbedienungen am Bett (awoken:asleep) und Wohnungstür (home:absent). Zusätzlich habe ich noch einige notifies auf pingbare Geräte zur Plausibilisierung, falls man einen Status nicht schaltet. Funktioniert soweit  ganz gut.  :)

Was mir auffällt:  Bei den automatisch erzeugten Makros fehlt irgendwie Macro_RESIDENTS_absent und Macro_RESIDENTS_home? Ist das Absicht, oder habe ich ausversehen etwas gelöscht?
Grüße Ralf
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 21 November 2015, 14:32:11
Ich habe gerade eine Änderung beim Reading lastActivity des RESIDENTS Moduls eingecheckt.
Das betrifft diejenigen, die in einem ROOMMATE oder GUEST Device eventMap verwenden. Bisher wurde dann in lastActivity der übersetzte Wert angezeigt statt dem originalen state des Devices. Nun wird in RESIDENTS ebenfalls der originale Wert angezeigt und nicht der durch eventMap übersetzte. Wer also darauf triggert, muss diese ggf. anpassen oder eventMap auch für das RESIDENTS Device definieren.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 21 November 2015, 14:36:21
Was mir auffällt:  Bei den automatisch erzeugten Makros fehlt irgendwie Macro_RESIDENTS_absent und Macro_RESIDENTS_home? Ist das Absicht, oder habe ich ausversehen etwas gelöscht?


Nein. Du sprichst vermutlich vom Wakeuptimer, welcher jedoch nur zu einem ROOMMATE oder GUEST Device gehört.
Es macht daher keinen Sinn für ein RESIDENTS Device etwas anzulegen, wenn dies für den Wakeuptimer gar nicht benötigt wird. Wenn du ein Notify auf ein RESIDENTS Device brauchst, musst du ihn selbst anlegen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ralfix am 25 November 2015, 21:29:06
Nein. Du sprichst vermutlich vom Wakeuptimer, welcher jedoch nur zu einem ROOMMATE oder GUEST Device gehört.
Es macht daher keinen Sinn für ein RESIDENTS Device etwas anzulegen, wenn dies für den Wakeuptimer gar nicht benötigt wird. Wenn du ein Notify auf ein RESIDENTS Device brauchst, musst du ihn selbst anlegen.
Die Macros  Macro_rr_Ralf_asleep , -_awoken und -_gotosleep wurden mir automatisch erzeugt, aber eben nicht Macro_rr_Ralf_absent und Macro_rr_Ralf_home.
Das finde ich etwas  unlogisch.
Ist aber kein Problem,  die notwendigen Aktionen habe alle per NOTIFY und DOIF eingestellt. :)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: MichaelO am 13 Dezember 2015, 19:31:12
So, nachdem mich die Arbeit nun wieder einige Minuten ans System lässt, ist mit bei den Readings

residentsTotalOwners*

aufgefallen, dass ich da beim Namensvorschlag wohl blockierte Denke hatte. Ich hatte nach einer Bezeichnung analog zu "Guests" gesucht und völlig daneben gegriffen. Eigentlich wäre es doch korrekter, die Readings als

residentsTotalRoommates*

zu bezeichnen.  :( Wäre es blöd, das jetzt noch zu ändern?

Dann noch eine Frage... ich komm vor lauter Readings nicht drauf. Wenn ich etwas genau einmal machen möchte, wenn der erste Bewohner nach Hause kommt, wie setze ich das in einem DOIF um? Das Haus auf "present" zu prüfen dürfte hier nicht gehen, oder... jede Statusänderung eines Bewohners würde doch einen Trigger auslösen und damit die Prüfung auf "present" wieder auslösen. Ich steht vor dem Wald und seh grad nix.

Danke
Michael
 
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 13 Dezember 2015, 20:08:50
Hallo Micha,

Bitte schau Die doch mal genau an was bei den DeviceInstanzen passiert. Versuche zu verstehen wie was genau abgebildet wird. Dann erkennst Du das die Residents auf den Zustand des ersten oder letzten Roommates an nimmt. Die Residents kann nur einmal den Status Home annehmen, nämlich vom ersten Roommate. Und dem zu Folge kannst Du auch ein DOIF auf home der Residents machen wenn der erste Bewohner der nach Hause kommt etwas auslösen soll.


Grüße
Leon
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 14 Dezember 2015, 14:29:41
So, nachdem mich die Arbeit nun wieder einige Minuten ans System lässt, ist mit bei den Readings

residentsTotalOwners*

aufgefallen, dass ich da beim Namensvorschlag wohl blockierte Denke hatte.


Das ist schon in Ordnung so, sonst hätte ich das selbst entsprechend anders benannt.
Es geht ja vornehmlich um Bewohner, daher wird auch sonst in keinem Reading explizit von "roommates" gesprochen. Nur dort, wo es sich um temporäre Bewohner handelt, wird ein Reading dann mit "guests" im Namen bezeichnet.


Dann noch eine Frage... ich komm vor lauter Readings nicht drauf. Wenn ich etwas genau einmal machen möchte, wenn der erste Bewohner nach Hause kommt, wie setze ich das in einem DOIF um? Das Haus auf "present" zu prüfen dürfte hier nicht gehen, oder... jede Statusänderung eines Bewohners würde doch einen Trigger auslösen und damit die Prüfung auf "present" wieder auslösen. Ich steht vor dem Wald und seh grad nix.[size=78%] [/size]


Wie CoolTux richtig schrieb, die Readings triggern nur wenn sich etwas verändert. Sprich nur wenn der erste Bewohner nach Hause kommt ändert sich das Reading "presence" von "absent" auf "present", danach bleibt es natürlich so, weil es den Gesamtstatus über alle Mitglieder dieser RESIDENTS Gruppe repräsentiert. Du kannst also in einem DOIF einfach auf [rgr_Residents:?presence] triggern.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 14 Dezember 2015, 14:33:00
Die Residents kann nur einmal den Status Home annehmen, nämlich vom ersten Roommate. Und dem zu Folge kannst Du auch ein DOIF auf home der Residents machen wenn der erste Bewohner der nach Hause kommt etwas auslösen soll.


Das funktioniert nur solange man keinen der anderen Status wie "asleep" verwendet. Ansonsten wechselt der Gesamtstatus natürlich irgendwann auch auf "asleep" wenn alle Bewohner schlafen und nach dem aufstehen dann wieder auf "awoken" oder sofort auf "home", sobald der erste aufgestanden ist (je nachdem wie man das in seiner Automation verwendet). Dann würde auf "home" erneut getriggert werden, obwohl die Bewohner gar nicht weg waren. Für diesen Fall ist das Reading "presence" deshalb besser geeignet.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 14 Dezember 2015, 14:39:14
Ich hatte nach einer Bezeichnung analog zu "Guests" gesucht und völlig daneben gegriffen. Eigentlich wäre es doch korrekter, die Readings als

residentsTotalRoommates*

zu bezeichnen.  :( Wäre es blöd, das jetzt noch zu ändern?[size=78%] [/size]


Hm, jetzt verstehe ich deine Denkweise. Ich kam auch naheliegenderweise zunächst auf "Owners", aber "Guests" ähnelt der Bezeichnung des GUEST-Moduls natürlich und demnach wäre es in der Tat sinnvoller die Readings mit "Roommates" zu bezeichnen, damit man den Zusammenhang direkt herstellen kann.


Ich werde die Readings umbenennen. Ich denke die sind noch nicht allzu verbreitet im Einsatz und eine Änderung des Namens ist für die bisherigen Verwender kein großes Problem.


Ab morgen dann per Update.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 15 Dezember 2015, 13:33:22
läuft soweit.

Sry für die vllt. doofe Frage, aber gibt's irgendeinen Befehl zum "aufräumen" der Readings? Ähnlich wie bei der msg-Funktion?

Gruß Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 15 Dezember 2015, 13:35:44
Sry für die vllt. doofe Frage, aber gibt's irgendeinen Befehl zum "aufräumen" der Readings? Ähnlich wie bei der msg-Funktion?


Da das kein häufiger Task ist, lohnt dafür kein eigener Setter.
Man kann einfach das Kommando deletereading entsprechend benutzen:


deletereading .* residentsTotalOwners.*
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 15 Dezember 2015, 14:08:31
alles klar,

danke!
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 19 Dezember 2015, 10:18:24
Hallo, wir haben mit dem Wecker ein "Problem". Die Grundfunktion ist perfekt, da darf man wiederholt nochmals DANKE sagen.
 :) Wenn ich nun ins Bett gehe, drücke ich auf einen Knopf, ich nehme den Status "asleep" ein - alles bestens.
 :) Drücke ich den Knopf lange, wird der Wecker ausgeschaltet, ich kann lange schlafen, am nächsten Tag ist der Wecker automatisch wieder eingeschaltet - alles bestens.
 :) Will ich 2 Stunden später aufstehen, stelle ich die Zeit, alles klappt, auch am Folgetag wieder normale Weckzeit - alles bestens.
 :( Will ich früher aufstehen, stelle ich die Zeit, ich werde pünktlich geweckt, sobald die Kaffeemaschine läuft habe ich den Status "home" - soweit alles ok. Aber dann klingelt der Wecker zur Standardzeit wieder, und wei ich nicht "asleep" bin, sondern "home" kommt natürlich einiges bei mir durcheinander. Gibt es irgendeine Idee, wo ich meinen Fehler suchen muss?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: masterpete23 am 19 Dezember 2015, 10:49:24
Hi. Wie kann ich mehrere zu einer  Gruppe Familie zusammen fassen oder die Kinder zur Gruppe Kinder bündeln damit ich darauf abfragen machen kann.

Gesendet von meinem Huawei Honor 7

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 19 Dezember 2015, 11:16:06
Hallo, wir haben mit dem Wecker ein "Problem". Die Grundfunktion ist perfekt, da darf man wiederholt nochmals DANKE sagen.
 :) Wenn ich nun ins Bett gehe, drücke ich auf einen Knopf, ich nehme den Status "asleep" ein - alles bestens.
 :) Drücke ich den Knopf lange, wird der Wecker ausgeschaltet, ich kann lange schlafen, am nächsten Tag ist der Wecker automatisch wieder eingeschaltet - alles bestens.
 :) Will ich 2 Stunden später aufstehen, stelle ich die Zeit, alles klappt, auch am Folgetag wieder normale Weckzeit - alles bestens.
 :( Will ich früher aufstehen, stelle ich die Zeit, ich werde pünktlich geweckt, sobald die Kaffeemaschine läuft habe ich den Status "home" - soweit alles ok. Aber dann klingelt der Wecker zur Standardzeit wieder, und wei ich nicht "asleep" bin, sondern "home" kommt natürlich einiges bei mir durcheinander. Gibt es irgendeine Idee, wo ich meinen Fehler suchen muss?

Da kannst Du nichts machen. Stell Dir doch einfach vor was genau passiert.
Du hast eine default Zeit auf die jeden Tag gestellt wird, und zwar immer nach dem Stoppen des Weckers beim letzten Weckprozess. So und nun überlege mal was wohl passiert wenn Deine default Zeit 5 Uhr ist, Du Dich aber mal um 4 Uhr wecken lässt.

Das ist nicht gegen Dich so der an alle User gerichtet. Wenn Ihr ein Modul verwendet, versucht bitte zu verstehen wo die Zusammenhänge sind und wie das Modul funktioniert. Logik.



Grüße
Leon
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 19 Dezember 2015, 11:37:21
Da kannst Du nichts machen. Stell Dir doch einfach vor was genau passiert.
Du hast eine default Zeit auf die jeden Tag gestellt wird, und zwar immer nach dem Stoppen des Weckers beim letzten Weckprozess. So und nun überlege mal was wohl passiert wenn Deine default Zeit 5 Uhr ist, Du Dich aber mal um 4 Uhr wecken lässt.

Das ist nicht gegen Dich so der an alle User gerichtet. Wenn Ihr ein Modul verwendet, versucht bitte zu verstehen wo die Zusammenhänge sind und wie das Modul funktioniert. Logik.

Grüße
Leon
Ok, soweit klar, aber wie funktioniert das dann bei "Wecker aus"? Wann wird da wieder die Defaultzeit eingestellt?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 19 Dezember 2015, 12:13:49
Weil eine Zeit immer eingestellt wird/ist. Und wenn Du eine default Zeit hast dann wird die auch gesetzt. ABER, wenn Dein Wecker auf OFF steht, werden die entsprechenden Skripte nicht ausgeführt.



Grüße
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 19 Dezember 2015, 12:32:48
Hi. Wie kann ich mehrere zu einer  Gruppe Familie zusammen fassen oder die Kinder zur Gruppe Kinder bündeln damit ich darauf abfragen machen kann.


Dazu gibt es ein Beispiel in der Commandref von ROOMMATE (http://fhem.de/commandref.html#ROOMMATE) und GUEST (http://fhem.de/commandref.html#GUEST):



# Complex family structure
define rr_Manfred ROOMMATE rgr_Residents,rgr_Parents # Parent
define rr_Lisa ROOMMATE rgr_Residents,rgr_Parents # Parent
define rr_Rick ROOMMATE rgr_Residents,rgr_Children # Child1
define rr_Alex ROOMMATE rgr_Residents,rgr_Children # Child2


Wichtig ist dabei, dass alle 3 RESIDENTS Devices vor den ROOMMATE Devices angelegt sind.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 19 Dezember 2015, 12:45:01
:( Will ich früher aufstehen, stelle ich die Zeit, ich werde pünktlich geweckt, sobald die Kaffeemaschine läuft habe ich den Status "home" - soweit alles ok. Aber dann klingelt der Wecker zur Standardzeit wieder, und wei ich nicht "asleep" bin, sondern "home" kommt natürlich einiges bei mir durcheinander. Gibt es irgendeine Idee, wo ich meinen Fehler suchen muss?


Ja das ist ein bekannter Fehler, für den ich noch keine Zeit hatte ihn genauer zu untersuchen.
Es gibt eigentlich eine Art Karenzzeit, in der der Wecker kein zweites Mal auslösen sollte (siehe Attribut wakeupWaitPeriod mit Default Wert = 6h). Sprich, wenn z.B. die Default-Time auf 7:00 steht und ich den Wecker ausnahmsweise früher auf 5:00 gestellt habe, sollte er um 7:00 nicht nochmals ausgelöst werden, obwohl nach dem Wecken um 5:00 die Uhrzeit wieder automatisch auf 7:00 gestellt worden ist, damit am nächsten Tag wieder zur Standardzeit geweckt wird.


Leider sind Tests und Debugging-Sessions da immer sehr aufwändig, weil man eben dauernd einen Timer setzen und 1-2 Minuten warten muss, bis dieser dann ausgeführt wird. Daher habe ich das noch nicht gemacht, auch weil es bei mir nicht so häufig vorkommt, dass ich früher als normal aufstehe.
Spontan könnte es damit zu tun haben (Auszug Commandref): "Does not apply in case wake-up time was changed during this period".
Das muss ich aber wie gesagt erstmal ausprobieren.


-----


Es bleibt auch noch der Anwendungsfall, dass ich von alleine früher aufwache und mich auf "awoken" etc. setze. Dabei sollte der Wecker dann eigentlich auch nicht mehr auslösen. Das ist auch noch nicht berücksichtigt, aber eben auch ein seltener, jedoch realistischer Anwendungsfall.


Das ist nicht gegen Dich so der an alle User gerichtet. Wenn Ihr ein Modul verwendet, versucht bitte zu verstehen wo die Zusammenhänge sind und wie das Modul funktioniert. Logik.


Grundsätzlich richtige Schlussfolgerung, das Modul versucht dem aber wie oben beschrieben durchaus entgegenzuwirken (bzw. soll es)  ;)


Ok, soweit klar, aber wie funktioniert das dann bei "Wecker aus"? Wann wird da wieder die Defaultzeit eingestellt?


Das zum Wecker dazugehörige at-Device bleibt immer aktiv und löst trotzdem aus. Wenn man also den Wecker einmal auf OFF stellt, dann wird die Default-Time am nächsten Tag zur gewohnten Weckzeit wieder eingeschaltet, so dass am übernächsten Tag wieder geweckt wird (u.U. je nach Einstellung von wakeupResetdays).


Weil eine Zeit immer eingestellt wird/ist. Und wenn Du eine default Zeit hast dann wird die auch gesetzt. ABER, wenn Dein Wecker auf OFF steht, werden die entsprechenden Skripte nicht ausgeführt.


Richtig.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 19 Dezember 2015, 12:57:35
:( Will ich früher aufstehen, stelle ich die Zeit, ich werde pünktlich geweckt, sobald die Kaffeemaschine läuft habe ich den Status "home" - soweit alles ok. Aber dann klingelt der Wecker zur Standardzeit wieder, und wei ich nicht "asleep" bin, sondern "home" kommt natürlich einiges bei mir durcheinander. Gibt es irgendeine Idee, wo ich meinen Fehler suchen muss?


Eine Überlegung, mit der ich immer wieder ringe, ist auch:
Momentan wird ein Wecker IMMER ausgelöst, unabhängig vom Status des Bewohners (solange er nur zu Hause ist). Das soll vermeiden, dass man ggf. einmal vergisst über die Hausautomation schlafen zu gehen (sprich sich nicht in den Status "asleep" schaltet) und dann eben nicht geweckt würde. Wie man hier merkt kann es jedoch auch Vorteile haben, dass ein Wecker wirklich nur auslöst, wenn man tatsächlich "asleep" ist. Ich kenne es aber von mir selbst, dass ich z.B. auf dem Sofa einschlafe und dann nur noch im Halbschlaf ins Schlafzimmer wanke ohne mich in den Status "asleep" zu schalten und einfach nur  jeden Lichtschalter betätige, der mir begegnet. Das kann man sicher auch mit einer feiner ausgeklügelten Automation auffangen, dennoch bleibt immer ein "Restrisiko". Da ist es mir bisher immer wichtiger gewesen am nächsten Morgen zuverlässig geweckt zu werden und eben mit der Komplexität umzugehen, dass der Wecker implizit schauen muss nicht doppelt auszulösen.


Wenn da jemand eine bessere Logik für erfinden kann, bitte gerne ;)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 19 Dezember 2015, 14:15:33
Hallo Loredo,

ich finde deine Logik ok, habe es soweit verstanden und muss doch jetzt nur noch "meinen Laden aufräumen". Mir ist es auch lieber 2x geweckt zu werden als gar nicht! Wenn das Attribut wakeupWaitPeriod richtig tut, wäre es doch schon prima. Die ganz Vorsichtigen können das Attribut auf 0 setzen, dein Default von 6 Stunden erscheint mir ganz ok.

Wenn man dann noch das genannte Attribut immer beim Übergang auf den Status "home" nutzt, dann hätte man auch den Fall des freiwillig früheren Aufstehens ohne Wecker erschlagen.

Sicherlich gibt es noch weitere Meinungen, ich kann auch mit den jetzigen Zustand leben.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: masterpete23 am 19 Dezember 2015, 23:23:50
könnt mich  bitte einer in die richtige Richtung Schubsen
Möchte die residents zu eltern zusammen fassen.
und dort dann auch den status anzeigt
über presence zieh ich mir das .
BIn ich hier überhaupt korrekt?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 20 Dezember 2015, 12:48:33
könnt mich  bitte einer in die richtige Richtung Schubsen
Möchte die residents zu eltern zusammen fassen.
und dort dann auch den status anzeigt
über presence zieh ich mir das .
BIn ich hier überhaupt korrekt?

Ich verstehe irgendwie gar nicht, was du hier schreibst, deine Worte ergeben für mich keinen Sinn.

Du musst doch quasi nur die Beispiele von oben nachempfinden. Was fehlt dir da?
Du kannst RESIDENTS nicht gruppieren, du kannst ROOMMATE und GUEST in einer oder mehreren RESIDENTS Gruppen zusammenfassen.

Also wie oben beschrieben:

Eltern (Type: RESIDENTS)
   |--Vater (Type: ROOMMATE)
   |--Mutter (Type: ROOMMATE)

Kinder (Type: RESIDENTS)
   |--Kind1 (Type: ROOMMATE)
   |--Kind2 (Type: ROOMMATE)

Bewohner (Type: RESIDENTS)
   |--Vater (Type: ROOMMATE)
   |--Mutter (Type: ROOMMATE)
   |--Kind1 (Type: ROOMMATE)
   |--Kind2 (Type: ROOMMATE)


Das definiert sich dann so:


define Bewohner RESIDENTS
define Eltern RESIDENTS
define Kinder RESIDENTS

define Vater ROOMMATE Bewohner,Eltern
define Mutter ROOMMATE Bewohner,Eltern
define Kind1 ROOMMATE Bewohner,Kinder
define Kind2 ROOMMATE Bewohner,Kinder
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: MichaelO am 21 Dezember 2015, 19:09:25
Moin,

ich hätte eine Frage zu den Reading "*Names":

residentsHomeNames
residentsTotalPresentNames
residentsTotalRoommatesPresentNames

Ich habe alle Roomates gruppiert zu "Status Hausbewohner". Nun fiel mir auf, dass alle Readings, wo die Namen der Roomates auftauchen sollten, als "Status Hausbewohner" angezeigt werden.

residentsTotalRoommatesPresentNames
Status Hausbewohner, Status Hausbewohner
2015-12-21 18:58:42

Hab ich da was falsch gemacht, oder kann/sollte das im Modul geändert werden?

Gruß
Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Haecksler am 22 Dezember 2015, 21:43:09
Hallo Loredo,
habe gerade auch ein wenig mit dem RESIDENTS Toolkit wakeuptimer gespielt, was mir aber nicht gefällt ist, dass man nur Weckezeiten im 15min Abstand wählen kann.
Deshalb habe ich die "setlist" wie folgt angepasst:

setList      state:time reset:noArg trigger:noArg start:noArg stop:noArg end:noArg
und das "webcmd" entsprechend

webCmd state
Könnte diese eine Beeinträchtigung der Funktion zur folge haben?

Gruß,
Stefan
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 22 Dezember 2015, 22:16:55
Deshalb habe ich die "setlist" wie folgt angepasst:

setList      state:time reset:noArg trigger:noArg start:noArg stop:noArg end:noArg
und das "webcmd" entsprechend

webCmd state
Könnte diese eine Beeinträchtigung der Funktion zur folge haben?


Grundsätzlich ist es auch so gedacht, dass man die Zeiten in setList anpasst, wenn man das möchte (z.B. wenn man während eines Zeitraums 5min Schritte ö.ä. möchte).
Wenn du dabei auf das Widget "time" umstellst, kannst du den Wecker nicht mehr auf OFF setzen (ok, wenn man drauf verzichten möchte).


Es ist allerdings falsch "state" zu setzen, es muss bei nextRun bleiben:

attr rr_Julian_wakeuptimer1 setList nextRun:time reset:noArg start:noArg trigger:noArg stop:noArg
attr rr_Julian_wakeuptimer1 webCmd nextRun

Das Reading state wird indirekt durch den wakeuptimer gestellt. Es sieht nur so aus, als wenn man state direkt stellen könnte.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Haecksler am 22 Dezember 2015, 22:38:07
Das Reading state wird indirekt durch den wakeuptimer gestellt. Es sieht nur so aus, als wenn man state direkt stellen könnte.

Heißt das, dass

set rr_Julian_wakeuptimer1 08:37
nicht funktioniert?

Oder muss man
set rr_Julian_wakeuptimer1 nextRun 08:37
schreiben?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 22 Dezember 2015, 22:38:55
Heißt das, dass

set rr_Julian_wakeuptimer1 08:37
nicht funktioniert?


Richtig.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Haecksler am 22 Dezember 2015, 22:42:18
Geht
set rr_Julian_wakeuptimer1 nextRun 08:37?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 22 Dezember 2015, 22:42:59
Geht
set rr_Julian_wakeuptimer1 nextRun 08:37?


Yep.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Haecksler am 22 Dezember 2015, 22:49:36

Grundsätzlich ist es auch so gedacht, dass man die Zeiten in setList anpasst, wenn man das möchte (z.B. wenn man während eines Zeitraums 5min Schritte ö.ä. möchte).
Wenn du dabei auf das Widget "time" umstellst, kannst du den Wecker nicht mehr auf OFF setzen (ok, wenn man drauf verzichten möchte).


OFF geht doch wenn ich auf das
devStateIcon OFF:general_aus@red:reset running:general_an@blue:stop .*:general_an@green:nextRun%20OFFklicke...oder stehe ich immer noch auf dem Schlauch?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: masterpete23 am 23 Dezember 2015, 18:47:28
jemand bei http://forum.fhem.de/index.php/topic,46021.0.html eine Idee?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 02 Januar 2016, 00:37:52
ROOMMATE und GUEST bieten jetzt direkte Unterstützung bei der Nutzung zusammen mit GEOFANCY:
http://forum.fhem.de/index.php/topic,18485.msg382980.html#msg382980
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 03 Januar 2016, 07:07:35
Ich habe seit kurzem mehrere Warnungen. Eine davon
2016.01.03 05:30:00 1: PERL WARNING: Odd number of elements in anonymous hash at (eval 108531) line 1.Die fast immer auf die Sekunde genau (manchmal 1 Sekunde später) mit meinen programmierten Weckzeiten auftritt. Ich konnte bei mir aber nichts finden, obschon der Fehler vermutlich schon bei mir liegt. Kann ich da vielleicht einen Hinweis bekommen, in welche Richtung ich bei mir suchen sollte?

Die andere Warnung
2016.01.03 05:54:32 1: PERL WARNING: Argument "" isn't numeric in numeric lt (<) at (eval 109037) line 2.kommt, wenn ich aufgestanden bin und meinen Status wieder auf "home" setze (was ich ganz einfach mit "set rr_Juergen status home" mache).
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: marvin78 am 03 Januar 2016, 09:11:24
Seit dem letzten Update gibt es (wieder) folgende Meldungen im Log:

2016.01.03 09:01:43.849 1: readingsUpdate(rr_XXX,lastDurAbsence_cr,638) missed to call readingsBeginUpdate first.
2016.01.03 09:01:43.849 1: readingsUpdate(rr_XXX,lastDurAbsence,10:37:35) missed to call readingsBeginUpdate first.
2016.01.03 09:01:43.849 1: readingsUpdate(rr_XXX,lastArrival,2016-01-03 09:01:43) missed to call readingsBeginUpdate first.
2016.01.03 08:57:56.337 1: readingsUpdate(rr_XXX,lastDurPresence_cr,633) missed to call readingsBeginUpdate first.
2016.01.03 08:57:56.337 1: readingsUpdate(rr_XXX,lastDurPresence,10:33:01) missed to call readingsBeginUpdate first.
2016.01.03 08:57:56.337 1: readingsUpdate(rr_XXX,lastDeparture,2016-01-03 08:57:56) missed to call readingsBeginUpdate first.

Restore der älteren Versionen behebt das Problem.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: SirUli am 03 Januar 2016, 13:47:05
Seit dem letzten Update gibt es (wieder) folgende Meldungen im Log.

Genau das wollte grad melden. Habe es gerade kurz auf einem jungfräulichen FHEM nachgestellt. Wenn man FHEM 5.7 von der Homepage runterlädt, geht es noch - nach einem update & shutdown restart nicht mehr. Leider stürzt dann bei mir bei Nutzung des Moduls (Hatte Notifies von Geofancy zu RESIDENTS eingerichtet) auch noch FHEM komplett mit dem Fehler "month "-1" out of range" aus Zeile 1581 der RESIDENTStk.pm ab. Ich dachte erst, es liegt am $m -= 01; aber es dann kommt es klarer im Log: Anscheinend wird da ein leerer Timestamp übergeben.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: shady88 am 04 Januar 2016, 12:36:50
Puh, ich dachte schon ich kapiers nicht :D
Habe gerade damit begonnen dieses Modul auszuprobieren. Nach dem anlegen von RESIDENTS hab ich einen ROOMATE hinzugefügt und als ich dann zB auf "Everything" ging (wo der Roomate dann ja angezeigt wird) stürtzt FHEM ab.

Hier meine (teilweise schon bekannten) Logs nach dem Anlegen eines Roomates. Der Fehler ohne Zeitstempel am Ende kommt erst, wenn ich Everything oder den Roomate direkt aufrufe:

2016.01.04 12:28:52 1: PERL WARNING: Use of uninitialized value $time in concatenation (.) or string at ./FHEM/20_ROOMMATE.pm line 911.
2016.01.04 12:28:52 1: PERL WARNING: Use of uninitialized value $device in concatenation (.) or string at ./FHEM/20_ROOMMATE.pm line 911.
2016.01.04 12:28:52 1: readingsUpdate(rr_XXX,wayhome,0) missed to call readingsBeginUpdate first.
2016.01.04 12:28:52 1: readingsUpdate(rr_XXX,lastArrival,2016-01-04 12:28:52) missed to call readingsBeginUpdate first.
2016.01.04 12:28:52 1: readingsUpdate(rr_XXX,durTimerPresence_cr,0) missed to call readingsBeginUpdate first.
2016.01.04 12:28:52 1: readingsUpdate(rr_XXX,durTimerPresence,00:00:00) missed to call readingsBeginUpdate first.
2016.01.04 12:28:52 1: readingsUpdate(rr_XXX,durTimerAbsence_cr,0) missed to call readingsBeginUpdate first.
2016.01.04 12:28:52 1: readingsUpdate(rr_XXX,durTimerAbsence,00:00:00) missed to call readingsBeginUpdate first.
2016.01.04 12:28:52 1: readingsUpdate(rr_XXX,durTimerSleep_cr,0) missed to call readingsBeginUpdate first.
2016.01.04 12:28:52 1: readingsUpdate(rr_XXX,durTimerSleep,00:00:00) missed to call readingsBeginUpdate first.
2016.01.04 12:29:06 1: readingsUpdate(rr_XXX,wayhome,0) missed to call readingsBeginUpdate first.
2016.01.04 12:29:06 1: readingsUpdate(rr_XXX,lastDeparture,2016-01-04 12:29:06) missed to call readingsBeginUpdate first.
Month '-1' out of range 0..11 at FHEM/RESIDENTStk.pm line 1581
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 06 Januar 2016, 18:07:44
Hab gerade einen vorübergehenden Patch dafür eingecheckt.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: LarsMie am 06 Januar 2016, 20:44:10
Wo bekomme ich den Patch denn her? Bei update check wird mit nichts angezeigt. Hast du nen repo oder wird der patch verzögert verteilt?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 06 Januar 2016, 20:57:00
wie üblich bei FHEM immer über Nacht am nächsten Morgen oder manuell aus dem Subversion Repo bei Sourceforge.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: LarsMie am 06 Januar 2016, 21:08:58
Na gut, ich warte lieber auf das FHEM update, kenne mich mit subversion nicht so aus. Nich dass ich mir da noch was zerschiesse.

Muss mich mal damit beschäftigen, habe da nur noch nicht ganz durchgeblickt wie git und/oder subversion prinzipiell funktionieren.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: shady88 am 07 Januar 2016, 15:22:49
Läuft jetzt wieder!

Danke Loredo für den Patch und für die tolle Modulfamilie. Ist ein wirklich mächtiges Ding, dass sehr viele Möglichkeit bietet!
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: LarsMie am 07 Januar 2016, 18:11:06
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 08 Januar 2016, 19:32:02
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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: LarsMie am 08 Januar 2016, 20:17:56
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 08 Januar 2016, 20:30:16

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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 09 Januar 2016, 06:45:44
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.

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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 09 Januar 2016, 12:37:16
Der Wecker funktioniert nicht mehr!

Im Log steht:
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:
{
  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:
{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:
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:
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 09 Januar 2016, 22:38:41
Also ich bekomme mittlerweile grundsätzlich bei jeder Änderung des "state" eines Roommate eine Warnung im log:
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:
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 10 Januar 2016, 19:37:31

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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 10 Januar 2016, 19:41:31
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 11 Januar 2016, 06:31:56
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   ;D



Grüße
Leon
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 11 Januar 2016, 17:41:39
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 11 Januar 2016, 18:05:33
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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 11 Januar 2016, 22:34:14
@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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 11 Januar 2016, 22:36:44
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 17 Januar 2016, 17:34:06
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Per am 31 Januar 2016, 22:10:59
Obwohl es auch ne allgemeine RegEx-Frage, stelle ich sie mal gezielt hier ein:
Mit attr rr_noDuration 1 stelle ich die ganze Duration-Geschichte auf aus.
Könnte ich event-on-change-reading so einstellen, dass ich zwar die Zeiten abfragen kann, aber dennoch keine Events generiere?
"event-on-change-reading durTimer.*"geht ja nicht, man bräuchte das "Gegenteil".

Zweite Frage: ich habe das Glück, im Normalfall keinen Wecker zu brauchen. Funktioniert der Resetswitcher dafür auch, oder muss ich mir einfach eine einzelne Weckzeit definieren? Denn dann würde ich ja auch auf die integrierten Prozesse verzichten müssen, oder?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 07 Februar 2016, 14:12:52
Mit attr rr_noDuration 1 stelle ich die ganze Duration-Geschichte auf aus.
Könnte ich event-on-change-reading so einstellen, dass ich zwar die Zeiten abfragen kann, aber dennoch keine Events generiere?
"event-on-change-reading durTimer.*"geht ja nicht, man bräuchte das "Gegenteil".


Das ist in der Tat keine Frage für diesen Thread hier.
Vielleicht mit sowas hier (ungetestet):


event-on-change-reading ^(?!(?:durTimer.*)).*$


Zweite Frage: ich habe das Glück, im Normalfall keinen Wecker zu brauchen. Funktioniert der Resetswitcher dafür auch, oder muss ich mir einfach eine einzelne Weckzeit definieren? Denn dann würde ich ja auch auf die integrierten Prozesse verzichten müssen, oder?


Sicher, du kannst das Attribut wakeupDefaultTime einfach auf OFF setzen. Dann wird nach einmaligem wecken der Wecker deaktiviert.


Das hat aber mit dem Resetswitcher direkt nichts zu tun, denn der ist nur dafür da, dass man den automatischen Reset schnell ein und aus schalten kann.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: stromer-12 am 07 Februar 2016, 14:34:39
Vielleicht mit sowas hier (ungetestet):

event-on-change-reading ^(?!(?:durTimer.*)).*$

lässt fhem abstürzen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 13 Februar 2016, 10:06:45
Ich habe gerade den Wakeuptimer dahingehend erweitert, dass wakeupWaitPeriod jetzt nicht mehr den letzten Lauf des jeweiligen Weckers berücksichtigt, sondern generell jeden Wecker, der einem ROOMMATE/GUEST Device zugeordnet ist. Außerdem wird zusätzlich neu geschaut, ob die Person bereits innerhalb der letzten Stunden aufgewacht ist. Das hilft dagegen, dass der Wecker auslöst, wenn man z.B. bereits vor dem Wecker von selbst wach geworden ist und sich manuell auf "awoken" geschaltet hat. Der Zeitraum dafür ist momentan identisch mit wakeupWaitPeriod ansich, da mir gerade kein Grund einfiel dafür ein extra Attribut einzuführen.


Ab morgen dann per Update.




Gruß
Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: knochenmuehle am 14 Februar 2016, 13:01:43
Hallo,

ich habe hier folgende Konfiguration:

EgiGeoZone mit GPS und Beacons

Eine Work und eine Wayhome Zone ist mit GPS Erkennung eingerichtet.

Meine Home Zone habe ich mit Beacons eingerichtet.
1. Beacon Zone: home Reichweite gesamtes Haus
2. Beacon Zone: Wohnzimmer aktiv nur im Wohnzimmer
3. Beacon Zone: Schlafzimmer aktiv nur im Schlafzimmer

EgiGeoZone meldet zuverlässig ein Verlassen jeder Zone. Das hat aber den Nachteil, wenn ich das Wohnzimmer Beacon verlasse bin ich underway und nicht home obwohl ich die ganze Zeit im Bereich des Home Beacons bin.

im Attribut rr_locationHome habe ich alle Beacon Zonen erfasst.

Gibts dafür eine Lösung ?

Andreas
   
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 14 Februar 2016, 14:04:31
Gibts dafür eine Lösung ?

Ja, du scheinst die Funktion falsch zu nutzen bzw. nicht korrekt eingerichtet zu haben:

1. Das Attribut rr_locationHome ist nur für Lokationen vorgesehen, für die ein kommen/gehen dann auch den tatsächlichen Anwesenheitsstatus verändern soll (siehe Beschreibung in der CommandRef). iBeacons sollte man hier nur eintragen, wenn diese iBeacon ID auch dauerhaft im gesamten Wohnbereich empfangen wird. iBeacons für einzelne Zonen sollte man hier nicht eintragen, da es auch nicht notwendig ist.

2. In der Geofencing App sollte man für iBeacons nur einen Event-Trigger fürs betreten aktivieren, nicht aber fürs verlassen. Dadurch relativiert sich auch die Aussage unter Punkt 1 und man kann unter rr_locationHome genannte iBeacons dafür nutzen sich als "zu Hause" zu schalten, sofern das über Geofencing noch nicht ausgelöst hat. Gleichzeitig wird verhindert, dass man als "abwesend" erkannt wird. Der Wechsel zwischen den Räumen findet dann ausschließlich über das Entering-Event statt. Somit wird auch verhindert, dass man zwar zu Hause ist, aber in FHEM der aktuelle Raum "unbekannt" ist (bzw. das Reading locationPresence auf "absent" steht, was eben gleichbedeutend ist mit "ich weiß grad nicht wo du bist").
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 15 Februar 2016, 12:44:43
Ich habe gerade einen weiteren Fix für den Wakeuptimer eingecheckt.

Ab morgen werden noch laufende Weckprogramme durch einen Statuswechsel ordnungsgemäß frühzeitig gestoppt. Das war im Code zwar schon drin, hatte bisher aber nicht gegriffen.
Wer also vor Ende des Weckprogrammes auf "awoken" schaltet, beendet damit ab sofort das Weckprogramm auch entsprechend.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 15 Februar 2016, 12:51:50
Na das nenne ich doch mal eine saubere Lösung. Vielen Dank Julian.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 18 Februar 2016, 09:43:58
Hallo Julian,

Hast Du in letzter Zeit was am Guest Modul gemacht? Irgendwie fehlt mir der Status none für dauerhaft weg. Also kein Guest im Haus.



Grüße
Leon
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 18 Februar 2016, 10:49:16
Hi Leon,


nein, da gab es keine Änderung in der Richtung.
Ich kann bei mir auch "none" ganz normal auswählen. Hast du die angezeigten Werte mittels Attributen abgeändert? (z.B. widgetOverride oder rg_states)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 18 Februar 2016, 10:55:31
Hallo Julian,

Nein habe nichts geändert. Muss auch erst vor kurzem passiert sein. Kann aber mit meinen Dilemma von gestern zu tun haben, habe bei einem Set Befehl mit FILTER statt = ein : hinter FILTER gemacht und somit alle states auf nextRun gesetzt   ;D

Habe jetzt den Guest gelöscht und neu angelegt und siehe da, none ist wieder da. Hatte da zum Glück noch keine weiteren Verknüpfungen.
Vielen Dank für die floltte Antwort.



Grüße
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 18 Februar 2016, 11:44:21
Habe jetzt den Guest gelöscht und neu angelegt und siehe da, none ist wieder da. Hatte da zum Glück noch keine weiteren Verknüpfungen.


Selbst wenn: Löschen und unter dem selben Namen wieder neu anlegen ist überhaupt gar kein Problem :-)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: wmr72 am 19 Februar 2016, 20:41:55
Hallo,

ich habe bei mir ein notify auf das state-Reading eines RESIDENTS-Device, in dem ich dann per Push den Auslöser der Änderung verschicken möchte:
rgr_residents:state:.(home|absent|gone) {
    my $lastActivity = ReadingsVal("rgr_residents", "lastActivityBy", "unbekannt");
    fhem("set sys_pushbullet message $lastActivity | Homestatus: $EVTPART1", 1);
}

Das funktionierte bei mir nicht (ich bekomme das vorletzte aktive Device und nicht den eigentlichen Auslöser), da im Modul erst der state geändert wird und erst anschließend die entsprechenden Readings gesetzt werden, allerdings in unterschiedlichen Updates. Mit dem folgenden Patch hab ich das mal umgedreht, negative Auswirkungen konnte ich keine feststellen:

--- a/FHEM/10_RESIDENTS.pm
+++ b/FHEM/10_RESIDENTS.pm
@@ -154,20 +154,6 @@ sub RESIDENTS_Notify($$) {
                 Log3 $hash, 5,
                   "RESIDENTS " . $hashName . ": processing change $change";

-                # state changed
-                if (   $change !~ /:/
-                    || $change =~ /wayhome:/
-                    || $change =~ /wakeup:/ )
-                {
-                    Log3 $hash, 4,
-                        "RESIDENTS "
-                      . $hashName . ": "
-                      . $devName
-                      . ": notify about change to $change";
-
-                    RESIDENTS_UpdateReadings($hash);
-                }
-
                 # activity
                 if ( $change !~ /:/ ) {

@@ -205,6 +191,21 @@ sub RESIDENTS_Notify($$) {
                     readingsBulkUpdate( $hash, "lastActivityByDev", $devName );
                     readingsEndUpdate( $hash, 1 );
                 }
+
+                # state changed
+                if (   $change !~ /:/
+                    || $change =~ /wayhome:/
+                    || $change =~ /wakeup:/ )
+                {
+                    Log3 $hash, 4,
+                        "RESIDENTS "
+                      . $hashName . ": "
+                      . $devName
+                      . ": notify about change to $change";
+
+                    RESIDENTS_UpdateReadings($hash);
+                }
+
             }

             return;

Spricht was dagegen das allgemein zu übernehmen, evtl. übersehe ich ja was?

Wolfgang

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 20 Februar 2016, 21:22:59
Ich habe gerade eine Erweiterung des Wakeuptimers eingecheckt.
Man kann jetzt bei einem aktiven Wecker dessen Zeit relativ zur bereits gesetzten Weckzeit verändern, also z.B. 10 Minuten früher oder auch später:


set rr_Julian_wakeuptimer1 nextRun +10
set rr_Julian_wakeuptimer1 nextRun -00:10


Man kann die Zeit in Minuten oder im Format HH:MM angeben.


Das kann z.B. dazu verwendet werden, wenn man verkehrsbedingt (Auto oder Bahn) früher geweckt werden möchte. Zusammen mit dem wakeupDefaultTime Attribut wird dann auch sichergestellt, dass die Weckzeit am nächsten Tag wieder zunächst wie gewohnt ist.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 20 Februar 2016, 22:00:57
Das funktionierte bei mir nicht (ich bekomme das vorletzte aktive Device und nicht den eigentlichen Auslöser), da im Modul erst der state geändert wird und erst anschließend die entsprechenden Readings gesetzt werden, allerdings in unterschiedlichen Updates.


Ich habe den Patch abgewandelt; die Readings werden jetzt allesamt zusammen erzeugt und es wird nur noch ein einziges Event ausgelöst.
Ab morgen dann per Update verfügbar.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 22 Februar 2016, 12:35:59
Hallo Julian,

Ist es Möglich zwei Residents Devices in Abhängigkeit zu einem weiteren Residents Device zu schalten? So wie Roommate zu Residents.

Ich möchte gerne Residents Eltern, Residents Kinder und Residents Wohnung haben. Oder muss ich in Residents Wohnung alle Roommate's von Residents Eltern und Residents Kinder eintragen?


Grüße
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 22 Februar 2016, 14:02:56
Die Möglichkeit gleiche Devices miteinander zu verschachteln habe ich absichtlich verworfen, da es dann zu komplex wird.
Auch wenn der erste Implus ist, dass man mehrere RESIDENTS Devices hintereinander kaskadieren können möchte, so hilft etwas umdenken auch dabei zu sehen, dass man das selbe auch erreichen kann, wenn die ROOMMATE/GUEST Devices einfach in mehreren RESIDENTS Devices gleichzeitig Mitglied sein können.


Ein Beispiel für das, was du möchtest, findet sich sogar in der CommandRef (http://fhem.de/commandref.html#ROOMMATE):



# Complex family structure
define rr_Manfred ROOMMATE rgr_Residents,rgr_Parents # Parent
define rr_Lisa ROOMMATE rgr_Residents,rgr_Parents # Parent
define rr_Rick ROOMMATE rgr_Residents,rgr_Children # Child1
define rr_Alex ROOMMATE rgr_Residents,rgr_Children # Child2


Übrigens nur so rein als Hinweis: Ein RESIDENTS Device als "Wohnung" zu führen ist rein syntaktisch nicht ganz richtig, da es nicht den wirklichen Hausstatus wiedergibt (also z.B. in welchem "Modus" sich das Haus gerade befindet - also sowas wie Morgen/Tag/Abend/Nacht), sondern lediglich den Status seiner Bewohner.


Für den tatsächlichen Hausstatus war/ist noch immer ein Modul "HOMESTATE" o.ä. vorgesehen. Allerdings feile ich da noch immer an vielerlei Logik und schaue auch noch, ob es überhaupt noch ein eigenständiges Modul sein muss. Mit DOIF lässt sich auch sehr viel machen (aber noch nicht 100%ig alles). Ich überlege also mehr ähnlich wie beim Wakeuptimer eine Art Framework/Template bereitzustellen, welches dann eben genauso anpassbar ist und direkt auf die Zusammenarbeit mit RESIDENTS/ROOMMATE/GUEST ausgelegt ist. Das ist aber noch ein langer Weg, ich komme einfach nicht dazu das rund zu machen (auch zum Leidwesen meiner eigenen Hausautomation).






Gruß
Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 22 Februar 2016, 14:28:48
Vielen Dank für Deine ausführliche Antwort. Naja es heißt ja nicht direkt Wohnung bei mir sondern so wie meine Straße   ;D
Aber ich weiß was Du meinst und so führe ich es auch Gedanklich.



Grüße
Leon
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Per am 11 März 2016, 11:34:49
Könnte ich event-on-change-reading so einstellen, dass ich zwar die Zeiten abfragen kann, aber dennoch keine Events generiere?
Da ich keine Antwort (https://forum.fhem.de/index.php/topic,49574.msg412813.html#msg412813) bekommen habe, scheint es nicht zu gehen.

Mit attr rr_noDuration 1 stelle ich die ganze Duration-Geschichte auf aus.
Wäre es möglich, mit attr rr_noDuration 2 (oder halt einer anderen Syntax) die Abfragen selbst an, aber die Events auszuschalten?

Edit: Jetzt hat sich doch eine Lösung ergeben! Danke.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: SirMarco am 23 April 2016, 17:06:58
Kann jemand einem Neuling weiterhelfen?
Möchte gerne bei HomeStatus Änderung "absent" einen Befehl ausführen. Wird das auch über ein Macro geregelt?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 23 April 2016, 17:29:45
Du kannst ein vorhandenes Macro kopieren und für absent anpassen. Denk auch daran den Watchdog mit zu kopieren.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 23 April 2016, 17:34:08
Über DOIF oder Notify. Schau mal in die CommandRef.


Gruß
Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: SirMarco am 23 April 2016, 17:59:24
Du kannst ein vorhandenes Macro kopieren und für absent anpassen. Denk auch daran den Watchdog mit zu kopieren.

Danke das war die Lösung, manchmal echt einfach  ;)

Nun bekomme ich im Log die Meldung

 2016.04.23 17:52:29 2: ROOMMATE set rr_Marco absent
2016.04.23 17:52:33 3: Watchdog wd_rr_Marco_absent triggered
2016.04.23 17:52:33 2: IT set Flex_2 off
2016.04.23 17:52:33 3: Please define wd_rr_Marco_absend first

wd_rr_Marco_absend ist die Kopie von wd_rr_Marco_asleep

Die DEF wurden angepasst
rr_Marco:absent 00:00:04 rr_Marco:(home|absent|gone|none|gotosleep|awoken) trigger Macro_rr_Marco_absent; setstate wd_rr_Marco_absend defined
Wie kann ich prüfen warum der watchdog nicht auf defined zurück gesetzt wird?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 23 April 2016, 18:36:12
Du hast dich verschrieben. Einmal absent und einmal absend
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 04 Mai 2016, 08:20:23
Guten Morgen Julian,

Ich wollte heute mal Dein msg Befehl im wakeuptime Skript aus probieren. Aber irgendwie meckert er wegen dem @

Macro_rr_Thomas_wakeuptimer1 return value: Global symbol "@Sonos_Schlafzimmer" requires explicit package name at (eval 24470) line 55.

So sieht die Zeile im Skript aus

fhem "define atTmp_7_$NAME at +01:00:00 msg audio @Sonos_Schlafzimmer |Hint| Guten Morgen Thomas. Es ist ".$EVTPART1." Uhr, Zeit zum aufstehen!

Irgendwie ja auch verständlich. Für Perl ist das @ ja eigentlich ein Array. Welches aber im Wakeup script global vorhanden sein muß, aber irgendwie ist es das im Script nicht.

Ne Idee?


Grüße
Leon
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 07 Mai 2016, 18:33:16
im Perl Kontext muss ein @ als \@ escaped werden.
Dazu ist auch ein Beispiel im Default-Macro.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 07 Mai 2016, 18:39:58
Hallo Julian,

Mir war so als hätte ich das auch schon getestet. Mache es aber heute oder morgen noch mal so und teste. Frage ist nur wird das \ dann nicht auch in den define des at mit übertragen und somit dann im FHEM Kontext? Ich schaue mir mal das default Makro an. Muss mal sehen wo das sein soll. Lach.
Es gibt ja ein Beispiel genau so wie ich es habe, daher dachte ich das irgendwas fehlt oder ich übersehen habe.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 07 Mai 2016, 18:49:18
Die Beispiel-Macros waren da wohl auch nicht ganz korrekt bisher, ich hatte zwei \\ zu wenig im File RESIDENTStk.pm und das gerade korrigiert, damit die Vorlagen auch akkurat sind ;-)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 07 Mai 2016, 18:58:24
Cool. Firma Dankt.
Ich teste dann die Tage mal.


Beste Grüße
Leon
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Otto am 07 Juni 2016, 22:05:53
Gib es eine Möglichkeit den RESIDENTS Status gotosleep nicht zu schalten wenn die ROOMMATES den Status gotosleep und der andere absent haben.

Ich fahre alle Rollos beim RESIDENTS Status gotosleep runter aber ein ROOMMATES ist ja noch absent, und somit sollten die Rollos noch nicht runterfahren.

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 07 Juni 2016, 22:28:13
Gib es eine Möglichkeit den RESIDENTS Status gotosleep nicht zu schalten wenn die ROOMMATES den Status gotosleep und der andere absent haben.

Ich fahre alle Rollos beim RESIDENTS Status gotosleep runter aber ein ROOMMATES ist ja noch absent, und somit sollten die Rollos noch nicht runterfahren.

Soweit mir bekannt nicht. Macht auch irgendwie wenig Sinn. Wenn man ganz böse ist würde ich sagen, während Du unterwegs bist darf Deine Frau nicht in Ruhe schlafen   ;D
Was Du machen kannst ist alle Roommates in die Abfrage Deiner Rollos ein zu bauen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 08 Juni 2016, 10:37:21
Gib es eine Möglichkeit den RESIDENTS Status gotosleep nicht zu schalten wenn die ROOMMATES den Status gotosleep und der andere absent haben.


Das wäre unlogisch, denn es geht immer in erster Linie um die anwesenden Personen. Zudem kann man nicht logisch voraussagen, ob eine abwesende Person noch nach Hause kommt oder nicht.
Wenn also alle anwesenden Personen bereits schlafen oder den Status "gotosleep" haben, dann wird auch der Gesamtstatus auf "gotosleep" geschaltet. Nur wenn eine Person anwesend ist und wach (=home) bleibt, bleibt auch der Gesamtstatus auf "home".


Ich fahre alle Rollos beim RESIDENTS Status gotosleep runter aber ein ROOMMATES ist ja noch absent, und somit sollten die Rollos noch nicht runterfahren.


Warum denn eigentlich nicht? Hast du ein Rollo vor der Haustür und man kommt sonst nicht ins Haus? Oder steigt der abwesende Bewohner gerne durch die Terrassentür ein  ;D


Ich gebe CoolTux recht: Du solltest überlegen, ob du die Rollos der einzelnen Schlafzimmer dann nicht am Status des jeweiligen ROOMMATE Gerätes fest machst. Bei zwei Personen kannst du auch mit einem zusätzlichen RESIDENTS Device nur für den "Pärchenstatus" arbeiten. Ich gehe davon aus, dass der noch abwesende Partner nicht verlangt, dass der andere solange im hellen Schlafzimmer schlafen muss, bis er auch zu Hause ist.  ;)


Wenn du aber immer noch Gründe siehst es so zu lösen, wie du es schreibst, dann solltest du dein Notify/DOIF nicht auf das Reading "state" schalten, sondern durch logische Vergleiche+Verknüpfung der Nummern-Readings wie residentsGotosleep, residentsHome und residentsTotal.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Otto am 08 Juni 2016, 10:50:17
Hallo Loredo,

vielen Dank für die Erklärung.

Ich werde mal überlegen wie ich es anstelle.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Thyraz am 21 Juni 2016, 09:15:48
Hi,

nach Umstellung auf iBeacons hätte ich noch einen kleinen Verbesserungsvorschlag bei Verwendung mit Geofancy / rr_geofenceUUIDs:
Evtl. wäre der Vorschlag auch besser im Geofancy Thread platziert?
Weiss nicht wie die beiden Module intern genau zusammenspielen.

Selbst mit mehreren Beacons und höchster Sendeleistung + Häufigkeit hat man ab und an (alle paar Tage) bei jedem Gerät mal kurze Aussetzer.
Nicht zur selben Zeit, scheint also kein Problem der Beacons zu sein sondern eher Systembedingt.
Sprich sehr selten sendet Geofency vom iPhone ein "Home Verlassen" und 2-3 Sekunden später wieder ein "Home Betreten" obwohl man die ganze Zeit in der Wohnung war.

Könnte man hier eine Art Delay in Sekunden als Option für Location-Änderungen einbauen?

Kleines Beispiel:
- Home Betreten -> Timer startet aber Status bleibt weiter auf Absent
- Wartezeit läuft ab -> Status geht auf Home
- Fehlerhafterweise tritt nun "Home verlassen" auf -> Timer startet aber Status bleibt auf Home
- Innerhalb des Timers tritt nun wieder "Home betreten" auf -> Timer startet von vorne, Status ist immer noch Home
- Timer läuft ab -> aktueller Status wieder (oder immer noch) Home
- "Home verlassen" tritt nun berechtigterweise auf -> Timer startet
- Timer läuft ab -> Status auf Absent
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 21 Juni 2016, 11:27:35
Delay für die Kombination mit GEOFANCY steht bereits auf der Todo Liste.
Wer statt dem UUID Attribut manuell über DOIF oder watchdog verknüpft, kann dies auch jetzt bereits haben (mit einigen Einschränkungen in der Weitergabe der Readings).


Achso: Ein Delay ansich kann man im übrigen auch direkt in der Geofency App einstellen (sogar je Location).
Der Grund weshalb das on ROOMMATE noch nicht drin ist liegt auf der Hand: Ein einfaches Delay alleine reicht nicht unbedingt, da muss etwas mehr Intelligenz mit hinein. Insbesondere beim Betreten der Homezone möchte ich persönlich nämlich keinerlei Verzögerung haben, da ich z.B. durch Empfang in der Tiefgarage womöglich ohnehin eher spät erkannt werde oder der Webhook spät abgesetzt werden kann. Erst in der Wohnung erkannt zu werden ist zu spät; insbesondere auch wenn jemand einen Beacon einsetzt will man eigentlich, dass der Status sofort auf "anwesend" geht.


Beim Thema Abwesend sieht es wieder anders aus: Da darf es ruhig länger dauern. Mein Tipp für die Beacon Fetischisten ist daher: Nutzt die Beacons nur für den Entry und deaktiviert das Exit Event. Nutzt für den Exit stattdessen Geofencing.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Thyraz am 22 Juni 2016, 08:54:16
Gute Idee dein letzer Abschnitt. :)

Und ja, die Logik mit Verzögerung nur bei Verlassen klingt nach dem richtigen Ansatz.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Bademeister am 24 August 2016, 00:16:50

Wie kann ich ein Logfile für den rr_Markus erstellen? Ich habe ein Log anlegen können, es wurden allerdings die Statuswechsel nicht dokumentiert.

Zudem möchte ich gerne über einen 6-er Schalter die Anwesenheit/Abwesenheit/GoToSleep auslösen.
Für einen kurzen Tastendruck, die des Bewohners; ein langer Tastendruck für die eines Gastes.

Das habe ich bisher mit einem notify gemacht, der dann über die Sonos die mit Sprachausgabe bestätigt.
Der Statuswechsel triggert anschließend die den Status zugehörigen Aktionen.
 
Auf den erfolgreichen GoToSleep Statuswechsel bei rr_Markus soll nach 10 Minuten (Einschlafvorbereitung) der Status automatisch auf Asleep springen.
Wie kann ich das triggern? fhem "sleep 600; set rr_Markus:state=asleep"
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 24 August 2016, 06:15:20
Du kannst im gotosleep Script den Code einfach eintragen. Dann wechselt er nach 10 min in den asleep Status
fhem "sleep 600; set rr_Markus:FILTER=STATE=gotosleep asleep"

Und für Dein Log Problem mach mal bitte ein list vom Logdevice


Grüße
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 03 Oktober 2016, 07:15:14
Guten Morgen,

Wenn ich da mal ganz kurz die Aufmerksamkeit drauf lenken darf.
https://forum.fhem.de/index.php/topic,58114.msg495234.html#msg495234

Da gibt es wohl seit neustem Probleme mit automatischen Statuswechsel.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 03 Oktober 2016, 10:45:55
Danke, ist wohl deshalb (https://forum.fhem.de/index.php/topic,58354.0.html) durchgerutscht.
Habe im anderen Thread geantwortet.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Florian_GT am 18 Oktober 2016, 22:36:24
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.

Welchen Namen trägt denn der neue Setter?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 19 Oktober 2016, 01:23:13
Die Auswahlliste in Fhemweb verrät es: create locationMap


Sent from my iPad using Tapatalk
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Florian_GT am 27 Oktober 2016, 00:08:36
Die Auswahlliste in Fhemweb verrät es: create locationMap


Sent from my iPad using Tapatalk


Ahh! Vielen Dank!

Ich hatte vergebens, Google, FHEM Forum, FHEM Wiki und Dokumentation danach durchsucht, hätte ich mal im Code geschaut... *koppkratz*

PS: Was auch noch cool wäre, wenn man änliches im Device Type RESIDENTS einbaut, dass dann alle Bewohner die zugeordnet sind, zeigt.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 18 November 2016, 09:27:32
hi zusammen,

kurze Frage:

Wann wird das Reading nextWakeup und nextWakeupDev im Roommate gesetzt und ist dafür ein trigger notwendig?

aktuell steht das Reading auf 7:00 Uhr und rr_Michael_wakeuptimer1, was dem Wecker für die Wochentage entspricht. Morgen ist aber Samstag und somit müsste dort eig. wakeuptimer2 genutzt werden.

Wakeupresetdays ist passend gesetzt.

Gruß Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 19 November 2016, 18:51:52
Kommando zurück!

Ich hatte ein event-on-change-reading für location,mood,presence,state gesetzt. Dadurch konnte wohl irgendein Trigger nicht mehr greifen. Habs wieder rausgenommen und es läuft wieder.


Gruß Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Bootscreen am 24 November 2016, 14:07:59
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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 24 November 2016, 14:10:41
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Bootscreen am 24 November 2016, 14:18:53
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?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 24 November 2016, 16:22:59
Das heißt das Attribut unterbindet im Grunde nur dur* Readings?


Korrekt.


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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 25 November 2016, 11:28:56
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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 25 November 2016, 12:14:33
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 :-)


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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 25 November 2016, 12:19:53
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?

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

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 25 November 2016, 18:07:50
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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Bootscreen am 07 Dezember 2016, 16:46:11
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?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 07 Dezember 2016, 18:20:33
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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Bootscreen am 07 Dezember 2016, 21:06:10
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?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ThommyTom am 13 Dezember 2016, 11:34:47
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??

Zitat
Internals:
   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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag 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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ThommyTom am 13 Dezember 2016, 13:49:55
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....
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: visionsurfer am 31 Dezember 2016, 17:49:03
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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: visionsurfer am 02 Januar 2017, 22:28:24
Hallo,

ich habe noch eine Frage an der ich gerade hänge.

Gibt es eine einfache Möglichkeit die Macros, also die Notifys und Watchdogs für die anderen Statusse zu installieren ? Also kann man die vorhandenen Beispiele irgendwie kopieren und umbennen ?

Ich würde gerne auch gone und absent einbauen, bzw. ein Notify Macro haben wollen. Muss ich das alles von Hand anlegen ? Oder gibt es eine andere Möglichkeit ?

Grüße,
Visionsurfer
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 02 Januar 2017, 22:36:02
einfach kopieren und anpassen

copy macro_absent macro_asleep

und dann den kopf des Notifys anpassen und bei den watchdogs genau das selbe
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: visionsurfer am 03 Januar 2017, 16:03:15
Hallo,

ist hier jemand der sich mit SONOS auskennt ?
Ich nutze aus den Macros die Beispiele und wollte auch mein Sonos einbauen.

Ich habe aus dem Macro folgende Code aktiviert, bzw. mit meinem Geräten umgeschrieben:

## Stop playback bedroom's Sonos device might be involved in
fhem "set Sonos_Schlafzimmer:transportState=PLAYING stop;";

## Make Bedroom's and Bathroom's Sonos devices a single device
## and do not touch other Sonos devices (this is why we use RemoveMember!)
fhem "sleep 10; set Sonos_Schlafzimmer RemoveMember Sonos_Schlafzimmer";
fhem "sleep 11; set Sonos_Bad RemoveMember Sonos_Bad";

## Group Bedroom's and Bathroom's Sonos devices with Bedroom as master
fhem "sleep 12; set Sonos_Bad AddMember Sonos_Schlafzimmer; set Sonos_Schlafzimmer:FILTER=Shuffle!=1 Shuffle 1; set Sonos_Schlafzimmer,Sonos_Bad:FILTER=Volume!=12 Volume 12";

## Start music from playlist
fhem "sleep 13; set Sonos_Schlafzimmer StartPlaylist Abendentspannung";

Wenn ich nun den Status aktiviere, fängt meine Sonos im Schlafzimmer auch an zu spielen. Nur meine Sonos im Bad bleibt ruhig.
Ist an dem Code was falsch ? Weil die sollen doch eigentlich gekoppelt werden und dann beide spielen, oder nicht ?

Grüße,
Visionsurfer
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 03 Januar 2017, 16:30:51
Kommt mir komisch vor

set Sonos_Schlafzimmer,Sonos_Bad:FILTER=Volume!=12 Volume 12"

set (Sonos_Schlafzimmer,Sonos_Bad):FILTER=Volume!=12 Volume 12"

Wenn dann so
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: visionsurfer am 03 Januar 2017, 16:45:15
ok. Muss ich probieren.

So steht es halt im mitgeliefertem Beispiel Macro :)
Ich denke Loredo ist wahrscheinlich im Winterurlaub :)

Grüße,
Visionsurfer
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 03 Januar 2017, 16:50:30
Das oder arbeiten. Julian hat meist nur am WE wirklich Zeit.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Cobra am 03 Januar 2017, 23:18:22
@Visionsurfer

Dreh das mal um:
set Sonos_Bad AddMember Sonos_Schlafzimmer
in:

set Sonos_Schlafzimmer AddMember Sonos_Bad
Dann sollte es klappen.
Du gibst ja in deinem Code an dass die Sonos im Bad das Haupgerät ist und gibst weiter unten an dass die Sonos im Schlafzimmer Musik abspielen soll.

Gruß Cobra
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 04 Januar 2017, 15:52:17
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 ?


Wie man sieht sind die Macros einfach Devices vom Typ "notify". Es gilt also alles, was für das Notify Modul gilt. Die DOIF Notation wird darin nicht unterstützt.
Die Beispiel Macros sind in reinem Perl geschrieben. DOIF hat IMHO keinen Macro Modus, der mit Notify vergleichbar wäre.


einfach kopieren und anpassen


So ist es gedacht. Alles FHEM 1x1 und Boardmittel.


Kommt mir komisch vor

set Sonos_Schlafzimmer,Sonos_Bad:FILTER=Volume!=12 Volume 12"

set (Sonos_Schlafzimmer,Sonos_Bad):FILTER=Volume!=12 Volume 12"

Wenn dann so


Nee, geht auch nicht. :FILTER muss für jedes Device separat gesetzt werden, habe das im Beispielcode gerade korrigiert.
Dennoch ist das nicht tragisch, der Befehl wird halt nur ggf. unnötigerweise geschickt und hat mit sonstigen Schwierigkeiten dann nichts zu tun.


@Visionsurfer

Dreh das mal um:
set Sonos_Bad AddMember Sonos_Schlafzimmer
in:

set Sonos_Schlafzimmer AddMember Sonos_Bad
Dann sollte es klappen.
Du gibst ja in deinem Code an dass die Sonos im Bad das Haupgerät ist und gibst weiter unten an dass die Sonos im Schlafzimmer Musik abspielen soll.


Exakt, auch meine Vermutung. Ansonsten mal Reinerlein in einem separaten Thread zu seinem SONOS Modul befragen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: visionsurfer am 04 Januar 2017, 18:34:31
Hey,

Danke für eure Hilfe. Mit dem umdrehen funktioniert es nun wunderbar. So wie gewünscht. Man es wird immer geiler bei mir :)

Jetzt muss ich die Macros noch kopieren für absend und home und dann kann ich weiter basteln.
Tausend Dank.

Grüße,
Visionsurfer
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 10 Januar 2017, 18:28:06
Ich habe gerade eine aktualisierte Version von ROOMMATE und GUEST eingecheckt.

Über das neue Attribut r*_presenceDevices kann man jetzt ähnlich wie mit r*_geofenceUUIDs vereinfacht auf andere FHEM Geräte verweisen, die einen Wechsel absent->home oder home->absent auslösen. Es können auch mehrere Devices mit Komma getrennt angegeben werden. Erst wenn alle Geräte den selben Status haben wird der Status auch in ROOMMATE/GUEST übernommen. Das ganze funktioniert mit jedem FHEM Device, welches entweder ein Reading "presence" oder "state" mit dem folgenden Status hat:

 absent ODER disappeared ODER unavailable
 present ODER appeared ODER available

Ein Beispiel dafür ist der Einsatz zusammen mit dem PRESENCE Modul.


Wie immer ab morgen per Update verfügbar.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ToKa am 10 Januar 2017, 20:05:14
Hallo zusammen,
 
habe gerade gestern begonnen, das residents Modul einzurichten und bin ganz begeistert. Mit der letzten Änderung kann ich mir dann auch das notify meines G-Tags sparen - echt genial.

Beim wakeuptimer habe ich aber das Problem, dass ich auch Zeiten wie z.B. 04:20 Uhr bräuchte. Soweit ich mich jetzt durch die Doku und das Forum gesucht habe, finde ich aber nicht zu beliebigen Weckzeiten oder einem Art Offset zu den "festen" Zeiten.

Sehe ich das richtig, dass ich dann im wakeup-Device setlist bzw. das userattr wakeupdefaulttime ändern muss? Übersteht so eine Änderung ein Update des Moduls? Könnte man auch das neue DateTimePicker Widget zum Einstellen der Uhrzeit verwenden?

Beste Grüße
Torsten
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 10 Januar 2017, 20:35:24
Sehe ich das richtig, dass ich dann im wakeup-Device setlist bzw. das userattr wakeupdefaulttime ändern muss? Übersteht so eine Änderung ein Update des Moduls?


Es ist vorgesehen setlist abzuändern. userattr wird bei einem Neustart wieder neu gesetzt.


Könnte man auch das neue DateTimePicker Widget zum Einstellen der Uhrzeit verwenden?


Das kommt darauf an, ob du das Dummy Device entsprechend umgebogen bekommst, so dass hinterher trotzdem das Uhrzeitformat 12:00 erhalten bleibt.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ToKa am 10 Januar 2017, 20:44:35
Zitat
userattr wird bei einem Neustart wieder neu gesetzt.
Bedeutet also, dass man wakeupDefaultTime nicht beliebig setzen kann? Oder wie verhält sich der Wecker, wenn man mit dem attr Befehl wakeupDefaultTime auf einen beliebigen Wert setzt?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 10 Januar 2017, 21:25:59
Doch selbstverständlich. setlist ist rein optisch für FHEMWEB und komplett unabhängig, genauso wie wakeupDefaultTime.


Gruß

Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 10 Januar 2017, 22:01:27
@Loredo: Ich hab nur eine rein informative Frage. Hattest du dir bei dem Update auch das Timingproblem bei der Vorhersage von NextWakeUp angeschaut?

Aktuell behelfe ich mir, indem ich beim asleep-Makro die Funktion RESIDENTStk_wakeupGetNext(<ROOMMATE>) aufrufe und damit die Variablen nextWakeupDev und nextWakeup belege und bei der Durchsage nutze. Seit dem habe ich keine falschen Zeiten mehr angesagt bekommen.

Besten Dank für deinen tolle Arbeit und noch einen schönen Abend!

Gruß Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: FunkOdyssey am 11 Januar 2017, 09:52:07
Ich habe gerade eine aktualisierte Version von ROOMMATE und GUEST eingecheckt.

Über das neue Attribut r*_presenceDevices kann man jetzt ähnlich wie mit r*_geofenceUUIDs vereinfacht auf andere FHEM Geräte verweisen, die einen Wechsel absent->home oder home->absent auslösen. Es können auch mehrere Devices mit Komma getrennt angegeben werden. Erst wenn alle Geräte den selben Status haben wird der Status auch in ROOMMATE/GUEST übernommen. Das ganze funktioniert mit jedem FHEM Device, welches entweder ein Reading "presence" oder "state" mit dem folgenden Status hat:

 absent ODER disappeared ODER unavailable
 present ODER appeared ODER available

Ein Beispiel dafür ist der Einsatz zusammen mit dem PRESENCE Modul.


Wie immer ab morgen per Update verfügbar.

Hi Loredo, danke für diese Vereinfachung. Gefällt mir sehr gut.
Ich hatte sonst immer ein DOIF dazwischen. Hatte dann aber auch die Möglichkeit ein paar weitere Bedingungen einzubauen.
So habe ich (ganz individuell) eine Statusänderung durch Presence nur von 10:00 bis 22:00 Uhr zugelassen, da außerhalb des Zeitraum ja theoretisch die Handys auch ausgeschaltet sein können. Dann wären die Bewohne absent, obwohl die ruhig im Bett liegen. Wenn ich deine "Abkürzung" nutze, dann kann ich dies nicht mehr steuern, oder?

Weiterhin habe ich auch manuell "gotosleep" gesetzt, wenn gewissen Kriterien zutrafen (Licht aus, Rolladen runter, etc.).
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 11 Januar 2017, 11:16:36
Ich hatte sonst immer ein DOIF dazwischen. Hatte dann aber auch die Möglichkeit ein paar weitere Bedingungen einzubauen.
So habe ich (ganz individuell) eine Statusänderung durch Presence nur von 10:00 bis 22:00 Uhr zugelassen, da außerhalb des Zeitraum ja theoretisch die Handys auch ausgeschaltet sein können. Dann wären die Bewohne absent, obwohl die ruhig im Bett liegen. Wenn ich deine "Abkürzung" nutze, dann kann ich dies nicht mehr steuern, oder?


Nein. Für solch außergewöhnliche Anwendungsfälle ist die Vereinfachung nicht gedacht. Es kann aber weiterhin DOIF, Notify etc. statt dem Attribut genutzt werden. Daran ändert sich nichts.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 11 Januar 2017, 11:17:14
@Loredo: Ich hab nur eine rein informative Frage. Hattest du dir bei dem Update auch das Timingproblem bei der Vorhersage von NextWakeUp angeschaut?


Nein, dafür war und ist keine Zeit.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 11 Januar 2017, 13:40:04
Ich habe gerade eine aktualisierte Version von ROOMMATE und GUEST eingecheckt.

Über das neue Attribut r*_presenceDevices kann man jetzt ähnlich wie mit r*_geofenceUUIDs vereinfacht auf andere FHEM Geräte verweisen, die einen Wechsel absent->home oder home->absent auslösen. Es können auch mehrere Devices mit Komma getrennt angegeben werden. Erst wenn alle Geräte den selben Status haben wird der Status auch in ROOMMATE/GUEST übernommen. Das ganze funktioniert mit jedem FHEM Device, welches entweder ein Reading "presence" oder "state" mit dem folgenden Status hat:

 absent ODER disappeared ODER unavailable
 present ODER appeared ODER available

Ein Beispiel dafür ist der Einsatz zusammen mit dem PRESENCE Modul.


Wie immer ab morgen per Update verfügbar.

Hallo Julian,

Wird hier auf beides getriggert? Sowohl dem Reading presence als auch dem Reading state. Ich habe es eben mal kurz mit dem Reading presence ausprobiert, da hat es leider nicht geklappt. Habe jetzt mal auf state umgestellt. Mal schauen.
Ach so, umstellen heißt das ich event-on-change-reading state jetzt stehen habe, hatte da vorher presence stehe.



Grüße
Leon
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 11 Januar 2017, 19:34:08
Wird hier auf beides getriggert? Sowohl dem Reading presence als auch dem Reading state. Ich habe es eben mal kurz mit dem Reading presence ausprobiert, da hat es leider nicht geklappt. Habe jetzt mal auf state umgestellt. Mal schauen.


Es wird zunächst auf das Vorhandensein von presence geprüft und ansonsten auf state.


Ach so, umstellen heißt das ich event-on-change-reading state jetzt stehen habe, hatte da vorher presence stehe.


Beim angegebenen FHEM-Drittgerät nehme ich an, bei ROOMMATE macht es wenig Sinn ;-)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 11 Januar 2017, 19:43:21
Hallo Julian

event-on-change-reading beim presence Device meine ich. Auch bei state hatte ich kein Erfolg. Das Reading im presence Device wird korrekt geändert aber das rommate Device stellt sich nicht um.

Internals:
   CFGFN
   CHANGED
   DEF        AnniKraussStr,Eltern
   NAME       rr_Marko
   NR         16
   NTFY_ORDER 50-rr_Marko
   RESIDENTGROUPS AnniKraussStr,Eltern,
   STATE      home
   TYPE       ROOMMATE
   Helper:
     Dblog:
       Presence:
         Logdb:
           TIME       1484148504.74305
           VALUE      present
   Readings:
     2017-01-11 16:28:24   durTimerAbsence 00:00:00
     2017-01-11 16:28:24   durTimerAbsence_cr 0
     2017-01-11 19:38:25   durTimerPresence 03:10:01
     2017-01-11 19:38:25   durTimerPresence_cr 190
     2017-01-11 07:02:02   durTimerSleep   00:00:00
     2017-01-11 07:02:02   durTimerSleep_cr 0
     2017-01-11 16:28:24   lastArrival     2017-01-11 16:28:24
     2017-01-11 07:02:02   lastAwake       2017-01-11 07:02:02
     2017-01-11 13:26:32   lastDeparture   2017-01-11 13:26:32
     2017-01-11 16:28:24   lastDurAbsence  03:01:52
     2017-01-11 16:28:24   lastDurAbsence_cr 182
     2017-01-11 13:26:32   lastDurPresence 03:45:15
     2017-01-11 13:26:32   lastDurPresence_cr 225
     2017-01-11 07:02:02   lastDurSleep    08:22:13
     2017-01-11 07:02:02   lastDurSleep_cr 502
     2017-01-11 13:26:32   lastLocation    home
     2017-01-11 13:26:32   lastMood        calm
     2017-01-10 22:39:49   lastSleep       2017-01-10 22:39:49
     2017-01-11 16:28:24   lastState       absent
     2017-01-11 06:00:01   lastWakeup      07:00
     2017-01-11 06:00:01   lastWakeupDev   rr_Marko_wakeuptimer1
     2017-01-11 16:28:24   location        home
     2017-01-11 16:28:24   mood            calm
     2017-01-11 07:00:04   nextWakeup      07:00
     2017-01-11 07:00:04   nextWakeupDev   rr_Marko_wakeuptimer1
     2017-01-11 16:28:24   presence        present
     2016-04-21 07:34:58   pushDev         nexus5-marko
     2017-01-11 16:28:24   state           home
     2017-01-11 07:00:04   wakeup          0
     2016-05-03 17:09:02   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:home
   event-on-change-reading state,userState,presence,wayhome,location
   group      Marko
   icon       people_sensor
   room       AnniKraussStr
   rr_locations atwork,home,wayhome,underway
   rr_presenceDevices presenceMarko
   rr_realname group
   rr_states  home,gotosleep,asleep,awoken,absent,gone
   rr_wakeupDevice rr_Marko_wakeuptimer1
   sortby     0
   webCmd     state

Internals:
   ADDRESS    7C:2F:80:98:B8:3D
   CFGFN
   CHANGED
   DEF        lan-bluetooth TAG-MAC IP-ADRESSE:5333 10 60
   DeviceName 10.6.6.20:5333
   FD         24
   MODE       lan-bluetooth
   NAME       presenceMarko
   NOTIFYDEV  global
   NR         177
   NTFY_ORDER 50-presenceMarko
   PARTIAL
   STATE      present
   TIMEOUT_NORMAL 10
   TIMEOUT_PRESENT 60
   TYPE       PRESENCE
   Helper:
     Dblog:
       Presence:
         Logdb:
           TIME       1484136534.11303
           VALUE      absent
   Readings:
     2017-01-11 17:14:44   command_accepted yes
     2017-01-10 16:12:25   device_battery  ok
     2017-01-10 16:12:25   device_batteryLevel 26
     2017-01-11 19:38:44   device_name     Gigaset G-tag
     2016-06-11 22:57:12   lastStatusRequestState statusRequest_done
     2017-01-11 13:08:54   presence        absent
     2017-01-11 19:38:44   state           present
   Helper:
     CURRENT_TIMEOUT present
Attributes:
   absenceThreshold 36
   alias      G-tag
   event-on-change-reading presence,device_battery,device_batteryLevel
   group      Marko
   room       AnniKraussStr
   timestamp-on-change-reading presence
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ToKa am 11 Januar 2017, 20:47:41
Hallo zusammen,

ich kann das Verhalten bestätigen. Leider wird beim roommate device der presence Wert nicht aus dem presence Device übernommen. Mit verbose 5 ist roommate leider auch nicht sehr gesprächig und es wird auch im Eventmonitor nichts ausgegeben.

Gruß
Torsten
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: marvin78 am 11 Januar 2017, 20:52:24
Hier kein Problem. Das klappt einwandfrei. Habt ihr eventuell noch die ein oder anderen notify/DOIF Leiche, die den Status beeinflusst?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 11 Januar 2017, 20:52:40
Das trat in Verbindung mit der gleichzeitigen Nutzung von Wakeuptimer auf. Habe gerade einen fix eingecheckt.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ToKa am 11 Januar 2017, 22:09:28
Hallo zusammen,

habe gerade mal getestet, ob man das DateTimePickerWidget für den wakeuptimer verwenden kann. Es funktioniert prima mit der aktuellen svn Version des Widgets. Als Einstellungen habe ich im setlist des wakeuptimer folgende Einstellungen vorgenommen:

nextRun:datetime,theme:default,datepicker:false,format:H:i,step:5
Gruß Torsten
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 12 Januar 2017, 11:04:36
Das trat in Verbindung mit der gleichzeitigen Nutzung von Wakeuptimer auf. Habe gerade einen fix eingecheckt.

Update gemacht und getestet. Funktioniert. Das ist eine super Idee gewesen Julian. Danke. Geht aber richtig sauber nur mit presence/absentsThreshold daher war es auch der richtige Zeitpunkt, vor einem halben Jahr hätte es noch kein Sinn gemacht.

Danke
Leon
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 12 Januar 2017, 13:45:08
Geht aber richtig sauber nur mit presence/absentsThreshold daher war es auch der richtige Zeitpunkt, vor einem halben Jahr hätte es noch kein Sinn gemacht.


Ganze genau :-)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 12 Januar 2017, 15:13:58
@Cooltux: sry, dass ich so doof nachfrage, Aber: presence/absentsThreshold ??? habe ich da was nicht auf dem Schirm oder im letzten halben Jahr nicht mitbekommen?

Gruß Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: marvin78 am 12 Januar 2017, 15:15:31
Siehe commandref zu PRESENCE.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 12 Januar 2017, 15:17:26
jo .... man sollte auch bis zum Ende lesen ;D

Danke!
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: FunkOdyssey am 13 Januar 2017, 14:32:28
Ich habe noch einmal eine Frage:

Ich setze über ein DOIF das Roommate-Device manuell auf "gotosleep".
Nun dachte ich, dass durch das Einschalten des Handy (Presence-Device = present) das Roommate-Device auch wieder auf "present" gesetzt werden würde.
Leider ist dies nicht der Fall.

Ist das korrekt?

Sollte die Änderung im Presence-Device von "absent" zu "present" am frühen morgen das Roommate-Device nicht eigentlich wieder anpassen?
Oder muss ich das auch per DOIF nachkorrigieren?

Vielleicht hat ja jemand einen Tipp für mich. Danke.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 13 Januar 2017, 14:44:48
grundsätzlich wird davon ausgegangen, dass du wenn du gotosleep bist auch gleichzeitig present bist. Da du durch ausschalten des Handys nicht auf absent gesetzt wirst, gehe ich davon aus, dass wenn du im Status gotosleep /asleep /awoken bist dein Presence-Status nicht aktualisiert wird?! oder habe ich da was falsch verstanden?

Gruß Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: FunkOdyssey am 13 Januar 2017, 15:07:05
grundsätzlich wird davon ausgegangen, dass du wenn du gotosleep bist auch gleichzeitig present bist. Da du durch ausschalten des Handys nicht auf absent gesetzt wirst, gehe ich davon aus, dass wenn du im Status gotosleep /asleep /awoken bist dein Presence-Status nicht aktualisiert wird?! oder habe ich da was falsch verstanden?

Gruß Michael

Das Problem Nr.1 ist, dass das Presence-Device den "rrBewohner:presence" auf "absent" wie auch "rrBewohner:state" auf  "absent" setzt.
Und das obwohl ich daheim bin. Die Presence-Integration übernimmt ein wenig zu viele Einstellungen.

Die Reihenfolge:

1)
Bewohner daheim: state=home / presence=present

2)
Handy aus: state=absent / presence=absent (grundsätzlich auch okay)

3)
Dann folgt evtl. folgendes DOIF:

(
[rr_Bewohner:state] eq "absent" and
[rr_Bewohner:lastState] eq "home" and
[rr_Bewohner:lastState:sec] < 60 and
[23:00-09:00] and
[rolladen:level] < 15
)
(set rr_Bewohner state gotosleep)

4)

Am frühen morgen wir das Handy wieder eingeschaltet.
Das Presence-Device geht auf "present".
rrBewohner hat sich heute morgen jedoch nicht aktualisiert.

Ich habe nun einiges geändert und warte zu diesem Thema den morgigen Tag mal ab.



Am Rande:
Hat jemand einen Tipp, woran man zuverlässig erkennen kann, dass im Roommate-Device die Abwesenheit durch ein Presence-Device gesetzt wurde?
Wenn die Handys in der Nacht ausgeschaltet sind, werden die Roommates auf "absent" geschaltet. Dann setze ich unter Prüfung weitere Bedingungen (Licht aus, Jalousien runter, Türen zu) den "gotosleep"-Status. Jedoch könnte der Bewohner das Haus auch verlassen haben und über Geofancy auf "absent" gesetzt worden sein.
Ich suche also die Unterscheidung zwischen "absent" durch Presence oder "absent" durch Geofancy/manuell.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 13 Januar 2017, 15:24:24
Leider ist dies nicht der Fall.

Ist das korrekt?

Ja. Diese Vereinfachung ist nur für einfache Anwendungsfälle gedacht, um die generelle Anwesenheit zu steuern. Deshalb wird ein Wechsel zwischen absent/present bei einem PRESENCE Device nur abhängig vom presence-Reading in ROOMMATE/GUEST weitergegeben. Stimmen die beiden Zustände bereits überein, passiert gar nichts.

Spezialfälle wie "ich schalte mein Handy aus und eigentlich bin ich aber noch zu Hause, das muss man sich aber denken und kann das nicht von normaler Abwesenheit unterscheiden" lassen sich mit keiner generellen Logik definieren, die auf alle passen würde. Dafür bleibt ja wie gehabt die Freiheit das flexibel über Notify und DOIF so zu definieren, wie man es haben möchte.

grundsätzlich wird davon ausgegangen, dass du wenn du gotosleep bist auch gleichzeitig present bist.

Korrekt. Siehe auch das reading "presence" in einem ROOMMATE/GUEST Device.

Da du durch ausschalten des Handys nicht auf absent gesetzt wirst

Bei Verwendung des r*_presenceDevices Attributs würde ein ROOMMATE/GUEST Device definitiv auch immer auf absent wechseln. Das ist so gewollt.
Wer sein Handy nachts so ausschaltet, dass es nicht mehr als Anwesenheitsindikator dienen kann, braucht mindestens einen anderen parallel dazu (mehrere PRESENCE Devices lassen sich ja im Attribut gemeinsam koppeln) oder muss sich generell eine andere Methode überlegen die Anwesenheit zu steuern (Bluetooth Beacons am Schlüsselbund, manuelle Schalter, etc.). Eine Kopplung mit GEOFANCY brächte hier keine Besserung, weil GEOFANCY rein eventbasiert arbeitet. Man kann zwar beides gemeinsam einsetzen, es schalten aber beide unabhängig voneinander den Status (wer zuerst An- oder Abwesenheit erkennt, schaltet diese dann).

Das Problem Nr.1 ist, dass das Presence-Device den "rrBewohner:presence" auf "absent" wie auch "rrBewohner:state" auf  "absent" setzt.

Works as designed/intended.

Und das obwohl ich daheim bin. Die Presence-Integration übernimmt ein wenig zu viele Einstellungen.

Im Gegenteil, es wird nur ganz wenig übernommen. Ganz einfach gesprochen: Es wird nur der Status des einen presence-Readings in einem PRESENCE Device auf as Reading "presence" eines ROOMMATE/GUEST Devices übertragen. Anders ausgedrückt: Es wird das kommen und gehen übernommen, mehr nicht.

Ich glaube du verwendest die unterschiedlichen Status nicht so wie sie gedacht sind. In den Status "gotosleep" zu wechseln, indem man das Handy ausschaltet kann man zwar machen, ist aber doch IMHO höchst ungewöhnlich/eigensinnig (is dann eben halt Kacke  ;) ).
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: FunkOdyssey am 13 Januar 2017, 15:32:29
Vorab erst einmal vielen Dank für die ausführliche Erklärung.
Ich werden die Vereinfachung dann bei mir besser wieder deaktivieren und zurück zu einem DOIF gehen.
Darüber steuere ich dann vollständig die Verknüpfung zwischen PRESENCE und ROOMMATE.
Damit kann ich leben. Ich wollte nur wissen, ob ich nicht beides nutzen könnte.
Danke dennoch.

Ich glaube du verwendest die unterschiedlichen Status nicht so wie sie gedacht sind. In den Status "gotosleep" zu wechseln, indem man das Handy ausschaltet kann man zwar machen, ist aber doch IMHO höchst ungewöhnlich/eigensinnig (is dann eben halt Kacke  ;) ).

Okay, zugegeben. Erst einmal ist "gotosleep" vollkommen unsinnig, weil es eigentlich "asleep" sein sollte. Ich war halt zu faul, die anderen States über "r*_showAllStates" freizuschalten. :-)

Aber ansonsten verstehe ich deine Aussage nicht. Ist das nicht legitim, den Schlafensstatus über eigene Regeln zu setzen?
(Das DOIF überprüft in Wirklichkeit auch noch mehr Parameter).
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 13 Januar 2017, 15:37:35
Hat jemand einen Tipp, woran man zuverlässig erkennen kann, dass im Roommate-Device die Abwesenheit durch ein Presence-Device gesetzt wurde?

Derzeit nein, dafür wäre ein eigenes Reading erforderlich, bei dem ich aber irgendwie den Sinn und Zweck nicht ganz verstehen würde. Der Status wird ja 1-zu-1 ins ROOMMATE Device übernommen und der Sinn dahinter ist, dass du sämtliche Automationen dann nicht mehr von PRESENCE abhängig machst, sondern von ROOMMATE und RESIDENTS. Ansonsten erhältst du keinen Vorteil.

Wenn die Handys in der Nacht ausgeschaltet sind, werden die Roommates auf "absent" geschaltet. Dann setze ich unter Prüfung weitere Bedingungen (Licht aus, Jalousien runter, Türen zu) den "gotosleep"-Status.

Sowas macht man ja in der Regel eher abhängig von einem RESIDENTS Device und nicht einem einzelnen ROOMMATE. Dafür ist es da und es bietet auch Readings dafür, welches ROOMMATE Device zuletzt seinen Status geändert hat, um das z.B. in DOIF entsprechend mit auswerten zu können.

Ich suche also die Unterscheidung zwischen "absent" durch Presence oder "absent" durch Geofancy/manuell.

Hm, dafür ließe sich vielleicht ein zusätzliches Reading rechtfertigen. Ich baue das bei Gelegenheit mit ein und denke auch nochmal darüber nach, wie man ggf. sinnvoll beinflussen kann in welchen Status das ROOMMATE/GUEST Device bei present/absent eines PRESENCE Devices wechseln soll.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: FunkOdyssey am 13 Januar 2017, 15:47:23
Sowas macht man ja in der Regel eher abhängig von einem RESIDENTS Device und nicht einem einzelnen ROOMMATE. Dafür ist es da und es bietet auch Readings dafür, welches ROOMMATE Device zuletzt seinen Status geändert hat, um das z.B. in DOIF entsprechend mit auswerten zu können.

Hier muss ich noch einmal nachkorrigieren.
Jeder Bewohner hat sein eigenes Handy. Ich habe vielleicht den Plural oben benutzt, aber jedes ausgeschaltete Handy schaltet das dazugehörige ROOMMATE-Device. Schlussendlich landen die Ergebnisse natürlich in RESIDENTS.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 13 Januar 2017, 15:48:55
Okay, zugegeben. Erst einmal ist "gotosleep" vollkommen unsinnig, weil es eigentlich "asleep" sein sollte.

Nee, gar nicht. Es macht ja Sinn, wenn man sich auf den Weg ins Bett begibt und man entsprechend die Lichtstimmung anpassen will und TV aus, Schlummermusik im Bad einschalten etc.
Danach den Status auf "asleep" zu setzen ist dann auch richtig, z.B. über einen Schalter am Bett oder das ausschalten der Nachttischlampe (die man vorher bei "gotosleep" eingeschaltet hat  ;) ).

Ich war halt zu faul, die anderen States über "r*_showAllStates" freizuschalten. :-)

Man muss da nix "freischalten", um diesen oder andere Status zu nutzen. Es geht dabei rein um die visuelle Einblendung in FHEMWEB; den Status kann man jederzeit und immer so setzen, wie man das will. "Show" in der Bezeichnung des Attributes ist also durchaus wörtlich zu nehmen.

"asleep" ist per Default ausgeblendet, weil der Standardprozess eigentlich ist, dass zunächst "gotosleep" ausgewählt werden sollte. Dann wird auch "asleep" in der Liste aufgeführt bzw. alternativ der Status über die Nutzung dev devStateIcons entsprechend zum nächsten Status gewechselt. Wer das anders möchte, kann r*_showAllStates verwenden und jemand, der FHEMWEB gar nicht benutzt, sondern z.B. TabletUI, muss gar nichts tun.

Aber ansonsten verstehe ich deine Aussage nicht. Ist das nicht legitim, den Schlafensstatus über eigene Regeln zu setzen?
(Das DOIF überprüft in Wirklichkeit auch noch mehr Parameter).

Doch natürlich. Wie man von einem Status in den anderen geht ist ganz egal und das Modul interessiert sich auch nicht dafür. Man kann auch jeden Status so nutzen, wie man ihn möchte.
Die einzige Abhängigkeit besteht zum Reading "presence", welches durch den Wechsel zu bestimmten Status eben dann auf "absent" oder "present" wechselt.
Man muss also unterscheiden zwischen dem Anwesenheitsstatus (im Reading "presence") und dem Aktivitätsstatus (im Reading "state"). Außerdem muss man sich bewusst machen, dass man nur den Aktivitätsstatus selbst setzt (oder mit Hilfe von GEOFANCY/PRESENCE) und davon dann indirekt der Anwesenheitsstatus von abgeleitet wird.

Wenn man das einmal verinnerlicht hat, ist es eigentlich ganz einfach.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ujaudio am 24 Januar 2017, 21:57:36
In https://sourceforge.net/p/fhem/code/9978/ (https://sourceforge.net/p/fhem/code/9978/) steht:
Zitat
RESIDENTStk.pm: make Wakeuptimer compatible with Tablet UI settimer widget:

<div data-type="settimer"
data-device="rr_Firstname_wakeuptimer1"
data-get="nextRun"
data-set="nextRun"></div>

Damit kann ich den Wecker grundsätzlich auch stellen, aber die eingestellte Zeit wird nicht angezeigt, insbesondere kommt beim Aufruf die Anzeige "NaN"
Auch wenn ich die Zeit in FHEM setze wird sie auf dem Tablet nicht aktualisiert - sollte ja aber sein, weil am nächsten Tag bei mir die Standard-Weckzeit wieder verwendet wird, wenn ich am Tag zuvor mal extra früher aufstehen musste.
Ungünstig ist auch, dass man nicht erkennen kann, ob der Wecker an oder aus ist. Vielleicht muss ich es doch anders lösen, aber das Widget schien so praktisch...

Ich habe immer die zulässigen Zeiten ("alle 15 Minuten") mit dem Widget eingestellt, wie ich ihm die unzulässigen abgewöhne muss ich noch herausfinden.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 25 Januar 2017, 11:19:29
Damit kann ich den Wecker grundsätzlich auch stellen, aber die eingestellte Zeit wird nicht angezeigt, insbesondere kommt beim Aufruf die Anzeige "NaN"


Für TabletUI kann hier keine Unterstützung gegeben werden, dafür solltest du hier (https://forum.fhem.de/index.php/board,71.0.html) einen separaten Thread starten. Deine Schwierigkeit hat nichts mit dieser Modulfamilie zu tun.


Ich habe immer die zulässigen Zeiten ("alle 15 Minuten") mit dem Widget eingestellt, wie ich ihm die unzulässigen abgewöhne muss ich noch herausfinden.


Es kann jede beliebige Uhrzeit minutengenau gesetzt werden. Die 15min Abschnitte sind nur für die Anzeige in FHEMWEB so hinterlegt und können auch beliebig angepasst werden.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 25 Januar 2017, 11:40:24
In https://sourceforge.net/p/fhem/code/9978/ (https://sourceforge.net/p/fhem/code/9978/) steht:
Damit kann ich den Wecker grundsätzlich auch stellen, aber die eingestellte Zeit wird nicht angezeigt, insbesondere kommt beim Aufruf die Anzeige "NaN"
Auch wenn ich die Zeit in FHEM setze wird sie auf dem Tablet nicht aktualisiert - sollte ja aber sein, weil am nächsten Tag bei mir die Standard-Weckzeit wieder verwendet wird, wenn ich am Tag zuvor mal extra früher aufstehen musste.
Ungünstig ist auch, dass man nicht erkennen kann, ob der Wecker an oder aus ist. Vielleicht muss ich es doch anders lösen, aber das Widget schien so praktisch...

Ich habe immer die zulässigen Zeiten ("alle 15 Minuten") mit dem Widget eingestellt, wie ich ihm die unzulässigen abgewöhne muss ich noch herausfinden.

<div data-type="settimer" data-device="rr_Marko_wakeuptimer1"
                        data-get="nextRun"
                        data-set="nextRun"
                        data-off="OFF"
                        data-running-set-off="stop"
                        class="cell top-space">
</div>

Klappt ohne Probleme
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: DeeSPe am 27 Januar 2017, 16:54:10
Ich finde gerade irgendwie nicht was ich suche!

Gab es nicht mal eine Möglichkeit RESIDENTS auf Deutsch zu stellen, oder habe ich das nur geträumt?
Bin ich schon geistesgestört?  ??? ??? ???

Danke.

Gruß
Dan
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 27 Januar 2017, 17:33:06
Die Vorlage dazu gibt es in GEOFANCY als Setter.


Gruß

Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: DeeSPe am 27 Januar 2017, 18:30:01
Die Vorlage dazu gibt es in GEOFANCY als Setter.


Gruß

Julian

Ich benutze aber kein GEOFANCY und habe es auch noch nie benutzt!
Geht das noch woanders?

Danke.

Gruß
Dan
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 28 Januar 2017, 15:51:10
Jetzt sitze ich vorm Rechner.


Hier der Artikel, wie man generell Devices in Fhem übersetzen kann:
Frontend übersetzen mit widgetOverride und eventMap (am Beispiel ROOMMATE) (https://forum.fhem.de/index.php/topic,33613.0.html)


msgConfig hat einen Setter "createResidentsDev" (https://fhem.de/commandref.html#msgConfigset), der RESIDENTS Devices in Deutsch oder Englisch vorkonfiguriert.



Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: DeeSPe am 28 Januar 2017, 23:30:44
Jetzt sitze ich vorm Rechner.


Hier der Artikel, wie man generell Devices in Fhem übersetzen kann:
Frontend übersetzen mit widgetOverride und eventMap (am Beispiel ROOMMATE) (https://forum.fhem.de/index.php/topic,33613.0.html)


msgConfig hat einen Setter "createResidentsDev" (https://fhem.de/commandref.html#msgConfigset), der RESIDENTS Devices in Deutsch oder Englisch vorkonfiguriert.

Danke Julian für die nachgereichte Info.
Ich hatte es zwischenzeitlich selbst in msgConfig wieder gefunden.
Irgendwo hatte ich es gesehen, wusste nur nicht mehr wo und fing an an mir selbst zu zweifeln. ::)

Gruß
Dan
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: volschin am 03 Februar 2017, 12:52:13
Ich habe jetzt mal versucht, das Presence-Device direkt im ROOMMATE einzutragen und nicht mehr über Watchdog zu setzen. Leider funktioniert das nur unzuverlässig, da es immer wieder mal vorkommt, dass für kurze Zeit das Bluetooth-Signal abhanden kommt. Der Watchdog hat das kompensiert. Gibt es etwas ähnliches doch auch im ROOMMATE?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: DeeSPe am 03 Februar 2017, 12:53:50
absenceThreshold im PRESENCE Device?

Gruß
Dan
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: volschin am 03 Februar 2017, 13:12:39
Danke, man muss nur im richtigen Device schauen.  :-[
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: DeeSPe am 03 Februar 2017, 13:19:46
Danke, man muss nur im richtigen Device schauen.  :-[

Macht aber auch nur da Sinn wenn man mal genau drüber nachdenkt. ;)

Gruß
Dan
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 02 März 2017, 10:57:07
hallo Julian,

ich habe vorhin versucht mit das Attribut wakeupOffset in meinen WakeupTimern zu ändern. Das ist ja ein Slider
Wenn ich den gewünschten Wert eingestellt habe und auf attr klicke, dann wird anstatt des eingestellten Wertes der String WakeupOffset bei dem Attribut eingetragen.
Kann das sonst noch jemand bestätigen?

über die Kommandozeile habe ich es dann manuell eingetragen.

Bei mir läuft FHEM 5.8

Gruß Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 02 März 2017, 11:05:55
Das wäre ein genereller FHEM Bug.


Gruß

Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 05 März 2017, 14:27:38
Ich habe gerade ein kleines Update eingecheckt. Damit spielt die Reihenfolge keine Rolle mehr, in der RESIDENT/ROOMMATE/GUEST Devices definiert werden.
Es sollte dabei eigentlich keine Verhaltensänderung auftreten. Falls doch, bitte hier melden.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 05 März 2017, 19:43:57
Ich habe gleich noch einen weiteren Patch hinterher geschoben:


1. Das globale Attribut "language" wird jetzt berücksichtigt und neu angelegte Devices werden automatisch in deutscher Anzeigesprache vorkonfiguriert, wenn die Sprache entsprechend gesetzt ist
2. Mittels neuem Attribut r*_lang lässt sich die globale Spracheinstellung übersteuern und zwischen deutscher und englischer Anzeigesprache umschalten
3. Das Attribut "disable" wird unterstützt
4. Bei Verwendung der Attribute r*_autoGoneAfter oder r_noDuration wird der interne Timer jetzt gestoppt
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: justme1968 am 20 März 2017, 13:43:35
hallo loredo,

könntest du bitte für RESIDENTS die gleichen durTimer.* readings einbauen wie für ROOMMATE?

ich bin gerade dabei in der willkommens nachricht beim tür öffnen mit anzusagen ob schon jemand anders zuhause ist. je nach dem wie schnell sich jemand genähert hat kann es aber sein das er schon im wlan eingebaucht ist und selber auf present springt bevor er die tür auf macht. ein einfacher vergleich auf durTimerPresence  < 15 sekunden direkt auf das RESIDENTS  device wäre deutlich einfacher als von hand alle ROOMMATEs durch zu gehen oder irgendwie anders selber zu zählen.

danke
  andre
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 22 März 2017, 10:33:56
hi Loredo,

ich hab eine kleine Frage zu deinem DOIF. Und zwar verwendest du bei manchen msg-Befehlen ein ! hinter dem Empfänger msg push @rgr_Residents! -1 |Anwesenheit| Längere Abwesenheit aller Bewohner registriert. Erweitere Sicherheitsprotokolle wurden etabliert.Was bewirkt das ! ?

Gruß Michael

Ich habe gerade folgendes DOIF bei mir im Test, welches auch zwischen Bewohnern und Gästen unterscheidet:



## ROOMMATE arrives at home
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
$devType eq "ROOMMATE" and
($lastState eq "absent" or $lastState eq "gone")
)
(
(msg push @[rgr_Residents:lastActivityByDev] |Anwesenheit| [rgr_Residents:residentsTotalPresent] Bewohner zuhause: [rgr_Residents:residentsTotalPresentNames])
)


## ROOMMATE leaves home but residents are still present
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
[?rgr_Residents:presence] eq "present" and
$devType eq "ROOMMATE"
)
(
(msg push @[rgr_Residents:lastActivityByDev] |Anwesenheit| [rgr_Residents:lastActivityBy] abgemeldet. [rgr_Residents:residentsTotalPresent] Bewohner verblieben: [rgr_Residents:residentsTotalPresentNames])
)


## ROOMMATE is absent for longer period but others are still nearby
DOELSEIF
(
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "gone" and
[?rgr_Residents:state] ne "gone"
)
(
(msg push @[rgr_Residents:lastActivityByDev]! -2 |Anwesenheit| Längere Abwesenheit für [rgr_Residents:lastActivityBy] wurde vermerkt.)
)


## all residents are absent for longer period
DOELSEIF
(
[rgr_Residents:?state] and
[?rgr_Residents:state] eq "gone"
)
(
(msg push @rgr_Residents! -1 |Anwesenheit| Längere Abwesenheit aller Bewohner registriert. Erweitere Sicherheitsprotokolle wurden etabliert.)
)


## ROOMMATE leaves home and all residents are absent now
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
[?rgr_Residents:state] eq "absent" and
$devType eq "ROOMMATE"
)
(
(msg push @[rgr_Residents:lastActivityByDev] |Anwesenheit| [rgr_Residents:lastActivityBy] abgemeldet. Alle Bewohner sind abwesend, Sicherheitsprotokolle wurden etabliert.)
)


## GUEST control enabled
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
(([?rgr_Residents:lastActivity] ne "absent" and [?rgr_Residents:residentsHome] > 1) or ([?rgr_Residents:lastActivity] eq "absent" and [?rgr_Residents:residentsHome] == 0)) and
$devType eq "GUEST" and
$lastState eq "none"
)
(
(msg push @rgr_Residents -1 |Anwesenheit| Steuerung für [rgr_Residents:lastActivityBy] wurde aktiviert)
)


## GUEST control enabled while no resident present (EXCEPTION!)
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] ne "absent" and
[?rgr_Residents:residentsHome] == 1 and
$devType eq "GUEST" and
$lastState eq "none"
)
(
(msg push @rgr_Residents! 2 |Anwesenheit| Steuerung für [rgr_Residents:lastActivityBy] wurde aktiviert, obwohl kein Bewohner zuhause ist!)
)


## GUEST control was disabled
DOELSEIF
(
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "none" and
[?rgr_Residents:state] ne "gone"
)
(
(msg push @rgr_Residents -1 |Anwesenheit| Steuerung für [rgr_Residents:lastActivityBy] wurde deaktiviert)
)


## GUEST arrives at home while residents are present
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:residentsHome] > 1 and
$devType eq "GUEST" and
$lastState eq "absent"
)
(
(msg push @rgr_Residents -2 |Anwesenheit| [rgr_Residents:lastActivityBy] ist jetzt zuhause. Anwesende Bewohner: [rgr_Residents:residentsTotalPresentNames])
)


## GUEST arrives at home while he is the only one (EXCEPTION!)
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:residentsHome] == 1 and
$devType eq "GUEST" and
$lastState eq "absent"
)
(
(msg push @rgr_Residents! 2 |Anwesenheit| [rgr_Residents:lastActivityBy] ist jetzt alleine zuhause!)
)


## GUEST leaves home while others are still at home
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
[?rgr_Residents:presence] eq "present" and
$devType eq "GUEST"
)
(
(msg push @rgr_Residents -2 |Anwesenheit| [rgr_Residents:lastActivityBy] abgemeldet. [rgr_Residents:residentsTotalPresent] Bewohner verblieben: [rgr_Residents:residentsTotalPresentNames])
)


## GUEST leaves home after all residents
DOELSEIF
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
[?rgr_Residents:presence] eq "absent" and
$devType eq "GUEST"
)
(
(msg push @rgr_Residents! |Anwesenheit| [rgr_Residents:lastActivityBy] abgemeldet. Alle Bewohner sind jetzt abwesend, Sicherheitsprotokolle werden etabliert.)
)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: acw81 am 23 März 2017, 12:27:48
Ich habe an dem Attribut rr_presenceDevices meines ROOMATE eine PRESENCE Gerät verknüpft das über Events meines AccessPoints getriggert wird. Leider kommen die Änderungen vom PRESENCE Geräte nicht beim ROOMATE Geräte an. Liegt es daran das ich das PRESENCE über Events aktualisiere?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: mumpitzstuff am 24 März 2017, 15:46:07
Ich habe an dem Attribut rr_presenceDevices meines ROOMATE eine PRESENCE Gerät verknüpft das über Events meines AccessPoints getriggert wird. Leider kommen die Änderungen vom PRESENCE Geräte nicht beim ROOMATE Geräte an. Liegt es daran das ich das PRESENCE über Events aktualisiere?

Bei mir funktioniert das in die andere Richtung. Ich habe ROOMMATES definiert, die durch Sensoren einen bestimmten Status erhalten (Tags, Bewegung, Strom usw.) und den Gesamtstatus der sich daraus ergibt, finde ich im PRESENCE. Nur wenn alle ROOMMATES auf absent geschaltet sind, dann springt PRESENCE auf absent, ansonsten steht es auf present.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: KernSani am 24 März 2017, 16:04:54
Bei mir funktioniert das in die andere Richtung. Ich habe ROOMMATES definiert, die durch Sensoren einen bestimmten Status erhalten (Tags, Bewegung, Strom usw.) und den Gesamtstatus der sich daraus ergibt, finde ich im PRESENCE. Nur wenn alle ROOMMATES auf absent geschaltet sind, dann springt PRESENCE auf absent, ansonsten steht es auf present.
Verwechselst du PRESENCE und RESIDENTS?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: mumpitzstuff am 24 März 2017, 18:06:05
Ups sry du hast natürlich recht. Ich nehme alles zurück.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: KernSani am 24 März 2017, 18:28:18
Ich habe an dem Attribut rr_presenceDevices meines ROOMATE eine PRESENCE Gerät verknüpft das über Events meines AccessPoints getriggert wird. Leider kommen die Änderungen vom PRESENCE Geräte nicht beim ROOMATE Geräte an. Liegt es daran das ich das PRESENCE über Events aktualisiere?
Poste mal ein list des PRESENCE devices. Was genau meinst du mir "das PRESENCE über events aktualisieren"?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 25 März 2017, 10:56:44
könntest du bitte für RESIDENTS die gleichen durTimer.* readings einbauen wie für ROOMMATE?


Habe ich gerade eingebaut.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: justme1968 am 25 März 2017, 11:04:05
danke!
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 25 März 2017, 11:55:18
ich hab eine kleine Frage zu deinem DOIF. Und zwar verwendest du bei manchen msg-Befehlen ein ! hinter dem Empfänger msg push @rgr_Residents! -1 |Anwesenheit| Längere Abwesenheit aller Bewohner registriert. Erweitere Sicherheitsprotokolle wurden etabliert.Was bewirkt das ! ?


Das Ausrufezeichen bewirkt, dass trotz der niedrigen Priorität die Nachricht verschickt wird, obwohl die Bewohner abwesend sind. Normalerweise wird ansonsten die Nachricht bei Abwesenheit nicht zugestellt, wenn sie keine hohe Priorität hat.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 25 März 2017, 12:05:31
Ich habe an dem Attribut rr_presenceDevices meines ROOMATE eine PRESENCE Gerät verknüpft das über Events meines AccessPoints getriggert wird. Leider kommen die Änderungen vom PRESENCE Geräte nicht beim ROOMATE Geräte an. Liegt es daran das ich das PRESENCE über Events aktualisiere?


Sofern du kein falsch definiertes event-on-* Attribut verwendest, ist das vermutlich der Fall und eine Schutzvorrichtung vor Loops von FHEM selbst.

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 27 März 2017, 09:03:28
@Loredo: Danke für die Aufklärung!

Hattest du auch noch an den WakeUpTimern rumgeschraubt?

Ich habe einen Wecker für Mo-FR außer Donnerstags um 7 Uhr. Der Wecker am Donnerstag steht auf 6 Uhr. Heute morgen, bin ich allerdings auch um 6 Uhr gewecket worden. An der Config habe ich nichts geändert und diese lief auch die letzte Zeit wunderbar. Gestern Abend beim zuBett gehen habe ich auch die Ansage bekommen, dass mein Wecker auf 7 Uhr steht.

Gruß Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: acw81 am 27 März 2017, 20:11:31
Poste mal ein list des PRESENCE devices. Was genau meinst du mir "das PRESENCE über events aktualisieren"?


Internals:
   DEF        event ak_accesspoint:metal:.disconnected ak_accesspoint:metal:.connected
   EVENT_ABSENT ak_accesspoint:metal:.disconnected
   EVENT_PRESENT ak_accesspoint:metal:.connected
   MODE       event
   NAME       Andreas
   NOTIFYDEV  global,ak_accesspoint
   NR         101
   NTFY_ORDER 50-Andreas
   STATE      present
   TYPE       PRESENCE
   Readings:
     2017-03-27 20:07:45   presence        present
     2017-03-27 20:07:45   state           present
   Helper:
     CURRENT_STATE present
Attributes:
   devStateIcon Initialized:10px-kreis-rot absent:10px-kreis-rot present:10px-kreis-gruen
   group      Anwesenheit
   icon       it_smartphone
   room       Info
   stateFormat presence

Das PRESENCE Gerät wird über die Events connected/disconnected von meinem Smartphone am AP aktualisiert ...
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: bastelfeak am 27 März 2017, 22:04:25
Hallo liebe Fhemler,
ich bin gerade dabei das Resident-Modul zu entdecken und schaue, was ich davon wie gebrauchen kann.
Jetzt bin ich dabei es auf dem Floorplan abzulegen und frage mich gerade wie ich die Dropdown-Menüs des ROOMMATE und der Wakeuptimer auf den Floorplan bekomme? Die Icons erscheinen dort, aber nicht die Dropdowns.

Ich hoffe, ich bin hier richtig und freue mich auf eure Hilfe.

Viele Grüße
bastelf(r)eak

EDIT: Habe es gefunden, eine Option im floorplan richtet es.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 28 März 2017, 13:42:58

Internals:
   DEF        event ak_accesspoint:metal:.disconnected ak_accesspoint:metal:.connected
   EVENT_ABSENT ak_accesspoint:metal:.disconnected
   EVENT_PRESENT ak_accesspoint:metal:.connected
   MODE       event
   NAME       Andreas
   NOTIFYDEV  global,ak_accesspoint
   NR         101
   NTFY_ORDER 50-Andreas
   STATE      present
   TYPE       PRESENCE
   Readings:
     2017-03-27 20:07:45   presence        present
     2017-03-27 20:07:45   state           present
   Helper:
     CURRENT_STATE present
Attributes:
   devStateIcon Initialized:10px-kreis-rot absent:10px-kreis-rot present:10px-kreis-gruen
   group      Anwesenheit
   icon       it_smartphone
   room       Info
   stateFormat presence

Das PRESENCE Gerät wird über die Events connected/disconnected von meinem Smartphone am AP aktualisiert ...


Ich habe gerade ein Update eingecheckt, damit du dir das PRESENCE Device sparen und direkt den AccessPoint als Quelle für die Präsenz angeben kannst.
Dem Attribut r*_presenceDevices kann dafür jetzt optional einen Readingnamen übergeben bekommen. In deinem Fall also:


attr rr_Bewohner1 rr_presenceDevices ak_accesspoint:metal




Gruß
Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: acw81 am 28 März 2017, 15:30:55

Ich habe gerade ein Update eingecheckt, damit du dir das PRESENCE Device sparen und direkt den AccessPoint als Quelle für die Präsenz angeben kannst.
Dem Attribut r*_presenceDevices kann dafür jetzt optional einen Readingnamen übergeben bekommen. In deinem Fall also:


attr rr_Bewohner1 rr_presenceDevices ak_accesspoint:metal
@Loredo: Kann das funktionieren? Das reading ak_accesspoint:metal liefert doch nur connected und disconnected.

BTW, das ROOMMATE Gerät scheint nun zu funktionieren (zumindest mit meinem bisherigen PRESENCE Gerät). Ich glaube es lag daran, dass es noch keinen gültigen STATE gehabt hatte. Kann das sein?

Trotzdem vielen Dank für das neue Feature ...

Grüße Andreas
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 28 März 2017, 18:44:06
@Loredo: Kann das funktionieren? Das reading ak_accesspoint:metal liefert doch nur connected und disconnected.


Ja, die möglichen Values sind in ROOMMATE/GUEST bereits hinterlegt.


BTW, das ROOMMATE Gerät scheint nun zu funktionieren (zumindest mit meinem bisherigen PRESENCE Gerät). Ich glaube es lag daran, dass es noch keinen gültigen STATE gehabt hatte. Kann das sein?


Jaein, du meinst vermutlich das Reading state (STATE ist ein INTERNAL). Wenn also noch keine Veränderung deiner Anwesenheit ein Event ausgelöst hat, ändert sich auch das Reading nicht und solange kann auch keine andere Aktion erfolgen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Schlimbo am 29 März 2017, 07:11:43
Hallo Loredo,

seit ein paar Tagen funktioniert mein Wecker nicht mehr, wurde hier etwas geändert?
Im Log steht folgendes:
2017.03.29 05:20:00.040 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.03.29 05:20:00.041 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=0
2017.03.29 05:20:00.042 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found
2017.03.29 05:20:00.042 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=05:20 wakeupOffset=30
2017.03.29 05:20:00.043 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today
2017.03.29 05:20:00.043 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - until now, will be NEXT WAKE-UP RUN today based on weekday decision
2017.03.29 05:20:00.043 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 06 - won't be running today based on holiday decision (wakeupHolidays=andNoHoliday)
2017.03.29 05:20:00.044 4: RESIDENTStk rgr_Bewohner: 07 - next wake-up result: today at 05:50:00, wakeupDevice=rgr_Bewohner_wakeuptimer1
2017.03.29 05:20:00.072 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.03.29 05:20:00.072 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=0
2017.03.29 05:20:00.073 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found
2017.03.29 05:20:00.073 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=05:20 wakeupOffset=30
2017.03.29 05:20:00.074 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today
2017.03.29 05:20:00.074 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - until now, will be NEXT WAKE-UP RUN today based on weekday decision
2017.03.29 05:20:00.074 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 06 - won't be running today based on holiday decision (wakeupHolidays=andNoHoliday)
2017.03.29 05:20:00.075 4: RESIDENTStk rgr_Bewohner: 07 - next wake-up result: today at 05:50:00, wakeupDevice=rgr_Bewohner_wakeuptimer1

So wie ich das verstehe startet der Wecker aufgrund des "holiday" checks nicht:
2017.03.29 05:20:00.074 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 06 - won't be running today based on holiday decision (wakeupHolidays=andNoHoliday)Mein holiday Device hat aber für heute keinen Eintrag.

Gruß Schlimbo
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 29 März 2017, 08:29:12
kann ich bestätigen. Nachdem ich Montag zu früh geweckt wurde werde ich aktuell gar nicht mehr geweckt... :-[

Gruß Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: peter0255 am 29 März 2017, 09:41:52
Hallo Loredo,

bei mir das Gleiche. Am Montag ging es los, habe natürlich prompt verschlafen.

2017.03.29 05:45:00 4: RESIDENTStk rr_Peter_wakeuptimer1: lastRun = nextRun = 06:00
2017.03.29 05:45:00 4: RESIDENTStk rr_Peter_wakeuptimer1: weekday restriction in conjunction with andNoHoliday in use - not triggering wake-up program this time
2017.03.29 05:45:00 4: RESIDENTStk rr_Peter_wakeuptimer1: Wakeuptime recalculation triggered by at-device at_rr_Peter_wakeuptimer1
2017.03.29 05:45:00 4: RESIDENTStk rr_Peter_wakeuptimer1: wakeupGetBegin source: nextRun
2017.03.29 05:45:00 4: RESIDENTStk rr_Peter_wakeuptimer1: wakeupGetBegin result: 06:00 = 20700 s - 15 m = 05:45:00

Holiday Datei ist ok

Gruß
Peter
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 29 März 2017, 11:52:58
Muss ich mir genauer ansehen, auf den ersten Blick ist nichts zu finden.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: moskito am 29 März 2017, 15:22:40
Auch bei mir meldet das Modul die "weekday restriction" - sogar wenn ich die Attribute "wakeupDays" und "wakeupHolidays" entferne.

Gruß
Danny
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Chris76FiSi am 29 März 2017, 17:35:02
Hallo zusammen,

auch bei mir funktionieren seit Montag die WakeUp-Timer nicht mehr. Habe gestern extra zum Test einen neuen zusätzlichen WakeUp-Timer erstellt, da ich hier im Forum noch nichts zu diesem Fehler gefunden hatte. Egal was ich auch mache, ich erhalte immer wieder den Fehler "weekday restriction in use - not triggering wake-up program this time".
Anbei ein Auszug aus dem Log mit Verbose 5:

2017.03.28 19:39:00 4: dummy set rr_Christian_wakeuptimer3 trigger
2017.03.28 19:39:00 4: RESIDENTStk rr_Christian_wakeuptimer3: lastRun = nextRun = 19:40
2017.03.28 19:39:00 4: RESIDENTStk rr_Christian_wakeuptimer3: weekday restriction in use - not triggering wake-up program this time
2017.03.28 19:39:00 4: RESIDENTStk rr_Christian_wakeuptimer3: Wakeuptime recalculation triggered by at-device at_rr_Christian_wakeuptimer3
2017.03.28 19:39:00 4: RESIDENTStk rr_Christian_wakeuptimer3: wakeupGetBegin source: nextRun
2017.03.28 19:39:00 4: RESIDENTStk rr_Christian_wakeuptimer3: wakeupGetBegin result: 19:40 = 70740 s - 1 m = 19:39:00

Viele Grüße, Chris
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Chris76FiSi am 29 März 2017, 18:31:41
Hi zusammen,

habe mir im SVN mal die letzten Änderungen angesehen und bin auf folgende Syntax gestoßen:
!grep { $wday eq $_ } @days (kommt in Summe 3x vor).

Dies habe ich nun bei mir im Modul RESIDENTStk.pm ersetzt durch
!( grep { $wday eq $_ } @days ).

Und siehe da, es funktioniert :)

@Loredo: vielleicht solltest Du Dir die Zeilen 1052, 1062 und 1077 nochmal anschauen ;)

Viele Grüße, Chris
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 29 März 2017, 19:53:05
@Loredo: vielleicht solltest Du Dir die Zeilen 1052, 1062 und 1077 nochmal anschauen ;)

Danke, das sowas aber auch an Klammern scheitern muss...  ::)
Habe inzwischen eine etwas andere Variante implementiert.

Außerdem konnte ich bei dem Deep-Dive jetzt auch herausfinden, weshalb Sonntags die Vorhersage für den nächsten Wecker am Montag nicht stimmt. Das sollte jetzt auch behoben sein.
Außerdem behoben: Wenn der nächste Wecker nicht innerhalb der nächsten 24 Stunden gesetzt ist, werden die Readings nextWakeup und nextWakeupDev jetzt korrekt auf "OFF" respektive "" gesetzt.

Wer morgen wieder richtig geweckt werden will und nicht auf das morgige Update warten möchte:
https://svn.fhem.de/trac/export/13851/trunk/fhem/FHEM/RESIDENTStk.pm (https://svn.fhem.de/trac/export/13851/trunk/fhem/FHEM/RESIDENTStk.pm)



Gruß
Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 29 März 2017, 23:37:42
Danke fürs schnelle ändern.habe mir die aktuelle Version aus dem SVN gezogen. Gerade als ich schlafen gehen wollte habe ich die Weckzeit minus dem eingestellten Offset angesagt bekommen. Gewollt oder bug?
Ich werde morgen früh berichten, wann ich geweckt wurde.

Gruß Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 30 März 2017, 00:38:52
Da warst du etwas zu schnell, ist bereits gefixt. Habe den DL-Link aktualisiert.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 30 März 2017, 08:10:55
alles klar, danke ;-)

Gruß Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 01 April 2017, 11:45:45
Bei der Untersuchung des Wakeuptimers ist mir aufgefallen, dass "setstate watchdog defined" wohl nicht mehr dafür funktioniert, um die für die Weckfunktion verwendeten Watchdogs wieder zurückzusetzen. Das führt (bei mir) dazu, dass die Statuswechsel der ROOMMATE und GUEST Geräte nicht mehr richtig vom Weckprogramm gesteuert werden und das ROOMMATE Device z.B. im Status "awoken" hängen bleibt statt auf "home" zu wechseln.


Da es laut diesem Beitrag (https://forum.fhem.de/index.php/topic,65406.msg567704.html#msg567704) keine offizielle Funktion zu sein scheint und es inzwischen das Attribut autoReset gibt, habe ich die Templates entsprechend umgebaut. Bestehende Watchdogs, die für den Wakeuptimer bereits erstellt wurden, muss man allerdings einmalig händisch entsprechend anpassen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 01 April 2017, 12:07:47
Hallo Julian,

Welche genau sind das?

wd_rr_Steven_asleep
wd_rr_Steven_gotosleep
wd_rr_Steven_awoken

Und so???
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 01 April 2017, 12:13:37
Ja genau die.
Ich traue mich gerade nicht daran die ganzen Watchdog- und at-Devices alle in ein einzelnes DOIF zusammenzufassen. DamalsTM gab es noch kein DOIF  ;)
Das steht schon länger auf der Todo Liste, aber bedarf halt doch einiger Tests und vermutlich auch einiger Änderungen. Da die Tests für den Wecker aber so langwierig und aufwändig sind, ist das bisher noch so geblieben. Aber wenn sich jemand berufen fühlt hier ein DOIF zu basteln, was alles ersetzen und zusammenfassen kann... :-)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 01 April 2017, 12:21:01
Bitte bitte kein DOIF. Das tut nicht Not
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: peter0255 am 01 April 2017, 13:27:24
Hallo Loredo,

hab ich das richtig verstanden, ich muß bei
wd_rr_Peter_asleep
wd_rr_Peter_gotosleep
wd_rr_Peter_awoken
 das attr. autoRestart auf 1 setzen ?

Viele Grüße Peter
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 01 April 2017, 15:50:14
Genau. Optimalerweise änderst du die DEF noch so um, dass der setstate Befehl am Ende wegfällt.

Also aus

defmod wd_rr_Son_asleep watchdog rr_Son:asleep 00:00:04 rr_Son:(home|absent|gone|none|gotosleep|awoken) trigger Macro_rr_Son_asleep; setstate wd_rr_Son_asleep defined

wird

defmod wd_rr_Son_asleep watchdog rr_Son:asleep 00:00:04 rr_Son:(home|absent|gone|none|gotosleep|awoken) trigger Macro_rr_Son_asleep
attr wd_rr_Son_asleep autoRestart 1
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: peter0255 am 02 April 2017, 14:25:29
Hallo Loredo,

vielen Dank für Deine tolle Unterstützung.

Gruß
Peter
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 02 April 2017, 19:05:01
Man kann es sich übrigens auch einfacher machen und alle at_r.* und wd_r.* Devices löschen. Sie werden beim nächsten stellen des Timers dann neu angelegt.
Wer das vor hat, dem sei geraten auf das morgige Update zu warten. Dort sind Anpassungen für die Unterstützung der deutschen Sprache enthalten, sofern man seine Devices über das r*_lang Attribut eingedeutscht hat.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: JoeALLb am 02 April 2017, 20:37:29
Bitte bitte kein DOIF. Das tut nicht Not

Warum denn nicht? Ist so schön übersichtlich... und viel intuitiver für Anfänger, besonders bei komplexeren Dingen... ;-)
Du bist ja fähig, es Dir nach belieben umzuändern....
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 02 April 2017, 22:24:22
Vermutlich weil DOIF eine eierlegende Wollmilchsau ist und nur bei wirklich einfachen Dingen intuitiv erscheint.
Bei komplexeren Angelegenheiten wird es schnell so unübersichtlich, dass man sehr einfach graue Haare kriegen kann, nur weil eine der vielen Optionen an der falschen Stelle steht oder ein einzelner Buchstabe falsch steht. Von der Performance ganz zu schweigen ;-)


Ich habe auch extrem viel auf DOIF umgestellt vor über einem Jahr, irgendwann haben Dinge nicht mehr funktioniert (Änderungen sind wohl teils nicht rückwärts kompatibel) und die habe ich bis heute noch nicht gefixt, weil die DOIFs ein dermaßen Wirrwahr sind und man zudem die Millionen von Threads gelesen haben muss um zu verstehen, was sich jetzt an der Notation in welchem Detailgrad wieder geändert hat. Es mag sein, dass es inzwischen eine stabilere Basis hat. Aber wenn man einmal Tage Arbeit reingesteckt hat und es dann nicht mehr geht und man wieder Tage bräuchte um den Fehler zu finden, ist man wohl ein gebranntes Kind.
Ich vermute Heiko hat ähnliche Erfahrungen und ist deshalb nicht so gut auf DOIF zu sprechen ;-)


Nichts desto trotz: Das DOIF für den Wecker sähe vermutlich eher einfach aus und würde im Grunde das at und den watchdog zusammenfassen. Man sparte sich also lediglich ein einzelnes Device, denn pro Wecker bräuchte man wahrscheinlich doch auch ein eigenes DOIF, wenn man es nicht wieder verkomplizieren wollen würde und mit einem einzigen DOIF alle Wecker erschlagen wollen würde. Das sind dann nämlich wieder so Dinge, bei denen DOIF aus der vergangenen Erfahrung heraus kein Vertrauen genießen würde.
Dennoch habe ich überlegt DOIF zusätzlich einzubauen, damit man zumindest die Wahl hat. Wie gesagt: Wer eins baut, kriegt zwar kein Eis, aber kann danach zwischen at+watchdog und DOIF wählen  8)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 09 April 2017, 12:43:15
Ich habe jetzt für den Wakeuptimer eingebaut, dass das forcierte Wecken nur denn stattfinden kann, wenn die eingestellte Weckzeit früher ist als die Standardweckzeit.
Bisher konnte man wakeupEnforce nur auf 2 setzen, um forciert zu wecken, falls generell von der Standartweckzeit abgewichen wurde. mit der neuen Option wakeupEnforce=3 wird dies weiter eingeschränkt, so dass man z.B. Sonntags nur noch forciert aus dem Bett geworfen wird, wenn die Weckzeit explizit früher eingestellt wurde als die Standardweckzeit. Sinnvoll, wenn man zuvor eine Party Nacht hatte und eigentlich gerne länger schlafen möchte als die Standardweckzeit. Vorher wurde man dann zum eigenen Bedauern sogar noch zum aufstehen gezwungen - das ist nun vorbei  :)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ComputerZOO am 12 April 2017, 12:23:53
Moin,
mir ist da gerade beim durchsehen des Log-Files etwas aufgefallen:
delete atTmp_.*_Macro_rr_XYZ_wakeuptimer1 : Please define atTmp_.*_Macro_rr_XYZ_wakeuptimer1 firstbei früheren Versionen des Moduls wurde in der Macro_rr_XYZ_wakeuptimer1 noch geprüft, ob das AT bereits definiert wurde:
for (my $i=1; $i <= 10; $i++) {
if (defined($defs{"atTmp_".$i."_".$NAME})) {
    fhem "delete atTmp_".$i."_".$NAME;
}
}
bei der aktuellen Version nicht:
fhem "delete atTmp_.*_".$NAME;Gibt es dafür irgendwelche Gründe? Ich habe es selbst wieder hinzugefügt und mir sind dadurch noch keine Fehler aufgefallen.

Des Weiteren ist mir aufgefallen, dass das rr_XYZ_wakeuptimer1_resetswitcher - Device nicht mehr automatisch angelegt wird.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 12 April 2017, 12:27:51
Bei der Untersuchung des Wakeuptimers ist mir aufgefallen, dass "setstate watchdog defined" wohl nicht mehr dafür funktioniert, um die für die Weckfunktion verwendeten Watchdogs wieder zurückzusetzen. Das führt (bei mir) dazu, dass die Statuswechsel der ROOMMATE und GUEST Geräte nicht mehr richtig vom Weckprogramm gesteuert werden und das ROOMMATE Device z.B. im Status "awoken" hängen bleibt statt auf "home" zu wechseln.


Da es laut diesem Beitrag (https://forum.fhem.de/index.php/topic,65406.msg567704.html#msg567704) keine offizielle Funktion zu sein scheint und es inzwischen das Attribut autoReset gibt, habe ich die Templates entsprechend umgebaut. Bestehende Watchdogs, die für den Wakeuptimer bereits erstellt wurden, muss man allerdings einmalig händisch entsprechend anpassen.

und folgende....
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ComputerZOO am 12 April 2017, 12:41:42
Hmm,
soll heissen, das ich mir den rr_XYZ_wakeuptimer1_resetswitcher inklusive des wakeupResetSwitcher-Attributs in dem rr_XYZ_wakeuptimer1 sparen kann?

Was hat das mit der Prüfung auf existierende ATs zu tun?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: heig am 12 April 2017, 18:31:41
Hallo,
ich hatte auch das Problem, dass der Wecker nach der Umstellung nicht mehr richtig funktioniert hat.
Allerdings ist es bei mir so, dass morgens das Reading "wakeup" in meinem Roommate-Modul erhalten bleibt und der Status nicht auf "home" geändert wird.
ich muss händisch morgens das System auf "home" setzen und ein deletereading rr_Henning wakeup ausführen.

Woran kann das liegen? Mir ist leider aktuell nicht wirklich klar, wo die zwei Aktionen oben eigentlich ausgeführt werden sollten. Der Rest vom Wecker klappt super ;)

Danke euch!
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 14 April 2017, 12:11:16
Gibt es dafür irgendwelche Gründe?

Ja: Das Kommando ist unabhängig der Anzahl der temporären at-Devices und übersichtlicher/kürzer.
Ich habe im Template gerade eine leichte Abänderung eingecheckt, die die Fehlermeldung unterdrückt, wenn die at-Devices bereits alle abgelaufen sind und nicht mehr existieren:

fhem "delete atTmp_.*_".$NAME.":FILTER=TYPE=at";
Des Weiteren ist mir aufgefallen, dass das rr_XYZ_wakeuptimer1_resetswitcher - Device nicht mehr automatisch angelegt wird.

Wird es generell seit jeher nur, wenn für das dummy Modul die Attr-Funktion überschrieben werden konnte. Wenn ein anderes Modul das auch macht, dann gibt es einen entsprechenden Hinweis im Log.
Man muss dann eben einfach das Dummy Device selbst anlegen und konfigurieren und auf die Annehmlichkeit verzichten, das ist alles.

soll heissen, das ich mir den rr_XYZ_wakeuptimer1_resetswitcher inklusive des wakeupResetSwitcher-Attributs in dem rr_XYZ_wakeuptimer1 sparen kann?

Diese Frage verstehe ich nicht.

ich hatte auch das Problem, dass der Wecker nach der Umstellung nicht mehr richtig funktioniert hat.
Allerdings ist es bei mir so, dass morgens das Reading "wakeup" in meinem Roommate-Modul erhalten bleibt

Bitte FHEM aktualisieren, da ist bereits seit einiger Zeit ein entsprechendes Update dabei.

und der Status nicht auf "home" geändert wird.
ich muss händisch morgens das System auf "home" setzen

Das hängt ganz davon ab, ob du enforced Wakeup aus der Beispiel Konfiguration übernommen hast und wenn ja, ob du die entsprechende Sektion "END WAKE-UP PROGRAM" auch im Macro "Macro_rr_Son_wakeuptimer1" beibehalten hast. Dort wird sonst normal von "asleep" auf "awoken" umgeschaltet. Man kann dann in diesem Status bleiben oder auch über das Macro "Macro_rr_Hening_awoken", welches auf "awoken" triggert, ebenfalls automatisch auf "home" wechseln. Dazu ist diese Beispielzeile dort enthalten:

## change user state to home after 60 seconds
fhem "sleep 60; set rr_Henning:FILTER=state!=home home";

Wenn du sie entfernt hast, ist die Funktion natürlich nicht mehr da.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Schlimbo am 14 April 2017, 21:45:43
Hallo Loredo,

ich ändere bei meinem Wecker öfter das Attribut wakeupDays und wakeupHolidays je nach dem wie ich den Wecker gerade verwenden möchte, dabei ist mir aufgefallen dass die Readings nextWakeup und nextWakeupDev bei dieser Art von Änderung nicht aktualisiert werden und somit falsche Werte anzeigen. Ist es möglich hier noch etwas einzubauen, damit die Readings auch bei Änderung der beiden Attribute aktualisiert werden?

Gruß Schlimbo
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 15 April 2017, 13:07:51
ich ändere bei meinem Wecker öfter das Attribut wakeupDays und wakeupHolidays je nach dem wie ich den Wecker gerade verwenden möchte, dabei ist mir aufgefallen dass die Readings nextWakeup und nextWakeupDev bei dieser Art von Änderung nicht aktualisiert werden und somit falsche Werte anzeigen. Ist es möglich hier noch etwas einzubauen, damit die Readings auch bei Änderung der beiden Attribute aktualisiert werden?


Über Attribute geht das leider nicht zuverlässig, da die Events dazu ggf. nicht zuverlässig abzufangen sind (gleicher Grund wie für den gerade erst beschriebenen Resetswitcher, der u.U. nicht automatisch angelegt wird).


Ich habe das ganze deshalb als Setter implementiert. Ist ohnehin schicker, weil das nicht als Änderungen an der Struktur von FHEM erkannt wird.
Die Setter werden nur zu neu angelegten Wakeuptimern automatisch hinzugefügt. Zu bestehenden Timern muss man manuell das setList Attribut entsprechend erweitern:


attr rr_Julian_wakeuptimer1 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 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 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,3


Ist eines der Readings wakeupDefaultTime, wakeupResetdays, wakeupDays, wakeupHolidays oder wakeupEnforced gesetzt, hat es Vorrang vor einem evtl. noch gesetzten Attribut.
Möchte man wieder die Attribute verwenden, muss man das Reading mittels deletereading löschen.


Der Patch, den ich gerade eingecheckt habe, ist recht umfangreich. Es ist leider immer schwer das ganze vorher trocken zu testen, deshalb will ich nicht ausschließen, dass es zu Seiteneffekten kommt und empfehle ggf. das Update erst in einigen Tagen vorzunehmen, wenn Erfahrungswerte vorliegen. Natürlich würde ich mich freuen, wenn einige das Update trotzdem wagen und dann berichten :-)




Viele Grüße
Julian

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Schlimbo am 15 April 2017, 13:31:18
Vielen Dank, werde ich gerne testen und dann berichtigen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Schlimbo am 16 April 2017, 11:01:12
Hallo Loredo,

ich habe die Attribute wakeupDays und wakeupHolidays gelöscht und stattdessen als Readings angelegt.
list rgr_Bewohner_wakeuptimer1:
Internals:
   NAME       rgr_Bewohner_wakeuptimer1
   NR         584
   STATE      09:55
   TYPE       dummy
   Readings:
     2017-04-13 04:48:00   lastRun         05:18
     2017-04-16 09:50:34   nextRun         09:55
     2017-04-13 05:18:01   running         0
     2017-04-16 10:22:08   state           09:55
     2017-04-15 18:22:19   wakeupDays      0,1,2,3,4,5,6
     2017-04-16 10:22:07   wakeupHolidays  andHoliday
Attributes:
   alexaName  wecker
   alexaRoom  wohnzimmer
   alias      Wake-up Timer 1
   comment    Auto-created by RESIDENTS module for use with RESIDENTS Toolkit
   devStateIcon OFF:general_aus@red:reset running:general_an@green:stop .*:general_an@orange:nextRun%20OFF
   genericDeviceType wecker
   group      Home State
   homebridgeMapping Weckzeit=nextRun,cmd=nextRun
   icon       time_timer
   room       Residents,alexa
   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 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 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,3
   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,3 wakeupWaitPeriod:slider,0,1,360
   verbose    5
   wakeupAtdevice at_rgr_Bewohner_wakeuptimer1
   wakeupMacro Macro_rgr_Bewohner_wakeuptimer1
   wakeupOffset 4
   wakeupUserdevice rgr_Bewohner
   wakeupWaitPeriod 0
   webCmd     nextRun


Der Wecker wird aber nicht ausgelöst.
Im Log steht folgendes:
2017.04.16 09:51:00.005 4: dummy set rgr_Bewohner_wakeuptimer1 trigger
2017.04.16 09:51:00.029 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: lastRun = nextRun = 09:55
2017.04.16 09:51:00.030 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: weekday restriction in conjunction with andHoliday in use - not triggering wake-up program this time
2017.04.16 09:51:00.031 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 09:51:00.032 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 09:51:00.033 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 09:51:00.033 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=09:51 wakeupOffset=4 nextRunSec=35460 nextRunSecTarget=35700
2017.04.16 09:51:00.034 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today - weekdayToday=0
2017.04.16 09:51:00.034 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run today due to holiday based on combined weekday and holiday decision
2017.04.16 09:51:00.039 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 09:51:00.040 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 09:51:00.040 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 09:51:00.041 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=09:51 wakeupOffset=4 nextRunSec=35460 nextRunSecTarget=35700
2017.04.16 09:51:00.041 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today - weekdayToday=0
2017.04.16 09:51:00.041 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run today due to holiday based on combined weekday and holiday decision
2017.04.16 09:51:00.058 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: Wakeuptime recalculation triggered by at-device at_rgr_Bewohner_wakeuptimer1
2017.04.16 09:51:00.059 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: wakeupGetBegin source: nextRun
2017.04.16 09:51:00.059 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: wakeupGetBegin result: 09:55 = 35460 s - 4 m = 09:51:00

Und noch eine Bitte:
Könntest du das wakeupOffset auch noch als Setter umsetzten?
Da ich möchte, dass der Wecker immer funktioniert, auch wenn ich nur ein 15 Minuten Powernap mache, berechne ich mir die wakeupOffset Zeit bei jedem Wecker stellen neu, ist die Weckzeit > 30 min wird sie auf 30min gesetzt, bei Weckzeit < 30 min wird sie verringert.
Beispiel:
Um 14:00 Uhr stelle ich den Wecker auf 14:20 Uhr
Der standard Offset von 30 würde bewirken, dass der Wecker erst am nächsten Tag klingelt.
Deswegen rechne ich mir den maximal möglichen Offset aus, in diesem Beispiel 19 min.

Im Macro_wakeuptimer werden dann die "atTmp_" Timer auch im Bezug auf die offset Zeit berechnet:
my $wakeupOffset = AttrVal($EVTPART[4]."_wakeuptimer1", "wakeupOffset",30);
        my $offset1 =sprintf("%02.0f", (max(0,($wakeupOffset - 0))));
        my $offset2 =sprintf("%02.0f", (max(0,($wakeupOffset - 5))));

        fhem 'define atTmp_1_'.$NAME.' at +00:'.$offset1.':00 set ....

Gruß Schlimbo


Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Schlimbo am 16 April 2017, 22:15:56
Hallo Loredo,
habe gerade noch etwas getestet.
Wenn das  Reading wakeupHolidays auf "andNoHoliday" steht wurde der Wecker getriggert, bei dem Test heute morgen stand das Reading auf "andHoliday" und da wurde er nicht getriggert, solange aber wakeupDays auf "0,1,2,3,4,5,6" steht sollte es doch mit beiden Varianten funktionieren, oder?

Beim ausführen des Weckers ist jetzt aber noch ein weiteres Probleme aufgetreten:
Das FHEM Webinterface war nicht mehr erreichbar, das Log ist voll mit Einträgen, die sich ständig wiederholen:
17.04.16 21:16:25.795 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:16:25.819 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: New wake-up time: 21:20
2017.04.16 21:16:25.823 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: Wakeuptime recalculation triggered by at-device at_rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:25.823 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: wakeupGetBegin source: nextRun
2017.04.16 21:16:25.824 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: wakeupGetBegin result: 21:20 = 76620 s - 3 m = 21:17:00
2017.04.16 21:16:25.827 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: Wakeuptime recalculation triggered by at-device at_rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:25.828 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: wakeupGetBegin source: nextRun
2017.04.16 21:16:25.828 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: wakeupGetBegin result: 21:20 = 76620 s - 3 m = 21:17:00
2017.04.16 21:16:25.859 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:25.860 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:16:25.861 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:16:25.861 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:16:25.862 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today - weekdayToday=0
2017.04.16 21:16:25.862 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run today due to holiday based on combined weekday and holiday decision
2017.04.16 21:16:25.913 5: RESIDENTS rgr_Bewohner: called function RESIDENTS_Set()
2017.04.16 21:16:25.921 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:16:25.926 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:25.927 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:16:25.928 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:16:25.929 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:16:25.929 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today - weekdayToday=0
2017.04.16 21:16:25.929 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run today due to holiday based on combined weekday and holiday decision
2017.04.16 21:16:25.933 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:25.934 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:16:25.935 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:16:25.935 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:16:25.935 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today - weekdayToday=0
2017.04.16 21:16:25.936 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run today due to holiday based on combined weekday and holiday decision
2017.04.16 21:16:25.940 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:25.940 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:16:25.941 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:16:25.942 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:16:25.942 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today - weekdayToday=0
2017.04.16 21:16:25.942 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run today due to holiday based on combined weekday and holiday decision
2017.04.16 21:16:26.516 5: RESIDENTS rgr_Bewohner: called function RESIDENTS_Set()
2017.04.16 21:16:29.371 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:16:29.376 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:29.377 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:16:29.378 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:16:29.379 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:16:29.379 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today - weekdayToday=0
2017.04.16 21:16:29.379 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - until now, will be NEXT WAKE-UP RUN today based on weekday decision
2017.04.16 21:16:29.380 4: RESIDENTStk rgr_Bewohner: 07 - next wake-up result: today at 21:20:00, wakeupDevice=rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:29.429 5: RESIDENTS rgr_Bewohner: called function RESIDENTS_Set()
2017.04.16 21:16:29.440 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:29.441 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:16:29.441 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:16:29.442 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:16:29.442 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for today - weekdayToday=0
2017.04.16 21:16:29.442 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - until now, will be NEXT WAKE-UP RUN today based on weekday decision
2017.04.16 21:16:29.443 4: RESIDENTStk rgr_Bewohner: 07 - next wake-up result: today at 21:20:00, wakeupDevice=rgr_Bewohner_wakeuptimer1
2017.04.16 21:16:32.123 5: RESIDENTS rgr_Bewohner: called function RESIDENTS_Set()
2017.04.16 21:16:39.809 5: RESIDENTS rgr_Bewohner: called function RESIDENTS_Set()
2017.04.16 21:17:00.016 4: dummy set rgr_Bewohner_wakeuptimer1 trigger
2017.04.16 21:17:00.045 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: lastRun = nextRun = 21:20
2017.04.16 21:17:00.047 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: trigger Macro_rgr_Bewohner_wakeuptimer1 (running=1)
2017.04.16 21:17:00.057 3: Macro_rgr_Bewohner_wakeuptimer1: Wake-up program start for rgr_Bewohner with target time 21:20. Current state: home
2017.04.16 21:17:00.057 3: Macro_rgr_Bewohner_wakeuptimer1: Wake-up program started for rgr_Bewohner with target time 21:20. Current state: home
2017.04.16 21:17:00.059 3: Macro_rgr_Bewohner_wakeuptimer1: wakeupOffset: 3, offset1: 03, offset2: 00, wakeupLight: off, wakeupHeat: on
2017.04.16 21:17:00.608 5: RESIDENTS rgr_Bewohner: called function RESIDENTS_Set()
2017.04.16 21:17:00.618 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: created at-device at_rgr_Bewohner_wakeuptimer1_stop to stop wake-up program in 3 minutes
2017.04.16 21:17:00.902 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:00.903 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:00.904 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:00.905 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:00.905 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:00.905 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:00.968 5: RESIDENTS rgr_Bewohner: called function RESIDENTS_Set()
2017.04.16 21:17:00.978 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:00.981 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:00.984 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:00.990 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:00.991 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:00.991 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:00.992 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:00.992 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:00.993 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:00.998 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:00.999 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.000 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.000 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.001 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.001 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.006 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.007 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.008 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.008 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.009 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.009 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.011 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.017 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.018 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.019 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.020 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.020 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.021 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.023 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.029 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.030 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.031 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.032 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.032 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.033 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.035 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.041 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.042 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.043 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.043 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.044 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.044 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.046 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.052 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.054 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.054 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.055 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.055 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.056 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.058 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.064 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.065 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.066 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.066 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.067 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.067 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.069 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.075 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.076 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.077 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.078 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.078 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.079 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.081 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.087 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.088 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.089 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.090 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.090 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.090 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.092 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.098 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.100 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.100 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.101 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.101 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.102 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.104 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.110 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.111 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.112 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.112 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.113 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.113 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.115 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.121 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.122 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.123 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.124 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.124 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.125 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.127 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.133 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.134 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.135 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.135 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.136 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.136 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.139 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.144 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.146 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.146 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.147 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.148 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.148 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.150 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.156 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.158 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.158 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.159 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.160 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.160 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.162 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.168 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.169 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.170 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.171 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.171 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.171 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.173 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.179 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.181 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.181 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.182 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.182 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.183 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.185 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.191 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.192 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.193 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.193 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.194 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.194 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.196 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.202 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.203 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.204 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.205 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.205 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.205 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.209 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.217 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.218 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.220 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.221 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.221 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.222 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.224 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.234 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.236 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.237 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.238 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.239 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.239 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.242 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.254 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.260 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.261 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.262 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.262 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.263 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.266 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.274 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.275 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.276 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.277 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.278 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.278 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.281 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.289 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.290 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.291 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.292 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.292 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.293 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 05 - no run tomorrow due to holiday based on combined weekday and holiday decision
2017.04.16 21:17:01.296 4: dummy set rgr_Bewohner_wakeuptimer1 nextRun 21:20
2017.04.16 21:17:01.303 4: RESIDENTStk rgr_Bewohner: 00 - checking for next wake-up candidate rgr_Bewohner_wakeuptimer1
2017.04.16 21:17:01.305 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 01 - Holidays to be considered - today=0 tomorrow=1
2017.04.16 21:17:01.305 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 02 - possible candidate found - weekdayToday=0 weekdayTomorrow=1
2017.04.16 21:17:01.306 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 03 - considering at-device value wakeupAtNTM=21:17 wakeupOffset=3 nextRunSec=76620 nextRunSecTarget=76800
2017.04.16 21:17:01.307 4: RESIDENTStk rgr_Bewohner_wakeuptimer1: 04 - this is a candidate for tomorrow or later - weekdayTomorrow=1
2017.04.16 21:17:01.307 4: RESIDENTStk rgr_Bewohn...
Erst nach einem Neustart von FHEM war das Webinterface wieder erreichbar.

Gruß
Schlimbo
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Phiolin am 17 April 2017, 07:58:24
Das gleiche Problem hier heute morgen auch. FHEM nicht erreichbar , Wecker hat nicht ausgelöst.
Logfile ist voll mit Einträgen und CPU auf 100%.

2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:05 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:06 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:06 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:06 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:06 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:06 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:06 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:06 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
2017.04.17 07:53:06 4: dummy set rr_Andreas_wakeuptimer2 nextRun 08:00
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ComputerZOO am 17 April 2017, 09:43:24
Moin  >:(
Bei mir ist der Wecker zusammen mit FHEM auch abgekackt!!
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 17 April 2017, 14:15:16
Moin  >:(

Siehe Warnung vor dem Update hier (https://forum.fhem.de/index.php/topic,19040.msg620900.html#msg620900).

Beim ausführen des Weckers ist jetzt aber noch ein weiteres Probleme aufgetreten:
Das FHEM Webinterface war nicht mehr erreichbar, das Log ist voll mit Einträgen, die sich ständig wiederholen:
...
Erst nach einem Neustart von FHEM war das Webinterface wieder erreichbar.
Das gleiche Problem hier heute morgen auch. FHEM nicht erreichbar , Wecker hat nicht ausgelöst.
Logfile ist voll mit Einträgen und CPU auf 100%.

Ich habe das jetzt zum Anlass genommen die ohnehin fällige Überarbeitung des Notification Systems vorzunehmen. Dafür habe ich gerade einen abermals recht großen Patch eingespielt, der auch den berichteten Loop korrigiert.

Der Wecker wird aber nicht ausgelöst.

Ich bin nicht sicher, woher dieser Fehler sich eingeschlichen hat. Ich habe auch die gesamte Und/Oder Logik für die Einschränkung auf Tage und Feiertage überarbeitet.

Den gesamten Patch habe ich so gut es eben geht trocken durchgetestet. Jedoch zunächst ohne Gewähr, bis hier keine Fehlermeldungen auftauchen.
Vielleicht mag ja auch jemand einmal trocken durchtesten, bevor er sich wieder am Morgen wundert.  ::)
Wer heute blind updated, muss damit rechnen, dass morgen etwas nicht funktionieren könnte!

Und noch eine Bitte:
Könntest du das wakeupOffset auch noch als Setter umsetzten?

Ist ebenfalls eingebaut. Ggf. erweitere ich die interne Logik noch um eine eigene Schlummer-Funktion, dass dein Vorhaben nicht im Macro platziert sein muss. Danke für die Inspiration.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Schlimbo am 17 April 2017, 16:28:24
Hallo Loredo,

erst mal danke für deine Mühe, bin gerade dabei die neue Version zu testen:

Für den neuen Setter wakeupOffset muss ich dann das setList Attribut wieder anpassen, oder?
(+ wakeupOffset:slider,0,1,120):
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 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  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,3 wakeupOffset:slider,0,1,120Bei einem neu erstellten wakeuptimer fehlt wakeupOffset auch noch im setList Attribut.

Was mir noch aufgefallen ist, bei einem neu erstellten wakeuptimer steht im Attribut userattr nur noch "wakeupUserdevice", hier musste doch auch noch "wakeupMacro wakeupAtdevice wakeupResetSwitcher" stehen, oder?

Bei der neuen Version funktionieren die Setter nicht mehr.
Bei Eingabe von
set rgr_Bewohner_wakeuptimer1 wakeupHolidays andNoHolidaySollte doch eigentlich das Reading wakeupHolidays angelegt werden, jedoch wird nur das Reading state auf "wakeupHolidays andNoHoliday" gesetzt.

Im UserDevice werden bei mir jetzt die Readings "nextWakeup" und "nextWakeupDev" nicht mehr angelegt.

Gruß Schlimbo

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 17 April 2017, 21:46:39
Danke dir!
Da fehlte noch eine Aktualisierung der NOTIFYDEV Definition nachdem ein Wecker neu angelegt wurde, habe ich gerade hinzugefügt.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 18 April 2017, 09:20:49
Guten Morgen,

Nachdem ich heute zuverlässig geweckt wurde, kann ich wohl sagen, dass das Gröbste überstanden zu sein scheint :-)

Die aktuelle Version sollte bei großen Installationen auch durch den Einsatz von NOTIFYDEV performanter laufen.

Happy updating...


Gruß

Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Schlimbo am 18 April 2017, 09:53:25
Guten Morgen Julian,
kann ich bestätigen, auch ich wurde heute wieder richtig geweckt :)

Die beiden Punkte sind aber immer noch vorhanden:
Was mir noch aufgefallen ist, bei einem neu erstellten wakeuptimer steht im Attribut userattr nur noch "wakeupUserdevice", hier musste doch auch noch "wakeupMacro wakeupAtdevice wakeupResetSwitcher" stehen, oder?

Bei der neuen Version funktionieren die Setter nicht mehr.
Bei Eingabe von
set rgr_Bewohner_wakeuptimer1 wakeupHolidays andNoHolidaySollte doch eigentlich das Reading wakeupHolidays angelegt werden, jedoch wird nur das Reading state auf "wakeupHolidays andNoHoliday" gesetzt.
Gruß Schlimbo
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: visionsurfer am 18 April 2017, 10:33:26
Hallo,

ich nutze das Residents Modul in Verbindung mit Geofency. Bisher war ich als einzige Bewohner angelegt. Funktioniert auch alles perfekt. Wenn ich weg bin und z.B. die Homezone verlasse, dann meldet Geofency das und FHEM schaltet auf Absent.

Nun hab ich meine Frau hinzugefügt und auch soweit alles eingerichtet. Die App auf Ihrem Handy meldet auch sauber, wenn sie zu Hause verlassen hat. In FHEM steht auch in den Readings unter "location", das Sie nun im Büro ist. Aber der Status bleibt weiterhin auf "zu Hause".

Muss ich noch irgendwas machen ? Muss noch irgendwo was eingerichtet werden, das der Status automatisch auf abwesend wechselt ?

Grüße,
Visionsurfer
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 18 April 2017, 12:22:21
Die beiden Punkte sind aber immer noch vorhanden:Gruß Schlimbo


Das kann ich bei mir nicht nachvollziehen, weder mit der Test noch Live Umgebung. Vielleicht hast du nicht alle Dateien aktualisiert?
Nach wie vor ist es wichtig zu betonen, dass die Events nicht ankommen, wenn man event-on-* Attribute verwendet und diese falsch gesetzt sind. Sie sollten für keines der involvierten Geräte gesetzt sein.


Muss ich noch irgendwas machen ? Muss noch irgendwo was eingerichtet werden, das der Status automatisch auf abwesend wechselt ?


Der automatische Wechsel passiert nur, wenn die Location "home" heißt. Andere Namen funktionieren nur, wenn sie im Attribut rr_locationHome angegeben sind.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Schlimbo am 18 April 2017, 13:54:20
Okay, hab jetzt den Wecker noch mal komplett gelöscht und über create wakeuptimer neu angelegt.
Jetzt funktioniert es auch bei mir wie es soll. :)
Danke
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: visionsurfer am 18 April 2017, 14:15:59
@Loredo

Hmmm. Ok. Ich hatte mich schon gewundert. Als ich damals das Modul installiert habe, war bei mir alles auf englisch. Also home, absent, gosleep usw.

Als ich nun meine Frau hinzugefügt habe, war bei der alles auf deutsch. Dort steht jetzt "zu Hause".

Also trage ich bei ihr im attr. "rr_locationHome" dann einfach den Wert "zu Hause" ein ? Dann geht es automatisch ?

Grüße,
Visionsurfer
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 18 April 2017, 14:32:36
Hmmm. Ok. Ich hatte mich schon gewundert. Als ich damals das Modul installiert habe, war bei mir alles auf englisch. Also home, absent, gosleep usw.

Als ich nun meine Frau hinzugefügt habe, war bei der alles auf deutsch. Dort steht jetzt "zu Hause".


Das liegt daran, dass du als globales Attribut wohl language=DE gesetzt hast. Es werde dann entsprechende Attribute gesetzt, um die Anzeige von RESIDENTS/ROOMMATE/GUEST für diese Sprache vorzubelegen. Es ist aber nur die FHEMWEB Anzeige davon betroffen, intern wird weiterhin mit home, absent etc gearbeitet (siehst du auch an den Readings). Über das Attribut r*_lang an den Bewohner-Devices kann das übersteuert werden und die Vorbelegung wird entsprechend umgeändert.


Also trage ich bei ihr im attr. "rr_locationHome" dann einfach den Wert "zu Hause" ein ? Dann geht es automatisch ?


Nein. Entscheidend ist, was du in der Geofency.app als Namen für die Lokation angegeben hast. Der Name dort darf kein Leerzeichen beinhalten und sollte "home" lauten. Nur wenn der Name davon abweicht musst du das in rr_locationHome entsprechend setzen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: visionsurfer am 18 April 2017, 15:01:06
Hi,

ah ok. Jetzt hab ich es verstanden. Ja ich hab in der App auch "zu Hause" eingetragen. Bei mir in meiner App steht noch home. Daher funktioniert es auch sehr gut.

Dann ändere ich das bei meiner Frau und dann sollte es ja funktionieren.

Grüße,
Visionsurfer
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Per am 18 April 2017, 15:48:38
fhem "delete atTmp_.*_".$NAME.":FILTER=TYPE=at";
Das ist ja mal genial! Muss ich glatt mal verinnerlichen...
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: acw81 am 18 April 2017, 17:38:01
Hallo Julian,

folgendes scheint nicht mehr zu funktionieren:

Zitat
Ich habe gerade ein Update eingecheckt, damit du dir das PRESENCE Device sparen und direkt den AccessPoint als Quelle für die Präsenz angeben kannst.
Dem Attribut r*_presenceDevices kann dafür jetzt optional einen Readingnamen übergeben bekommen. In deinem Fall also:


attr rr_Bewohner1 rr_presenceDevices ak_accesspoint:metal

Ich bekomme das nur folgendes zurückgeliefert:

Value for rr_presenceDevices has invalid format
Mir ist das aufgefallen, da das Attribut komplett gefehlt hatte. Ist das bekannt?

Grüße
Andreas
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 18 April 2017, 18:44:56
Mir ist das aufgefallen, da das Attribut komplett gefehlt hatte. Ist das bekannt?


Danke, hatte ich nicht berücksichtigt und ist nun gefixt.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Schlimbo am 18 April 2017, 20:05:36
Okay, hab jetzt den Wecker noch mal komplett gelöscht und über create wakeuptimer neu angelegt.
Jetzt funktioniert es auch bei mir wie es soll. :)
Danke
Mist, zu früh gefreut. Das Phänomen ist wieder da.
Bei der neuen Version funktionieren die Setter nicht mehr.
Bei Eingabe von
set rgr_Bewohner_wakeuptimer1 wakeupHolidays andNoHolidaySollte doch eigentlich das Reading wakeupHolidays angelegt werden, jedoch wird nur das Reading state auf "wakeupHolidays andNoHoliday" gesetzt.

Der dummy "rgr_Bewohner_wakeuptimer1" verhält sich bei mir wie ein "normaler" Dummy.
Wenn ich set rgr_Bewohner_wakeuptimer1 nextRun 07:00 eingebe ändert sich nur "state".
Konnte leider noch nicht herausfinden durch was dieses Phänomen ausgelöst wird.
Wie ist der Dummy mit dem Wecker verknüpft?

List von rgr_Bewohner_wakeuptimer1:
Internals:
   NAME       rgr_Bewohner_wakeuptimer1
   NR         619
   STATE      nextRun 07:30
   TYPE       dummy
   Readings:
     2017-04-18 18:15:44   state           nextRun 07:30
Attributes:
   alexaName  wecker
   alexaRoom  wohnzimmer
   alias      Wake-up Timer 1
   comment    Auto-created by RESIDENTS module for use with RESIDENTS Toolkit
   devStateIcon OFF:general_aus@red:reset running:general_an@green:stop .*:general_an@orange:nextRun%20OFF
   genericDeviceType wecker
   group      Home State
   homebridgeMapping Weckzeit=nextRun,cmd=nextRun
   icon       time_timer
   room       Residents,alexa
   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 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  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,3
   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,3 wakeupWaitPeriod:slider,0,1,360
   wakeupAtdevice at_rgr_Bewohner_wakeuptimer1
   wakeupMacro Macro_rgr_Bewohner_wakeuptimer1
   wakeupUserdevice rgr_Bewohner
   wakeupWaitPeriod 0
   webCmd     nextRun


Am RESIDENTS Device rgr_Bewohner ist das Attribut
attr rgr_Bewohner rgr_wakeupDevice rgr_Bewohner_wakeuptimer1gesetzt.

Gibt es eine Möglichkeit die Verbindung vom Dummy zum Wecker zu erneuern ohne alles zu löschen und neu anzulegen?

Beim Versuch den Wecker komplett zu Löschen und neu anzulegen bekomme ich beim Löschversuch des Attribut rgr_wakeupDevice die Meldung:
Value for rgr_wakeupDevice has invalid format
Gibt es auch eine einfache Möglichkeit einen kompletten Wecker zu löschen, inklusive aller automatisch angelegten Devices?:
Macro_rgr_Bewohner_asleep
Macro_rgr_Bewohner_awoken
Macro_rgr_Bewohner_gotosleep
Macro_rgr_Bewohner_wakeuptimer1
wd_rgr_Bewohner_asleep
wd_rgr_Bewohner_awoken
wd_rgr_Bewohner_gotosleep,
at_rgr_Bewohner_wakeuptimer1
Schön wäre ein Befehl ähnlich dem removeRoommate Befehl --> removeWakeuptimer
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Schlimbo am 18 April 2017, 20:25:50
Bin etwas weiter gekommen:

habe einen zweiten wekeuptimer über create angelegt.
Und jetzt funktioniert der erste auch wieder.

Seltsam sieht aber jetzt das NOTIFYDEV von rgr_Bewohner aus:
   NOTIFYDEV  rr_Hans,rr_Sina,,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2,rgr_Bewohner_wakeuptimer1,rgr_Bewohner_wakeuptimer2
Als ich nur einen wakeuptimer hatte sah es so aus:
   NOTIFYDEV  rr_Hans,rr_Sina
Nach einem Neustart von FHEM gehen dann bei beiden Weckern die Setter nicht mehr und das NOTIFYDEV von rgr_Bewohner sieht wieder so aus:
   NOTIFYDEV  rr_Hans,rr_Sina(save config habe ich vor dem Neustart natürlich ausgeführt)

Edit:
noch zur Info: Da ich möchte, dass der Wecker klingelt, sobald irgendjemand Anwesend ist läuft mein wakeuptimer auf dem RESIDENTS Device und nicht auf ROOMMATE, dies sollte aber doch keinen unterschied machen, oder?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 18 April 2017, 21:30:33
Du bist der erste, der den Wecker mit einem RESIDENTS Device statt ROOMMATE verwendet. Kannst du mal damit testen?


noch zur Info: Da ich möchte, dass der Wecker klingelt, sobald irgendjemand Anwesend ist läuft mein wakeuptimer auf dem RESIDENTS Device und nicht auf ROOMMATE, dies sollte aber doch keinen unterschied machen, oder?


Doch, selbstverständlich.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Schlimbo am 18 April 2017, 22:50:17
Okay, gerade mit ROOMMATE getestet, hier funktionieren die Setter auch nach Neustart.

Habe den Wecker aber seit langer Zeit ohne Probleme auf RESIDENTS laufen, da es für mich keinen Sinn macht für ein gemeinsames Schlafzimmer zwei unterschiedliche Wecker anzulegen. Wenn im Schlafzimmer meine "aufwachsen"-Szene gestartet wird (Licht,Radio,Charlousie...) werden zwangsläufig sowieso beide geweckt ;D. Deswegen erschien mir hier das RESIDENTS Device geeigneter.
Könnte bis jetzt auch nirgends lesen dass es hierfür nicht vorgesehen ist, aus welchem Grunde sollte es sonst am RESIDENTS Device den "create wakeuptimer" Befehl geben?

Gruß Schlimbo


Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 18 April 2017, 23:13:44
Wie du merkst ist es halt der Vollständigkeit halber drin, erfuhr aber keiner besonderen Beachtung bei der Pflege. Von daher wird ein Fix etwas dauern.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Schlimbo am 18 April 2017, 23:40:43
Alles klar, dann warte ich.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Schlimbo am 19 April 2017, 08:01:55
Gutem Morgen,
nach dem ich mit meinem neuen Wecker (ROOMMATE-Wecker ;))  mal wieder in die wakeupWaitPeriod Falle getappt bin  :-\
2017.04.19 05:00:00.041 3: RESIDENTStk rr_Simon_wakeuptimer1: won't trigger wake-up program due to non-expired wakeupWaitPeriod threshold since lastAwake (expLastAwake=1492577457 > nowRunSec=1492572600)
Ist mir beim setzen von wakeupWaitPeriod ein weiters Problem aufgefallen:
Beim ersten erstellen des Attributs wakeupWaitPeriod wird das Attribut richtig gesetzt.
Beim anschließenden Änderungsversuch über den slider wird es immer auf den Wert "wakeupWaitPeriod" gesetzt.
Erst durch löschen und neu setzten kann der Werte geändert werden.
Manuelles setzen über
attr rr_Simon_wakeuptimer1 wakeupWaitPeriod 0Funktioniert.

Das gleich ist auch bei dem Attribut wakeupOffset, wenn es über den slider verändert wird.

Gruß Schlimbo

Edit: Da dieses Verhalten auch mit "normalen" Dummys auftritt, ist das denke ich ein globales Problem und hat erst mal nichts mit ROOMMATE zu tun.
Hat das sonst noch jemand beobachtet?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 19 April 2017, 11:46:54
Ja das Verhalten habe ich auch und hatte ich auch schon mal in diesem Thread erwähnt...

scheint aber ein globales Problemen zu sein.

Gruß Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 19 April 2017, 19:56:56
Ist mir beim setzen von wakeupWaitPeriod ein weiters Problem aufgefallen:
Beim ersten erstellen des Attributs wakeupWaitPeriod wird das Attribut richtig gesetzt.
Beim anschließenden Änderungsversuch über den slider wird es immer auf den Wert "wakeupWaitPeriod" gesetzt.
Erst durch löschen und neu setzten kann der Werte geändert werden.


Das scheint ein Problem mit dem Widget selbst zu sein, nicht mit dem Modul. Sollte man ggf. einmal Rudi oder André sagen.





Nichtsdestotrotz habe ich gerade einen sehr umfangreichen Patch eingecheckt, der alle Module auf eine gemeinsame Codebasis hebt (in RESIDENTS/ROOMMATE/GUEST steht demnach nur noch die Commandref und die Initialize Funktion drin).
Auch das Notification System wurde weiter verbessert, so dass jetzt eigentlich alles immer zuverlässig (und deutlich schneller, zumindest auf dem Papier...) aktualisiert werden sollte.


Wie immer: Tester vor!  :)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Schlimbo am 19 April 2017, 21:43:43
Danke.
Erste Tests verliefen gut, mein RESIDENTS-Wecker funktioniert wieder :)

Das Slider Problem habe ich hier mal gemeldet:
https://forum.fhem.de/index.php/topic,70813.msg623077.html#msg623077 (https://forum.fhem.de/index.php/topic,70813.msg623077.html#msg623077)

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ComputerZOO am 19 April 2017, 22:15:21
Nichtsdestotrotz habe ich gerade einen sehr umfangreichen Patch eingecheckt, der alle Module auf eine gemeinsame Codebasis hebt (in RESIDENTS/ROOMMATE/GUEST steht demnach nur noch die Commandref und die Initialize Funktion drin).
Auch das Notification System wurde weiter verbessert, so dass jetzt eigentlich alles immer zuverlässig (und deutlich schneller, zumindest auf dem Papier...) aktualisiert werden sollte.

Moin,
wie ist denn bei einem Update eigentlich die beste Herangehensweise? Update durchführen (inkl. shutdown restart) und warten was passiert,
oder am besten vorher alle Wecker löschen und wieder neu zusammenschnurzeln?
Ich frage deshalb, weil bei mir die rr_XYZ_wakeuptimerX (Montag bis Sonntag je einen) immer sehr umfangreiche Änderungen enthalten
wie z.B. die Wecknachricht, die Lichtszene, den Radiosender, andere Zeitvorgaben etc., die dann im Macro_rr_XYZ_wakeuptimer eingelesen und ausgewertet werden.

Ich würde mir dann nen eigenes Makro erstellen, das dann nach dem Anlegen der Wecker diese attr und readings wieder einfügt.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 20 April 2017, 08:57:02
wie ist denn bei einem Update eigentlich die beste Herangehensweise? Update durchführen (inkl. shutdown restart)


Genau so. Bestehende Automationen bleiben einfach wie sie sind. Es hat sich ja auch an der eigentlichen Funktionsweise nichts geändert.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 20 April 2017, 10:26:56
hi,

folgendes hatte ich vorhin nach dem Update im Log:

Use of uninitialized value $definitiveNextToday in numeric ge (>=) at FHEM/RESIDENTStk.pm line 3272.
Use of uninitialized value $definitiveNextToday in numeric lt (<) at FHEM/RESIDENTStk.pm line 3275.
Use of uninitialized value $definitiveNextToday in numeric ge (>=) at FHEM/RESIDENTStk.pm line 3272.
Use of uninitialized value $definitiveNextToday in numeric lt (<) at FHEM/RESIDENTStk.pm line 3275.

Nix dramatisches, nur zur Info.

Gruß Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 20 April 2017, 20:59:06
Hallo Julian,

Ich habe gestern Abend ein Update gemacht. Seit dem schalten meine Roommates nicht mehr entsprechend des presence Devices. Events werden vom present Device erzeugt, aber dem Roommate scheint das nicht zu jucken. Hat vorher super funktioniert. Auch das heutige Update bringt keine Verbesserung.
Hast Du eine Idee?


Grüße

Internals:
   AUTOGONE   1492840392
   CFGFN
   CHANGED
   DEF        AnniKraussStr,Eltern
   DURATIONTIMER 1492714573.26375
   NAME       rr_Marko
   NOTIFYDEV  global,rr_Marko_wakeuptimer1,presenceMarko
   NR         16
   NTFY_ORDER 50-rr_Marko
   RESIDENTGROUPS AnniKraussStr,Eltern
   STATE      absent
   TYPE       ROOMMATE
   Helper:
     Dblog:
       Presence:
         Logdbcurrent:
           TIME       1492710793.29799
           VALUE      absent
   Readings:
     2017-04-20 20:55:13   durTimerAbsence 01:02:01
     2017-04-20 20:55:13   durTimerAbsence_cr 62
     2017-04-20 19:53:12   durTimerPresence 00:00:00
     2017-04-20 19:53:12   durTimerPresence_cr 0
     2017-04-20 05:02:01   durTimerSleep   00:00:00
     2017-04-20 05:02:01   durTimerSleep_cr 0
     2017-04-20 18:44:40   lastArrival     2017-04-20 18:44:40
     2017-04-20 05:02:01   lastAwake       2017-04-20 05:02:01
     2017-04-20 19:53:12   lastDeparture   2017-04-20 19:53:12
     2017-04-20 18:44:40   lastDurAbsence  11:36:46
     2017-04-20 18:44:40   lastDurAbsence_cr 697
     2017-04-20 19:53:12   lastDurPresence 01:08:32
     2017-04-20 19:53:12   lastDurPresence_cr 69
     2017-04-20 05:02:01   lastDurSleep    07:33:19
     2017-04-20 05:02:01   lastDurSleep_cr 453
     2017-04-20 19:53:12   lastLocation    home
     2017-04-20 19:53:12   lastMood        calm
     2017-04-19 21:28:42   lastSleep       2017-04-19 21:28:42
     2017-04-20 19:53:12   lastState       home
     2017-04-20 04:00:00   lastWakeup      05:00
     2017-04-20 04:00:00   lastWakeupDev   rr_Marko_wakeuptimer1
     2017-04-20 19:53:12   location        underway
     2017-04-20 19:53:12   mood            -
     2017-04-17 23:59:04   nextWakeup      05:00
     2017-04-17 23:59:04   nextWakeupDev   rr_Marko_wakeuptimer1
     2017-04-20 19:53:12   presence        absent
     2016-04-21 07:34:58   pushDev         nexus5-marko
     2017-04-20 19:53:12   state           absent
     2017-04-20 05:00:01   wakeup          0
     2017-04-20 18:44:40   wayhome         0
   Timer:
     Rr_marko_autogone:
       HASH       rr_Marko
       MODIFIER   AutoGone
       NAME       rr_Marko_AutoGone
     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:home
   event-on-change-reading state,userState,presence,wayhome,location
   group      Marko
   icon       people_sensor
   room       AnniKraussStr
   rr_locations atwork,home,wayhome,underway
   rr_presenceDevices presenceMarko
   rr_realname group
   rr_states  home,gotosleep,asleep,awoken,absent,gone
   rr_wakeupDevice rr_Marko_wakeuptimer1
   sortby     0
   webCmd     state

nternals:
   ADDRESS    7C:2F:80:98:B8:3D
   CFGFN
   CHANGED
   DEF        lan-bluetooth 7C:2F:80:98:B8:3D 10.6.6.20:5333 10 60
   DeviceName 10.6.6.20:5333
   FD         27
   MODE       lan-bluetooth
   NAME       presenceMarko
   NOTIFYDEV  global
   NR         177
   NTFY_ORDER 50-presenceMarko
   PARTIAL
   STATE      present
   TIMEOUT_NORMAL 10
   TIMEOUT_PRESENT 60
   TYPE       PRESENCE
   Helper:
     Dblog:
       Presence:
         Logdbcurrent:
           TIME       1492710860.21439
           VALUE      present
   Readings:
     2017-04-20 19:54:20   command_accepted yes
     2017-04-20 20:56:21   daemon          lepresenced V0.8
     2017-04-20 19:59:48   device_battery  ok
     2017-04-20 19:59:48   device_batteryLevel 85
     2017-04-20 20:56:21   device_name     Gigaset G-tag
     2016-06-11 22:57:12   lastStatusRequestState statusRequest_done
     2017-04-20 19:54:20   presence        present
     2017-04-20 20:56:21   rssi            -67
     2017-04-20 20:56:21   state           present
   Helper:
     CURRENT_STATE present
     CURRENT_TIMEOUT present
Attributes:
   absenceThreshold 24
   alias      G-tag
   comment    Batteriewechsel am 03.03.2017
   event-on-change-reading presence,device_battery,device_batteryLevel
   group      Marko
   room       AnniKraussStr
   stateFormat presence
   timestamp-on-change-reading presence
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: acw81 am 20 April 2017, 21:39:16
Hallo Julian,

Ich habe gestern Abend ein Update gemacht. Seit dem schalten meine Roommates nicht mehr entsprechend des presence Devices. Events werden vom present Device erzeugt, aber dem Roommate scheint das nicht zu jucken. Hat vorher super funktioniert. Auch das heutige Update bringt keine Verbesserung.
Hast Du eine Idee?


Grüße

Internals:
   AUTOGONE   1492840392
   CFGFN
   CHANGED
   DEF        AnniKraussStr,Eltern
   DURATIONTIMER 1492714573.26375
   NAME       rr_Marko
   NOTIFYDEV  global,rr_Marko_wakeuptimer1,presenceMarko
   NR         16
   NTFY_ORDER 50-rr_Marko
   RESIDENTGROUPS AnniKraussStr,Eltern
   STATE      absent
   TYPE       ROOMMATE
   Helper:
     Dblog:
       Presence:
         Logdbcurrent:
           TIME       1492710793.29799
           VALUE      absent
   Readings:
     2017-04-20 20:55:13   durTimerAbsence 01:02:01
     2017-04-20 20:55:13   durTimerAbsence_cr 62
     2017-04-20 19:53:12   durTimerPresence 00:00:00
     2017-04-20 19:53:12   durTimerPresence_cr 0
     2017-04-20 05:02:01   durTimerSleep   00:00:00
     2017-04-20 05:02:01   durTimerSleep_cr 0
     2017-04-20 18:44:40   lastArrival     2017-04-20 18:44:40
     2017-04-20 05:02:01   lastAwake       2017-04-20 05:02:01
     2017-04-20 19:53:12   lastDeparture   2017-04-20 19:53:12
     2017-04-20 18:44:40   lastDurAbsence  11:36:46
     2017-04-20 18:44:40   lastDurAbsence_cr 697
     2017-04-20 19:53:12   lastDurPresence 01:08:32
     2017-04-20 19:53:12   lastDurPresence_cr 69
     2017-04-20 05:02:01   lastDurSleep    07:33:19
     2017-04-20 05:02:01   lastDurSleep_cr 453
     2017-04-20 19:53:12   lastLocation    home
     2017-04-20 19:53:12   lastMood        calm
     2017-04-19 21:28:42   lastSleep       2017-04-19 21:28:42
     2017-04-20 19:53:12   lastState       home
     2017-04-20 04:00:00   lastWakeup      05:00
     2017-04-20 04:00:00   lastWakeupDev   rr_Marko_wakeuptimer1
     2017-04-20 19:53:12   location        underway
     2017-04-20 19:53:12   mood            -
     2017-04-17 23:59:04   nextWakeup      05:00
     2017-04-17 23:59:04   nextWakeupDev   rr_Marko_wakeuptimer1
     2017-04-20 19:53:12   presence        absent
     2016-04-21 07:34:58   pushDev         nexus5-marko
     2017-04-20 19:53:12   state           absent
     2017-04-20 05:00:01   wakeup          0
     2017-04-20 18:44:40   wayhome         0
   Timer:
     Rr_marko_autogone:
       HASH       rr_Marko
       MODIFIER   AutoGone
       NAME       rr_Marko_AutoGone
     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:home
   event-on-change-reading state,userState,presence,wayhome,location
   group      Marko
   icon       people_sensor
   room       AnniKraussStr
   rr_locations atwork,home,wayhome,underway
   rr_presenceDevices presenceMarko
   rr_realname group
   rr_states  home,gotosleep,asleep,awoken,absent,gone
   rr_wakeupDevice rr_Marko_wakeuptimer1
   sortby     0
   webCmd     state

nternals:
   ADDRESS    7C:2F:80:98:B8:3D
   CFGFN
   CHANGED
   DEF        lan-bluetooth 7C:2F:80:98:B8:3D 10.6.6.20:5333 10 60
   DeviceName 10.6.6.20:5333
   FD         27
   MODE       lan-bluetooth
   NAME       presenceMarko
   NOTIFYDEV  global
   NR         177
   NTFY_ORDER 50-presenceMarko
   PARTIAL
   STATE      present
   TIMEOUT_NORMAL 10
   TIMEOUT_PRESENT 60
   TYPE       PRESENCE
   Helper:
     Dblog:
       Presence:
         Logdbcurrent:
           TIME       1492710860.21439
           VALUE      present
   Readings:
     2017-04-20 19:54:20   command_accepted yes
     2017-04-20 20:56:21   daemon          lepresenced V0.8
     2017-04-20 19:59:48   device_battery  ok
     2017-04-20 19:59:48   device_batteryLevel 85
     2017-04-20 20:56:21   device_name     Gigaset G-tag
     2016-06-11 22:57:12   lastStatusRequestState statusRequest_done
     2017-04-20 19:54:20   presence        present
     2017-04-20 20:56:21   rssi            -67
     2017-04-20 20:56:21   state           present
   Helper:
     CURRENT_STATE present
     CURRENT_TIMEOUT present
Attributes:
   absenceThreshold 24
   alias      G-tag
   comment    Batteriewechsel am 03.03.2017
   event-on-change-reading presence,device_battery,device_batteryLevel
   group      Marko
   room       AnniKraussStr
   stateFormat presence
   timestamp-on-change-reading presence

Das kann ich leider auch nur bestätigen. Das Attribut rr_presenceDevices lässt sich nun zwar wieder mit Readings von meinem Unify AP verknüpfen, aber das Roommate Device bekommt davon nichts mit. Verknüpfe ich ein PRESENCE Device ändert dies leider auch nichts. Hatte bei mir vorher auch super funktioniert und ich habe damit sogar die Haustür auf- und zugeschlossen.

Grüße
Andreas
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 20 April 2017, 22:51:07
Hast Du eine Idee?


Fix eingecheckt.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 20 April 2017, 22:52:28
Supi. Haben vielen Dank. Werde ich dann gleich mal einspielen um morgen früh zu testen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 20 April 2017, 22:57:09
Habe gerade mal geschaut. Einzig und allein ein fehlendes s. Das ist hart  ;D

Guts Nächtle
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: acw81 am 21 April 2017, 08:48:44

Fix eingecheckt.

Thx Julian, läuft wieder  8)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 21 April 2017, 08:53:59
Jepp kann ich bestättigen. Heute Morgen wieder super geschalten.


Grüße
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: DeeSPe am 21 April 2017, 15:00:49
Hallo Julian,

hat sich in den letzten Updates von RESIDENTS der Initialisierungsprozess verändert?
Bis zum Update war immer sichergestellt dass nach global:INITIALIZED auch die ROOMMATE/GUEST im Hash von RESIDENTS verfügbar sind.
Das ist nun leider nicht mehr so.
Siehe: https://forum.fhem.de/index.php/topic,70882.msg623997.html#msg623997

Ich bin nun am Grübeln wie ich das vernünftig lösen kann... ???

Gruß
Dan
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 21 April 2017, 18:03:31
hat sich in den letzten Updates von RESIDENTS der Initialisierungsprozess verändert?

Wesentlich:
https://forum.fhem.de/index.php/topic,19040.msg621738.html#msg621738 (https://forum.fhem.de/index.php/topic,19040.msg621738.html#msg621738)
https://forum.fhem.de/index.php/topic,19040.msg623008.html#msg623008

Ich bin nun am Grübeln wie ich das vernünftig lösen kann... ???

NotifyOrderPrefix
https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Notify (https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Notify)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 21 April 2017, 18:55:12
Hi,

Ich hätte da auch nochmal ne Frage:

Wie füllst du das Reading lastActivityBy vom Resident?

Bei mir steht dort aktuell der Wert Anwesenheit,Michael drin.

Jetzt stellt sich bei mir die Frage ob ich da bei mir was verbogen habe oder ob das ein bug ist.

Gruß Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: DeeSPe am 21 April 2017, 18:56:02
Danke Julian für die Hinweise.

Mit
$hash->{NotifyOrderPrefix} = "51-";sind die ROOMMATE/GUEST Devices wieder da.

Muss mal schauen wie sich das evtl. noch auswirkt auf mein Modul.

Gruß
Dan
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 21 April 2017, 20:02:06
Wie füllst du das Reading lastActivityBy vom Resident?

Bei mir steht dort aktuell der Wert Anwesenheit,Michael drin.

Jetzt stellt sich bei mir die Frage ob ich da bei mir was verbogen habe oder ob das ein bug ist.

Das liegt daran, dass du bei dem dazugehörigen ROOMMATE oder GUEST Gerät das Attribut r*_realname nicht richtig gesetzt hast.
Dort wird angegeben aus welchem Attribut der echte Name geholt werden soll. Bei einem ROOMMATE Device ist das standardmäßig das group-Attribut, bei einem GUEST Device das alias-Attribut. Wenn r*_realname nicht gesetzt ist, gilt der Default Wert.


EDIT:
Ich habe das glaube ich mal vor längerer Zeit wie oben geändert, aber ich denke es macht Sinn das einheitlich auf "group" als Default zu setzen. Ich habe dafür gerade einen Patch eingecheckt.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Phiolin am 22 April 2017, 08:28:09
Mein Wecker hat heute morgen leider nicht ausgelöst.
Wie kann ich das am besten nachvollziehen/debuggen?
Code-Stand ist der vom gestrigen Update - heutiges Update ist noch nicht drin.
Sollte um 08:30 auslösen (nextRun 08:45 abzüglich 15 Minuten WakeUpOffset).

Internals:
   NAME       rr_Andreas_wakeuptimer2
   NR         158
   STATE      08:45
   TYPE       dummy
   Readings:
     2017-04-22 08:26:00   nextRun         08:45
     2017-04-22 08:26:00   state           08:45
Attributes:
   alias      Wake-up Timer 2
   comment    Auto-created by ROOMMATE module for use with RESIDENTS Toolkit
   devStateIcon OFF:general_aus@red:reset running:general_an@green:stop .*:general_an@orange:nextRun%20OFF
   group      Andreas
   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 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 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,3
   sortby     2
   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,3 wakeupWaitPeriod:slider,0,1,360
   wakeupAtdevice at_rr_Andreas_wakeuptimer2
   wakeupDays 0,6
   wakeupDefaultTime 08:15
   wakeupEnforced 0
   wakeupHolidays orHoliday
   wakeupMacro Macro_rr_Andreas_wakeuptimer1
   wakeupOffset 15
   wakeupResetdays 0,6
   wakeupUserdevice rr_Andreas
   webCmd     nextRun

Internals:
   COMMAND    set rr_Andreas_wakeuptimer2 trigger
   DEF        *{RESIDENTStk_wakeupGetBegin("rr_Andreas_wakeuptimer2","at_rr_Andreas_wakeuptimer2")} set rr_Andreas_wakeuptimer2 trigger
   NAME       at_rr_Andreas_wakeuptimer2
   NR         159
   NTM        08:30:00
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 08:30:00
   TIMESPEC   {RESIDENTStk_wakeupGetBegin("rr_Andreas_wakeuptimer2","at_rr_Andreas_wakeuptimer2")}
   TRIGGERTIME 1492842600
   TRIGGERTIME_FMT 2017-04-22 08:30:00
   TYPE       at
   Readings:
     2017-04-22 08:26:00   state           Next: 08:30:00
Attributes:
   comment    Auto-created by RESIDENTS Toolkit: trigger wake-up timer at specific time
   computeAfterInit 1
   room       Residents

Laut Eventlog löst das at device pünktlich den Trigger aus, aber das war es dann auch schon...

2017-04-22 08:30:00 at at_rr_Andreas_wakeuptimer2 Next: 08:00:00
2017-04-22 08:30:00 ROOMMATE rr_Andreas nextWakeup: 08:15
2017-04-22 08:30:00 dummy rr_Andreas_wakeuptimer2 trigger
2017-04-22 08:30:00 dummy rr_Andreas_wakeuptimer2 nextRun 08:15
2017-04-22 08:30:00 dummy rr_Andreas_wakeuptimer2 nextRun: 08:15
2017-04-22 08:30:00 dummy rr_Andreas_wakeuptimer2 08:15
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 22 April 2017, 10:44:48
Ah, ok. Ich habs auf alias stehen, er scheint das aber zu ignorieren und Group zu nehmen. Den Patch teste ich nachher mal


Gesendet mit Tapatalk
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 22 April 2017, 10:45:54
Du setzt verbose auf 5 und schickst dann den set-Befehl "set rr_Andreas_wakeuptimer1 trigger". Im Logfile steht dann, weshalb der Wecker nicht ausgelöst wird.


Gruß

Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 22 April 2017, 12:59:47
Hi gerade hab ich das Update gemacht und egal ob ich group oder alias auswähle. Es wird immer noch Group genommen für das Reading.

Gruß Michael


Gesendet von iPad mit Tapatalk Pro
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 22 April 2017, 13:28:11
Hi gerade hab ich das Update gemacht und egal ob ich group oder alias auswähle. Es wird immer noch Group genommen für das Reading.


Und von welchem Modul reden wir hier?
Titel: Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 22 April 2017, 13:30:55
Ich hab ein normales FHEM update gemacht da wurde ja auch Residents und ResidentStk aktualisiert

Das Attribut habe ich im Roommate auf alias gesetzt


Gruß Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Phiolin am 22 April 2017, 13:51:30
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.

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

    elsif (
        !$forceRun
        && !$days{$today}
        && (
            ( $wakeupHolidays eq "andHoliday" && !$holidayToday )
            || (   $wakeupHolidays eq "andNoHoliday"
                && $holidayToday )
            || ( $wakeupHolidays eq "orHoliday" && !$holidayToday )
            || (   $wakeupHolidays eq "orNoHoliday"
                && $holidayToday )
        )
      )
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 22 April 2017, 17:12:10
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 22 April 2017, 17:15:51
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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Phiolin am 23 April 2017, 08:02:32
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?🤔
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: choenig am 23 April 2017, 09:14:30
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:

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

# 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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 23 April 2017, 11:05:54
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:

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

# 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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Phiolin am 23 April 2017, 12:19:38

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. :)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag 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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: choenig am 23 April 2017, 15:23:50
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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 23 April 2017, 17:48:12
hi,

ich hab nach einem shutdown restart folgendes im Log stehen:

main::RESIDENTStk_findDummySlaves() called too early to check prototype at FHEM/RESIDENTStk.pm line 3568, <$fh> line 712.
Gruß Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 23 April 2017, 21:57:01
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 24 April 2017, 10:02:00
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:
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
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 24 April 2017, 16:58:47
Danke, ich hatte irgendwie überlesen, dass es dir um lastActivityBy geht und nicht um die Listen in residentsTotal*.
Damit ist das nun auch gefixt ;-)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: l2r am 24 April 2017, 17:01:13
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!
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: choenig am 24 April 2017, 22:29:17
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 :)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: choenig am 24 April 2017, 22:31:38
Ich habe alle Modulautoren per PM angeschrieben.

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

LG
Christian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ComputerZOO am 25 April 2017, 21:49:40
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 26 April 2017, 08:56:27
Mea culpa, ich hatte das GEOFANCY Modul nicht auf eine interne Änderung bei ROOMMATE/GUEST angepasst. Patch ist eingecheckt.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: cheanrod am 27 April 2017, 07:10:50
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

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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 27 April 2017, 09:45:44
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: cheanrod am 27 April 2017, 10:18:49

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

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

Viele Grüße
Sven
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: cheanrod am 27 April 2017, 20:18:32
Zitat
Danke, 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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: choenig am 01 Mai 2017, 09:22:34
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 ;-).
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Phiolin am 01 Mai 2017, 09:28:42
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: ComputerZOO am 01 Mai 2017, 10:05:50
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: CoolTux am 01 Mai 2017, 11:30:54
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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 01 Mai 2017, 21:50:31
Im Folgenden ist ein ungetesteter Patch (!) von mir, der meiner Meinung nach das Logik-Problem behen sollte.


Danke, ich habe den Patch so übernommen.


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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: oberlon am 01 Mai 2017, 21:51:35
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?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 01 Mai 2017, 21:53:26
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: oberlon am 01 Mai 2017, 23:03:06
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?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 01 Mai 2017, 23:08:51

Das ist schonmal nicht STATE ;-)

Das RESIDENTS Modul unterstützt seit einiger Zeit ebenfalls den Duration Timer.
Die Filterung in einem DOIF ist zu ungenau und reagiert auf sämtliche Reading Änderungen, nicht nur der Duration Readings, das solltest du einschränken. Alternativ kannst du den Duration Timer mit dem Attribut rgr_noDuration abschalten.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: oberlon am 01 Mai 2017, 23:31:53
Auf STATE bin ich nur gekommen weil DOIF ein Reading anlegt mit e_rgr_Bewohner_STATE.
Vorerst nutze ich jetzt ([rgr_Bewohner:residentsTotalPresent] != 0).
Das verhalten war dennoch mal anders.  ???
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 01 Mai 2017, 23:45:56
DOIF gibt ofter mal Rätsel auf. Mir persönlich ist es inzwischen zu komplex. Hatte auch schon Änderungen und vertraue dem Modul deshalb nicht mehr bei wichtigen Sachen.


Gruß

Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Per am 02 Mai 2017, 10:18:31
DOIF gibt ofter mal Rätsel auf. Mir persönlich ist es inzwischen zu komplex.
Hm, über RESIDENTS könnte man gleiches sagen!

Den Großteil der "Eventflut" konnte ich erfolgreich mit

attr rr.* event-on-change-reading (?!(durTimer|lastActivity)).*eindämmen. Ich will ja die durTimer nicht loswerden, sie sollen sich halt nur melden, wenn sie gefragt werden.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Loredo am 02 Mai 2017, 10:33:40
Hm, über RESIDENTS könnte man gleiches sagen!


Touché ;)
Da bin ich allerdings nicht neutral, denn da habe ich es zumindest selbst in der Hand und kann aktiv Einfluss nehmen.


Den Großteil der "Eventflut" konnte ich erfolgreich mit

attr rr.* event-on-change-reading (?!(durTimer|lastActivity)).*eindämmen. Ich will ja die durTimer nicht loswerden, sie sollen sich halt nur melden, wenn sie gefragt werden.


Kann man so machen. Allerdings ändern sich die Zahlen beim Duration Timer ja tatsächlich auch, deshalb wird es so nichts helfen.
Der richtige Ansatz ist das DOIF richtig zu definieren, so dass dort auch nur auf das Event reagiert wird, welches beabsichtigt ist.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Per am 02 Mai 2017, 10:52:20
Allerdings ändern sich die Zahlen beim Duration Timer ja tatsächlich auch, deshalb wird es so nichts helfen.
Dürfen sie ja auch. Ich (!) brauche nur keinen Event dafür, deshalb der o.a. Filter.

Der richtige Ansatz ist das DOIF richtig zu definieren, so dass dort auch nur auf das Event reagiert wird, welches beabsichtigt ist.
Ja, wenn man an anderer Stelle auf ein Event des DT (z.B. seit 3 Stunden keiner zu Hause...) reagieren will, muss man das so machen, ansonsten hilft der Filter schon für Platz im EventLog.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: oberlon am 03 Mai 2017, 12:49:32
@Per
Danke für den Regex. Gleich mal mit aufgenommen.

Ansonsten konnte ich jetzt mein Problem lösen indem ich im DOIF direkt auf das Reading [rgr_Bewohner:state] lausche. Zusätzlich ist das Attribut checkReadingEvent notwendig damit e_rgr_Bewohner_state im DOIF nicht bei jedem Event von rgr_Bewohner aktualisiert wird.
Fehlt checkReadingEvent wird durch durTimer* das Reading e_rgr_Bewohner_state jede Minute aktualisiert und führt dann bei mir in Verbindung mit Twilight zu einem schalten des Lichts obwohl ich lange daheim bin.

Warum der alte Ausdruck im DOIF lange Zeit funktioniert hat... Keine Ahnung.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: oberlon am 03 Mai 2017, 12:58:18
Der richtige Ansatz ist das DOIF richtig zu definieren, so dass dort auch nur auf das Event reagiert wird, welches beabsichtigt ist.

Damit hast du recht.
Mir war bis jetzt nur nicht bewusst, dass egal welches Event vom Device kommt alle Readings im DOIF aktualisiert werden. Und da geht es mir bestimmt nicht als einzigen so.

z.B. wird [rgr_Bewohner:presence] auch dann im DOIF aktualisiert wenn sich nur durTimerAbsence ändert. In Kombination mit anderen Devices (Twilight oder Zeit) können da komische Dinge bei rum kommen.

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST 00_HOMESTATE
Beitrag von: Phiolin am 03 Mai 2017, 13:02:09
Für dieses Problem gibt es im DOIF das Attribut "checkReadingEvent (https://fhem.de/commandref_DE.html#DOIF_checkReadingEvent)". Damit wird das DOIF nur aktualisiert, wenn genau die im DOIF angegebenen Readings aktualisiert werden.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 08 Mai 2017, 10:57:00

Für Interessierte:

Für das hier einmal vor Zeiten angekündigte, ergänzende Modul 00_HOMESTATE habe ich gerade eine separate Diskussion eröffnet:
https://forum.fhem.de/index.php/topic,71692.0.html (https://forum.fhem.de/index.php/topic,71692.0.html)




Gruß
Julian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: acw81 am 21 Mai 2017, 14:46:50
Hallo,

ich verwende bei meinen ROOMMATE Geräten als rr_presenceDevices Attribut, Readings von WLAN meinem AccessPoint. Ist in den Readings nun das entsprechende Gerät nicht vorhanden steht der ROOMMATE Status auf "home". Wäre es nicht sinnvoller diesen auf "absent" zu stellen, falls das Reading nicht existiert. Zumindest bei mir bereitet das im Moment leichte Probleme.

Grüße
Andreas
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 22 Mai 2017, 18:36:30
ich verwende bei meinen ROOMMATE Geräten als rr_presenceDevices Attribut, Readings von WLAN meinem AccessPoint. Ist in den Readings nun das entsprechende Gerät nicht vorhanden steht der ROOMMATE Status auf "home". Wäre es nicht sinnvoller diesen auf "absent" zu stellen, falls das Reading nicht existiert. Zumindest bei mir bereitet das im Moment leichte Probleme.


Eher anders herum: Die meisten Nutzer werden Probleme haben, wenn sie plötzlich aufgrund einer irrtümlichen Annahme oder eines Fehler als "abwesend" bewertet werden, weil ein Reading fehlt. Da stehen dann Leute im dunkeln und können womöglich nichtmal mehr was schalten ;)
Der Sinn dieses Attributes ist, dass nur dann auf abwesend geschaltet wird, wenn dies mit hoher Wahrscheinlichkeit auch die richtige Annahme ist. Für jemanden, der eine andere Logik benötigt, ist dieses Attribut nichts und man kann das ganze problemlos über Notify, DOIF oder Watchdog nach der Logik lösen, wie man es selbst braucht.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: acw81 am 22 Mai 2017, 20:53:38
Ja, muss ich dann wohl so lösen. Bei mir war das Problem, dass trotz Anwesenheit die Haustür nicht abgeschlossen wurde und das Licht an war.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Amenophis86 am 29 Mai 2017, 22:07:06
Ich habe folgende Art der Schaltung:
- Ich habe die Geo Überwachung und einen Schalter, welcher gedrückt wird für an und Abwesenheit.
- Ein Dummy erhält sowohl für Geo, als auch für den Schalter das Reading absent / present
- Ein DOIF setzt den Status des Dummy auf absent bzw present (priorisiert wird der Schalter)
- Roommate schaltet die Anwesenheit unter Bezug auf den Dummy (rr_presenceDevices -> AE.Dummy.Etienne)

Früher war es so, dass ich darüber informiert wurde, wenn Schalter und Geo unterschiedliche Zustände haben. Nun ist mir aufgefallen, dass automatisch mit dem Drücken des Schalters auch die Location verändert wird. Loredo hast du was am Code geändert? Ein Verbose 5 hat mir im Log folgendes gezeigt:

ROOMMATE rr_Etienne: implicit location change caused by state absent
Soll heißen, wird nun die Location automatisch geändert, wenn das presenceDevice sich ändert? Ich dachte Location steht wird immer über die Geolocation geholt? Ist es möglich dann noch das Reading GeoLocation einzuführen, welches sich nur über den Geo Status ändert? Sonst bekomme ich keine Erinnerung mehr, wenn jemand zuhause ist und den Schalter nicht gedrückt hat bzw. Abwesend und den Schalter vergessen hat.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: ThiemoSt am 06 Juni 2017, 10:02:30
Hallo Zusammen,

ich habe eine Frage die ich durch suchen noch nicht beantworten konnte. Eventuell auch weil ich nicht weiß nach was ich genau suchen muss.

Die Module sind eine große Hilfe um nicht alles händisch zu machen. Daher steuere ich über die Anwesenheit auch alle Rolladen.

Jedoch hätte ich gerne eine "Sonderlösung":
In der Nacht ist der Status des Resident Device asleep. Sobald morgens der Wecker für den ersten Bewohner geht wird dieser auf home gesetzt. Und jetzt kommt die Frage:
Wie kann ich dies am besten Abfangen das in dem Moment mindestens eine Rollade nicht geöffnet wird? Ich löse das aktuell mit einem Doif:
##3 - Rollo hoch wenn zu Hause
DOELSEIF
([K29a:state] eq "home"
and [$SELF:Automatik] eq "an")
(set OG.wz.RO.FensterTerrasse:FILTER=pct!=100 pct 100)

Hat da jemand noch eine andere Idee wo ich gerade blind für bin? Vielleicht mit anderen Funktionen aus dem Modul?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: theophilou85 am 09 Juni 2017, 20:12:24
Hallo Leute

Ich habe ein Problem mit Roommate und Geofancy.
Hardware: S7 Edge, Android 7, Egigeo (Ausnahme bei den Energiesparmaßnahmen). Raspbi 3, Zugang per SSL über Port 8083. Ubee Router der kein NAT Loopback unterstützt.

Eine Zone (mein Zuhause)+150Meter, ich Roommate mit der UUID. Keine notifys, schleifen, dummys oder sonst irgendwas. Ich möchte einfach nur "home" bei betreten der Zone und "absent" beim Verlassen der Zone haben.

Zwei Serverprofile eingerichtet, einmal mit der internen IP meines Pi im Wlan und eine mit meiner externen IP. Serverprofil mit Wifi-IP verwende ich als Ausfallserver, sofern das Betreten der Zone noch nicht über 3G/Lte gesendet wurde, bevor ich das Wlan betreten habe.

Mit beiden Serverprofilen erreiche ich im Wlan bzw. Internet meinen Pi. Auch das Betreten und Verlassen der Zonen wird mir am Handy unter den Notifications richtig gezeigt. Aber das Roommatedevice tut IRGENDWAS.

Gerade eben heimgekommen, und war mehr als 10h außer Haus:
lastArrival
2017-06-09 19:54:56

lastDeparture
2017-06-09 19:52:29
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: theophilou85 am 12 Juni 2017, 11:04:39
Heute morgen schon wieder. EgiGeoZone meldet um 8:40Uhr korrekt, dass ich die Zone verlassen habe. FHEM meint dazu:

lastArrival
2017-06-12 08:20:19
2017-06-12 08:20:19
lastDeparture
2017-06-12 08:15:23
2017-06-12 08:15:23

Ich werde nicht schlau aus der Sache.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: kadettilac89 am 04 August 2017, 11:06:00
Hallo,

ich habe eine Frage zum Reading "location". Lt. Beschreibung "location - the current location".

Ich habe 2 Zonen. Home + Work. Home ist auch status home zugeordnet und State presence oder absent / gone funktioniert alles wunderbar.

Das Reading location wird gesetzt wenn ich home oder work betrete. Es bleibt aber gesetzt solange bis ich eine andere Zone betrete. Kann ich das irgendwie beeinflussen? Ich würde erwarten, dass es auf away oder woanders hin wechselt wenn ich die Zone verlasse.

Ich habe aktuell ein userreading in dem ich locationpresence + location kombiniert auswerte, ich sehe dort, dass die Information an Fhem geliefert werden.

Ist das gewolltes Verhalten? Wenn ja, wofür ist das so eingebaut worden, ich möchte nicht kritisieren, würde es halt gerne verstehen.

Danke!

Ist-Verhalten

Event                           Reading location                Reading location - erwarteter Status                Reading locationPresence             
Home betretenhomehome (OK)present
Home verlassenhomeawayaway
Work betretenworkwork (OK)present
Work verlassenworkawayaway
]

Internals:
   DEF        Residents
   NAME       rr_S6
   NOTIFYDEV  global,
   NR         622
   NTFY_ORDER 50-rr_S6
   READY      1
   RESIDENTGROUPS Residents
   STATE      home
   TYPE       ROOMMATE
   Helper:
     DBLOG:
       location_real:
         myDbLog:
           TIME       1501834840.41013
           VALUE      home
   READINGS:
     2017-08-03 20:28:35   lastArrival     2017-08-03 20:28:35
     2017-08-01 19:41:37   lastDeparture   2017-08-01 19:41:37
     2017-08-03 20:28:35   lastDurAbsence  48:46:58
     2017-08-03 20:28:35   lastDurAbsence_cr 2927
     2017-08-01 19:41:37   lastDurPresence 00:00:04
     2017-08-01 19:41:37   lastDurPresence_cr 0
     2017-08-03 20:28:35   lastLocation    work
     2017-08-03 20:28:35   lastLocationAddr -
     2017-08-03 20:28:35   lastLocationLat xxxx
     2017-08-03 20:28:35   lastLocationLong xxx
     2017-08-01 19:41:37   lastMood        calm
     2017-08-03 20:28:35   lastState       gone
     2017-08-03 20:28:35   location        home
     2017-08-03 20:28:35   locationAddr    -
     2017-08-03 20:28:35   locationLat     4xxxx
     2017-08-03 20:28:35   locationLong    1xxxx
     2017-08-03 20:28:35   locationPresence present
     2017-08-03 20:28:35   location_real   home
     2017-08-03 20:28:35   mood            calm
     2017-08-03 20:28:35   presence        present
     2017-08-03 20:28:35   state           home
     2017-07-14 19:27:29   wayhome         0
   TIMER:
Attributes:
   alias      Galaxy S6
   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
   event-on-change-reading location_real,state
   group      Home Status
   icon       people_sensor
   room       Status
   rr_autoGoneAfter 0.25
   rr_geofenceUUIDs 82c29acf-xxxxx
   rr_locationHome home
   rr_noDuration 1
   rr_realname alias
   rr_states  home,absent
   sortby     2
   userReadings location_real { if( ReadingsVal("rr_S6","locationPresence","err") ne "present"  ) { sprintf("away")} else { ReadingsVal("rr_S6","location","err");; } }
   webCmd     state
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: l2r am 04 August 2017, 13:03:12
setz mal das Attribut rr_locations home, away, work

dann kennt er auch away.

Gruß Michael
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: kadettilac89 am 04 August 2017, 15:18:34
setz mal das Attribut rr_locations home, away, work

dann kennt er auch away.

Gruß Michael
werde ich mal testen ... thx
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Jamo am 12 August 2017, 19:44:39
Hallo,
ich würde gerne beim "rr_Inoma" Device als 4-tes Feld / Setter die Weckzeit einstellen können, also etwa so
attr rr_Inoma webCmd state:location:mood:nextRun
wobei "nextRun" dann das nextRun vom rr_Inoma_wakeuptimer1 einstellen würde, damit ich alle 4 setter für rr_Inoma einer Zeile habe, sonst brauche ich für den Wecker im Frontend eine eigene Zeile.
Leider hat das Device "rr_Inoma" kein Attribut setList, so dass ich keinen neuen Setter definieren kann. Hat einer eine Idee?

Danke und Gruss!
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Otto am 14 August 2017, 17:10:33
Hallo,

ich habe G-Tags am Schlüssel für die Steuerung (PRESENCE) des Status Home|Absent - das klappt soweit so gut.

Jetzt kommt es aber vor, dass meine Freundin Ihre Schlüssel in der Wohnung lässt und mit mir zusammen weg geht. Bei mir geht der Status ja automatisch auf Absent, aber wie mache ich es mit dem G-Tag meiner Freundin. Der meldet ja Home.

Kann man für diese Sonderfälle einen extra Status einrichten?
Also z.B. den Status auf "tour" setzen und dann das notify bei Status "tour" nicht auslösen...

Mit diesem notify mache ich den Statuswechsel

GTagOrange:present
{if (Value("rr_Peg") ne "gotosleep")
{fhem("set rr_Peg:FILTER=STATE!=home home");}
}

GTagOrange:absent
{if (Value("rr_Peg") ne "gone")
{fhem("set rr_Peg:FILTER=STATE!=absent absent");}
}
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: CoolTux am 14 August 2017, 17:47:26
Da hilft dann nur über's Handy einwählen und von Hand auf absent setzen oder versuchen der Freundin zu erklären wieso es besser ist wenn sie den Schlüssel immer mit nimmt.

Im übrigen denke ich nicht das Dein "Problem" von einem Modul gelöst werden sollte. Man kann und sollte keine speziellen Situationen abbilden in einem Modul.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Amenophis86 am 14 August 2017, 17:54:32
Da hilft dann nur über's Handy einwählen und von Hand auf absent setzen oder versuchen der Freundin zu erklären wieso es besser ist wenn sie den Schlüssel immer mit nimmt.

Im übrigen denke ich nicht das Dein "Problem" von einem Modul gelöst werden sollte. Man kann und sollte keine speziellen Situationen abbilden in einem Modul.

Naja, der Status wird vom Modul vermutlich wieder zurück gesetzt bei der nächsten Abfrage der G-Tags, daher wird ein Ändern von Hand nicht wirklich sinnvoll sein. Kann mich aber irren. Somit wäre die Idee einen "manuelle Änderung", welche nicht durch die G-Tags / Geofence / etc geändert werden kann schon nicht verkehrt.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: CoolTux am 14 August 2017, 18:09:29
Naja, der Status wird vom Modul vermutlich wieder zurück gesetzt bei der nächsten Abfrage der G-Tags, daher wird ein Ändern von Hand nicht wirklich sinnvoll sein. Kann mich aber irren. Somit wäre die Idee einen "manuelle Änderung", welche nicht durch die G-Tags / Geofence / etc geändert werden kann schon nicht verkehrt.

Wenn man es richtig macht wird nichts zurück gesetzt. Meine Freundin ist seit heute Morgen im Urlaub, GTab ist hier geblieben und sie ist auf absent gestellt. Alles schick.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Amenophis86 am 14 August 2017, 19:08:31
Das heißt lepresenced setzt bei dir den Status nicht wieder zurück. Und wie macht man es richtig? :)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: CoolTux am 14 August 2017, 19:10:03
event-on-change-reading               presence,device_battery,device_batteryLevel
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Amenophis86 am 14 August 2017, 19:13:17
Oder disbale des Gtag habe ich gerade überlegt. Aber deine Version geht auch, stimmt. Danke
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: blade-of-fire am 21 August 2017, 23:09:41
Hallo zusammen,

ich habe ein Problem und finde einfach nicht die Lösung.

Ich habe 2 Dummys, die jeweils 2 Readings haben (Key und Mobile). Das Reading Key wird vom jeweiligen iButton auf present/absent, das gleiche passiert über ein Presence Device, der mit der Fritzbox verknüpft ist.
Ich habe nun 2 Roommates, die mit dem jeweiligen Dummy und dessen Readings verknüpft sind (attr roommate1 rr_presenceDevices dummy1:Key,dummy1:Mobile).

Und nun zu meinem Problem:
Bei dem einen Roommate funktioniert das ganze einwandfrei. Sobald eines der Readings auf "present" steht, wird der Status geändert. Genauso umgekehrt, wenn alle Readings auf "absent" stehen.
Bei dem 2. Roommate allerdings passiert gar nichts.
Ich habe den 2. Roommate schon automatisch über den Resident-Device erzeugt und auch schon manuell angelegt. Die Readings, Attribute und Settings habe ich auch schon alle verglichen.
Ich könnte ja einfach mit Notifys arbeiten, aber wenn ich das richtig verstanden habe, brauche ich ja durch das Attribut "rr_presenceDevices" eigentlich kein Notify. Oder habe ich da was falsch verstanden?

Danke schonmal für eure Hilfe.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: CoolTux am 22 August 2017, 03:16:58
Hallo,

Du hast das schon richtig verstanden und Dein einer Roommate macht es ja auch korrekt.
Am Ende macht der Roommate nichts anderes wie ein Notify, er reagiert auf Events. Schau Mal im Eventmonitor was für Events Dein Dummy wirft. Und stell man ein liest von den beiden Roommates ein und eines vom Dummy der zum nicht funktionierenden Roommate gehört.


Grüße
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: blade-of-fire am 23 August 2017, 18:12:45
Ich verstehe nicht, was die ganze Zeit das Problem war, aber als ich eben die Events abgefragt habe, funktionierte es jetzt plötzlich mit beiden Roommates.

Naja, Hauptsache es funktioniert jetzt. Sollte ich noch dahinterkommen, was schlussendlich die Ursache war, melde ich mich wieder :)

Danke schonmal :)
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Jamo am 24 August 2017, 20:55:08
Hallo alle zusammen,

anbei ein Bild was ich gerne machen möchte, vielleicht kann mir jemand einen Schubs in die richtige Richtung geben.

Ich würde gerne beim "rr_Inoma" Device, als 4-tes Feld/Setter die Weckzeit einstellen können, also etwa so, wie auch im angehängten Bild unter "Nachher"

attr rr_Inoma webCmd state:location:mood:nextRunwobei "nextRun" dann das nextRun vom rr_Inoma_wakeuptimer1 einstellen würde, damit ich alles für rr_Inoma einer Zeile habe, sonst brauche ich für den Wecker im Frontend eine eigene Zeile.

Hast Jemand eine Idee, wie man das einfach machen kann, ohne alles mit einem Dummy umständlich zu verdoppeln?

Danke und Gruss!
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: justme1968 am 24 August 2017, 20:57:32
schau dir cmdalias und widgetOverride an. oder readingsGroup.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Jamo am 24 August 2017, 21:26:18
Hallo Justme,
für "cmdalias und widgetOverride" brauche ich aber das attribut "setList", das gibts im rr_Inoma aber nicht.

Dann nur Readingsgroup, oder?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: justme1968 am 24 August 2017, 21:27:32
nein. brauchst du nicht. beides hat nichts mit setList zu otun.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Jamo am 25 August 2017, 00:54:09
Hallo Andre,
Zitat
nein. brauchst du nicht. beides hat nichts mit setList zu otun.
Ich habe jetzt folgendes:attr rr_Inoma webCmd state:location:mood:nextRun
attr rr_Inoma widgetOverride nextRun:OFF,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00
damit siehts schon so aus wie ich es haben möchte (siehe Bild), allerdings kommt dann beim setzten immer
Zitat
Unknown argument nextRun, choose one of state:home,gotosleep,asleep,awoken,absent,gone mood:..........  create:wakeuptimer,locationMap

Wie verknüpfe ich das jetzt mit dem wakeuptimer?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Jamo am 25 August 2017, 21:07:19
Hallo Andre,
danke! Ich habs jetzt gelöst, wie im unten im Bild. Das funktioniert auch.
Aber, nach einem 'refresh' oder 're-load' der fhem website wird das drop-down vom nextRun menu 'leer' (ich weiss nicht wie ich es anders beschreiben soll).
Kann man das ändern, dass das drop-down menue vom nextRun die eingestellte Zeit behält?

attr rr_Inoma webCmd state:location:mood:nextRun
attr rr_Inoma widgetOverride nextRun:OFF,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00
und das cmdaliasInternals:
   ALIAS      set
   CFGFN
   DEF        set rr_Inoma nextRun .* AS {fhem ("set rr_Inoma_wakeuptimer1 nextRun $EVTPART2")}
   NAME       c_rr_Inoma
   NEWCMD     {fhem ("set rr_Inoma_wakeuptimer1 nextRun $EVTPART2")}
   NR         5237
   PARAM      rr_Inoma nextRun .*
   STATE      defined
   TYPE       cmdalias
Attributes:
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: ComputerZOO am 25 August 2017, 21:10:48
Moin,
versuch mal das attr readingList auf nextRun zu setzen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Jamo am 25 August 2017, 21:13:02
Mmmh, das Device rr_Inoma hat kein 'attr readingList'. Oder habe ich das falsch verstanden?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: ComputerZOO am 25 August 2017, 21:14:52
Stimmt, sorry, hatte ich übersehen
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Jamo am 25 August 2017, 21:28:56
So, ist gelöst, wie folgt. Ich habe dem cmdalias noch ein 'setreading rr_Inoma nextRun $EVTPART2' mitgegeben, und dem 'rr_Inoma' ein 'attr userReadings nextRun'. Damit funktionierts!
Mein dank an Andre!!!

attr rr_Inoma userReadings nextRun
attr rr_Inoma webCmd state:location:mood:nextRun
attr rr_Inoma widgetOverride nextRun:OFF,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00
und das cmdaliasInternals:
   ALIAS      set
   CFGFN
   DEF        set rr_Inoma nextRun .* AS {fhem ("set rr_Inoma_wakeuptimer1 nextRun $EVTPART2;setreading rr_Inoma nextRun $EVTPART2")}
   NAME       c_rr_Inoma
   NEWCMD     {fhem ("set rr_Inoma_wakeuptimer1 nextRun $EVTPART2;setreading rr_Inoma nextRun $EVTPART2")}
   NR         5237
   PARAM      rr_Inoma nextRun .*
   STATE      defined
   TYPE       cmdalias
Attributes:
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: popy am 31 Oktober 2017, 10:37:47
Hallo.

Danke für das Modul, bin grad am einrichten, aber als Anfänger sehr viele Fragen:

Habe es vor einer Woche nie zusammengebracht dass sich der Status der Roommates ändert.
Nun wieder Zeit, weiter zu experimentieren  ;)
Bei den roommates waren die richtigen Presences hinterlegt: "rr_presenceDevices P_BT_Tobias,P_WIFI_Tobias", diese Presences änderten sich auch, aber nicht der Roommate.
Folgende Fragen habe ich nicht dazu:


Fragen über Fragen :-)

Danke pOpY
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Phiolin am 31 Oktober 2017, 16:42:35
Von den unter rr_presenceDevices angegebenen Geräten sollte das Reading "presence" automatisch auf das Roommate Device übernommen werden.
Für den "absent" Status bedeutet das übrigens, dass ALLE angegebenen Geräte "absent" sein müssen, um den Roommate auf "absent" zu setzen. Umgekehrt reicht es für den Status "present" aus, wenn ein Gerät wieder erreichbar ist um den Roommate auch auf "present" zu setzen.
Bezüglich event-on-change-reading, würde ich vermuten, dass du zumindest auch das "presence" Reading dort aufnehmen musst, damit das funktioniert. Bei mir habe ich jeweils state,presence und room im event-on-change-reading bei den Presence Devices.

Die Location des Roommate Devices musst du selber z.B. über ein Notify setzen. Das bringt dir auch entsprechende Flexibilität, z.B. wenn ein Presence Device eine höhere Priorität bei der Location haben soll als ein anderes.
Ich hatte bei mir z.B. die Apple Watch entsprechend höher priorisiert als das iPhone, da es wahrscheinlicher ist, dass ich mit der Uhr durch das Haus laufe, als mit dem Handy. Lasse ich also mein Handy irgendwo liegen, wird meine Location primär basierend auf der Location der Uhr gesetzt. Ist die Uhr nicht erreichbar, wird die Location vom Handy genommen. Hier musst du also etwas für dich passendes selber programmieren.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: popy am 01 November 2017, 11:37:42
Von den unter rr_presenceDevices angegebenen Geräten sollte das Reading "presence" automatisch auf das Roommate Device übernommen werden.
Für den "absent" Status bedeutet das übrigens, dass ALLE angegebenen Geräte "absent" sein müssen, um den Roommate auf "absent" zu setzen. Umgekehrt reicht es für den Status "present" aus, wenn ein Gerät wieder erreichbar ist um den Roommate auch auf "present" zu setzen.
Bezüglich event-on-change-reading, würde ich vermuten, dass du zumindest auch das "presence" Reading dort aufnehmen musst, damit das funktioniert. Bei mir habe ich jeweils state,presence und room im event-on-change-reading bei den Presence Devices.

Die Location des Roommate Devices musst du selber z.B. über ein Notify setzen. Das bringt dir auch entsprechende Flexibilität, z.B. wenn ein Presence Device eine höhere Priorität bei der Location haben soll als ein anderes.
Ich hatte bei mir z.B. die Apple Watch entsprechend höher priorisiert als das iPhone, da es wahrscheinlicher ist, dass ich mit der Uhr durch das Haus laufe, als mit dem Handy. Lasse ich also mein Handy irgendwo liegen, wird meine Location primär basierend auf der Location der Uhr gesetzt. Ist die Uhr nicht erreichbar, wird die Location vom Handy genommen. Hier musst du also etwas für dich passendes selber programmieren.

Danke für deine Hilfe, nun wird absent und home/present der ROOMMATES von je 2x PRESENCES übertragen. Der Clou war dass ich zuerst mal selbst jeden ROOMMATE auf absent setzten musste, ansonsten wurde der Status nicht übernommen. Durch das richtige setzen von event-on-change-reading auf "state, presence, room"veringere ich nun auch die umherschirrenden events, Danke Vielmals für Deine Hilfe.

Wie du schon sagtest wird der room nicht automatisch auf die location übernommen und muss ich noch selbst per notify machen.
Könntest du mir Bitte ein Beispiel Notify von deinem System posten?

Ziel wäre es mit einem notify jeweils den rr_ zu setzen.
Meine Bluetooth presences wo ich den room nun mitbekomme heissen alle "P_BT_<NAME>" und meine ROOMMATES "rr_<NAME>".
Bin leider nicht so fit mit Perl und RegEx, vermute das geht irgendwie?

Danke Vielmals
pOpY
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Phiolin am 01 November 2017, 16:47:45
Ich verwende wie gesagt hauptsächlich DOIF, deshalb kann ich spontan auch nur ein DOIF Beispiel geben.
Als Presence Device wird hier ein "MyName_iPhone" angenommen, dass zum Bewohner rr_MyName gehört.

Was das macht:
Wenn das Presence Device "present" ist und ein Event generiert, bei dem sich das "room" Reading ändert, wird der neue Wert des "room" Readings als Location für den Bewohner gesetzt. Damit nicht unnötig Daten geändert werden, wird das Location Reading zudem auch nur dann gesetzt, wenn sich der neue Raum vom vorherigen Raum unterscheidet.

(
  [MyName_iPhone:presence] eq "present"
  and ["^MyName_iPhone$:room"]
) (
  set rr_MyName:FILTER=location!=[MyName_iPhone:room] location [MyName_iPhone:room]
) DOELSEIF (
  [MyName_iPhone:room] ne ""
  and [MyName_iPhone:presence] eq "present"
) (
  set rr_MyName:FILTER=location!=[MyName_iPhone:room] location [MyName_iPhone:room]
)

Und die Attribute vom DOIF:
Attributes:
   checkReadingEvent 1
   checkall   event
   do         always


Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: popy am 01 November 2017, 22:40:03
Danke für die Infos.

Habe es jetzt mit einem Notify gemacht damit der room in die location übernommen wird, mit folgendem code:

P_BT.*.room:.* {
  my $roommate = "rr_".substr($NAME,5);
  my $room = ReadingsVal($NAME,"room","");

  if ($room eq "")
  {
    $room = "unbekannt";
  }

  Log 1, "act_set_rr_location: Bluetooth Gerät ".$NAME." ist jetzt im Raum ".$room;
  fhem "setreading ".$roommate." location ".$room;
}

Funktioniert 1a, es wird in location der room gesetzt oder sonst unbekannt.
Weiters setzte ich mir jetzt einen Dummy Alias "Jemand im Wohnzimmer" mit folgendem DOIF:

([#"^rr_.*":location:$_ eq "Wohnzimmer"] > 0) (set P_WZ present) DOELSE (set P_WZ absent)
Danke Deiner Hilfe im anderen Thread  ::)
Und zu Guter letzt kann ich nun meinen "Niemand mehr im Wohnzimmer" Watchdog drauf aufsetzen:

P_WZ:absent 00:15 P_WZ:present {evtWZBTAbsentHandler()} ; setstate watchdog_Niemand_im_WZ defined
und das Wohnzimmer nach 15 Minuten ausschalten.
Funktioniert soweit alles, muss sich noch in der Praxis beweisen.

Danke Jedenfalls für Deine Unterstützung und Deine Code Schnippsel, diese helfen ungemein.

pOpY
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: popy am 02 November 2017, 22:51:04
Eine Frage noch zum Modul.
Derzeit habe ich als webcmd "state" gesetzt und somit eine Combobox mit dem aktuellen state & Dazu passende devStateIcon's (Siehe Bild).

Ich möchte Gerne neben der state combobox noch die location anzeigen und aber das devSTateIcon behalten.
Alle meine Versuche mit setzen von "stateformat" und entfernen von devStateIcon waren nur semi-erfolgreich.
Sprich ich kann die icons entfernen und mittels stateformat ausgeben was ich will, beides (icon & stateformat) geht aber nicht!?
Hoffe ich habe mich verständlich ausgedrückt  ::)

Würde mich über jeden Hinweis freuen.
Danke pOpY
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: CoolTux am 03 November 2017, 03:02:35
webCmd   state:location
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: popy am 03 November 2017, 08:07:11
webCmd   state:location

Danke für die Antwort.
Leider funktioniert es nicht ganz mit:

webCmd state:location
Raus kommt das wie im Bild im Anhang.

pOpY
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: CoolTux am 03 November 2017, 08:57:46
Dann stimmt irgendwas nicht. Gerade getestet. Bei mir geht das.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: moskito am 03 November 2017, 09:28:59
@popy
schau mal ob das Attribut rr_locations existiert und dort Werte eingetragen sind

Gruß
Danny
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: popy am 03 November 2017, 09:54:12
@popy
schau mal ob das Attribut rr_locations existiert und dort Werte eingetragen sind

Gruß
Danny

Nun klappts, habe bei rr_locations nun "home,gotosleep,asleep,awoken,absent,Wohnzimmer,Schlafzimmer,unbekannt" eingetragen.

Danke
pOpY

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: CoolTux am 03 November 2017, 09:57:31
bisschen übereifrig. es geht um location. asleep ist keine location

atwork,home,wayhome,underway

wegen meiner noch Bahnhof oder so. aber nicht asleep oder gotosleep
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: mrbreil am 07 Dezember 2017, 14:25:45
Bekomme nach dem ich ein "userReadings" Attribut
attr rr_Lisa userReadings image {((ReadingsVal("rr_Lisa","state","absent") eq "home" ) ? "/fhemcommands/images/residents/lisa-farbe.png" : "/fhemcommands/images/residents/lisa-grau.png");;}\
 angelegt habe immer folgenden Fehler:

readingsUpdate(rr_Lisa,image,/fhemcommands/images/residents/lisa-farbe.png) missed to call readingsBeginUpdate first.
Ich denke das hat irgendwas mit readingsSingleUpdate und readingsBeginUpdate zu tun, aber das übersteigt meine Fähigkeiten bei weitem, hat jemand eine Idee?

Gruß Christian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Jamo am 13 Dezember 2017, 12:14:31
Hi Loredo,
mir ist aufgefallen, dass das reading 'presence' im RESIDENTS modul für rgr_Guests überhaupt erst dann erzeugt wird, wenn man den 'state' von rgr_Guests einmal auf 'present' setzt. Vorher gibt es das reading gar nicht. 

Was war mein Problem? Nun ich hatte ich mir irgendwie den fhem statefile zerschossen nachdem ich meine CCU2 gelöscht hatte (FHEM hatte sich aufgehängt). Danach war der Status von rgr_Guests kaputt. Viele meiner Abfragen verwenden (Readingsval ("rgr_Guests","presence","na") eq "present"), deswegen funktionierte nichts nehr so wie vorher. Ich habe dann mit set rgr_Guests state absent den status auf 'absent' gesetzt, trotzdem funktionierten meine Abfragen nicht. Ich habe dann festgestellt, das es das reading 'presence' im RESIDENTS modul für rgr_Guests gar nicht gibt. Erst mit einem set rgr_Guests state present wurde dieses reading dann letztendlich angelegt.

Falls Du das nachvollziehen kannst, könnte man das in der Art fixen das es ein reading present immer gibt, dann eben mit einem 'none' oder so als startwert?

Meine definition von rgr_Guests defmod rgr_Guests RESIDENTS
Alternativ ist mir beim schreiben dieses Textes eingefallen, das es schlauer wäre, auf (Readingsval ("rgr_Guests","presence","absent") eq "present") anstatt auf (Readingsval ("rgr_Guests","presence","na") eq "present") abzufragen :-(

Danke fürs lesen!
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: nias am 14 Dezember 2017, 19:10:21
Nabend,

ROOMMATE schaltet "Nias" nicht auf state=home zurück und ich weiss nicht mehr weiter...

RAW-Block:
defmod Nias ROOMMATE Bewohner
attr Nias alias Status
attr Nias 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
attr Nias eventMap home:zuhause absent:abwesend gone:verreist gotosleep:bettfertig asleep:schläft awoken:aufgestanden
attr Nias group Nias
attr Nias icon people_sensor
attr Nias room Residents
attr Nias rr_geofenceUUIDs xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
attr Nias rr_lang DE
attr Nias rr_realname group
attr Nias sortby 1
attr Nias verbose 5
attr Nias webCmd state
attr Nias widgetOverride state:zuhause,bettfertig,schläft,aufgestanden,abwesend,verreist

setstate Nias zuhause
setstate Nias 2017-12-14 18:59:34 durTimerAbsence 00:00:00
setstate Nias 2017-12-14 18:59:34 durTimerAbsence_cr 0
setstate Nias 2017-12-14 18:50:22 durTimerPresence 00:00:00
setstate Nias 2017-12-14 18:50:22 durTimerPresence_cr 0
setstate Nias 2017-12-11 22:20:51 durTimerSleep 00:00:00
setstate Nias 2017-12-11 22:20:51 durTimerSleep_cr 0
setstate Nias 2017-12-14 18:59:34 lastArrival 2017-12-14 18:59:34
setstate Nias 2017-12-14 18:50:22 lastDeparture 2017-12-14 18:50:22
setstate Nias 2017-12-14 18:59:34 lastDurAbsence 00:09:12
setstate Nias 2017-12-14 18:59:34 lastDurAbsence_cr 9
setstate Nias 2017-12-14 18:50:22 lastDurPresence 00:01:19
setstate Nias 2017-12-14 18:50:22 lastDurPresence_cr 1
setstate Nias 2017-12-14 18:31:19 lastLocation Zuhause
setstate Nias 2017-12-14 17:29:00 lastLocationAddr -
setstate Nias 2017-12-14 17:29:00 lastLocationLat XXX
setstate Nias 2017-12-14 17:29:00 lastLocationLong YYY
setstate Nias 2017-12-14 18:50:22 lastMood calm
setstate Nias 2017-12-14 18:59:34 lastState absent
setstate Nias 2017-12-14 18:57:26 location home
setstate Nias 2017-12-14 18:57:26 locationAddr -
setstate Nias 2017-12-14 18:57:26 locationLat -
setstate Nias 2017-12-14 18:57:26 locationLong -
setstate Nias 2017-12-14 18:57:26 locationPresence absent
setstate Nias 2017-12-14 18:59:34 mood calm
setstate Nias 2017-12-14 18:59:34 presence present
setstate Nias 2017-12-14 18:59:34 state home
setstate Nias 2017-12-14 17:10:59 wayhome 0

Nun simuliere ich mit wget die GeofancyApp:
# sim_geo.sh wayhome
2017.12.14 19:03:41 5: GEOFANCY geofancy: detected data format: Geofency.app
2017.12.14 19:03:41 5: GEOFANCY geofancy: Checking rr_geofenceUUIDs for Nias
2017.12.14 19:03:41 4: GEOFANCY geofancy: Found matching UUID at ROOMMATE device Nias
2017.12.14 19:03:41 4: GEOFANCY geofancy: id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx name=wayhome trig=0 date=1513274621 lat= long= address:- dev=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx devAlias=Nias
2017.12.14 19:03:41 5: ROOMMATE Nias: received location information: id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx name=wayhome trig=0 date=2017-12-14 19:03:41 lat=- long=- address:- device=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
2017.12.14 19:03:41 5: ROOMMATE Nias: received signal from underway location
2017.12.14 19:03:41 5: ROOMMATE Nias: wayhome signal received
2017.12.14 19:03:41 4: ROOMMATE Nias: implicit state change caused by location wayhome
2017.12.14 19:03:41 4: ROOMMATE Nias: implicit mood change caused by state absent
2017.12.14 19:03:41 4: ROOMMATE Nias: AutoGone timer scheduled: 1513404221

Das klappt *prima*!

Aber leider gehts nicht mehr zurück...
# sim_geo.sh home
2017.12.14 19:05:14 5: GEOFANCY geofancy: detected data format: Geofency.app
2017.12.14 19:05:14 5: GEOFANCY geofancy: Checking rr_geofenceUUIDs for Nias
2017.12.14 19:05:14 4: GEOFANCY geofancy: Found matching UUID at ROOMMATE device Nias
2017.12.14 19:05:14 4: GEOFANCY geofancy: id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx name=home trig=0 date=1513274714 lat= long= address:- dev=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx devAlias=Nias
2017.12.14 19:05:14 5: ROOMMATE Nias: received location information: id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx name=home trig=0 date=2017-12-14 19:05:14 lat=- long=- address:- device=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
2017.12.14 19:05:14 5: ROOMMATE Nias: received signal from home location

Die "location" steht danach auf "home", aber der state/presence bleiben auf "absent".
Jemand eine Idee wo es hier hakt?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: nias am 14 Dezember 2017, 22:31:32
okay, hat sich erledigt.
Hab in meiner Simulation den "entry" Parameter an die URL falsch verfüttert...
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: mrbreil am 20 Dezember 2017, 09:14:02
Möchte das noch mal nach vorne holen, spamt mir das ganze log zu. Das ist doch kein normales Verhalten des Moduls?
Keiner einen Tip, was da falsch läuft?

Gruß Christian

Bekomme nach dem ich ein "userReadings" Attribut
attr rr_Lisa userReadings image {((ReadingsVal("rr_Lisa","state","absent") eq "home" ) ? "/fhemcommands/images/residents/lisa-farbe.png" : "/fhemcommands/images/residents/lisa-grau.png");;}\
 angelegt habe immer folgenden Fehler:

readingsUpdate(rr_Lisa,image,/fhemcommands/images/residents/lisa-farbe.png) missed to call readingsBeginUpdate first.
Ich denke das hat irgendwas mit readingsSingleUpdate und readingsBeginUpdate zu tun, aber das übersteigt meine Fähigkeiten bei weitem, hat jemand eine Idee?

Gruß Christian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: DeeSPe am 20 Dezember 2017, 09:29:03
Möchte das noch mal nach vorne holen, spamt mir das ganze log zu. Das ist doch kein normales Verhalten des Moduls?
Keiner einen Tip, was da falsch läuft?

Gruß Christian

Ich sehe im userReading zu viele Klammer und einen Trigger gibt es auch nicht.
Mit einem angegebenen Trigger wären es auch weniger Log Ausgaben.

Gruß
Dan
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: igami am 31 Dezember 2017, 11:33:17
Ich hätte da noch einen Wunsch zum neuen Jahr.
Im Log habe ich viele Meldungen der Art
2017.12.31 10:43:29 2: ROOMMATE set Michael_P home
2017.12.31 10:43:29 2: ROOMMATE set Michael_P location arrival
Diese werden mit verbose 2 gelogt. Laut der Definition in der commandref
Zitat
verbose
Set the verbosity level. Possible values:

    0 - server start/stop
    1 - error messages or unknown packets
    2 - major events/alarms.
    3 - commands sent out will be logged.
    4 - you'll see whats received by the different devices.
    5 - debugging.
sollten diese aber mit verbose 3 gelogt werden.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: ujaudio am 21 Januar 2018, 16:22:36
Ich bitte um Hilfe zur Selbsthilfe: seit einiger Zeit läuft mein System relativ instabil, weil die HomeMatic-Kommunikation  Problem macht. Apptime liefert mir aber Zeitbedarfe bei ROOMMATE. Deswegen zuerst mal die Frage hier: ist dieses Verhalten normal?
                      name             function    max  count    total  average maxDly
tmr-ROOMMATE_DurationTimer      HASH(0x2d15c60)    868      1      868   868.00      4 HASH(rr_Juergen_DurationTimer)
tmr-ROOMMATE_DurationTimer      HASH(0x2d07680)    658      1      658   658.00      6 HASH(rr_Juergen_DurationTimer)
tmr-ROOMMATE_DurationTimer      HASH(0x2e59828)    655      1      655   655.00      9 HASH(rr_Ursula_DurationTimer)
tmr-ROOMMATE_DurationTimer      HASH(0x2c82a28)    653      1      653   653.00     58 HASH(rr_Ursula_DurationTimer)
tmr-ROOMMATE_DurationTimer      HASH(0x2d17300)    652      1      652   652.00      5 HASH(rr_Ursula_DurationTimer)
tmr-ROOMMATE_DurationTimer      HASH(0x2c8aae0)    651      1      651   651.00      5 HASH(rr_Ursula_DurationTimer)
tmr-ROOMMATE_DurationTimer      HASH(0x2d3d4f8)    651      1      651   651.00      9 HASH(rr_Juergen_DurationTimer)
tmr-ROOMMATE_DurationTimer      HASH(0x2d59fa0)    649      1      649   649.00      5 HASH(rr_Juergen_DurationTimer)
tmr-ROOMMATE_DurationTimer      HASH(0x2d3d6c0)    613      1      613   613.00      5 HASH(rr_Ursula_DurationTimer)
tmr-ROOMMATE_DurationTimer      HASH(0x2cb6638)    607      1      607   607.00      6 HASH(rr_Juergen_DurationTimer)
tmr-ROOMMATE_DurationTimer      HASH(0x2276878)    606      1      606   606.00    406 HASH(rr_Ursula_DurationTimer)
tmr-ROOMMATE_DurationTimer      HASH(0x2cd4648)    603      1      603   603.00      5 HASH(rr_Juergen_DurationTimer)
tmr-ROOMMATE_DurationTimer      HASH(0x2a4f298)    595      1      595   595.00      9 HASH(rr_Juergen_DurationTimer)
tmr-ROOMMATE_DurationTimer      HASH(0x2c8bef0)    595      1      595   595.00      8 HASH(rr_Ursula_DurationTimer)
Das sind die Appliaktionen mit dem größten Zeitbedarf, alles andere liegt um Faktoren darunter. Was kann ich da durch mein Verwenden des Moduls falsch gemacht haben? Oder soll ich zuerst einfach mal auf gut Glück ein Update machen?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: pappn am 21 Januar 2018, 22:04:02
Ich möchte gerne den Status der Presence devices als auch des daraus resultierenden Residents status aufzeichnen und in einem LogFile zusammenfassen. Für die Presence devices funktioniert das auch prima. Beim Residends device habe ich Probleme.
define PRESENCE.File FileLog ./log/presence-%Y-%m.log andrea_handy:presence.*|armin_handy:presence.*|christof_handy:presence.*|Familie:state.* mit attr PRESENCE.File addStateEvent 1Der State des Residents Devices wird korrekt gemeldet/erfasst, wenn er sich ändert, aber, obwohl ich attr Familie event-min-interval state:900 für das Device gesetzt habe, bekomme ich nicht die erwarteten Log Einträge im 15 min Takt.

Ist in diesem Modul etwas anders als in anderen, das ich übersehen habe?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: moskito am 21 Januar 2018, 22:21:08
Ich glaube Du interpretierst das Attribut "event-min-interval" falsch.

Zitat
event-min-interval
Dieses Attribut enthält eine durch Kommata getrennte Liste von "readings:minInterval" Paare. readings kann ein regexp sein. Ein Event wird nur dann generiert, falls seit dem letzten Auftreten des gleichen Events mindestens minInterval Sekunden vergangen sind. Falls event-on-change-reading auch spezifiziert ist, dann werden sie mit ODER kombiniert, d.h. wenn einer der beiden Bedingungen wahr ist.

Ich hatte mal etwas ähnliches für Rollläden in Betrieb, evtl. hilft Dir das weiter:

### jede 1/2 Stunde einen Eintrag für Rollläden
define roll_log notify roll_log {addLog("Roll_Kinderzimmer","position")}

define roll_log_hour at +*00:30:00 trigger roll_log

Gruß
Danny
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: pappn am 21 Januar 2018, 23:16:03
Danke für den Hinweis. Also kommt es offensichtlich auf das Zusammenspile zwischen event-min-interval und event-on-change-reading an. Wenn das Modul gar keine events generiert, bewegt sich also auch nichts. Insofern verhält es sich hier schon anders als andere Module, wo das Vorgehen mit event-min-interval und event-on-change-reading sehr gut funktioniert. Ich habe addlog daher sonst nicht mehr im Einsatz.

Mit dieser Variante bekomme ich aber auch was ich brauche.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: en-trust am 16 Februar 2018, 15:54:12
Kann ich irgendwie neue Stati (neben home zum Beispiel homeoffice) einfügen und wie kann ich die dann einbinden ?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: kjmEjfu am 16 Februar 2018, 15:57:59
Kann ich irgendwie neue Stati (neben home zum Beispiel homeoffice) einfügen und wie kann ich die dann einbinden ?

rr_locations?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: CoolTux am 16 Februar 2018, 16:50:05
rr_locations?

Hätte ich auch gesagt
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: en-trust am 16 Februar 2018, 19:15:03
Ich meinte eher eine Art 2.Status. Folgendes Szenario stellt sich dar. Ich habe eine Awesenheitsprüfung über wlan. Allerdings Meldet sich das Handy öfters ab (ist wohl ein Bug in der letzten HandyFirmware). Dies hat zur Folge, dass meine Jalousie dann automatisch runter fährt. Nun würde ich gerne eine Funktion haben, wo ich manuell fhem mitteile, dass ich jetzt 'manuell' zu Hause bin und er die Prüfung hinten anstellen kann.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: CoolTux am 16 Februar 2018, 19:35:46
Zweites anwesenheitsdevice und mit dem ersten zusammen ein Structuredevice erstellen und das dann halt abfragen wegen Abwesenheit
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: en-trust am 16 Februar 2018, 19:45:22
Oje... hast Du ein Beispiel ?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: CoolTux am 16 Februar 2018, 19:58:53
verrate erstmal wie du es bis jetzt machst.
Gib bitte ein list von Deinem presence device und Deinem Roommate Device. Ich gehe davon aus das Du das presence Attribut Deines Roomates verwendest.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: en-trust am 17 Februar 2018, 19:56:34
Hier die beiden Lists welche ich parallel abfrage.

Internals:
   CFGFN      ./FHEM/fhem_residents.cfg
   CHANGED   
   DEF        function {CheckiPhone("ip","mac")} 60 120
   INTERVAL_NORMAL 60
   INTERVAL_PRESENT 120
   MODE       function
   NAME       Galaxy.A5.Wlan
   NOTIFYDEV  global
   NR         916
   NTFY_ORDER 50-Galaxy.A5.Wlan
   STATE      present
   TYPE       PRESENCE
   Helper:
     DBLOG:
       presence:
         logdb:
           TIME       1518891868.75429
           VALUE      present
       state:
         logdb:
           TIME       1518892726.06711
           VALUE      present
   READINGS:
     2018-02-16 13:42:42   model           function
     2018-02-17 19:51:44   presence        present
     2018-02-17 19:51:44   state           present
   helper:
     CURRENT_STATE present
     call       {CheckiPhone("ip","mac")}
Attributes:
   Bewohner_structure Bewohner
   Handys     alleHandys
   event-on-change-reading state,presence
   group      Anwesenheit
   room       3.2_Anwesenheit,Fritzbox,Status,System
   userattr   Bewohner_structure Bewohner_structure_map Handys Handys_map structexclude

Internals:
   ADDRESS    ip
   CFGFN      ./FHEM/fhem_residents.cfg
   CHANGED   
   DEF        lan-ping ip 60
   INTERVAL_NORMAL 60
   INTERVAL_PRESENT 60
   MODE       lan-ping
   NAME       HA.SvenWlan
   NOTIFYDEV  global
   NR         910
   NTFY_ORDER 50-HA.SvenWlan
   STATE      absent
   TYPE       PRESENCE
   Helper:
     DBLOG:
       presence:
         logdb:
           TIME       1518892601.37061
           VALUE      absent
       state:
         logdb:
           TIME       1518892601.37061
           VALUE      absent
   READINGS:
     2018-02-16 13:42:42   model           lan-ping
     2018-02-17 19:52:44   presence        absent
     2018-02-17 19:52:44   state           absent
   helper:
     CURRENT_STATE present
     RUNNING_PID:
       abortFn    PRESENCE_ProcessAbortedScan
       arg        HA.SvenWlan|ip|0|4
       bc_pid     46927
       finishFn   PRESENCE_ProcessLocalScan
       fn         PRESENCE_DoLocalPingScan
       pid        22934
       timeout    60
       abortArg:
Attributes:
   event-on-change-reading state,presence
   group      Anwesenheit
   pingCount  4
   presence   Anwesenheit
   room       3.2_Anwesenheit,Fritzbox,Status,System
   userattr   presence presence_map structexclude

und das Roommate...

Internals:
   CFGFN      ./FHEM/fhem_residents.cfg
   DEF        residents
   DURATIONTIMER 1518893783.03789
   NAME       rr_Sven
   NOTIFYDEV  global,Galaxy.A5.Wlan
   NR         954
   NTFY_ORDER 50-rr_Sven
   READY      1
   RESIDENTGROUPS residents
   STATE      home
   TYPE       ROOMMATE
   Helper:
     DBLOG:
       durTimerAbsence:
         logdb:
           TIME       1518891868.83542
           VALUE      00:00:00
       durTimerAbsence_cr:
         logdb:
           TIME       1518891868.83542
           VALUE      0
       durTimerPresence:
         logdb:
           TIME       1518893723.07864
           VALUE      00:30:55
       durTimerPresence_cr:
         logdb:
           TIME       1518893723.07864
           VALUE      31
       lastArrival:
         logdb:
           TIME       1518891868.83542
           VALUE      2018-02-17 19:24:28
       lastDeparture:
         logdb:
           TIME       1518891535.14473
           VALUE      2018-02-17 19:18:55
       lastDurAbsence:
         logdb:
           TIME       1518891868.83542
           VALUE      00:05:33
       lastDurAbsence_cr:
         logdb:
           TIME       1518891868.83542
           VALUE      6
       lastDurPresence:
         logdb:
           TIME       1518891535.14473
           VALUE      01:05:57
       lastDurPresence_cr:
         logdb:
           TIME       1518891535.14473
           VALUE      66
       lastState:
         logdb:
           TIME       1518891868.83542
           VALUE      absent
       location:
         logdb:
           TIME       1518891868.83542
           VALUE      home
       mood:
         logdb:
           TIME       1518891868.83542
           VALUE      calm
       presence:
         logdb:
           TIME       1518891868.83542
           VALUE      present
       state:
         logdb:
           TIME       1518891868.83542
           VALUE      home
   READINGS:
     2018-02-17 19:24:28   durTimerAbsence 00:00:00
     2018-02-17 19:24:28   durTimerAbsence_cr 0
     2018-02-17 19:55:23   durTimerPresence 00:30:55
     2018-02-17 19:55:23   durTimerPresence_cr 31
     2018-02-10 20:43:34   durTimerSleep   00:00:00
     2018-02-10 20:43:34   durTimerSleep_cr 0
     2018-02-17 19:24:28   lastArrival     2018-02-17 19:24:28
     2018-02-10 20:43:34   lastAwake       2018-02-10 20:43:34
     2018-02-17 19:18:55   lastDeparture   2018-02-17 19:18:55
     2018-02-17 19:24:28   lastDurAbsence  00:05:33
     2018-02-17 19:24:28   lastDurAbsence_cr 6
     2018-02-17 19:18:55   lastDurPresence 01:05:57
     2018-02-17 19:18:55   lastDurPresence_cr 66
     2018-02-10 20:43:34   lastDurSleep    00:02:33
     2018-02-10 20:43:34   lastDurSleep_cr 3
     2018-02-17 19:18:55   lastLocation    home
     2018-02-17 19:18:55   lastMood        calm
     2018-02-10 20:41:01   lastSleep       2018-02-10 20:41:01
     2018-02-17 19:24:28   lastState       absent
     2018-02-17 19:24:28   location        home
     2018-02-17 19:24:28   mood            calm
     2018-02-17 19:24:28   presence        present
     2018-02-17 19:24:28   state           home
     2018-02-07 20:07:19   wayhome         0
   TIMER:
     rr_Sven_DurationTimer:
       HASH       rr_Sven
       MODIFIER   DurationTimer
       NAME       rr_Sven_DurationTimer
Attributes:
   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
   event-on-change-reading .*
   group      Anwesenheit,Personen
   icon       people_sensor
   room       3.2_Anwesenheit,Flur
   rr_autoGoneAfter 24
   rr_presenceDevices Galaxy.A5.Wlan
   rr_realname group
   rr_states  home,asleep,absent,gone,homeoffice
   sortby     1
   webCmd     state
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: CoolTux am 17 Februar 2018, 20:06:06
Das passt doch gut. Du hast also 2 presence Devices, da machst du nun ein Dummy Device dazu mit state present absent für die manuelle Geschichte.
Nun fügst Du alle 3 Devices in eine structure zusammen, und beim Roommate Device gibst Du das structure Device als rr_presenceDevices an.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 20 Oktober 2018, 17:19:39
Morgen gibt es ein Update des RESIDENTS Toolkit und somit auch von ROOMMATE und GUEST, um Funktionen des aktualisierten GEOFANCY Moduls (https://forum.fhem.de/index.php/topic,18485.msg847898.html#msg847898) zu unterstützen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: mumpitzstuff am 22 Oktober 2018, 22:44:31
Habe seit neuestem dauernd sowas im Logfile:

2018.10.22 05:44:54 3: PRESENCE (GTAG_A) - collectord lost connection to room RPI2
2018.10.22 05:44:57 3: PRESENCE (GTAG_A) - collectord lost connection to room RPI0
2018.10.22 05:44:57 3: PRESENCE (GTAG_A) - collectord reconnected to room RPI0
2018.10.22 05:45:01 3: PRESENCE (GTAG_A) - collectord reconnected to room RPI2

Der GTAG ist eigentlich fast nie da, sondern nur wenn die Großeltern zu Besuch sind. Bis vor kurzem auch kein Problem und jetzt sehe ich laufend diese Meldungen im Logfile.

Kann ich was dagegen tun?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 23 Oktober 2018, 09:55:28
Beim heutigen Update hat sich noch ein Fehler eingeschlichen. Besser erst morgen FHEM updaten.


Habe seit neuestem dauernd sowas im Logfile:


Das ist aber ein Thema für das PRESENCE Modul bzw. dem dazugehörigen collectord.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: mumpitzstuff am 23 Oktober 2018, 12:42:29
Stimmt. Jetzt wo du es sagst...
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: mumpitzstuff am 23 Oktober 2018, 20:55:02
roommate macht seit neuestem auch sowas:

2018.10.23 17:16:26 2: ROOMMATE set rr_A home
2018.10.23 18:00:39 2: ROOMMATE set rr_A absent
2018.10.23 18:04:09 2: ROOMMATE set rr_B absent

Oder kommt das auch woanders her?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 24 Oktober 2018, 08:26:59
Das ist nicht neu, setter werden schon immer geloggt
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: der-Lolo am 24 Oktober 2018, 08:46:46
ja, leider... Mir wäre es auch lieber wenn diese "events" nicht im Log auftauchen würden... Ein set vorgang ist doch eine normale aktion.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 24 Oktober 2018, 08:52:19
verbose=1 ist dein Freund.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: CoolTux am 24 Oktober 2018, 08:52:32
ja, leider... Mir wäre es auch lieber wenn diese "events" nicht im Log auftauchen würden... Ein set vorgang ist doch eine normale aktion.

Ich finde sie sehr hilfreich. Und sie erscheinen wenn dann ja eh nur 3-4 mal pro Tag. Also nichts was das Log zu müllt.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: der-Lolo am 24 Oktober 2018, 10:18:57
Ich bin halt der meinung das nur etwas im Log auftauchen soll wenn was nicht planmässig läuft.
Aber das gehört hier nicht her.

Wenn ich einen Lichtschalter betätige ist das ja auch ein set -> taucht aber Gott sei Dank nicht im Log auf.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: CoolTux am 24 Oktober 2018, 10:22:05
Ich bin halt der meinung das nur etwas im Log auftauchen soll wenn was nicht planmässig läuft.
Aber das gehört hier nicht her.

Wenn ich einen Lichtschalter betätige ist das ja auch ein set -> taucht aber Gott sei Dank nicht im Log auf.

Das darf ja gerne der Entwickler selber entscheiden. Und so lange er die Möglichkeit gibt das es auch abstellbar ist, ist es ok.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: der-Lolo am 24 Oktober 2018, 10:24:43
Ach, das ist abstellbar..? Wie denn?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: CoolTux am 24 Oktober 2018, 10:33:55
verbose=1 ist dein Freund.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: mumpitzstuff am 24 Oktober 2018, 14:08:51
Naja Fehler will ich ja eigentlich sehen und soweit ich das verstanden haben sollten Fehler im Bereich von 1 - 3 gemeldet werden. 4 sind dann Meldungen die etwas mehr Informationen preisgeben und 5 ist z.b. für die Fehleranalyse, wo dann ganz viel im Logfile erscheint.
Wenn man die Meldungen da mit Level 4 loggen würde, dann kann derjenige der das sehen will auf dieses Level gehen und bei allen anderen bleibt das Logfile sauber und nur Fehler tauchen darin auf.

Und bei mir tauchen die Meldungen im Log erst seit kurzem auf. Mir ist nicht bewusst, dass ich da irgendwas geändert habe...
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: CoolTux am 24 Oktober 2018, 14:13:41
Level 3 steht für Informationen, ab Level 4 für Fehler und Debug.
Ich finde schon das die Ausgabe eine Information ist. Wer sie nicht haben will stellt auf 2 oder 1
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: der-Lolo am 24 Oktober 2018, 15:19:31
Zwei reicht nicht, hatte ich schon probiert - eins war mir auch zu sehr mit der keule...
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 24 Oktober 2018, 15:32:57
Das Loglevel ist aktuell 2.


Man mag es kaum glauben, aber die Module sind so alt, damals gab es keine (schriftlich) festgehaltenen Orientierungswerte was die Loglevel angeht. Ich habe mich an den vorhandenen Modulen orientiert (glaube war CUL_HM) und damals war es normal, dass man die Setter als Level 2 ausgegeben hat.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: der-Lolo am 24 Oktober 2018, 15:40:28
Passt schon, die Roommates und Guests stehen jetzt auf 1.
Bastelst Du eigentlich noch weiter am Homestate?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: mumpitzstuff am 24 Oktober 2018, 15:54:58
Bei mir hab ich auch alles auf Verbose 1 gesetzt.
Keine Ahnung warum mein Logfile seit neuestem mit diesen Meldungen überschwemmt wird und das früher nicht der Fall war. Wenn ich raten müsste, würde ich sagen, dass das PRESENCE Modul seit neuestem irgend was anders macht und deshalb auch diese Meldungen von den ROOMMATES bei mir im Log auftauchen (erscheinen immer direkt nach den neuen Meldungen des PRESENCE Moduls). Die Zusammenhänge sind mir hierzu leider nicht bekannt.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: TWART016 am 05 März 2019, 10:48:47
Ich habe in meiner Geofancy App den Status home und work, welcher auch korrekt an das Residence Modul übertragen wird.

Wie bekomme ich es hin, dass es ein Event gibt, wenn ich diese Zone verlasse?

Edit: Ziel ist ein Event beim Verlassen von Work
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 06 März 2019, 14:59:53
In der Geofency App gibt es zwei Slider, einen für das Event "ankommen" und einen für "verlassen". Du solltest beide einschalten und dann gibts auch beide Events in FHEM.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: TWART016 am 08 März 2019, 15:06:55
Ich habe bei beiden den Button aktiviert.

In geofancy Modul erscheint auch ein underway Event (Reading: currLoc_rr_Name). Dieses wird jedoch nicht ins das Roommate Modul übernommen.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 08 März 2019, 16:42:51
Du musst rr_geofenceUUIDs beim ROOMMATE Device setzen, wenn du den Status automatisch übernehmen willst.
Ansonsten musst du selbst mit entsprechenden Notify/DOIF Regeln arbeiten.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: klausw am 08 März 2019, 17:18:25
Hallo Julian,

ich bin dabei, für das livetracking Modul einen connector für die ROOMMATE/GUEST Module (via RESIDENTStk_SetLocation) zu bauen.

Dabei sind ein paar Fragen aufgetreten:

livetracking gibt zum einen den Abstand zur Home Position aus.
Mit diesem Abstand und zwei Attributen (homeradius uns wayhomeradius) setze ich über RESIDENTStk_SetLocation die $location abhängig von den eben genannten Werten auf
home|wayhome|underway

Je nach Einstellung kommen die Positionsdaten recht häufig. Für home und underway scheint das kein Problem zu sein.
Für wayhome schon.

Ein Wechsel von home nach wayhome funktioniert ohne Probleme
Wenn ich jetzt aber noch einmal wayhome über RESIDENTStk_SetLocation setze wird das Reading wayhome auf 1 gesetzt ($trigger ist immer 1).

Das ganze würde funktionieren, wenn ich $trigger beim wiederholten setzen von wayhome auf 0 setze. Dann geht allerdings locationPresence auf abwesend (aber ich bin ja noch in dieser location)

Habe ich einen Denkfehler drin?

Klaus
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 08 März 2019, 19:43:02
Ich kann dir da glaube ich nicht ganz folgen.


Ein direkter Wechsel von home nach wayhome macht irgendwie keinen Sinn, dazwischen wird der Logik nach immer ein "underway" erwartet.
"wayhome" ist eigentlich nur eine spezielle Unterart von "underway", bei der das _verlassen_ eines speziellen Ortes so gewertet wird, dass man sich anschließend auf dem (mehr oder weniger) direkten Weg nach Hause befindet. Dann wird das Reading "wayhome" auf 1 gesetzt, bis man durch ein "home" Event tatsächlich zuhause ankommt (egal, ob man noch Zwischenstationen macht).


So sollte sich das ganze auch aktuell mit dem GEOFANCY Modul verhalten.


Hast du mal ins Log geschaut? RESIDENTStk ist da sehr gesprächig ab verbose level 3.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: TWART016 am 08 März 2019, 22:57:18
Ich überwache 2 Smartphones. Beide sind in geofancy und Residents integriert. Ein Smartphone hat 2 Zonen, home und work. Sobald ich work oder home verlasse, wird der Status korrekterweise im geofancy Modul auf underway gesetzt. Nur ins Roommate Device wird das nicht übernommen.

Edit: rr_geofenceUUIDs habe ich gesetzt, work und home wird auch korrekt übertragen.

Ich habe das Roommate Device mal auf verbose 3 gestellt.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: kadettilac89 am 09 März 2019, 13:10:11
ich denke es geht um das verhalten von location und presence

<Aktion>            <Wert location>      <Wert presence>     <gewünschter wert eines Readings>
Home betretenhomepresencehome
Home verlassenhomeabsenceaway
Work betretenworkabsencework
Work verlassenworkabsenceaway

Ich hatte mir das Verhalten mit einem User-Readings gebaut.

https://forum.fhem.de/index.php/topic,98015.msg916438.html#msg916438

Wenn es um was anderes geht ... List der Devices und gewünschtes Verhalten dokumentieren
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: klausw am 11 März 2019, 10:06:40
Ein direkter Wechsel von home nach wayhome macht irgendwie keinen Sinn, dazwischen wird der Logik nach immer ein "underway" erwartet.
"wayhome" ist eigentlich nur eine spezielle Unterart von "underway", bei der das _verlassen_ eines speziellen Ortes so gewertet wird, dass man sich anschließend auf dem (mehr oder weniger) direkten Weg nach Hause befindet. Dann wird das Reading "wayhome" auf 1 gesetzt, bis man durch ein "home" Event tatsächlich zuhause ankommt (egal, ob man noch Zwischenstationen macht).


So sollte sich das ganze auch aktuell mit dem GEOFANCY Modul verhalten.


Hast du mal ins Log geschaut? RESIDENTStk ist da sehr gesprächig ab verbose level 3.

Prinzipiell hast du recht.
Wayhome war für mich ein Bereich, der Home in größerem Radius umschließt und bei dem das Wayhome Reading gesetzt wird, sobald man den von "außen" betritt. Also nicht mal, das es als Location angezeigt wird.
Ich hatte die logik dazu im RESIDENTStk vermutet (aufgrund dieses Satzes: "Immer wenn eine Lokation mit dem Namen 'wayhome' gesetzt wird, wird das Reading 'wayhome' auf '1' gesetzt, sofern die Anwesenheit zu diesem Zeitpunkt 'absent' ist.").
Ins Log habe ich nicht geschaut, Deine Erklärung lässt im Moment sowieso keine Fragen offen  ;)
Das kann ich aber ebenso in den connector einbauen.

Zwei Fragen habe ich noch:

Danke
Klaus






Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Jamo am 12 März 2019, 14:28:10
Hi Klaus,
für deinen ersten Punkt, probier mal das hier:
##########################################################
# Calculate distance between two geocoordinates
##########################################################
sub calcDistkm ($$$$) {
  my($latNew,$lonNew,$latOld,$lonOld) = @_;
  #Entfernung zur Home-Koordinate (Luftlinie)
  #Berechnung nach: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.kompf.de_gps_distcalc.html&d=DwICAg&c=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-_haXqY&r=fjkjtP90XwgwsFiC-zb01AeZ1ffjVVSXDnDyxQOtlCw&m=2E21LZkstx_fHrSuJ14UVHFNwuqW_c-9POHdUq-QuGI&s=h4xM_iBweT-_GlHSZVvpQiGevgDfVaUY4w0hHv_Vs3o&e=
  # Verbesserte Methode
  my $lat = ($latNew + $latOld) / 2 * 0.01745;
  my $dx = 111.3 * cos($lat) * abs($lonNew - $lonOld);
  my $dy = 111.3 * abs($latNew - $latOld);
 
  #Einfache Variante
  #my $dx =  71.5 * abs($lonNew - $lonNew);
  #my $dy = 111.3 * abs($latNew - $latOld);
 
  my $distance = sprintf("%.2f",sqrt($dx * $dx + $dy * $dy));
  return $distance;
}
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: klausw am 12 März 2019, 23:46:19
Hi inoma

für deinen ersten Punkt, probier mal das hier:

danke Dir, das kommt in meine Codesammlung

Hat aber nix mit meiner Frage zu tun  8)
Die Entfernung habe ich. Ich möchte nur den Status auf verreist (gone) setzen.
Derzeit mache ich das mit fhem "set $deviceAlias gone";Funktioniert, ist aber nicht die sauberste Lösung

Klaus
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 13 März 2019, 22:49:45
  • Ich würde gern, Abhängig von der Entfernung zu Home, den Status direkt auf verreist setzen. Also ohne Wartezeit. Ab 300km ist ein Tagesausflug nicht mehr so üblich  8)
    Gibt der RESIDENTStk das her?


Derzeit nicht. Es gibt ja aber das Reading positionDistHome und das ist genau dafür gedacht.
Von der Entfernung abhängige Aktionen sind bisher nicht geplant, dafür gibt es ja DOIF und notify, um dann beispielsweise auf ein Reading mit der Entfernung entsprechend zu reagieren. Da kannst du selbstverständlich auch von away auf gone wechseln, wenn du das willst. Das ist Teil deiner eigenen Automatisierung, nicht der von RESIDENTS.


[size=78%] [/size]
  • position.* und lastPosition.* sind klar für mich
    wann sollten die location.* Readings gesetzt werden?
    nur bei betreten oder verlassen einer location? Oder auch bei Aktualisierung innerhalb einer Location?


Der Unterschied zwischen Location und Position ergibt sich darauf, wie Geofency die Daten liefert.
Dort wird beim ankommen/verlassen einer Location zusätzlich die aktuelle Position und auch deren Adresse übermittelt. Wenn ich also beispielsweise in den Radius von "home" eintrete und damit "home" feuert, dann unterscheidet sich die tatsächliche Position von der eigentlichen Location. Position ist also immer mein tatsächlicher Aufenthaltsort und Location der gewollte Ort, an dem das Geofencing eingestellt wurde. Für einen Vergleich schlage ich vor, dass du dir Geofency einmal installierst.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: klausw am 25 März 2019, 13:16:42

Derzeit nicht. Es gibt ja aber das Reading positionDistHome und das ist genau dafür gedacht.
Von der Entfernung abhängige Aktionen sind bisher nicht geplant, dafür gibt es ja DOIF und notify, um dann beispielsweise auf ein Reading mit der Entfernung entsprechend zu reagieren. Da kannst du selbstverständlich auch von away auf gone wechseln, wenn du das willst. Das ist Teil deiner eigenen Automatisierung, nicht der von RESIDENTS.

Ok, habe es erstmal anderweitig gelöst.

Ein zu autoGoneAfter adäquates Attribut für die Entfernung wäre Grundsätzlich vielleicht doch keine Schlechte Idee


Der Unterschied zwischen Location und Position ergibt sich darauf, wie Geofency die Daten liefert.
Dort wird beim ankommen/verlassen einer Location zusätzlich die aktuelle Position und auch deren Adresse übermittelt. Wenn ich also beispielsweise in den Radius von "home" eintrete und damit "home" feuert, dann unterscheidet sich die tatsächliche Position von der eigentlichen Location. Position ist also immer mein tatsächlicher Aufenthaltsort und Location der gewollte Ort, an dem das Geofencing eingestellt wurde. Für einen Vergleich schlage ich vor, dass du dir Geofency einmal installierst.

Verstanden. Das gibt Owntracks so nicht her. Da gibt es nur die Position oder Betreten/Verlassen einer Zone als Nachricht. Demzufolge sind Location und Position identisch. Das ist meiner Meinung nach aber kein Problem.


Danke für die Infos
Klaus
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 04 Mai 2019, 13:56:26
Ich habe gerade analog zu ROOMMATE und GUEST noch einen dritten Bewohnertyp namens PET eingecheckt.
Ab morgen kann man also Haustiere wie beispielsweise einen Hund explizit als solchen führen. Dafür gibt es auch entsprechend neue Readings.


Außerdem gibt es ein neues Attribut r*_passStateTo, welches ähnlich wie r*_passPresenceTo nun den Status während man zuhause ist mit einem anderen Gerät abgleichen kann.
Das ist zum Beispiel bei einem Hund sinnvoll, der ja aller Wahrscheinlichkeit nach immer mit Herrchen und/oder Frauchen schlafen geht und aufsteht ;-)


Ich überlege noch, ob nun im RESIDENTS Modul noch neue Status sinnvoll wären, die nur dann eintreten, wenn ein Haustier allein zuhause ist. Ich denke da an ein Präfix "pet_" vor dem eigentlichen Status. Da ich aber weiß, dass es so einige Module und persönliche Automationen gibt, wollte ich vorher einmal horchen, wie dazu so die Meinung ist. Sicherlich kann man das als Attribut erst einschaltbar machen, aber selbst wenn man das tut, werden diejenigen, die das gerne möchten, vielleicht hier und dort auf Probleme stoßen. Und dafür müssten dann wahrscheinlich Module wie HOMEMODE oder AutoShuttersControl etc gewappnet sein.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: det. am 04 Mai 2019, 14:26:24
Hallo Loredo,
Für meine 2 Siamkatzen fällt mir für den neuen Bewohnertyp kein Sinn noch Nutzen ein. Aber für die Putzfrau, auch wenn das schon diskriminierend ist, sie unter PET einzugruppieren. Die Möglichkeit abhängig von deren " Alleinzuhause Status " anders zu schalten als bei ROMMATE oder GUEST macht aber schon Sinn. Das Gleiche trifft auf die Freunde (GTag) zu, die während unseres Urlaubs die Biester füttern und die Katzenklo's reinigen.
Meine Frage dazu also - könntest Du den 3ten Bewohnertyp nicht z.b. SERVICE nennen oder den Namen konfigurierbar machen?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: choenig am 04 Mai 2019, 14:28:39
Ich habe gerade analog zu ROOMMATE und GUEST noch einen dritten Bewohnertyp namens PET eingecheckt.
Ab morgen kann man also Haustiere wie beispielsweise einen Hund explizit als solchen führen. Dafür gibt es auch entsprechend neue Readings.

Finde ich ziemlich cool :)

Dann mach ich den Hundi direkt zum PET, zur Zeit ist er noch ein GUEST  8)

LG
Christian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 04 Mai 2019, 21:09:45
Ich überlege noch, ob nun im RESIDENTS Modul noch neue Status sinnvoll wären, die nur dann eintreten, wenn ein Haustier allein zuhause ist. Ich denke da an ein Präfix "pet_" vor dem eigentlichen Status. Da ich aber weiß, dass es so einige Module und persönliche Automationen gibt, wollte ich vorher einmal horchen, wie dazu so die Meinung ist. Sicherlich kann man das als Attribut erst einschaltbar machen, aber selbst wenn man das tut, werden diejenigen, die das gerne möchten, vielleicht hier und dort auf Probleme stoßen. Und dafür müssten dann wahrscheinlich Module wie HOMEMODE oder AutoShuttersControl etc gewappnet sein.

Ich habe jetzt gerade noch eine neue Version aller Module eingecheckt, die einen "Home Alone" Modus mitbringt.
Dabei werden für alle RESIDENTS Sub-Module auch subTypes eingeführt (über Attribute). Diese basieren bei ROOMMATE auf der Altersklasse ('baby', 'toddler', 'child', 'teenager', 'adult', 'senior'). Bei GUEST gibt es 'generic', 'minor', 'domesticWorker', 'vacationer'. Und bei PET kann man (eher spaßeshalber) auch angeben, um welche Art von Tier es sich handelt ('generic', 'bird',  'cat', 'dog', 'monkey', 'pig').

Aus dem subType wird dann errechnet, ob diese Person (oder das Tier) als unselbstständig angesehen wird und somit als "allein zu Hause" gilt. Dafür werden dann 3 neue Readings im RESIDENTS Device erstellt. Über ein weiteres Attribut kann man dann den RESIDENTS Gerätestatus mit einem Präfix versehen, welcher dem subType entspricht.

Bei der Ermittlung, welcher subType jetzt derjenige "in Verantwortung" ist, wird eine Reihenfolge beachtet, die über ein Attribut verändert werden kann. Die Reihenfolge ist dabei so gewählt, dass der "älteste" Mensch den Home Alone Status bestimmt (in der Annahme, dass dieser auf jüngere aufpasst, die auch anwesend sein könnten). Eine Ausnahme ist per Default der subType "senior", welcher für Erwachsene vergeben werden kann, die hilfebedürftig sind.

Der Home Alone Status ist beendet, sobald ein 'adult' zu Hause anwesend ist oder alle Bewohner außer Haus sind.


@det.: Schau doch mal, ob du mit dem subType domesticWorker jetzt weiter kommst.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: choenig am 05 Mai 2019, 10:08:50
Guten Morgen Julian,

ich habe jetzt unseren Brandy als PET statt vorher als GUEST eingerichtet und alles umgestellt und mal aufgeräumt :). Hat alles geklappt, ziemlich Cool!

Verstehe ich es richtig, dass der 'homealone'-Status dadurch ausgedrückt wird, dass homealoneType (bzw. homealoneSubtype) gesetzt werden?  (Ich habe rgr_homealoneInStatus nicht gesetzt.)

Das einzige, was mir jetzt fehlt, sind readings, die mir anzeigen, wie viele Personen anwesend sind, also ROOMMATE + GUEST  8)

Zitat

residentsTotalPresent          = ROOMMATES + PETS + GUEST
residentsTotalPeoplePresent    = ROOMMATES + GUEST
residentsTotalRoommatesPresent = ROOMMATES
residentsTotalPetsPresent      = PETS
residentsTotalGuestsPresent    = GUEST

LG und vielen Dank :)
Christian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 05 Mai 2019, 13:24:08
Ja das macht wohl Sinn - habe ich gerade eingecheckt.


Verstehe ich es richtig, dass der 'homealone'-Status dadurch ausgedrückt wird, dass homealoneType (bzw. homealoneSubtype) gesetzt werden?  (Ich habe rgr_homealoneInStatus nicht gesetzt.)


Ja, das sind die beiden Readings. Wenn sie etwas anderes als "-" enthalten, ist der homealone Status aktiv und man kann ableiten, welche "Form" von Allein Zuhause das ist. Entweder recht allgemein über Type oder etwas genauer über SubType.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: choenig am 05 Mai 2019, 19:53:09
Ja das macht wohl Sinn - habe ich gerade eingecheckt.

Ich konnte es nicht abwarten, hab' schonmal upgedated :)

So sehen meine DOIFs jetzt ein wenig aufgeräumter aus  :D

LG
Christian
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 14 Mai 2019, 19:15:06
Ich habe einige kleinere Fixes zum homealone Status eingecheckt.
Geändert hat sich dabei ein subType für GUEST: Aus "minor" (Minderjährig) wurde nun "childcare" (Kinderbetreuung).


Außerdem hat das bisher nicht vollständig veröffentlichte HOMESTATE (https://forum.fhem.de/index.php/topic,71692.0.html) Modul nun support für homealone erhalten.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: thegimliboy am 31 Mai 2019, 19:59:42
Seit einem Update heute bin ich auf dieser Version:
Zitat
20_ROOMMATE.pm 19386 2019-05-14 16:47:14Z loredo

Nach einem Neustart von FHEM wurde in der fhem.cfg alle ROOMATEs gelöscht. Das log hat diese Fehlermeldung
Zitat
Can't use an undefined value as an ARRAY reference at ./FHEM/20_ROOMMATE.pm line 29.

Auch wenn ich diese Roommates danach wieder neu anlegen will, kommt diese Fehlermeldung, und keine Roommates werden angelegt.
Kann ich noch was prüfen?
gruß
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: thegimliboy am 01 Juni 2019, 19:50:26
Nur zur Info: bin bei den drei Modulen (Residents, Roomate und Guest) wieder zurück zur Version 18995 vom 22.03.2019
Damit kann ich meine Roommates wieder herstellen.

Selbst wenn ich mit der aktuellen Version 19386 ein Roommate über Residents anlegen wollte, kam im Log diese Meldung:
Zitat
2019.06.01 17:36:03 0: Can't use an undefined value as an ARRAY reference at ./FHEM/20_ROOMMATE.pm line 29.
2019.06.01 17:36:03 3: define rr_Peter ROOMMATE rgr_myHome : Cannot load module ROOMMATE

gruß
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 01 Juni 2019, 22:36:34
Seit einem Update heute bin ich auf dieser Version:
Nach einem Neustart von FHEM wurde in der fhem.cfg alle ROOMATEs gelöscht. Das log hat diese Fehlermeldung
Auch wenn ich diese Roommates danach wieder neu anlegen will, kommt diese Fehlermeldung, und keine Roommates werden angelegt.
Kann ich noch was prüfen?


Du machst offenbar nur selektive Updates von einzelnen FHEM Dateien, das ist nicht gut.
Dir fehlt eine aktuelle Version von RESIDENTStk.pm.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: thegimliboy am 02 Juni 2019, 07:54:25
Ich hatte vorgestern ein "update all" gemacht. Da war Nichts selektiv.
OK. Beim zurückgehen auf eine ältere Version war ich selektiv vorgegangen. Mir ist kein Befehl bekannt, mit dem man das geregelt machen kann. Geht so etwas wirklich?
Für mich war erst mal wichtig, dass es wieder funktioniert.
Die Residentsk.pm war auch auf 19386. Ich habe diese Datei jetzt auch auf den älteren Stand gebracht. Die Störung wurde durch die 20_ROOMMATE.pm mit der Version 19386 verursacht. Zumindest bei mir, und ich hatte keine Idee mehr, wo ich noch schauen kann.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 02 Juni 2019, 11:17:24
Trotzdem besagt die Fehlermeldung, dass er eine Variable, die in RESIDENTStk erst neu hinzugekommen ist, nicht finden kann.
Hast du FHEM auch neu gestartet? Welche Perl Version?
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: thegimliboy am 02 Juni 2019, 17:55:07
ich kann bei dieser Fehlermeldung
Zitat
2019.06.01 17:36:03 0: Can't use an undefined value as an ARRAY reference at ./FHEM/20_ROOMMATE.pm line 29.
2019.06.01 17:36:03 3: define rr_Peter ROOMMATE rgr_myHome : Cannot load module ROOMMATE
beim besten Willen nicht herauslesen, dass er eine Variable, die in RESIDENTStk erst neu hinzugekommen ist, nicht finden kann.
Wo steht da was von RESIDENTStk.pm ?

Ich habe gerade Stunden von Recherche hinter mir, wofür die RESIDENTStk.pm überhaupt da ist. Im Wiki konnte ich nichts finden, und in diesem Thread auch nicht. Schade.
Gerne hätte ich die Ursache gefunden, aber trotz LogLevel 5 war nichts beim Starten zu finden.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 02 Juni 2019, 18:04:49
ich kann bei dieser Fehlermeldungbeim besten Willen nicht herauslesen, dass er eine Variable, die in RESIDENTStk erst neu hinzugekommen ist, nicht finden kann.
Wo steht da was von RESIDENTStk.pm ?

Dort steht eine Codezeile und in dieser Codezeile wird auf eine Variable verwiesen, die aus RESIDENTStk exportiert wird. Das weiß ich als Modulautor natürlich und kann es dir deshalb sagen.
RESIDENTStk beinhaltet den eigentlichen Code der Module RESIDENTS, ROOMMATE, PET und GUEST (kann dir im übrigen auch der FHEM Installer (https://forum.fhem.de/index.php/topic,98381.0.html) sagen). Das muss man aber gar nicht wissen, wenn man immer brav alle Dateien gemeinsam aktualisiert. Du schreibst zwar, dass das bei dir der Fall wäre, jedoch kann ich dann eben nicht erklären wie es zu dem Fehler bei dir kommt, da ich ihn absolut nicht nachstellen kann.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: blade-of-fire am 18 Juli 2019, 19:05:38
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
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 19 Juli 2019, 09:02:59
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.

Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Nestor am 30 Juli 2019, 11:05:59
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 30 Juli 2019, 12:26:28
I will, probably not today.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Nestor am 30 Juli 2019, 14:13:51
%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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: mumpitzstuff am 30 Juli 2019, 16:05:23
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Nestor am 30 Juli 2019, 16:23:27
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.
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Loredo am 30 Juli 2019, 17:02:33
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).
Titel: Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
Beitrag von: Nestor am 30 Juli 2019, 19:17:38
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)