Mein Modul HouseMode

[DeeSPe]

Das wäre ja wieder mit einem manuelle Eingriff verbunden, zudem nutzt nicht jeder Kalender. Wenigstens den Advent könnte man doch einfach unterbringen. Andere "wichtige" Jahreszeit fall mir spontan nicht ein. ^^

Da fällt mir gerade auf dass Du das selbst komplett frei mit dem Attribut hmSeasons konfigurieren kannst (default: spring,summer,autumn,winter)!
Da die Jahreszeiten (bisher) nur manuell gesetzt werden können (oder per at/notify/DOIF) spielt das Datum dafür ja eh (noch) keine Rolle.

Gruß
Dan

[DeeSPe]

Achso, noch eine Anmerkung.

Den Status des hier veröffentlichten Moduls würde ich zwischen stabiler Alpha bis stabiler Beta einordnen, eben Konzept.
Das heißt eigentlich nur so viel dass bisher weder der Name des Moduls, noch die Namen der Attribute endgültig sein müssen...
Falls es mal irgendwann zu einem offiziellen FHEM Check-in dieses Moduls kommen sollte, dann sollten evtl. die ganzen hm.... Attribut Namen noch einmal in etwas Eindeutigeres umbenannt werden damit es nicht mit HomeMatic kollidiert (HouseMode als Prefix statt hm ist aber zu lang, HoMo ist auch blöd)!

Gruß
Dan

[Spezialtrick]

So ist es gedacht und das tut es bei mir auch erfolgreich!
Es gibt bisher noch eine kleine Eigenheit des Moduls, muss erst mal schauen wie ich das evtl umgehen kann. Das definierte HouseMode Device muss in der fhem.cfg hinter allen Device stehen die es kontrollieren soll. Also bestenfalls ganz am Ende!

Bei mir funktioniert es leider nicht und ich weiß nicht woran es liegt. Ich habe Residents, Presence und auch HouseMode gelöscht und erneut angelegt. Presence zeigt den richtigen Status an, mehr passiert leider nicht und ich weiß nicht woran es liegt. Hier sind die Readings von Housemode, die aktualisieren sich in gewissen Abständen:


daytime                   night               2016-11-29 23:32:22
lastActivityByDev      rr_Bewohner    2016-11-29 23:32:23
mode                       night               2016-11-29 23:20:06
presence                  present            2016-11-29 23:20:06
prevActivityByDev     rr_Miro            2016-11-29 23:32:23
state                        night               2016-11-29 23:20:06

Das Reading presence ändert sich aber nicht. Hast du noch eine Idee?

Muss das RESIDENTS Modul für die Status Weitergabe/Umschaltung zwingend RESIDENTS heißen?

P.S. Man könnte dieses Konzept endlos weiter spinnen, aber wir wollen ja bei allem rund um den HouseMode bleiben...

Bezieht sich das auf den Advent? Es soll durchaus Leute geben, die im Advent irre Lichtshow an ihrem Haus abfeiern.  Da ist der Begriff HouseMode fast schon untertrieben. 

[DeeSPe]

Ich glaube ich habe mittlerweile eine ziemlich coole Lösung für die zugehörigen PRESENCE Devices gefunden, sogar ohne das Attribut presenceDevice.
Mal schauen ob ich bis morgen Abend was zum hier veröffentlichen zaubern kann, es wird großartig!

Bei mir funktioniert es leider nicht und ich weiß nicht woran es liegt. Ich habe Residents, Presence und auch HouseMode gelöscht und erneut angelegt. Presence zeigt den richtigen Status an, mehr passiert leider nicht und ich weiß nicht woran es liegt. Hier sind die Readings von Housemode, die aktualisieren sich in gewissen Abständen:


daytime                   night               2016-11-29 23:32:22
lastActivityByDev      rr_Bewohner    2016-11-29 23:32:23
mode                       night               2016-11-29 23:20:06
presence                  present            2016-11-29 23:20:06
prevActivityByDev     rr_Miro            2016-11-29 23:32:23
state                        night               2016-11-29 23:20:06

Das Reading presence ändert sich aber nicht. Hast du noch eine Idee?

Muss das RESIDENTS Modul für die Status Weitergabe/Umschaltung zwingend RESIDENTS heißen?

Nein, es muss nur vom TYPE RESIDENTS sein! Die Mitglieder wurden ja offensichtlich auch erkannt, sonst würden die keine Readings erzeugen! Warum das bei Dir mit dem PRESENCE nicht hinhaut kann ich mir gerade nicht wirklich erklären da ja die PRESENCE Devices einheitlich die Anwesenheit im Reading presence bereit stellen! Hast Du evtl. bei den PRESENCE Devices das Attribut event-on-change-reading auf state gesetzt? Das würde dann erklären warum die Events vom Reading presence nicht ankommen.

