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

[trinitywhm]

Hallo,

bzgl. des vermeintlichen Bug solltest du das Attribut rr_realname nicht auf group sondern auf alias stellen. Dann funktioniert es denke ich wie du möchtest. Somit wird der reale Name nicht aus der Gruppe sondern aus dem Attribut Alias genommen.

[flummy1978]

Hai trinitywhm,

danke für den schnellen Hinweis: Der Sinn dahinter ist mir jetzt nicht so ganz klar, aber so funktioniert es natürlich richtig

Grüße
Andreas

[kadettilac89]

- Gibt es eine Möglichkeit die Zeitspanne der An(ab)wesenheit etwas anzupassen ? Also zB 1-10 Min => jede Minute, 5-90 Min => alle 5 Min, danach alle => 30 Min (um das Ganze etwas übersichtlicher zu gestalten und auch ein mögliches Eventgespamme ein wenig zu verringern ? )

Events reduzieren ... event-on-change-reading
wenn du die Timer-Werte nicht brauchst Attribut rr_noDuration 1

[flummy1978]

Danke auch dir für die schnelle Antwort kadettilac89,

Events reduzieren ... event-on-change-reading
wenn du die Timer-Werte nicht brauchst Attribut rr_noDuration 1

Mir ging es in erster Linie um eine Moduleigene Möglichkeit, die allgemeinen kenne ich natürlich:

event-on-change-reading würde hier nichts ändern (das Event ändert sich ja immer). Außerdem wäre es hier nicht wie gewünscht statisch bei entsprechend langer / kurzer Abwesenheit die Abfrage zu erhöhen / verringern.

No duration habe ich bereits entdeckt, wäre jetzt für mich nicht so die optimale Lösung, weil es ja dadurch viele Möglichkeiten gibt

Grüße
Andreas

[persching]

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.

Also entweder hab ich Tomaten auf den Augen, oder ich blick gerade überhaupt nicht durch:
Wo finde ich die Einstellung des Alters eines ROOMMATES, so dass sich der SubType von 'adult' auf 'child' ändert???

[moskito]

Eine altersabhängige Einstufung wäre sicherlich wünschenswert, aber für die einen beginnen Teenager ab 12 und für die anderen ab 14.
Du kannst zur Zeit im Residents/Roommate-Device deiner Person das Attribut "subType" mit den passenden Einstellungen definieren.

Gruß
Danny

[persching]

Achso dann hab ich das total falsch verstanden. Danke für Hilfe.

[johndoe]

Danke auch dir für die schnelle Antwort kadettilac89,

Mir ging es in erster Linie um eine Moduleigene Möglichkeit, die allgemeinen kenne ich natürlich:

event-on-change-reading würde hier nichts ändern (das Event ändert sich ja immer). Außerdem wäre es hier nicht wie gewünscht statisch bei entsprechend langer / kurzer Abwesenheit die Abfrage zu erhöhen / verringern.

No duration habe ich bereits entdeckt, wäre jetzt für mich nicht so die optimale Lösung, weil es ja dadurch viele Möglichkeiten gibt

Grüße
Andreas

Ich fände das auch gut, alle 60 Sekunden Log-Einträge für drei Residents sind für mich relativ überflüssig.
Wenn ich das richtig verstehe, kann man aber nur entweder ganz darauf verzichten oder es so lassen? Nicht einmal abhängig von der Dauer, aber generell sagen zu können, dass presence auch auf 15 min. genau und damit Log-Einträge nur alle 15 Minuten benötigt werden, wäre auch schon prima.

[flummy1978]

Aloha,

wie passend, dass ich gerade hier eh am surfen und basteln bin, somit auch Zeit hab zu antworten 

Wenn ich das richtig verstehe, kann man aber nur entweder ganz darauf verzichten oder es so lassen? Nicht einmal abhängig von der Dauer, aber generell sagen zu können, dass presence auch auf 15 min. genau und damit Log-Einträge nur alle 15 Minuten benötigt werden, wäre auch schon prima.

Genau das kannst Du aber mit der Beschränkung machen. Ich habe es jetzt so gelöst:

Residents Device:
event-on-change-reading  durTimerPresence.*:150,.*
event-on-update-reading  presence

Residents:
event-on-change-reading lastDeparture,lastArrival,lastState,lastLocation,presence,state,location

Geloggt wird bei mir nur noch gezielt, weil ich die Sachen ja doch nicht anschaue, die sich da ewig sammeln. Ich möchte nicht zwingend mitloggen wann meine Frau genau wie lange warum zu Hause war oder eben nicht 

