Mein Modul HouseMode

[DeeSPe]

Hallo Community,

ich weiß dass bei einigen Devs ein Modul für den HouseMode/HouseState auf der Agenda steht.
Da es aber noch nichts Dergleichen verfügbar gibt, habe ich einfach mal alle meine HouseMode Funktionen in ein Modul gesteckt und erweitere diese auch Stück für Stück.

Dieses Modul stellt im Prinzip eine Verzahnung zwischen den ROOMMTE/GUEST Devices und ihren PRESENCE Devices, sowie zwischen dem RESIDENTS Device und dem eigentlichen HouseMode Device her.

Bisher bin ich mit dem Modul sehr zufrieden. Es hat bei mir alle möglichen Custom Funktionen rund um den HouseMode abgelöst, da man zu jedem möglichen Event von HouseMode und von RESIDENTS/ROOMMATE/GUEST die auszuführende Befehle festlegen kann (sogar separat pro auslösendem ROOMMATE/GUEST).

Was macht das Modul?

Es stellt für alle Events rund um RESIDENTS, ROOMMATE/GUEST, PRESENCE (ROOMMATE/GUEST zugehörig) und HouseMode eigene hmCMD... Attribute bereit.
In diesen Attributen kann man Befehle angeben die ausgeführt werden sollen sobald ein Event der genannten Devices eintrifft.
Es stellt optional eine Abhängigkeit zwischen jedem ROOMMATE/GUEST und seinem korrespondierenden PRESENCE Device her.
Ebenso können Tür-/Fensterkontakte per Attribut hinzugefügt werden, deren Status ebenfalls überwacht und in einem Reading bereitgestellt wird.
Ziel ist es alle möglichen sinnvollen Events rund um den HouseMode verfügbar zu haben und für diese entsprechende auszuführende Befehle festzulegen.
Das ist dann DIE zentrale Anlaufstelle und erspart langes suchen im Custom Code oder allen möglichen notify/DOIF, denn diese kann man dadurch alle entsorgen.

Beim Definieren wird das RESIDENTS Device mit angegeben:

Code Auswählen Erweitern

define myHM HouseMode rgr_Residents

Das HouseMode Device erkennt alle ROOMMATE/GUEST Mitglieder von RESIDENTS automatisch und fügt diesen ein neues userattr presenceDevice hinzu. In dieses Attribut kann man das korrespondierende PRESENCE Device eintragen, wenn das PRESENCE Device "PRESENCE_<ROOMMATE/GUEST-NAME>" heißt wird es automatisch erkannt (ohne Setzen des Attributs). Von nun an folgt der Status (home/absent) der ROOMMATE/GUEST Devices dem Status (present/absent) der korrespondierenden PRESENCE Devices.

Sobald der Status des RESIDENTS Devices home annimmt, wechselt der HouseMode automatisch auf einen Tageszeitstatus der Uhrzeit entsprechend (morning,day,....). Dieses Verhalten kann man durch Setzen des Attributs hmAutoDaytime auf 0 deaktivieren. Dann wird das HouseMode Device nur zwischen home und absent automatisch hin- und hergeschaltet.

Bei gotosleep eines ROOMMATE/GUEST wird automatisch das jeweilige Device nach einer Zeitspanne (default 5min) auf asleep gesetzt. Mit dem Attribut hmAutoAsleep kann die Zeitspanne bestimmt werden nach welcher von state gotosleep auf state asleep gesetzt werden soll (per Default deaktiviert). Mit dem Wert 0 kann man diese Automatik außer Kraft setzen. State asleep wird dann nicht mehr automatisch nach state gotosleep gesetzt.

Bei awoken bzw. "home nach asleep" eines ROOMMATE/GUEST wird automatisch das jeweilige Device auf awoken und nach einer Zeitspanne (default 5min) auf home gesetzt. Mit dem Attribut hmAutoAwoken kann die Zeitspanne bestimmt werden nach welcher von state awoken auf state home gesetzt werden soll (per Default deaktiviert). Mit dem Wert 0 kann man diese Automatik außer Kraft setzen. State home wird dann nicht mehr automatisch nach state awoken gesetzt, auch wird dann das ROOMMATE/GUEST Device nicht mehr automatisch auf state awoken bei "state home nach state asleep" gesetzt.

Die standardmäßig verfügbaren mode(s) von HouseMode sind morning,day,afternoon,evening,night,gotosleep,awoken,asleep,absent,gone,dnd + Tageszeit abhängige mode(s). Diese können über das Attribut hmStates erweitert/verändert werden (Tageszeit abängige mode(s) können dann evtl. nicht mehr gesetzt werden wenn diese entfernt wurden).
Um den automatischen Tageszeit abhängigen HouseMode zu deaktivieren kann man das Attribut hmAutoDaytime auf 0 setzen.