Hast Du das mit den Jahreszeiten mit dem Attribut hmSeasons erfolgreich lösen können?

Gruß
Dan

[hartenthaler]

Es gibt bei mir Ereignisse bei denen ich (bislang) per notify  rr_Hermann auf home setze. Dann kommt aber im Log eine Fehlermeldung.

Code Auswählen Erweitern


2016.11.30 00:32:20 2: ROOMMATE set rr_Hermann home
2016.11.30 00:32:20 3: set Wohnung mode lastActivity: home : "set Wohnung" needs at least one argument and maximum two arguments
"Wohnung" ist mein HouseMode Device.

Zur PRESENCE-Diskussion: aha es muss also ein PRESENCE-Device sein (und kein dummy). Allerdings muss es dann eine Zuordnung geben, welche PRESENCE-Devices zu welcher Person gehören. Bei der Welcome-Kamera wird das schon sehr spezifisch, denn die meldet "Gesicht von xyz gesehen". Gibt also Präsenzinformationen zu allen möglichen Personen wieder. Willst Du alle solche Spezial-Devices in Dein Modul einbauen? Macht keinen Sinn für mich. Besser Du erweiterst Dein Modul so, dass man auch dummy-Präsenz-Devices im Modul zuordnen kann. Ich schreibe dann ein notify für meine Welcome die das dummy entsprechend setzt. Das gleiche für meine Telegram-Koordinaten-nach-Hause schicken-Lösung. Ich empfange die Koordinaten, berechne den Abstand zu den Heimatkoordinaten und je nach Entfernung sage ich Präsenz ist zu Hause oder unterwegs. Das ist aber schon etwas speziell.

Die Unterscheidung von Tür-/Fenstersensoren nach Innen- und Aussensensoren ist eine gute Idee, denn beim Verlassen des Hauses interessiert wohl nur die Aussenhaut.

Die season setze ich derzeit über ein DOIF nach den meteorologischen Daten, also am 1.12. fängt der Winter an. Wie ist das mit den entsprechenden HouseMode-Season-Attributen gedacht? Wichtig ist aus meiner Sicht: es gibt die vier definierten Jahreszeiten und da kann man z.B. entscheiden, dass im Winter die Automatik der Markise deaktiviert wird oder dass im Winter nach einer anderen Strategie gelüftet und geheizt wird als im Sommer. Aber es gibt auch noch andere Zeiträume, die parallel laufen können, etwa der bereits aufgeführte Advent, der auch bei mir die Weihnachtsbeleuchtung aktiviert, aber vielleicht auch so etwas wie "Grillsaison" oder "Swimming-Pool-Saison" oder ganz profan "Wochenende" oder "Urlaub" (Aktivierung der Anwesenheitssimulation).

[DeeSPe]

Es gibt bei mir Ereignisse bei denen ich (bislang) per notify  rr_Hermann auf home setze. Dann kommt aber im Log eine Fehlermeldung.

Code Auswählen Erweitern


2016.11.30 00:32:20 2: ROOMMATE set rr_Hermann home
2016.11.30 00:32:20 3: set Wohnung mode lastActivity: home : "set Wohnung" needs at least one argument and maximum two arguments
"Wohnung" ist mein HouseMode Device.

Aha, das funktioniert zwar für das ROOMMATE/GUEST Device obwohl es diesen set Befehl offiziell nicht gibt bei denen. Richtig wäre:

Code Auswählen Erweitern

set rr_Hermann state home
Dann sollte es auch klappen. Kann den anderen Fall im nächsten Update aber auch berücksichtigen (denke ich)!

Zur PRESENCE-Diskussion: aha es muss also ein PRESENCE-Device sein (und kein dummy). Allerdings muss es dann eine Zuordnung geben, welche PRESENCE-Devices zu welcher Person gehören. Bei der Welcome-Kamera wird das schon sehr spezifisch, denn die meldet "Gesicht von xyz gesehen". Gibt also Präsenzinformationen zu allen möglichen Personen wieder. Willst Du alle solche Spezial-Devices in Dein Modul einbauen? Macht keinen Sinn für mich. Besser Du erweiterst Dein Modul so, dass man auch dummy-Präsenz-Devices im Modul zuordnen kann. Ich schreibe dann ein notify für meine Welcome die das dummy entsprechend setzt. Das gleiche für meine Telegram-Koordinaten-nach-Hause schicken-Lösung. Ich empfange die Koordinaten, berechne den Abstand zu den Heimatkoordinaten und je nach Entfernung sage ich Präsenz ist zu Hause oder unterwegs. Das ist aber schon etwas speziell.

