Autor Thema: Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST  (Gelesen 160545 mal)

Offline trinitywhm

  • Full Member
  • ***
  • Beiträge: 142
Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
« Antwort #675 am: 16 September 2019, 16:39:48 »
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.

Offline flummy1978

  • Full Member
  • ***
  • Beiträge: 389
Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
« Antwort #676 am: 16 September 2019, 16:44:32 »
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

Offline kadettilac89

  • Hero Member
  • *****
  • Beiträge: 1139
Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
« Antwort #677 am: 16 September 2019, 18:22:39 »
- 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

Offline flummy1978

  • Full Member
  • ***
  • Beiträge: 389
Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
« Antwort #678 am: 16 September 2019, 18:35:39 »
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

Offline persching

  • Full Member
  • ***
  • Beiträge: 202
Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
« Antwort #679 am: 23 Oktober 2019, 17:55:42 »
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???

Offline moskito

  • Full Member
  • ***
  • Beiträge: 134
  • No RISC - no fun
Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
« Antwort #680 am: 23 Oktober 2019, 20:24:25 »
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
FHEM auf Shuttle DX30 (Debian 10) + HM-CFG-USB + deconz/Conbee + Zwave

Offline persching

  • Full Member
  • ***
  • Beiträge: 202
Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
« Antwort #681 am: 23 Oktober 2019, 20:42:09 »
Achso dann hab ich das total falsch verstanden. Danke für Hilfe.

Offline johndoe

  • New Member
  • *
  • Beiträge: 22
Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
« Antwort #682 am: 10 Januar 2020, 20:29:21 »
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.

Offline flummy1978

  • Full Member
  • ***
  • Beiträge: 389
Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
« Antwort #683 am: 10 Januar 2020, 20:44:00 »
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  ;D

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

Offline johndoe

  • New Member
  • *
  • Beiträge: 22
Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
« Antwort #684 am: 10 Januar 2020, 21:00:41 »
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  ;D

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! :)

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3753
  • ~ Challenging Innovation ~
Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
« Antwort #685 am: 10 Januar 2020, 22:38:58 »
Bitte auch nicht Events mit Logeinträgen gleichsetzen, das sind zwei unterschiedliche Paar Schuhe.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Offline flummy1978

  • Full Member
  • ***
  • Beiträge: 389
Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
« Antwort #686 am: 11 Januar 2020, 01:31:34 »
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

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3753
  • ~ Challenging Innovation ~
Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
« Antwort #687 am: 11 Januar 2020, 11:47:51 »
(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.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Offline flummy1978

  • Full Member
  • ***
  • Beiträge: 389
Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
« Antwort #688 am: 11 Januar 2020, 12:26:52 »
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

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3753
  • ~ Challenging Innovation ~
Antw:Modulfamilie für Bewohner / 10_RESIDENTS 20_ROOMMATE 20_GUEST
« Antwort #689 am: 11 Januar 2020, 13:59:15 »
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 ;-)
« Letzte Änderung: 11 Januar 2020, 14:00:55 von Loredo »
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER