Test Adapter Residents (Bewohner) v0.1.x Latest (Beta)

[Loredo]

@da_woody sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

über den ping-adapter weis ich ob wer von uns zu hause ist.

Das genügt mir persönlich eben nicht. Allein schon, weil ich bei einem Ping-Fehler nicht so leicht manuell eingreifen kann und dafür wieder mit Blockly-Scripten und eigenen Datenpunkten was zwischenpuffern muss. Auch ist es schwierig, wenn man mehrere/unterschiedliche Anwesenheitstrigger benutzen will oder gar eine Kombination aus mehreren.
Genau das mache ich lieber mit meinem Residents Adapter. Das Funktionsprinzip dahinter habe ich schon seit 10 Jahren erfolgreich im Einsatz (damals habe ich das gleichnamige Residents Modul für FHEM dafür entwickelt).

Ich möchte zum Beispiel auch dynamisch Gäste in die Anwesenheit hinzufügen und entfernen. Ich möchte gerne wissen, ob jemand nur kurz abwesend ist und heute noch zurückkehrt oder ob derjenige länger als 1 Tag abwesend ist, um beispielsweise die Heizung noch weiter herunterzuregeln. Ich möchte wissen, wenn sich jemand auf dem Heimweg befindet und ggf. schonmal Vorbereitungen für die Ankunft treffen (z.B. Heizung früher hochregeln). Ich möchte wissen, an wen ich Benachrichtungen schicken kann. Ich möchte die Person namentlich begrüßen können, die zuletzt nach Hause gekommen ist. Ich möchte die Anwesenheit in Apple Homekit sehen und steuern. Die Liste ist lang – sehr lang.

Dafür brauche ich jede Menge Informationen, die mir der einfache Ping-Adapter nicht liefert. Wohl aber brauche ich (in deinem Fall) den Ping Adapter als Eingangsgröße für die Events. Aber die Logik-Verarbeitung für den tatsächlichen Anwesenheitsstatus überlasse ich lieber meiner ausgeklügelten Logik dazu. Das zu generalisieren, anstatt es in duzenden Blockly-Scripts zu pflegen, macht mir Spaß und es gibt mir gleichzeitig die Möglichkeit, die Logik mit weniger Aufwand auf mehreren Systemen zu pflegen und synchron zu halten (ich besitze mehrere Anwesen und Ferienhäuser, auch mit Pferdestall natürlich, aber auch Hühner).

Falls jemand ähnliche Anforderungen hat oder einen Mehrwert darin erkennt, die Anwesenheitssteuerung speziell auszulagern und zu zentralisieren, dann kann er meinen Residents Adapter auch dafür benutzen. Aber niemand MUSS ihn benutzen, denke aber das ist klar

[da_Woody]

@loredo sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

(ich besitze mehrere Anwesen und Ferienhäuser, auch mit Pferdestall natürlich, aber auch Hühner).

WOW! allerdings hast du noch nicht gesagt, wie du die anwesenheit und sonstige bewegungen prüfst.
müssen sich deine gäste in das WLAN einklinken, gezwungerner maßen? kann nicht funzen, wenn sie noch nicht anwesend sind.
ich find deinen ansatz sehr spannend, allerdings hätte ich ein problem damit. ich würd mich nicht rund um die uhr verfolgen lassen.

auch mit Pferdestall natürlich

warum betonst du das so?
triggert mich und mein weib. wir sind beide reiter. gnä frau eher englisch, meiner einer der typische westernreiter...

[Loredo]

@da_woody sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

warum betonst du das so?
triggert mich und mein weib. wir sind beide reiter. gnä frau eher englisch, meiner einer der typische westernreiter...

Nun, vielleicht einfach, weil mich dein passiv-agressiver Ton gekoppelt mit der Betonung deines Reitstalls dazu inspiriert hat... wäre eine Möglichkeit. Da bist du ja nun fast selbst drauf gekommen

@da_woody sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

allerdings hast du noch nicht gesagt, wie du die anwesenheit und sonstige bewegungen prüfst.

Doch, habe ich teilweise. Allerdings ist das hier auch kein Thread, in dem es um Automatisierungen für das Zuhause geht, sondern über den Betatest meines Moduls. Nur bedingt geht es darum, was man damit alles machen könnte, vor allem aber nicht um das wie, das ist hier Off-Topic. Dafür kann man aber natürlich ein neues Thema eröffnen und mich dort @-mention, damit ich davon Wind bekomme (sofern die Erwartung wäre, dass ich auch darauf antworten soll und nicht nur andere).

Die Anwesenheit wird bei mir über Geofency automatisch gesetzt, was ich für hinreichend genau halte. Es wird auch bei Abwesenheit aller nicht eine Sekunde später alles ausgeschaltet, sondern etwas gewartet. Eingeschaltet wird erst wieder das Nötigste, wenn der erste die Haustür öffnet (über den Kontakt dort getriggert). Passiert das, ohne dass zuvor eine Anwesenheit getriggert wurde, wird zeitverzögert die Alarmanlage ausgelöst.

Wie du darauf kommst, dass ich Bewegungen nachverfolge, verstehe ich nicht. Aktivitäten bei Anwesenheit setze ich manuell. Entweder per Sprachbefehl oder eben durch eine routinierte Abfolge von Dingen, die ich tue. Wenns z.B. Zeit fürs Bett ist, sage ich "es ist Schlafenszeit". Dann wird für meinen Benutzer der Status auf Bedtime gesetzt und für mich werden meine Stationen bis ins Bett entsprechend eingestellt. Wenn ich dann im Bad das Licht ausmache, dann wechselt der Status weiter auf "wach im Bett" und die Nachttischlampe wird eingeschaltet. Wenn ich dann tatsächlich schlafen will, dann sage ich entweder "Alexa, gute Nacht" oder ich mache meine Nachttischlampe aus. Danach wechselt mein Benutzer in ioBroker auf "Nacht" und entsprechend wird alles ausgeschaltet oder nur teilweise, je nachdem ob ich der letzte bin, der sich schlafen gelegt hat, oder ob andere noch wach sind.

Wie so eine Routine aussieht, ist individuell komplett verschieden.

müssen sich deine gäste in das WLAN einklinken, gezwungerner maßen?

Nö, warum? Das Bewohnergerät für den Gast kann ich selbst von meinem iPhone aus aktivieren und steuern.
Oder ich lade meinen Gast in die zweite Homekit Instanz ein, in der nur ausgesuchte ioBroker Geräte zur Steuerung veröffentlich sind, wie eben z.B. auch der Gastbewohner vom Residents Modul. Dafür braucht der Gast aber kein WLAN, das funktioniert ganz normal über Apple Homekit. (und ja, ein iOS-Benutzer zu sein ist grundsätzlich Voraussetzung, um mit mir befreundet zu sein).

ich würd mich nicht rund um die uhr verfolgen lassen.

Muss man doch gar nicht. Alles läuft Event basiert und wann ein solches Event ausgelöst wird, ist komplett in der Hand des Bewohners und dessen Endgeräts. Da wird nix dauerhaft und vor allem aus der Ferne auslesbar übertragen und nachverfolgt.
Wenn dich das tiefer interessiert, solltest du dich damit genauer auseinandersetzen.

[da_Woody]

@loredo danke für die erklärungen. ausgefuxtes system. wäre mir persönlich zu komplex. ok, "Alexa, gute Nacht" gibts da auch, aber in einem einfacheren fall. ist ja nur ein 2 personen haushalt.

[JLeg]

@loredo sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

und ja, ein iOS-Benutzer zu sein ist grundsätzlich Voraussetzung, um mit mir befreundet zu sein

YMMD

[blade-of-fire]

