Homestatus als Modul?

[pjakobs]

Moin zusammen,

ich versuche gerade mal mein Regelwerk für Anwesenheit ein bisschen aufzuräumen, und frage mich: muss das so komplex sein?
Ich verwende presence "Devices" für ... na ja, mich und alle anderen Personen
Ich verwende das Homestatus Widget im TabletUI - hinterlegt mit einem Dummy
Und ich verwende ein Konvolut von DoIfs und Notifies um Licht, elektrische Verbraucher, Heizung und allerhand anderes entsprechend des Homestatus zu schalten.

Insgesamt ist das nur bedingt toll und sicher eleganter lösbar.

Mein erster Kritikpunkt am aktuellen Modell: woher weiß ich eigentlich, wann niemand mehr zuhause ist? Sprich: wann setze ich den "Homestatus" auf "away"?
Klar, wenn alle gegangen sind, aber - das muss ich irgendwo zählen.
Ich möchte zudem die Zustände "der letzte hat das Haus verlassen" und "es ist wieder jemand zurück gekommen" als Trigger verwenden

Meine Idee:
Warum nicht ein Modul schreiben, dass selbst den Homestatus implementiert?
Die erste Idee war: das Modul kann als Readings Listen der Bewohner und evtl auch Listen von Gästen beinhalten. Diese würden jeweils mit einem presence device korelieren.
Im einfachsten Fall gibt es für jede Person dann ein notify, dass den Status der Person an das Homestatus Device überträgt. Dieses kann dann in der Liste nachsehen und weiß dann, ob und wie viele der Bewohner gerade daheim sind, bzw. ob Gäste da sind.
Möglicherweise wäre es sogar machbar, dass das Homestatus Device direkt die presence Devices steuert (ähnlich wie ein zweistufiges Modul ggf) und so die ganze Logik kapselt.

hat sich zu dem Thema schonmal wer Gedanken gemacht?

Grüße

pj

[CoolTux]

Residents und Roommates aus der Residentsfamilie.

[marvin78]

Es gibt so ein Modul bzw. eine Modulfamilie. RESIDENTS, ROOMMATE, GUEST...

Ich frage mich immer, warum man nicht erst einmal schaut, ob es sowas schon gibt!?

[pjakobs]

Es gibt so ein Modul bzw. eine Modulfamilie. RESIDENTS, ROOMMATE, GUEST...

Ich frage mich immer, warum man nicht erst einmal schaut, ob es sowas schon gibt!?

oh geschaut hab ich, nur gefunden nicht. Da gibt es einen Unterschied.

[Loredo]

Ich habe Pläne für ein HOMESTATE Modul passend zu den RESIDENTS Modulen und wollte damit auch in den letzten Tagen schon beginnen. Aktuell hänge ich aber noch an der Units/RTypes Implementierung.

[pjakobs]

Ich habe Pläne für ein HOMESTATE Modul passend zu den RESIDENTS Modulen und wollte damit auch in den letzten Tagen schon beginnen. Aktuell hänge ich aber noch an der Units/RTypes Implementierung.

Ich hab mir RESIDENTS gerade mal angesehen, auf die Schnelle scheinbar 70% dessen, was ich mir vorstelle.
Nachteile:
Keine direkte Einbindung der PRESENCE Objekte (oder hab ich da was übersehen?) -> ich brauche immer noch ein NOTIFY von PRESENCE nach ROOMMATE / GUEST
Es fehlt aus meiner Sicht der Zustand "Haus war leer"->"jemand kommt nach Hause" und "jemand war zu Hause -> Haus ist leer". Wenn ich die mit RESIDENTS nachbilden will, brauche ich wieder NOTIFYs von den einzelnen "Personen".
(Anmerkung: ich mag mich hier irren. Kommt vor)

Klar sind die durch den Zustandsübergang "away->home" und "home->away" gekennzeichnet, aber ein Notify auf einen spezifischen Zustand fänd ich sehr viel eleganter. Ich schalte z.B. die Treppenhausbeleuchtung anhand der PRESENCE Detection ein, wenn TWILIGHT unter 30% liegt oder so. Das soll natürlich nur beim Übergang geschehen, nicht, wenn ich daheim sitze.