Ich habe mir dazu etwas neues ausgedacht und bereits eingebaut. Teste das gleich ob das so funktioniert wie von mir gedacht. Aber sicher hast Du recht, es können nicht alle Spezialfälle abgedeckt werden. Versuche das aber so geschickt wie möglich zu realisieren.

Die Unterscheidung von Tür-/Fenstersensoren nach Innen- und Aussensensoren ist eine gute Idee, denn beim Verlassen des Hauses interessiert wohl nur die Aussenhaut.

Genau deshalb mache ich das!

Die season setze ich derzeit über ein DOIF nach den meteorologischen Daten, also am 1.12. fängt der Winter an. Wie ist das mit den entsprechenden HouseMode-Season-Attributen gedacht? Wichtig ist aus meiner Sicht: es gibt die vier definierten Jahreszeiten und da kann man z.B. entscheiden, dass im Winter die Automatik der Markise deaktiviert wird oder dass im Winter nach einer anderen Strategie gelüftet und geheizt wird als im Sommer. Aber es gibt auch noch andere Zeiträume, die parallel laufen können, etwa der bereits aufgeführte Advent, der auch bei mir die Weihnachtsbeleuchtung aktiviert, aber vielleicht auch so etwas wie "Grillsaison" oder "Swimming-Pool-Saison" oder ganz profan "Wochenende" oder "Urlaub" (Aktivierung der Anwesenheitssimulation).

Ist verstanden und kommt auch im neuen Update.
Nur um das wirklich richtig zu verstehen und umzusetzen! Es müsste dann einen zusätzliche set/Reading für, nennen wir es mal, specialEventPeriod geben für Special Events die mehrere Tage gehen (Advent/Ostern). Innerhalb dieser Zeitspanne kann es ja dann wiederum Events (set/Reading specialEvent) geben die mindestens einen Tag gehen (1. Advent/Ostersonntag).
Richtig gedacht?

Gruß
Dan

[hartenthaler]

Richtig wäre:

Code Auswählen Erweitern

set rr_Hermann state home
Dann sollte es auch klappen. Kann den anderen Fall im nächsten Update aber auch berücksichtigen (denke ich)!

Mein Befehl lautet tatsächlich "set rr_Hermann state home", nur die Zeile im Log ist etwas verkürzt dargestellt. Aber wie gesagt das führt zum Fehler laut Log "set Wohnung needs at least one argument and maximum two arguments". Das muss aus irgendeiner Automatikfunktion des Moduls HouseMode resultieren.

Zur specialEventPeriod: Ja ich denke es gibt Zeiträume, die sich über mehrere Tage erstrecken, und während derer etwas anders laufen kann als sonst. Solche Zeiträume sind Jahreszeiten (also kein expliziter Spezialfall wie derzeit implementiert), Adventszeit, Ostern (Karfreitag bis Ostermontag), Grill-Saison, Swimming-Pool-Saison, Urlaub. Ggf. gibt es zu einem Zeitpunkt auch Überlappungen, d.h. die specialEventPeriods sind eine Liste specialEventPeriod01, specialEventPeriod02, etc jeweils mit Beginn- und Endedatum. Es macht Sinn diese Liste im HouseMode zu verwalten, wobei die Anfangs- und Endedaten von mir aus auch aus einem Kalender stammen können. Dass es innerhalb einer specialEventPeriod ggf. noch einzelne Tage wie 1. Advent oder Ostermontag oder Urlaubsanfang geben mag, ist aus meiner Sicht irrelevant. Allerdings wird man die Information ob gerade so eine specialEventPeriod läuft verwenden. Ich schalte z.B. meine Weihnachtsbeleuchtung zwischen 9:00 und 23:00 Uhr an, aber nur wenn es draußen nicht zu hell ist und wenn Adventszeit ist. Adventszeit ist eine Funktion, die 0 oder 1 liefert. Oder anderes Beispiel: meine Anwesenheitssimulation würde dann abfragen ob gerade Urlaubszeit ist und nur dann etwas simulieren. Derzeit schalte ich diese Funktion manuell an und wieder ab, schöner wäre ich definiere im Kalender die Urlaubszeit und das wars.

[Spezialtrick]

Ich glaube ich habe mittlerweile eine ziemlich coole Lösung für die zugehörigen PRESENCE Devices gefunden, sogar ohne das Attribut presenceDevice.
Mal schauen ob ich bis morgen Abend was zum hier veröffentlichen zaubern kann, es wird großartig!

Ich bin schon in freudiger Erwartung. 

Warum das bei Dir mit dem PRESENCE nicht hinhaut kann ich mir gerade nicht wirklich erklären da ja die PRESENCE Devices einheitlich die Anwesenheit im Reading presence bereit stellen! Hast Du evtl. bei den PRESENCE Devices das Attribut event-on-change-reading auf state gesetzt?