@Loredo Ich finde es toll, dass du dich diesem Adpater angenommen hast. Ich hatte damals bei FHEM auch schon den Resident-Adapter benutzt und fand die Möglichkeiten sehr angenehm, die man damit hatte.
Ich hatte sogar schonmal begonnen, genau diesen Adapter hier in ioBroker nachzubauen, allerdings ließ ich das Projekt leider aufgrund fehlender Zeit, mich darum zu kümmern (und in die Adapterentwicklung einzuarbeiten) wieder fallen.
Daher habe ich sehr viel Logik bezüglich Anwesenheitserkennung und Bewohnerstatus ("zuhause", "auf dem Weg ins Bett", "einschlafen", "schlafen") in Blockly bzw. in Nodered gebaut.

Ich kenne also genau die Intention des Adapters
Bisher kam ich noch nicht dazu, den Adapter zu testen. Das werde ich aber so bald ich Zeit finde, nachholen.

[blade-of-fire]

Bei mir werden die DPs "Coming", "Going" der Bewohner gar nicht angelegt.

Ich habe schon ein bisschen mit Setzen der Bewohner auf "Away" und "Home" herumgespielt, hilft aber nichts.

Dann habe ich noch einen Vorschlag zur besseren Übersicht bzw. Abgrenzung der Bewohner zu den übrigen Infos. Wäre es möglich, die Bewohner in einen Unterordner zu schieben?

Ich verstehe noch nicht ganz, wie das mit den Gruppen funktionieren soll, also wie man einen Bewohner einer Gruppe zuordnen kann. Oder ist das noch nicht umgesetzt?

[Loredo]

@blade-of-fire sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

Bei mir werden die DPs "Coming", "Going" der Bewohner gar nicht angelegt.
Ich habe schon ein bisschen mit Setzen der Bewohner auf "Away" und "Home" herumgespielt, hilft aber nichts.

Ich weiß leider nicht, was genau du meinst, es gibt keine Datenpunkte, die "Coming" oder "Going" heißen. Kannst du bitte genauer sein?

@blade-of-fire sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

Dann habe ich noch einen Vorschlag zur besseren Übersicht bzw. Abgrenzung der Bewohner zu den übrigen Infos. Wäre es möglich, die Bewohner in einen Unterordner zu schieben?

Das hatte ich schon öfters überlegt und deine Anfrage zum Anlass genommen das umzubauen. Die gerade neu veröffentliche Version hat unter anderem diese Änderung. Bisherige Geräte-Objekte muss man natürlich manuell löschen, da die Objekte unter den neuen Ordnern neu angelegt werden.

@blade-of-fire sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

Ich verstehe noch nicht ganz, wie das mit den Gruppen funktionieren soll, also wie man einen Bewohner einer Gruppe zuordnen kann. Oder ist das noch nicht umgesetzt?

Doch, eigentlich schon. Du legst pro Gruppe eine eigene Adapter Instanz an und dann dann in den Einstellungen die Adapter Instanz ID hinterlegen, von der der Status übernommen werden soll. Anschließend wird der gemeinsame Gruppenstatus beider Instanzen unter residents.[child instance].group zusätzlich abgelegt.

[Loredo]

Ich habe gerade die Version 0.0.3-beta.6 veröffentlicht.

Die Änderungen sind diesmal etwas größer:

1. Emoji Icons zu States hinzugefügt
2. Anpassbare Übersetzungen für States hinzugefügt
3. Geänderte Werte für Laune, um sichtbare Sortierreihenfolge zu korrigieren
4. Aktivitäts-Tasks in Fokus Modus umbenannt (ähnlich dem Apple Fokus Modus)
5. Benutzerdefinierte Fokus Modi hinzugefügt
6. Bewohner Geräte in Unterordner verschoben
7. Timer können deaktiviert werden

[blade-of-fire]

@loredo said in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

@blade-of-fire sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

Bei mir werden die DPs "Coming", "Going" der Bewohner gar nicht angelegt.
Ich habe schon ein bisschen mit Setzen der Bewohner auf "Away" und "Home" herumgespielt, hilft aber nichts.

Ich weiß leider nicht, was genau du meinst, es gibt keine Datenpunkte, die "Coming" oder "Going" heißen. Kannst du bitte genauer sein?