Zudem, aber da bin ich mir nicht so ganz sicher, was wirklich "richtig" wäre, sind die Zustände von RESIDENTS nicht mit denen von HOMESTATUS gleich. Homestatus kennt den Zustand "guest", der als solcher ja eigentlich unsinnig ist.
Dass ein Gast im Haus ist ist eine Erweiterung des Zustandes, dass überhaupt jemand im Haus ist, also müsste eigentlich "home" und "guest" gleichzeitig aktiv sein können. RESITENTS liefert ein Reading "TotalGuests", in dem die Anzahl der Anwesenden Gäste steht - ich muss mal sehen, wie sich das in HOMESTATUS umsetzen lässt.

pj

[Loredo]

Keine direkte Einbindung der PRESENCE Objekte (oder hab ich da was übersehen?) -> ich brauche immer noch ein NOTIFY von PRESENCE nach ROOMMATE / GUEST

Wenn man mit PRESENCE statt GEOFANCY arbeiten will, ja. Der Autor von PRESENCE hatte bisher kein Interesse einer direkten Anbindung nach dem Vorbild von GEOFANCY.

Es fehlt aus meiner Sicht der Zustand "Haus war leer"->"jemand kommt nach Hause"

Siehe Readings (und entsprechende Trigger): lastActivity, lastActivityBy, lastActivityByDev, lastArrival, lastDurAbsence, lastDurAbsence_cr, residentsHome, residentsHomeDevs, residentsHomeNames, residentsTotal*Present* (uva.)

und "jemand war zu Hause -> Haus ist leer"

Siehe Readings (und entsprechende Trigger): lastActivity, lastActivityBy, lastActivityByDev, lastDeparture, lastDurPresence, lastDurPresence_cr, residentsAbsent, residentsAbsentDevs, residentsAbsentNames, residentsTotal*Absent* (uva.)

Wenn ich die mit RESIDENTS nachbilden will, brauche ich wieder NOTIFYs von den einzelnen "Personen".
(Anmerkung: ich mag mich hier irren. Kommt vor)