Für jeden verfügbaren mode von HouseMode gibt es ein Attribut (hmCMD<mode>) mit welchem man die zum HouseMode passenden auszuführenden Befehle definieren kann. Um die Alarmanlage scharf zu schalten und die offen stehenden Tür-/Fensterkontakte per msg zu versenden:

Code Auswählen Erweitern

attr <name> hmCMDabsent set Alarm:FILTER=state!=on on;{fhem "msg \@%NAME% ACHTUNG %ALIAS%! %CONTACTS%" if ("%CONTACTS%")}

Für jeden verfügbaren mode von HouseMode gibt es noch ein Attribut hmCMD<mode>-<user> mit welchem man zu den von einem bestimmten ROOMMATE/GUEST erzeugten HouseMode passenden auszuführenden Befehle definieren kann.
Also z.B.:

Code Auswählen Erweitern

attr <name> hmCMDabsent-rr_Dan set TVSimulation:FILTER=state!=on on
oder

Code Auswählen Erweitern

attr <name> hmCMDgotosleep-rr_Brina msg audio @rr_Brina Gute Nacht Brina
Beim ersten Beispiel wird erst hmCMDabsent ausgeführt und danach hmCMDabsent-rr_Dan wenn der absent mode durch rr_Dan erzeugt wurde.
Beim zweiten Beispiel wird erst hmCMDgotosleep ausgeführt und danach hmCMDgotosleep-rr_Brina wenn der gotosleep mode durch rr_Brina erzeugt wurde.
Sobald das HouseMode Device einen mode annimmt der anwesend bedeutet wird erst hmCMDpresent und danach hmCMDpresent-<user> (user ist der User der den present mode ausgelöst hat) ausgeführt.   

In alle hmCMD... Attribute kann man fhem Code schreiben, sowie Perl Code (in {}) oder auch beides mischen.
Zu beachten ist dabei dass im Perl Code die Semikola verdoppelt werden müssen. Im fhem Code reichen einfache Semikola, also alles wie in der FHEM Eingabezeile. z.B.:

Code Auswählen Erweitern

attr <name> hmCMDasleep set Nachtlicht on; {fhem "set Heizungen controlMode night" if (Value("Sommer") eq "off");; fhem "sleep 900;; set w_n_Steckdosen [FILTER=state!=off] off"}

Es gibt noch zwei spezielle Attribute hmCMDpresent und hmCMDpresent-<user>. Der Inhalt dieser Attribute wird immer ausgeführt wenn ein beliebiger anwesend HouseMode (nicht absent oder gone) gesetzt wird. Also z.B.:

Code Auswählen Erweitern

attr <name> hmCMDpresent set Alarm:FILTER=state!=off off



Set Befehle

hier eine Auflistung der set Befehle

mode <HouseMode>
manuelles aktivieren eines bestimmten Modus

mode <season>
manuelles aktivieren einer bestimmten Jahreszeit



Get Befehle

hier eine Auflistung der get Befehle

statusContacts
manuelles ausgeben der offenen Tür-/Fensterkontakte



Konfiguration

hier eine Auflistung der Attribute und ihrer Funktionsbestimmung

disable
deaktiviert das HouseMode Device

hmAutoAsleep
Zeit in Minuten nach der ein ROOMMATE/GUEST von gotosleep auf asleep geschaltet werden soll
Vorgabewert: 0 (deaktiviert)

hmAutoAwoken
Zeit in Minuten nach der ein ROOMMATE/GUEST von awoken auf home geschaltet werden soll, aktiviert auch die Funktion dass der jeweilige ROOMMATE/GUEST beim Setzen von home nach asleep automatisch auf awoken wechselt
Vorgabewert: 0 (deaktiviert)

hmAutoDaytime
schaltet den Modus statt auf home auf einen tageszeitabhängigen Modus
wird es deaktiviert, werden auch die tageszeitabhängigen set Befehle entfernt
Vorgabewert: 1 (aktiviert)

hmCMD<usermode>
zum jeweiligen ROOMMATE/GUEST Modus auszuführende Befehle
entweder FHEM-Befehle mit einfachen Semikola getrennt oder/und in {} eingeschlossene Perl Befehle mit verdoppelten Semikola

Verfügbare Platzhalter:
%NAME% - Name des ROOMMATE/GUEST Device welches den ROOMMATE/GUEST bezogenen Modus ausgelöst hat
%ALIAS% - Alias des ROOMMATE/GUEST Device welches den ROOMMATE/GUEST bezogenen Modus ausgelöst hat
%DEVICE% - Name des PRESENCE Device des ROOMMATE/GUEST welches den ROOMMATE/GUEST bezogenen Modus ausgelöst hat
%ADDRESS% - MAC Adresse des PRESENCE Device des ROOMMATE/GUEST welches den ROOMMATE/GUEST bezogenen Modus ausgelöst hat