Sigi hatte in einem oberen Post einen Screenshot angehängt. Unter den Bewohnern sind neben dem DP Presence noch weitere DPs, wann die Person gekommen bzw. gegangen ist.

Diese DPs kann ich nicht finden, allerdings sieht mittlerweile die Datenpunkt-Struktur ganz anders aus.
Wenn ich mich richtig erinnere, wurden damals in FHEM auch entsprechende Infos angezeigt, wann die Person bzw. Gruppe die Wohnung/Haus verlassen bzw. betreten haben. Ich hoffe, du weisst, was ich meine.

@blade-of-fire sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

Dann habe ich noch einen Vorschlag zur besseren Übersicht bzw. Abgrenzung der Bewohner zu den übrigen Infos. Wäre es möglich, die Bewohner in einen Unterordner zu schieben?

Das hatte ich schon öfters überlegt und deine Anfrage zum Anlass genommen das umzubauen. Die gerade neu veröffentliche Version hat unter anderem diese Änderung. Bisherige Geräte-Objekte muss man natürlich manuell löschen, da die Objekte unter den neuen Ordnern neu angelegt werden.

Super, die neueste Version werde ich mich gleich mal installieren

@blade-of-fire sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

Ich verstehe noch nicht ganz, wie das mit den Gruppen funktionieren soll, also wie man einen Bewohner einer Gruppe zuordnen kann. Oder ist das noch nicht umgesetzt?

Doch, eigentlich schon. Du legst pro Gruppe eine eigene Adapter Instanz an und dann dann in den Einstellungen die Adapter Instanz ID hinterlegen, von der der Status übernommen werden soll. Anschließend wird der gemeinsame Gruppenstatus beider Instanzen unter residents.[child instance].group zusätzlich abgelegt.

Ok, danke. Werde ich mir mal anschauen.

[sigi234]

@blade-of-fire sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

Sigi hatte in einem oberen Post einen Screenshot angehängt. Unter den Bewohnern sind neben dem DP Presence noch weitere DPs, wann die Person gekommen bzw. gegangen ist.

Hallo, diese DP sind vom fb-checkpresence Adapter!

[blade-of-fire]

@sigi234 said in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

@blade-of-fire sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

Sigi hatte in einem oberen Post einen Screenshot angehängt. Unter den Bewohnern sind neben dem DP Presence noch weitere DPs, wann die Person gekommen bzw. gegangen ist.

Hallo, diese DP sind vom fb-checkpresence Adapter!

Achso... ok, habs verstanden Danke

[blade-of-fire]

@loredo said in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

@blade-of-fire sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

Ich verstehe noch nicht ganz, wie das mit den Gruppen funktionieren soll, also wie man einen Bewohner einer Gruppe zuordnen kann. Oder ist das noch nicht umgesetzt?

Doch, eigentlich schon. Du legst pro Gruppe eine eigene Adapter Instanz an und dann dann in den Einstellungen die Adapter Instanz ID hinterlegen, von der der Status übernommen werden soll. Anschließend wird der gemeinsame Gruppenstatus beider Instanzen unter residents.[child instance].group zusätzlich abgelegt.

Leider muss ich hier nochmal nachhaken. Wenn ich das richtig verstanden habe, ist die Adapter-Instanz quasi die Bewohner Gruppe:

• resident.0 (Gruppe 1)
  • Bewohner 1
  • Bewohner 2
• resident.1 (Gruppe 2)
  • Bewohner 3
  • Bewohner 4

So lassen sich ja dann auch Überschneidungen abbilden. Ich habe zum Beispiel bei mir eine Gruppe "Eltern", eine Gruppe "Kinder" und eine Gruppe "Alle", die dann alle Bewohner beinhaltet.

Was mir noch nicht ganz klar ist: "dann in den Einstellungen die Adapter Instanz ID hinterlegen, von der der Status übernommen werden soll".
Ist hier eine Instanz ID einer anderen Residenz-Instanz gemeint?
Oder meinst du hier eine ID außerhalb des resident-Adapterst? Also ein DP, der von einem anderen Adapter geschaltet wird und den gesamten Gruppenstatus schaltet?

Ich habe hier schon mehrere IDs eingetragen, allerdings hatte das bisher keinen Einfluss.

Die Beschreibung des Feldes "Object IDs of the parents residents instances" lässt ja darauf schließen, dass hier mehrere eingetragen werden können.
Kannst du hier vielleicht mal ein Beispiel zeigen, was da eingetragen werden muss?

[Loredo]

@blade-of-fire sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

Sigi hatte in einem oberen Post einen Screenshot angehängt. Unter den Bewohnern sind neben dem DP Presence noch weitere DPs, wann die Person gekommen bzw. gegangen ist.

@sigi234 sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

diese DP sind vom fb-checkpresence Adapter!

Ich habe gerade neue Datenpunkte in der gerade veröffentlichten Version 0.0.3-beta.7 unter residents.[instance].[residentType].info.presence hinzugefügt.

@blade-of-fire sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

Leider muss ich hier nochmal nachhaken. Wenn ich das richtig verstanden habe, ist die Adapter-Instanz quasi die Bewohner Gruppe:

• resident.0 (Gruppe 1)
  • Bewohner 1
  • Bewohner 2
• resident.1 (Gruppe 2)
  • Bewohner 3
  • Bewohner 4

So lassen sich ja dann auch Überschneidungen abbilden. Ich habe zum Beispiel bei mir eine Gruppe "Eltern", eine Gruppe "Kinder" und eine Gruppe "Alle", die dann alle Bewohner beinhaltet.

Theoretisch, ja. Man kann aktuell aber noch nicht mehrere Instanzen angeben, weil ich nicht weiß, wie ich das grafisch richtig in Materialize darstellen kann. Die dafür nötige Hilfe hatte ich ja schon öfters erwähnt. Auch bei den Yahka Instanzen und den überwachten externen Datenpunkten für die Präsenz und den Nachhauseweg sollen mehrere Einträge möglich sein. Mangelt aber bisher an einer sinnvollen grafischen Eingabe.

@blade-of-fire sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

Was mir noch nicht ganz klar ist: "dann in den Einstellungen die Adapter Instanz ID hinterlegen, von der der Status übernommen werden soll".
Ist hier eine Instanz ID einer anderen Residenz-Instanz gemeint?

Ja ganz genau. Aber die Instanz-ID ist immer nur sowas wie residents.0, kein Datenpunkt darunter, so wie du das angegeben hast. Man muss aber natürlich aufpassen, dass man sich keinen Loop baut. Kann sein, dass sowas nicht hinreichend geprüft wird.

[Loredo]

Wer den Sync der Focus Modi von seinen Apple Geräten ausprobieren möchte: Ich habe in der aktuellen Version den Siri Shortcut dazu mit reingepackt.

Der Download Link im Admin funktioniert allerdings bisher nicht, weil ich noch nicht herausgefunden habe, wie ich dem Admin Adapter mitteilen kann, dass dort eine weitere Datei zum "hochladen" in die Objekte-Datenbank ist.
Deshalb muss man es aktuell hier von GitHub laden:

https://github.com/jpawlowski/ioBroker.residents/tree/main/admin/siri_shortcuts

Dieser Sync funktioniert explizit nur im lokalen WLAN, um es erstmal nicht zu kompliziert zu machen. Habe auch noch nicht geschaut, wie man die ioBroker.simple-api entsprechend gut absichern könnte, um die ggf. auch aus dem Internet erreichbar zu haben. Die ioBroker iOS App kann ja bisher leider keine Siri Shortcuts direkt, sonst wäre das wohl in Verbindung mit dem Cloud Zugriff auch etwas schickes (Home Assistant kann sowas ja, aber irgendwie auch sehr kompliziert, hab es darüber nicht hinbekommen, wäre sonst eine Hintertür über den ioBroker.hass Adapter).