Aber mit eingem Beispiel wie oben bei durTimerPresence.*:150,.* kannst Du es dennoch ja selbst beschränken, wann welche Wertänderungen ein Event auslösen sollen (hier ist es ja so beschränkt, dass es erst ein Event gibt, wenn der Wert von durTimerPresence sich um 150 geändert hat.

Hoffe geholfen zu haben.

Grüße
Andreas

[johndoe]

Aloha,

wie passend, dass ich gerade hier eh am surfen und basteln bin, somit auch Zeit hab zu antworten 

Genau das kannst Du aber mit der Beschränkung machen. Ich habe es jetzt so gelöst:

Residents Device:
event-on-change-reading  durTimerPresence.*:150,.*
event-on-update-reading  presence

Residents:
event-on-change-reading lastDeparture,lastArrival,lastState,lastLocation,presence,state,location

Geloggt wird bei mir nur noch gezielt, weil ich die Sachen ja doch nicht anschaue, die sich da ewig sammeln. Ich möchte nicht zwingend mitloggen wann meine Frau genau wie lange warum zu Hause war oder eben nicht 

Aber mit eingem Beispiel wie oben bei durTimerPresence.*:150,.* kannst Du es dennoch ja selbst beschränken, wann welche Wertänderungen ein Event auslösen sollen (hier ist es ja so beschränkt, dass es erst ein Event gibt, wenn der Wert von durTimerPresence sich um 150 geändert hat.

Hoffe geholfen zu haben.

Grüße
Andreas

Cool, danke, funktioniert!

[Loredo]

Bitte auch nicht Events mit Logeinträgen gleichsetzen, das sind zwei unterschiedliche Paar Schuhe.

[flummy1978]

Absolut OT aber

Bitte auch nicht Events mit Logeinträgen gleichsetzen, das sind zwei unterschiedliche Paar Schuhe.

Ich kann da nur aus meiner vollkommenen Anfängerzeit (Auch wenn ich mich jetzt maximal als Durchschnitt mit ein wenig Perl Erfahrung bezeichnen würde) sprechen:

(Fast) jedes Gerät (oder zumindest sehr viele von den, die ich bisher erstellt habe) erzeugen bei der Erstellung ein Log Device. Dieses wird am Anfang erstmal stehen gelassen (weil könnte man ja gebrauchen)... irgendwann stellt man fest, man hat viel zu viele und verbindet diese mit Fhem .... irgendwann hat man die Kinderkrankheiten im Griff, so dass man das Meiste davon nicht mehr braucht und dennoch sind die Logs noch da. Und eben um DIESE Logs zu sparen, versucht man (so ging es mir zumindest) auf die Masse an Event zu unterbinden die man persönlich nicht benötigt.

Ich für meinen Teil mache das jetzt so, dass ich alle Tage (oder wenn ich wenig gebastelt habe Wochen) für 1-3 Tage ein .* Log erstelle und kontrolliere damit ob ich irgendwo Events hab, die vollkommen unnötig sind, diese aber aktiv sind. So kann ich den Teil dann den letzten Teil, den ich vielleicht übersehen hab dann ausmerzen.... Bisher fahre ich damit ganz gut

Grüße
Andreas

[Loredo]

(Fast) jedes Gerät (oder zumindest sehr viele von den, die ich bisher erstellt habe) erzeugen bei der Erstellung ein Log Device.

Ich kenne da ehrlich gesagt kein einziges Modul, was das tut.

[flummy1978]

Ich kenne da ehrlich gesagt kein einziges Modul, was das tut.

Ähem... wenn ein MQTT oder Homematic Gerät erstelle wird doch immer ein FileLog erstellt?  (oder reden wir da grad an einander vorbei?)

Grüße
Andreas

[Loredo]

Mag sein, nutze ich beides nicht. Eigentlich gilt es als verpönt Geräte automatisch anzulegen, die für den Betrieb nicht zwingend erforderlich sind. ¯\_(ツ)_/¯
Ist aber Sache des jeweiligen Modulautors. Ich würde alle Geräte, die mir automatisch angelegt werden, mit denen ich aber nix anfangen kann, direkt wieder löschen. Welche Events auch als Daten geloggt werden sollen, ist eben eine explizite Entscheidung (und damit auch Konfiguration), wie ihr ja gerade auch selbst festgestellt habt