hmCMD<usermode>-any
zum jeweiligen ROOMMATE/GUEST Modus eines beliebigen ROOMMATE/GUEST Device auszuführende Befehle
entweder FHEM-Befehle mit einfachen Semikola getrennt oder/und in {} eingeschlossene Perl Befehle mit verdoppelten Semikola

Verfügbare Platzhalter:
wie bei Attribut hmCMD<usermode>

hmCMD<usermode>-<user>
zum jeweiligen ROOMMATE/GUEST Modus des bestimmten ROOMMATE/GUEST Device auszuführende Befehle
entweder FHEM-Befehle mit einfachen Semikola getrennt oder/und in {} eingeschlossene Perl Befehle mit verdoppelten Semikola

Verfügbare Platzhalter:
wie bei Attribut hmCMD<usermode>

hmCMDpresent
auszuführende Befehle bei beliebigem Modus der anwesend bedeutet
entweder FHEM-Befehle mit einfachen Semikola getrennt oder/und in {} eingeschlossene Perl Befehle mit verdoppelten Semikola

Verfügbare Platzhalter:
wie bei Attribut hmCMD<usermode>

hmCMD<housemode>
zum jeweiligen HouseMode Modus auszuführende Befehle
entweder FHEM-Befehle mit einfachen Semikola getrennt oder/und in {} eingeschlossene Perl Befehle mit verdoppelten Semikola

Verfügbare Platzhalter:
%NAME% - Name des HouseMode auslösenden Benutzers
%ALIAS% - Alias des HouseMode auslösenden Benutzers
%DEVICE% - PRESENCE Device des HouseMode auslösenden Benutzers
%CONTACTS% - offene Tür-/Fensterkontakte in menschenlesbaren Format (deutscher Satz aus Reading contactsOpen_hr)
%CONTACTSOPEN% - offene Tür-/Fensterkontakte (kommaseparierte Liste offener Tür-/Fensterkontakte aus Reading contactsOpen)
%CONTACTSCLOSED% - offene Tür-/Fensterkontakte (kommaseparierte Liste offenen Tür-/Fensterkontakte aus Reading contactsClosed)

hmCMD<season>
zur jeweiligen Jahreszeit auszuführende Befehle
entweder FHEM-Befehle mit einfachen Semikola getrennt oder/und in {} eingeschlossene Perl Befehle mit verdoppelten Semikola

hmContacts
devspec der Tür-/Fensterkontakte deren Status überwacht werden soll

hmContactsReading
Reading der Tür-/Fensterkontakte in dem der Status der Tür-/Fensterkontakte steht
Vorgabewert: state

hmContactsClosedCmd
Wert des Reading der Tür-/Fensterkontakte welcher geschlossen signalisiert
Vorgabewert: closed

hmContactsOpenCmd
Wert des Reading der Tür-/Fensterkontakte welcher offen signalisiert
Vorgabewert: open

hmMainDoors
noch nicht verwendet - für spätere Benutzung vorgesehen

hmSeasons
kommaseparierte Liste der Jahreszeiten die über den set Befehl season verfügbar sein sollen
Vorgabewert: spring,summer,autumn,winter

hmSeasonsCal
noch nicht verwendet - für spätere Benutzung vorgesehen

hmStates
zusätzliche eigene HouseModes die dann über den set Befehl mode verfügbar sein sollen
beim Übernehmen dieses Attributs werden die userattr neu erstellt, ebenso bei einem modify des HouseMode Device - das kann auch nötig sein wenn sich die Mitglieder vom RESIDENTS Device geändert haben
Vorgabewert: dnd

hmUserCmdDelay
damit die ROOMMATE/GUEST bezogenen Befehle nach denen des HouseModes verarbeitet werden, ist es nötig die ROOMMATE/GUEST bezogenen Befehle zu verzögern, da diese normalerweise vor den HouseMode bezogenen Befehlen verarbeitet werden. Hiermit kann die Verzögerungszeit in Sekunden festgelegt werden. Ist dieses Verzögerungsverhalten nicht gewünscht, so ist der Wert auf 0 zu setzen, dann werden die ROOMMATE/GUEST bezogenen Befehle vor den HouseMode bezogenen Befehlen verarbeitet.
Vorgabewert: 1


Readings

hier eine Auflistung der Readings und ihrer Beschreibungen

contactsClosed
kommaseparierte List der geschlossenen Kontakte

contactsOpen
kommaseparierte List der offenen Kontakte