Wenn jemand also weiß, wie man ioBroker.simple-api im Zugriff auf ganz bestimmte Objekte beschränkt, gerne hier dazu melden
Siri Shortcuts wäre dann auch eine mögliche (flexiblere) Alternative zur Nutzung von Geofency. Aber erstmal gucken, wie das nun so läuft.

Was Focus Modi auf Android angeht: Hab da keine Aktien drin und auch kein Interesse selbst was dafür zu bauen. Falls aber jemand anderes einen Sync für Android baut (wie auch immer man das dort machen würde), darf das gerne auf Github einreichen und ich nehme es mit in den Adapter auf.

[blade-of-fire]

@loredo said in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

Ich habe gerade neue Datenpunkte in der gerade veröffentlichten Version 0.0.3-beta.7 unter residents.[instance].[residentType].info.presence hinzugefügt.

Super, ich werde mir gleich heute abend mal die neueste Version runterladen.

Bezüglich der Gruppen: Gibt es einen bestimmten Grund, warum du dies über einzelne Instanzen lösen willst?
Ist es vielleicht einfacher, Gruppen anlegen zu können wie Bewohner (bzw. Haustiere) und man dann die Zuordnung über z.B. eine Listbox macht?

Vielleicht vereinfacht dies ein wenig die Umsetzung?

[Loredo]

@blade-of-fire sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

Bezüglich der Gruppen: Gibt es einen bestimmten Grund, warum du dies über einzelne Instanzen lösen willst?

Da gibt es eine Reihe von Gründen für, aber die wohl prägnanteste ist: So kannst du auch anhand der Objekt ID die Gruppe unterscheiden, einfach weil die Instanz eine andere ID hat. Gleichzeitig unterscheiden sich die Objekt ID Längen nicht und es bleibt übersichtlicher. Es wäre wesentlich komplizierter die Gruppen dynamisch im Objektbaum darzustellen. Und die Gruppenzugehörigkeit nicht im Baum darzustellen ist für mich keine richtige Option

[blade-of-fire]

@loredo said in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

Automatisches Synchronisieren des Anwesenheitsstatus zwischen zwei Residents Geräten (Presence Following)

Das steht ja oben bei "offene Features". Ich nehme an, dass dies noch nicht komplett implementiert ist, richtig?
Hab da ein bisschen rumprobiert, allerdings ohne Erfolg.

Gibt es ein Best Practice zur Verwendung der verschiedenen DP? Also wie geht man am besten vor, wenn man zum Beispiel zu Bett geht. Es gibt sehr viele Möglichkeiten, den Status abzubilden, was gut ist, es aber auch etwas komplex macht. Einige DPs stehen ja in Wechselwirkung zueinander.

[arni_h]

@loredo said in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

Siri Shortcuts wäre dann auch eine mögliche (flexiblere) Alternative zur Nutzung von Geofency.

Müsste ich mit einer SIRI Automation 'Wenn ich nach Hause komme' oder 'Wenn ich das Zuhause verlasse' und einem zusätzlichen yahka-schalter nicht Geofency überflüssig machen können - allein mit dem AppleTV als Homekit-Zentrale und ohne zusätzliche VPN bzw. API Lösungen..

[Loredo]

@blade-of-fire sagte in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

@loredo said in Test Adapter Residents (Bewohner) v0.0.x Latest (Beta):

Automatisches Synchronisieren des Anwesenheitsstatus zwischen zwei Residents Geräten (Presence Following)

Das steht ja oben bei "offene Features". Ich nehme an, dass dies noch nicht komplett implementiert ist, richtig?
Hab da ein bisschen rumprobiert, allerdings ohne Erfolg.

Ja das ist (war) korrekt. Ist in der gerade veröffentlichten Version 0.1.0-beta.1 nun enthalten.

Gibt es ein Best Practice zur Verwendung der verschiedenen DP? Also wie geht man am besten vor, wenn man zum Beispiel zu Bett geht. Es gibt sehr viele Möglichkeiten, den Status abzubilden, was gut ist, es aber auch etwas komplex macht. Einige DPs stehen ja in Wechselwirkung zueinander.

