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

[matzel]

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

[Loredo]

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.

[matzel]

Oh je!!!
DANKE!!!

Hab das völlig überlesen - sorry ;P

[geek]

Hallo Loredo,

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

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.
• die residents* readings von RESIDENTS erzeugen keine events - die kann man also auch nicht per notify oder userReadings abfrühstücken
• anders herum nerven die dur* events der ROOMMATES - besonders weil man mit event-on-$something nicht einfach nur "dur.*" verbieten kann (oder doch???)
• damit sich ROOMMATES + RESIDENTS gleich behandeln lassen können wäre cool, wenn auch RESIDENTS ein "wayhome" reading hätten das auch events erzeugt.

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

danke
Rainer

[Loredo]

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

[geek]

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.

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

[Loredo]

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.

[volschin]

Hallo zusammen,
ich habe bisher bereits ROOMMATE genutzt und wollte jetzt auch RESIDENTS nutzen. Ich bekomme es allerdings nicht hin.
Ich habe Residents mit

Code Auswählen Erweitern

define rgr_Residents RESIDENTS
angelegt.
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

[Loredo]

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

Code Auswählen Erweitern


define rr_Veit ROOMMATE



wird dann also z.B.

Code Auswählen Erweitern


define rr_Veit ROOMMATE rgr_Residents





Alternativ: ROOMMATE Device einfach löschen und mit gleichem Namen wieder anlegen

[volschin]

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.

[Loredo]

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

[der-Lolo]

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?

[marvin78]

Wenn du Gäste definiert hast, dann kannst du doch einfach auf die guest-Devices triggern. Sowas wie:

Code Auswählen Erweitern

define guestWlan notify GASTDEVICEREGEX:.home {schalteGastWlanan()}

[der-Lolo]

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.

[Loredo]

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.