contactsOpen_hr
menschenlesbarer deutscher Satz der offenen Kontakte - zur Weiterverarbeitung (z.B. per Mail/Push/Audio)

daytime
Tageszeit (HouseMode unabhängig)

lastActivityByDev
Device welches als letztes den HouseMode verändert hat

lastAsleepByDev
Device welches als letztes auf asleep gewechselt ist

lastAwokenByDev
Device welches als letztes auf awoken gewechselt ist

lastGoneNoneByDev
Device welches als letztes auf gone/none gewechselt ist

lastGotoleepByDev
Device welches als letztes auf gotosleep gewechselt ist

lastPresentByDev
Device welches als letztes auf einen beliebigen Anwesenheitsmodus gewechselt ist

mode
aktueller Modus des HouseMode

presence
aktuelle Anwesenheit des HouseMode

prevActivityByDev
Device welches als vorletztes den HouseMode verändert hat

prevActivityByDev
vorheriger Modus des HouseMode

season
aktuelle Jahreszeit

state
aktueller Status des HouseMode (analog zu mode)




Würde mich freuen wenn das mal jemand testet und mir ein Feedback geben könnte.
Bin bei Bedarf auch gerne bereit das noch weiter zu entwickeln.

Danke.

Gruß
Dan






###############################################################

UPDATE1:

• Tageszeit abhängige mode(s) können nicht mehr entfernt werden
• wenn hmAutoDaytime auf 0 gesetzt wird, werden die Tageszeit abhängigen mode(s) aus den set Befehlen entfernt und stattdessen der mode home hinzugefügt
• neues Reading daytime
• neues Reading prevMode
• commandref angepasst

UPDATE2:

• Fehler beseitig
• commandref berichtigt

UPDATE3:

• umstellen der ROOMATE/GUEST Devices von awoken auf home und von gotosleep auf asleep nach Zeit funktioniert jetzt auch unabhängig vom mode des HouseMode Device - die Automatismen dazu sind nun per Default deaktiviert, um sie zu aktivieren ist es nötig die Attribute hmAutoAsleep bzw. hmAutoAwoken mit einer Zeit von 1-59 (Minuten) zu setzen
• die zum jeweiligen state des ROOMMATE/GUEST Device gehörenden CMDs werden nun unabhängig vom HouseMode ausgeführt
• commandref angepasst

UPDATE  28.11.2016:

Riesiges Funktionsupdate!!!

• einige neue Attribute (siehe Konfiguration)
• einige neue Readings (siehe Readings)
• neuer set season Befehl für manuelles Setzen einer Jahreszeit
• Tür-/Fensterkontakt Überwachung integriert (siehe Konfiguration hmContacts)
• diverse Platzhalter hinzugefügt (siehe Konfiguration)
• mode home ist nun immer verfügbar, resultiert beim manuellen Setzen und hmDaytime 1 aber automatisch in einem tageszeitabhängigen Modus
• commandref angepasst
• ausführlichere Beschreibung, Dokumentation und neuen Screenshot hier in diesem Beitrag ergänzt

EDIT: Modul entfernt als Vorbereitung auf die VÖ des neuen Moduls unter neuem Namen.

[Loredo]

Cool, schaue ich mir bei Gelegenheit näher an.


Einige spontane Anmerkungen:


- die Abkürzung "hm" ist bereits von Homematic belegt und könnte zu Verwirrung führen
- die Verquickung mit PRESENCE an dieser Stelle finde ich unglücklich. PRESENCE sollte lieber direkt den Status der ROOMMATE Devices (analog zu GEOFANCY) steuern und nicht von hinten durch die Brust ins Auge
- entscheidender Unterschied zum von mir in Entwicklung befindlichen HOMESTATE Moduls: die Tageszeit-Modi wechseln zunächst unabhängig von der Anwesenheit und beeinflussen lediglich den HOMESTATE-Gesamtstatus. Die Abhängigkeit zur Anwesenheit hier finde ich daher (für meine Verwendung) nicht so toll
- die gotosleep Beeinflussung auf die ROOMMATE/GUEST Devices von außen finde ich hier fehl am Platz, sowas gehört in die ROOMMATE/GUEST Devices direkt, gerne als Patch
- den HomeMode "dnd" verstehe ich nicht
- die Koppelung mit auszuführenden Befehlen auch bis runter auf ROOMMATE/GUEST Ebene liest sich gut, was das genau bedeutet muss ich mal ausprobieren




Gruß
Julian

[DeeSPe]

Cool, schaue ich mir bei Gelegenheit näher an.


Einige spontane Anmerkungen:


- die Abkürzung "hm" ist bereits von Homematic belegt und könnte zu Verwirrung führen
- die Verquickung mit PRESENCE an dieser Stelle finde ich unglücklich. PRESENCE sollte lieber direkt den Status der ROOMMATE Devices (analog zu GEOFANCY) steuern und nicht von hinten durch die Brust ins Auge
- entscheidender Unterschied zum von mir in Entwicklung befindlichen HOMESTATE Moduls: die Tageszeit-Modi wechseln zunächst unabhängig von der Anwesenheit und beeinflussen lediglich den HOMESTATE-Gesamtstatus. Die Abhängigkeit zur Anwesenheit hier finde ich daher (für meine Verwendung) nicht so toll
- die gotosleep Beeinflussung auf die ROOMMATE/GUEST Devices von außen finde ich hier fehl am Platz, sowas gehört in die ROOMMATE/GUEST Devices direkt, gerne als Patch
- den HomeMode "dnd" verstehe ich nicht
- die Koppelung mit auszuführenden Befehlen auch bis runter auf ROOMMATE/GUEST Ebene liest sich gut, was das genau bedeutet muss ich mal ausprobieren




Gruß
Julian

Hi Julian,

ja, das mit hm dachte ich auch schon, ist aber so schön kurz und ist ja eben auch ein komplett anderes Device. Könnte ich aber umbenennen.

Das mit PRESENCE verstehe ich nicht ganz. Im besten Fall hat doch jeder ROOMMATE/GUEST ein korrespondierendes PRESENCE Device. Diese Abhängigkeit wird hier gebildet und das ROOMMATE/GUEST Device eben home/absent passend zum PRESENCE Device present/absent geschaltet, spart also notify/DOIF. Das ist aber auch ein kann-Feature - nichts muss...
Mit den Tageszeitmodi überlege ich mir mal, da könnte man auch ein zweites ROOMMATE unabhängiges Reading setzen.
Die Beeinflussung von gotosleep/asleep ist auch ein kann-Feature.
dnd ist halt "do not disturb", ein evtl. Spezialmodus bei dem Klingel usw. abgestellt werden sollen.

Danke für's schnelle Feedback auch ohne Testen!

Gruß
Dan

[DeeSPe]

Ich habe die Version im ersten Beitrag aktualisiert.

Folgende Verbesserungen/Veränderungen wurden vorgenommen:

• Tageszeit abhängige mode(s) können nicht mehr entfernt werden
• wenn hmAutoDaytime auf 0 gesetzt wird, werden die Tageszeit abhängigen mode(s) aus den set Befehlen entfernt und stattdessen der mode home hinzugefügt
• neues Reading daytime
• neues Reading prevMode
• commandref angepasst

Gruß
Dan

[DeeSPe]

Noch einmal ein Mini Update im ersten Beitrag.

Ich habe zwei kleine Fehler im Code und einen in der commandref behoben.

Gruß
Dan

[DeeSPe]

Im ersten Beitrag habe ich soeben das Modul aktualisiert.
Es ist ein riesiges Funktionsupdate geworden.
Sogar eine Tür-/Fensterkontakt offen/geschlossen Erkennung und diverse Platzhalter Variablen sind dazu gekommen.

Das Modul ist bereits so stabil dass ich es in meinem Live-System einsetze und dadurch etliche notify/DOIF und Custom Funktionen gelöscht habe.

Das HouseMode Device ist nun DIE Anlaufstelle für alles rund um RESIDENTS, ROOMMATE/GUEST, PRESENCE (ROOMMATE/GUEST zugehörig) und HouseMode.

Changelog:

• einige neue Attribute (siehe Konfiguration)
• einige neue Readings (siehe Readings)
• neuer set season Befehl für manuelles Setzen einer Jahreszeit
• Tür-/Fensterkontakt Überwachung integriert (siehe Konfiguration hmContacts)
• diverse Platzhalter hinzugefügt (siehe Konfiguration)
• mode home ist nun immer verfügbar, resultiert beim manuellen Setzen und hmDaytime 1 aber automatisch in einem tageszeitabhängigen Modus
• commandref angepasst
• ausführlichere Beschreibung, Dokumentation und neuen Screenshot hier im ersten Beitrag ergänzt

Gruß
Dan

P.S. Die commandref ist bereits angepasst aber noch nicht vollständig, dazu habe ich heute keine Lust mehr. Dafür sollte die Dokumentation im ersten Beitrag weitestgehend vollständig sein.
P.P.S. Habe auch noch weitere Ideen und Dinge die ich umsetzen möchte. z.B. Gesamtstromverbrauch definierter Geräte berechnen und als Reading bereitstellen oder Special Modes per Cal Device einbinden.......

[hartenthaler]

Habe gerade mal ein wenig damit rumgespielt. Ja, das Modul ist hilfreich und wird mir Arbeit abnehmen.

Bei den Fenstern ist mir aufgefallen: meine Fenster/Balkontüren haben drei Stati: open/tilted/closed. Ich kann natürlich tilted und open zu einem neuen open zusammenfassen, aber schöner wäre es, wenn alle drei unterstützt würden. Wobei es beim Verlassen der Wohnung auf diesen feinen Unterschied kaum ankommt. Nicht closed ist kritisch. Also könnte das Modul auch nur auf "closed" achten und jeden anderen Wert als "not closed" interpretieren.

[DeeSPe]

Habe gerade mal ein wenig damit rumgespielt. Ja, das Modul ist hilfreich und wird mir Arbeit abnehmen.

Klasse! Du scheinst verstanden zu haben worum es mir mit dem Modul geht!

Guter Einwand mit tilted! Werde das Attribut auf RegEx umbauen so dass man dann statt "open" auch "open|tilted" angeben kann.
Ein dritter Wert für Tamper Alarm wäre vielleicht auch nicht schlecht!

Danke für Dein Feedback!
Gerne mehr davon.

Gruß
Dan

[Spezialtrick]

Hallo Dan,

wieder mal ein klasse Modul! 

Ich habe es gerade eingerichtet und hätte ein paar Fragen.

Das HouseMode Device erkennt alle ROOMMATE/GUEST Mitglieder von RESIDENTS automatisch und fügt diesen ein neues userattr presenceDevice hinzu. In dieses Attribut kann man das korrespondierende PRESENCE Device eintragen, wenn das PRESENCE Device "PRESENCE_<ROOMMATE/GUEST-NAME>" heißt wird es automatisch erkannt (ohne Setzen des Attributs). Von nun an folgt der Status (home/absent) der ROOMMATE/GUEST Devices dem Status (present/absent) der korrespondierenden PRESENCE Devices.

Sämtliche Bewohner wurden korrekt vom Modul übernommen und es wurde auch das userattr presenceDevice hinzugefügt. Meine Presence Device sind alle so

Code Auswählen Erweitern

define PRESENCE_Miro PRESENCE local-bluetooth xx:xx:xx:xx:xx:xx 10 30

definiert. Hätte presenceDevice nun automatisch mit "PRESENCE_Miro" gefüllt werden sollen oder ist dies überflüssig? Automatisch wurde es nicht eingetragen. Sollte sich nun auch automatisch der Status von "rr_Miro" von Home auf absent ändern, wenn das entsprechende Presences Device umschaltet? Passiert bei mir leider ebenfalls nicht. Vllt. habe ich aber auch irgendwo einen Fehler drin. 

Könntest du noch etwas mehr zu "hmContacts" sagen? Wie würde man z.B. Fensterkontakte von MAX! eintragen?

Ich hätte auch noch einen Verbesserungsvorschlags/Wunsch. Wenn man schon die Jahreszeiten angibt, wäre es doch super, wenn man auch "spezielle" Zeiträume wie z.b. die Adventszeit erfassen könnte. Ein Beispiel zu Berechnung wurde nachfolgend vorgeschlagen:

https://forum.fhem.de/index.php/topic,42209.msg530772.html#msg530772

Vielen Dank für das großartige Modul. Es steckt viel Potential dahinter.

EDIT: Grad eben vergessen: Wäre es auch möglich mehrere Presence Devices für einen Bewohner auszuwerten?

[Icinger]

Wenn man schon die Jahreszeiten angibt, wäre es doch super, wenn man auch "spezielle" Zeiträume wie z.b. die Adventszeit erfassen könnte. Ein Beispiel zu Berechnung wurde nachfolgend vorgeschlagen

Das würde mich auch interessieren.
Vlt. könnte man auch mehrere benutzerdefinierbare Zeiträume machen o.ä.
zB um von Frühling bis Herbst die Poolsteuerung zu aktivieren

lg, Stefan

[DeeSPe]

Hallo Dan,

wieder mal ein klasse Modul! 

Ich habe es gerade eingerichtet und hätte ein paar Fragen.

Sämtliche Bewohner wurden korrekt vom Modul übernommen und es wurde auch das userattr presenceDevice hinzugefügt. Meine Presence Device sind alle so

Code Auswählen Erweitern

define PRESENCE_Miro PRESENCE local-bluetooth xx:xx:xx:xx:xx:xx 10 30

definiert. Hätte presenceDevice nun automatisch mit "PRESENCE_Miro" gefüllt werden sollen oder ist dies überflüssig? Automatisch wurde es nicht eingetragen. Sollte sich nun auch automatisch der Status von "rr_Miro" von Home auf absent ändern, wenn das entsprechende Presences Device umschaltet? Passiert bei mir leider ebenfalls nicht. Vllt. habe ich aber auch irgendwo einen Fehler drin. 