Nein das Attribut habe ich nicht gesetzt. Bei mir aktualisieren sich aber auch nur die Presence Devices selbst. In den Roomates passiert nichts und im Housemode steht das reading auf presence   present   2016-11-29 23:16:29. Lediglich lastActivityByDev und prevActivityByDev werden regelmäßig aktualisiert.

Hast Du das mit den Jahreszeiten mit dem Attribut hmSeasons erfolgreich lösen können?

Man kann natürlich über das Attribut andere "Jahreszeiten" setzen, aber eigentlich ist der Advent ja keine Jahreszeit sondern ein spezieller Zeitraum und wenn es rechnerisch möglich ist, sollten diese automatisch durch das Modul gesetzt werden, um gerade weitere DOIFs/Notifys zu vermeiden. Oder siehst du das anders?

[DeeSPe]

Es kommt ganz viel in der zukünftigen Version.

Leider stellte sich das bisher programmierte als wenig kompatibel dar für meine weiteren Vorhaben, drum habe ich mich entschlossen noch mal von vorne zu beginnen!
Wird also noch ein klein Wenig dauern bis es den nächsten Entwurf gibt.

Gruß
Dan

[Spezialtrick]

Ein bisschen kannst du uns schon mal verraten. 

[DeeSPe]

Hab doch in den Beiträgen vorher schon fast alles verraten.
Lass Dich doch auch ein Wenig überraschen!!!
Und ich sage Dir Du wirst überrascht sein über die Möglichkeiten!

Gruß
Dan

[DeeSPe]

Der grundlegende Um-/Neubau ist nun geschafft, die Basis ist wieder wie vor dem großen Eingriff!
Puhhh, das war ein Akt, dafür sollte nun alles so sein dass ich es problemlos erweitern kann.
Nun geht es an die Feature Erweiterungen...

Ich denke heute Abend kann ich was zeigen...

Gruß
Dan

[DeeSPe]

Ich muss Euch leider noch etwas vertrösten.

Leider hat das Modul meinen eigenen Qualitätstest gestern Abend noch nicht bestanden.
Durch die ganzen grundlegenden Umbauten (z.B. Eventverarbeitung) müssen die meisten anderen Funktionen auch angepasst werden und neue Sonderfälle abgefangen werden, damit kämpfe ich noch ein wenig.

Gruß
Dan

[DeeSPe]

Hier mal ein kurzer Statusbericht.

Das Modul macht großartige Fortschritte seit dem ich es (fast) von Grund auf neu geschrieben habe.
Um alles, was mir so vorschwebt, sinnvoll einzubauen brauche ich aber noch etwas Zeit.
Es wird einige tolle optionale Automatiken geben die sich durch die überwachten Geräte ergeben.
Zur Zeit arbeite ich an einer sinnvollen Einbindung von Special-Events die dann im HouseMode automatisch auftauchen und für die man dann Aktionen konfigurieren kann.

Die Integration der PRESENCE Devices ist bereits nach meinen Vorstellungen abgeschlossen.
Es muss nun kein bestimmtes PRESENCE Device mehr pro Resident konfiguriert werden!
Statt dessen kann man den Presence Device Type festlegen der überwacht werden soll (default PRESENCE (kann ein einzelner Type sein oder eine kommaseparierte Liste von Typen)). Match dann irgendein Teil des Resident-Namen (Kleinschrift und ohne rr_/rg_) auf den Namen des angegebenen Presence Device Type, wird dieses als zugehöriges Presence Device dem Resident zugeordnet. Evtl. Uneindeutigkeiten in der Erkennung (mit Hinweisen zur Behebung) werden im Log ausgegeben.
Damit alles richtig funktioniert muss man konfigurieren wie viele Presence Devices es pro Resident gibt (default 1), wie viele davon nötig sind um ein present (default 1) und wie viele davon nötig sind um ein absent (default 1) im jeweiligen Resident zu erzeugen.

Gruß
Dan

[l2r]

hi,

ich bin auch fließig am testen. Aktuell bekomme ich folgende Meldung im Log, wenn sich der HomeStatus von absent auf present ändert und umgekehrt:

Code Auswählen Erweitern

set L2R_Home mode residentsTotalRoommatesPresent: 1 : "set L2R_Home" needs at least one argument and maximum two arguments
readingsUpdate(L2R_Home,mode,day) missed to call readingsBeginUpdate first.
readingsUpdate(L2R_Home,state,day) missed to call readingsBeginUpdate first.


Außerdem stellt sich der Status von HouseMode nicht auf absent, wenn alle Roommates und das Residentsdevice absent sind

Gruß Michael