Du irrst. RESIDENTS ist genau das was du willst und fasst für dich alle Status von ROOMMATE Devices zu einer logischen Einheit zusammen und berechnet die entsprechenden Readings und stellt die dazu passenden Events bereit.
Du kannst also ganz bequem und zentral deine DOIF, Notify oder was auch immer auf die RESIDENTS Events auslegen (Beispiele gibt es viele im Forum, z.B. https://forum.fhem.de/index.php/topic,58413.msg498344.html#msg498344)
Was du mit den bereitgestellten Readings anfängst, musst du dir selbst überlegen. Es fehlt eigentlich kein Zustand, man kann alles irgendwie damit abfangen.

Zudem, aber da bin ich mir nicht so ganz sicher, was wirklich "richtig" wäre, sind die Zustände von RESIDENTS nicht mit denen von HOMESTATUS gleich. Homestatus kennt den Zustand "guest", der als solcher ja eigentlich unsinnig ist.
Dass ein Gast im Haus ist ist eine Erweiterung des Zustandes, dass überhaupt jemand im Haus ist, also müsste eigentlich "home" und "guest" gleichzeitig aktiv sein können. RESITENTS liefert ein Reading "TotalGuests", in dem die Anzahl der Anwesenden Gäste steht - ich muss mal sehen, wie sich das in HOMESTATUS umsetzen lässt.

Ich habe keine Ahnung, was du mit HOMESTATUS meinst. Mein geplantes Modul HOMESTATE gibts es noch nicht für die Öffentlichkeit. Ich kann nur nochmals dafür werben, die Wörter HOMESTATUS/HOMESTATE nicht mit der Anwesenheit von Personen zu verwechseln. Einen HOMESTATUS "guest" oder andere Status dieser Art zu haben ist eine Dopplung von RESIDENTS, die ich empfehle zu vermeiden. Mein HOMESTATE Modul setzt entsprechend sinnvoll auf RESIDENTS auf und es wird dort tatsächlich um das gehen, was der Name vermuten lässt: Den Status des Hauses im Sinne eines Betriebszustandes.


Mehr als eine Empfehlung auszusprechen kann ich halt nicht tun.

[schka17]

Wenn man mit PRESENCE statt GEOFANCY arbeiten will, ja. Der Autor von PRESENCE hatte bisher kein Interesse einer direkten Anbindung nach dem Vorbild von GEOFANCY.



Siehe Readings (und entsprechende Trigger): lastActivity, lastActivityBy, lastActivityByDev, lastArrival, lastDurAbsence, lastDurAbsence_cr, residentsHome, residentsHomeDevs, residentsHomeNames, residentsTotal*Present* (uva.)



Siehe Readings (und entsprechende Trigger): lastActivity, lastActivityBy, lastActivityByDev, lastDeparture, lastDurPresence, lastDurPresence_cr, residentsAbsent, residentsAbsentDevs, residentsAbsentNames, residentsTotal*Absent* (uva.)



Du irrst. RESIDENTS ist genau das was du willst und fasst für dich alle Status von ROOMMATE Devices zu einer logischen Einheit zusammen und berechnet die entsprechenden Readings und stellt die dazu passenden Events bereit.
Du kannst also ganz bequem und zentral deine DOIF, Notify oder was auch immer auf die RESIDENTS Events auslegen (Beispiele gibt es viele im Forum, z.B. https://forum.fhem.de/index.php/topic,58413.msg498344.html#msg498344)
Was du mit den bereitgestellten Readings anfängst, musst du dir selbst überlegen. Es fehlt eigentlich kein Zustand, man kann alles irgendwie damit abfangen.



Ich habe keine Ahnung, was du mit HOMESTATUS meinst. Mein geplantes Modul HOMESTATE gibts es noch nicht für die Öffentlichkeit. Ich kann nur nochmals dafür werben, die Wörter HOMESTATUS/HOMESTATE nicht mit der Anwesenheit von Personen zu verwechseln. Einen HOMESTATUS "guest" oder andere Status dieser Art zu haben ist eine Dopplung von RESIDENTS, die ich empfehle zu vermeiden. Mein HOMESTATE Modul setzt entsprechend sinnvoll auf RESIDENTS auf und es wird dort tatsächlich um das gehen, was der Name vermuten lässt: Den Status des Hauses im Sinne eines Betriebszustandes.


Mehr als eine Empfehlung auszusprechen kann ich halt nicht tun.

Hallo Loredo,

Das klingt interessant, habe zwar noch nicht genau mitbekommen was dein Ziel ist, aber vielleicht geht es in die Richtung die ich mir auch überlege, also z.b. Urlaub abwesend, Urlaub zuhause, auf Dienstreise usw. In diese Richtung möchte ich weitertun da die "ei fache" Presence von Personen diese möglichen Betriebszustände nicht abdeckt.


Sent from my iPad using Tapatalk

[Loredo]

Urlaub zuhause (?), Urlaub abwesend etc. wird es eher nicht sein, denn diese Status sind mit RESIDENTS bereits abgedeckt (Urlaub = gone aka extended away). Dienstreise das gleiche (warum sollte sich eine längere Abwesenheit von der anderen unterscheiden müssen?).
Die Status werden sich eher an der Tageszeit orientieren und dann mit dem Anwesenheitsstatus kumuliert werden..

[Prof. Dr. Peter Henning]

Ich habe bereits einen Zustandsautomaten für mein Haus, den ich sowohl mit PRESENCE als auch mit Alarm und GEOFANCY steuere. Ein Modul dafür ist in Planung.

Dieser Zustandsautomat ist hinreichend allgemein, um damit sowohl physikalische Devices (Heizung, Licht) als auch Helper (Alarm, Lichtszenarien) anzusteuern.

LG

pah

[schka17]

Urlaub zuhause (?), Urlaub abwesend etc. wird es eher nicht sein, denn diese Status sind mit RESIDENTS bereits abgedeckt (Urlaub = gone aka extended away). Dienstreise das gleiche (warum sollte sich eine längere Abwesenheit von der anderen unterscheiden müssen?).
Die Status werden sich eher an der Tageszeit orientieren und dann mit dem Anwesenheitsstatus kumuliert werden..

Nun das sind bei mir wesentliche Unterschiede, zuhause kann auch bedeuten zuhause arbeiten, und das ist etwas anderes als Feiertag oder Urlaub zuhause. Bei einer Abwesenheit von 1-3 Tagen macht eine grössere Absenkung der FBH null Sinn, bei Drei Wochen aber schon. Abwesenheitssimulation und Notfall Benachrichtigungen, Usw, aber ganz offensichtlich hat da jeder seine eigenen Vorstellungen, und mit FHEM kann ich mir das ja auch alles bauen.


Sent from my iPad using Tapatalk

[Prof. Dr. Peter Henning]

Darum macht ja ein Modul Sinn, bei dem man die Szenarien flexibel konfigurieren kann. So wie bei dem Alarm-Modul.

LG

pah

[Loredo]

Also ihr sprecht beide davon Szenarien zu definieren, die ihr dann "nur" gerne so nennen möchtet, wie euer Lebensumstand in einer bestimmten Situation ist. Also im Grunde das, was man mit DOIF oder Structure auch bereits machen kann. Auf eine Alternative zu Structure wäre ich da auch sehr gespannt, denn bisher ist es deutlich zu starr und kann z.B. keine Messages berücksichtigen.


Bei mir gehört das geplante HOMESTATE Modul jedoch zu den weiteren Eingangsgrößen um zu entscheiden, welche Szene überhaupt gesetzt wird (also neben der Anwesenheit aus RESIDENTS noch Morgen, Vormittag, Mittag, Nachmittag, Abend, Nacht oder Frühling, Sommer, Herbst, Winter oder Normalzeit, Sommerzeit oder Karnevalszeit, Valentinstag, Faschingstag, Fastenzeit, Osterzeit, Tanz in den Mai, Pfingsten, Oktoberfestzeit, Erntedankzeit, Halloweenzeit, St-Martins-Tag, Adventszeit, Neujahr oder Beschattung ja/nein oder Lichtsteuerung ja/nein - etc. pp). Diese Eingangsgrößen müssen natürlich entsprechend berechnet sein und automatisch wechseln, vor allem was den definierten Tageszeitraum angeht. Dass aus alledem dann wieder ein einzelner Gesamtzustand herausfällt, ist erklärtes Ziel und würde sich dann eben an eine Structure, ein DOIF oder an einen Automaten xyz ankoppeln.


Das Alarm Modul konnte ich für mich leider nie brauchbar in Einsatz bringen, ich glaube es lag dabei auch vor allem an der Messages Integration, die ich über DOIF besser hinbekam. Dieses Konstrukt ist allerdings seit den ganzen DOIF Änderungen/Neuerungen auch zu überarbeiten, weil vieles inzwischen "spontan" nicht mehr so funktioniert, wie es einmal gedacht war. Das ist auch eines der Gründe einige der Zustandsberechnungen in ein eigenes HOMESTATE Modul zu gießen, damit ich hier wieder Verlässlichkeit hereinbekomme.

[pjakobs]

na  da hab ich ja was losgetreten
Ich denke aber, die Diskussion zeigt: es gibt Bedarf für ein "besser definiertes" System, wobei "besser definiert" offenbar nicht für alle das gleiche bedeutet
Mir geht es primär darum, mit weniger DOIFs auszukommen, vor allem mit weniger DOIFs, die mehrere Eingangsgrößen auswerten müssen. und stattdessen einen Zustandsautomaten wie oben beschrieben zu haben. Wenn ich dem einmal Zustände und Trigger vorgebe, dann muss ich ihm die Trigger nur noch per NOTIFY schicken. Damit wären Bedingugnen und IF Abfragen in DOIFs und NOTIFY weitgehend eliminiert.
(und ich lerne gerne dazu, wenn es an anderer Stelle schon entsprechende Ansätze gibt, vielleicht habe ich in RESIDENTS ja auch noch was übersehen.

Um nochmal auf die Nomenklatur zurückzukommen: in meinem Eingangsposting habe ich auf das HOMESTATUS Widget aus dem TableUI verwiesen, da es im fhem Umfeld kein anderes für mich erkennbares (sprich öffentliches) Modul gibt, dass diesen Namen trägt ist das der Ausgangspunkt, den ich beschrieben habe.

Die Beschreibung für einen erweiterten "Hauszustand" finde ich erstmal prima ung bin gespannt, was da noch kommt.

Grüße

pj

[CoolTux]

Vielleicht kommst ja damit besser klar

https://forum.fhem.de/index.php?topic=51796.0