Könntest du noch etwas mehr zu "hmContacts" sagen? Wie würde man z.B. Fensterkontakte von MAX! eintragen?

Ich hätte auch noch einen Verbesserungsvorschlags/Wunsch. Wenn man schon die Jahreszeiten angibt, wäre es doch super, wenn man auch "spezielle" Zeiträume wie z.b. die Adventszeit erfassen könnte. Ein Beispiel zu Berechnung wurde nachfolgend vorgeschlagen:

https://forum.fhem.de/index.php/topic,42209.msg530772.html#msg530772

Vielen Dank für das großartige Modul. Es steckt viel Potential dahinter.

EDIT: Grad eben vergessen: Wäre es auch möglich mehrere Presence Devices für einen Bewohner auszuwerten?

Bin ja begeistert dass es nun doch ein paar gibt die sich trauen und dem Modul eine Chance geben!
Danke dafür, denn nur so kann man potentielle Schwachstellen aufdecken.
Das Modul ist mit Sicherheit noch nicht perfekt und auch bei Weitem nicht komplett fertig entwickelt.
Ich sehe das eher als ein Konzept das durch Community Feedback weiter ausgebaut und verbessert werden kann.

Nun zu Deinen Fragen!
Das zum ROOMMATE/GUEST gehörende PRESENCE Device muss genauso heißen wie das zugehörige ROOMMATE/GUEST Device mit vorangestelltem "PRESENCE_" damit es automatisch erkannt wird, also in Deinem Fall "PRESENCE_rr_Miro".
Klar könnte man auch mehrere Devices als RegEx angeben, ist aber bisher so nicht implementiert. Kann das aber gerne einbauen wenn es Sinn macht.
hmContacts ist ein devspec Attribut. Es kann also jede Form von devspec verwendet werden.
z.B.: name1,name2,name3
oder für die magnetischen und optischen HM Kontakte: TYPE=CUL_HM:FILTER=model=HM-SEC-SC(o|-2)

Ein Special Event Kalender steht noch auf meiner Todo Liste.
Damit soll ein Calender Device ausgewertet und die Kalender-Events von dort mit Namen und Datum übernommen werden.

Gruß
Dan

P.S. Danke für Euer wirklich wertvolles Feedback.

[hartenthaler]

Das mit Presence sehe ich als komplizierter an. Aus meiner Sicht muss das jeder individuell lösen, wenn er mehr als eine PRESENCE-Quelle hat. Ich habe z.B. mindestens vier Dinge, die meine Präsenz festlegen: ein bluetooth-ping auf mein SmartPhone, eine Welcome-Kamera, Koordinaten meiner Geo-Position, die ich manuell per Telegram nach Hause schicke, und Geofancy. Ich will diese Infos unterschiedlich wichten und in einem dummy-Präsenz-Device konsolidieren. Das will ich dann hier mit dem neuen Modul verknüpfen. Hat gestern aber nicht geklappt. Muss das verknüpfte presence-Device wirklich ein PRESENCE-Device sein oder kann es auch ein dummy-Device sein?#

PS: bin in der Doku auch über PRESENCE_rr_Miro versus PRESENCE_Miro gestolpert, da das dort nicht klar beschrieben ist, hatte mich dann aber richtigerweise für die Version mit dem üblichen rr_ entschieden.

[DeeSPe]

Au Mann jetzt hab ich ne halbe Stunde geschrieben und hab durch ne blöde Handbewegung auf dem Trackpad "Zurück" aktiviert. Beim Versuch auf "Vor" zu klicken statt darauf etwas zu tief geklickt und "Apps" erwischt, ergo: TEXT WEG!
Sollte doch lieber lange Texte im ext. Editor schreiben, was ich hier nun tue.

Ich versuche den vorherigen Text nochmal so gut es geht zusammenzufassen, halte mich aber kurz!

Bei der Frage nach mehreren PRESENCE Devices ist mir die dahinter steckende Komplexität der Sache schon aufgefallen.
Könnte das mit Attributen lösen ala: "hmPresencePresent all/any" und "hmPresenceAbsent all/any" und passenden CMD Attributen?
Da das Modul nur so vor Attributen strotzt und weiter strotzen wird, machen die paar Attribute mehr auch keinen Unterschied. Solange die Attributnamen irgendwie selbstredend und intuitiv sind, sollte das IMHO kein Problem darstellen.

Würde der o.g. Lösungvorschlag eventuell Deine dummy(s) obsolet machen? Wenn nein, wie könnte es Deine dummy(s) obsolet machen? Das globale Ziel dieses Moduls ist es ja manuelle Device Definitionen einzusparen, egal von welchem TYPE (notify/DOIF/dummy/.....).