Ein einfacher, typischer Status Lifecycle sieht so in etwa aus (kann aber unterschiedlich stark ausgeprägt sein):

1. presence.state wird auf zu Hause gesetzt. --> man kommt z.B. von der Arbeit nach Hause und macht dann dort "sein Ding" (die Fokus Modes lasse ich jetzt mal weg).
2. activity.bedtime wird auf Entspannen: Auf Schlaf einstellen gesetzt. --> Man kommt "runter", englisch "calm down", man stellt sich mental darauf ein bald schlafen zu gehen.
3. activity.bedtime wird auf Schlafenszeit: Bettfertig machen gesetzt. --> Nun geht man Zähneputzen, zieht den Schlafanzug an, etc.
4. activity.bedtime wird auf Nacht: Im Bett gesetzt. --> Nun geht man tatsächlich ins Bett oder liegt bereits darin. Man ist aber noch wach, hat noch die Nachttischlampe an, liest ein Buch, was auch immer.
5. presence.night wird auf Nacht gesetzt. --> Nun legt man sich tatsächlich schlafen, macht das Licht aus und die Augen zu... Man kann Punkt 2-4 auch auslassen (oder auch erst bei 3 oder gar 4 einsteigen) und nur mit der Night Presence für das Schlafengehen arbeiten, um sich "direkt" schlafen zu schalten.
6. activity.awake kann während der Nacht zwischen false und true wechseln. --> Das bedeutet, man ist kurz wach, wird aber anschließend wieder ins Bett gehen. z.B. ins Bad, nach dem Kind gucken, etc. Ist man mindestens einmal in der Nacht aufgestanden, obwohl man eigentlich schlafen sollte, dann wird das entsprechend auch in activity.state angezeigt. Während mindestens eine Person wach ist, wechselt auch der Residential state auf Nachtwanderung.
7. activity.wakeup wird auf true gesetzt. --> Der Wecker klingelt das erste Mal, activity.state wird entsprechend auf Nacht: Weckalarm" gesetzt.
8. activity.wakeupSnooze auf auf true gesetzt. --> Dem Wecker wird auf'n Kopf gehauen, um noch weiter zu dösen. activity.state wechselt entsprechend auf Aufwecken: Schlummern und zählt auch einige Male mit, wie of man auf Snooze drückt.
9. presence.state wird auf zu Hause gesetzt. --> Jetzt wird aufgestanden, man ist noch am Wachwerden. activity.awake steht nun automatisch auf true, wodurch der Residential State auf Aufgestanden wechselt, sobald die erste Person wach ist. activity.state steht nun ebenfalls auf Aufgestanden: Aufwachen.
10. activity.awake wird auf false gesetzt. --> Man bezeichnet sich jetzt als "wach" und ansprechbar, Morgenmuffeligkeit sollte vorbei sein ;-). Alle Status wechseln jetzt auf den normalen Anwesenheitsstatus für den Tag.
11. presence.state wird auf Abwesend gesetzt. --> Ich verlasse das Haus, fahre z.B. zur Arbeit. Falls ich eine längere Abwesenheit voraussehen kann (z.B. weil ich in den Urlaub fahre), dann kann ich activity.overnight nun auf false setzen. Damit wird beim Verlassen des Hauses mein Benutzer sofort deaktiviert anstatt erst am nächsten Morgen. Dies würde ansonsten auch passieren, sofern ich morgens um 04:59 Uhr (Standardeinstellung) nicht im Status zu Hause oder Nacht bin. Dann wird angenommen, dass ich verreist bin. Wenn das für alle Bewohner zugleich der Fall ist, könnte die Heizungssteuerung beispielsweise spätestens nun entsprechend das Haus nicht mehr so stark auf Temperatur halten, weil ich ja nicht absehbar zeitnah wieder zuhause sein werde.
12. activity.wayhome wird auf true gesetzt. --> Ich kann absehen, dass ich bald zuhause sein werde und befindet mich auf dem Weg.
13. Zyklus komplett, wieder bei Punkt 1 beginnen.