"PRESENCE_<ROOMMATE/GUEST-NAME>" ist im Text beschrieben, dachte der eindeutige Name wäre damit klar. Gebe zu dass das zusätzliche userattr für das ROOMMATE/GUEST Device sonst nicht weiter dokumentiert ist. Werde ich ändern...!
Könnte die Prüfung der PRESENCE Device Namen aber auch ändern! Das macht vielleicht sogar mehr Sinn, bitte um mögliche pro/contra Argumente dazu.
Z.B. vor dem Vergleich erst mal beides in Kleinbuchstaben ändern, dann noch (wenn vorhanden) rr_/rg_ raus und den Namen mit RegEx prüfen:

Code Auswählen Erweitern

$preseneName =~ /pres.*$username/
Das könnte folgende mögliche Namen der PRESENCE Devices ergeben (bei username rr_Dan):

PRESENCE_rr_Dan
PRESENCErr_Dan
xyzPRES_rr_Dan
xyzPRES_xyz_rr_Dan
xyzPRES_xyz_rr_Dan_xyz

PRESENCE_Dan
PRESENCEDan
xyzPRES_Dan
xyzPRES_xyz_Dan
xyzPRES_xyz_Dan_xyz

presence_dan
presencedan
xyzpres_dan
xyzpres_xyz_dan
xyzpres_xyz_dan_xyz

preSENce_dAn
preSenCedaN
............

Bin gerade dabei das Thema Kontaktsensoren noch weiter zu verfeinert damit es granularer auswertbar wird (Unterscheidung von Außen-/Innentüren und Fenstern). Das macht auch Sinn denke ich.

Ich habe noch so viele Ideen für Erweiterungen im Kopf dass ich mit der Umsetzung derer gar nicht hinterher komme, erst Recht nicht mit der Dokumentation eben dieser!!! Aber eine gute Doku ist das A+O wenn das Modul benutzt werden soll.

Gruß
Dan

EDIT: Bei der PRESENCE Namen Prüfung könnte ich eigentlich auch komplett auf den Prefix pres/PRES verzichten da ja nur PRESENCE Devices abgefragt werden!

[Spezialtrick]

Ich sehe das eher als ein Konzept das durch Community Feedback weiter ausgebaut und verbessert werden kann.

Na dann werden mir sicher noch einige Sachen einfallen. 

Das zum ROOMMATE/GUEST gehörende PRESENCE Device muss genauso heißen wie das zugehörige ROOMMATE/GUEST Device mit vorangestelltem "PRESENCE_" damit es automatisch erkannt wird, also in Deinem Fall "PRESENCE_rr_Miro".

D.h. dann sollte rr_Miro je nach Status von PRESENCE_rr_Miro automatisch zwischen Home und Absent wechseln? Das ist bei mir leider nicht der Fall. Vllt. sollte ich nochmals alles was damit zusammenhängt löschen.

Klar könnte man auch mehrere Devices als RegEx angeben, ist aber bisher so nicht implementiert. Kann das aber gerne einbauen wenn es Sinn macht.

Ich fände es sehr sinnvoll. Ein Presence Device ist fehleranfälliger als zwei oder sogar vier, wie es hartenthaler einsetzt. Und wenn man das Presence Device tatsächlich zum schalten verwendet möchte, sollte doch möglichst sicher garantiert sein, dass der ermittelte Status, auch wirklich der Wahrheit entspricht.

Ein Special Event Kalender steht noch auf meiner Todo Liste.
Damit soll ein Calender Device ausgewertet und die Kalender-Events von dort mit Namen und Datum übernommen werden.

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. ^^

[DeeSPe]

Na dann werden mir sicher noch einige Sachen einfallen. 

Schön, Ideen bitte möglichst hier im Thema mit sammeln.

D.h. dann sollte rr_Miro je nach Status von PRESENCE_rr_Miro automatisch zwischen Home und Absent wechseln? Das ist bei mir leider nicht der Fall. Vllt. sollte ich nochmals alles was damit zusammenhängt löschen.

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!

Ich fände es sehr sinnvoll. Ein Presence Device ist fehleranfälliger als zwei oder sogar vier, wie es hartenthaler einsetzt. Und wenn man das Presence Device tatsächlich zum schalten verwendet möchte, sollte doch möglichst sicher garantiert sein, dass der ermittelte Status, auch wirklich der Wahrheit entspricht.

Baue es gerade so ein!

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. ^^

Dazu lasse ich mir etwas sinnvolles einfallen!
Erst einmal sind mir gerade noch ein paar andere Dinge wichtig! Wie gesagt, die Finger kommen gerade mit dem Schreiben nicht hinterher bei den noch offenen Ideen....

Gruß
Dan

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