FHEM Forum

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:
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:
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.:
attr <name> hmCMDabsent-rr_Dan set TVSimulation:FILTER=state!=on on
oder
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.:
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.:
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.

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

Zitat von: Loredo am 26 November 2016, 14:43:18
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

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

Noch einmal ein Mini Update im ersten Beitrag.

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

Gruß
Dan

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

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.

Zitat von: hartenthaler am 29 November 2016, 04:53:18
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! 8)

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. 8)

Gruß
Dan

Hallo Dan,

wieder mal ein klasse Modul!  :)

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

ZitatDas 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

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 (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?

ZitatWenn 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

Zitat von: Spezialtrick am 29 November 2016, 18:51:40
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 (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.

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.

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:
$preseneName =~ /pres.*$username/
Das könnte folgende mögliche Namen der PRESENCE Devices ergeben (bei username rr_Dan):

Zitat
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!

Zitat von: DeeSPe am 29 November 2016, 19:14:37
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.  8)

Zitat von: DeeSPe am 29 November 2016, 19:14:37
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.

Zitat von: DeeSPe am 29 November 2016, 19:14:37
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.

Zitat von: DeeSPe am 29 November 2016, 19:14:37
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. ^^

Zitat von: Spezialtrick am 29 November 2016, 22:55:58
Na dann werden mir sicher noch einige Sachen einfallen.  8)

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

Zitat von: Spezialtrick am 29 November 2016, 22:55:58
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!

Zitat von: Spezialtrick am 29 November 2016, 22:55:58
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! 8)

Zitat von: Spezialtrick am 29 November 2016, 22:55:58
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.... 8) 8) 8) 8)

Gruß
Dan

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

Zitat von: Spezialtrick am 29 November 2016, 22:55:58
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

Achso, noch eine Anmerkung. 8)

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

Zitat von: DeeSPe am 29 November 2016, 23:03:35
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?

Zitat von: DeeSPe am 29 November 2016, 23:03:35
P.S. Man könnte dieses Konzept endlos weiter spinnen, aber wir wollen ja bei allem rund um den HouseMode bleiben... :o

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

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

Zitat von: Spezialtrick am 29 November 2016, 23:37:50
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

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

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

Zitat von: hartenthaler am 30 November 2016, 01:12:02
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:
set rr_Hermann state home
Dann sollte es auch klappen. Kann den anderen Fall im nächsten Update aber auch berücksichtigen (denke ich)!

Zitat von: hartenthaler am 30 November 2016, 01:12:02
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. 8)

Zitat von: hartenthaler am 30 November 2016, 01:12:02
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! ;)

Zitat von: hartenthaler am 30 November 2016, 01:12:02
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

Zitat von: DeeSPe am 30 November 2016, 01:33:21
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.

Zitat von: DeeSPe am 30 November 2016, 00:04:34
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! 8) 8) 8)

Ich bin schon in freudiger Erwartung.  ;D

Zitat von: DeeSPe am 30 November 2016, 00:04:34Warum 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.

Zitat von: DeeSPe am 30 November 2016, 00:04:34
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?

Es kommt ganz viel in der zukünftigen Version. 8) 8) 8)

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! :o ::)
Wird also noch ein klein Wenig dauern bis es den nächsten Entwurf gibt.

Gruß
Dan

Ein bisschen kannst du uns schon mal verraten.  ;D

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

Gruß
Dan

Der grundlegende Um-/Neubau ist nun geschafft, die Basis ist wieder wie vor dem großen Eingriff! :o
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

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

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

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:

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

Zitat von: l2r am 06 Dezember 2016, 11:10:47
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

Das sollte in der kommenden Version alles gefixt sein da ich die Eventverarbeitung komplett umgebaut habe.

Das Modul macht nun wieder sehr gute Fortschritte!!!
Ich denke dass ich in den nächsten Tagen die neue Version hier reinstellen werde, sofern sie meinen eigenen Qualitätsstandards entspricht.

Die ganzen bisherigen Zwischenversionen veröffentliche ich hier absichtlich nicht denn ich möchte Euch vor einem halbgaren Modul bewahren, welches im schlimmsten Fall sogar FHEM abstürzen lässt! ;)

Gruß
Dan

P.S. Die kommende Version wird viele interne Veränderungen bringen, u.a. auch ein verändertes Attributnamen-Prefix damit ich gleich mal von hm wegkomme und es keine Verwechslungen mit HomeMatic mehr geben kann.

alles klar,

dann warte ich auf die neue Version, bevor ich alles doppelt konfigurieren muss;)

Morgen Abend wird es denke ich soweit sein dass ich eine neue Testversion zur Verfügung stellen kann.

Nun ist es doch ein (fast) komplett neu geschriebenes Modul geworden... ;)

Das Modul läuft nun schon sehr zufriedenstellend in meinem Test-System.
Nachdem ich heute noch ein paar Features integriert haben werde, werde ich das Modul bis morgen Abend in meinem Live-System testen und es hier veröffentlichen wenn es keine Ungereimtheiten mehr gibt.

Gruß
Dan

P.S. Ich denke Ihr werdet staunen was und wie alles funktioniert. Bin selbst überrascht von dem bisherigen Funktionsumfang... 8)

Zitat von: DeeSPe am 08 Dezember 2016, 11:28:02
Morgen Abend wird es denke ich soweit sein dass ich eine neue Testversion zur Verfügung stellen kann.


Ich denke Ihr werdet staunen was und wie alles funktioniert. Bin selbst überrascht von dem bisherigen Funktionsumfang... 8)

Im Spannung aufbauen bist du Profi. :D

Zitat von: Spezialtrick am 08 Dezember 2016, 11:30:59
Im Spannung aufbauen bist du Profi. :D

Klar!!! 8) 8) 8)

Es soll ja spannend bleiben und ich will "Lust auf mehr" machen.
Bin gespannt was Euch dann noch so einfallen wird was mit rein soll...

Für heute ist noch eine Integration von (Special-Event-)Kalendern, Wetterdevice und Gesamtleistungs-/Gesamtstromverbrauchsmessung geplant!
Die Erkennung und Konfiguration der PRESENCE Devices verfeinere ich auch gerade noch ein letzte Mal.

Gruß
Dan

bezüglich PRESENCE und Location-Steuerung habe ich evtl. noch eine Anregung. Vielleicht muss ich auch nur in die richtige Richtung geschubst werden.

Zu meiner Konfig:
Ich habe 2 Unifi-Access Points, einer im 1.OG und einer im EG (Raum). Außerdem noch eine Fritzrepeater für den Hof. Die AccessPoints greife ich über die entsprechenden Module ab und kriege so raus, welches Gerät sich gerade wo angemeldet hat. Die Auswertung übernimmt ein DOIF und setzt anschließend die passende Location (1.OG, Raum, Hof oder underway).

Das läuft wunderbar, irgendwie ist die Sache für mich aber nicht ganz rund.

Jetzt meine Frage: Würdet ihr das so lassen? Ob ich jetzt für jedes Device ein DOIF oder ein PRESENCE-Device anlege, ist ja egal. Oder würdet ihr versuchen das über das PRESENCE-Modul abzubilden, damit das dann auch im HouseMode weiterverarbeitet werden kann?  Bzw. kann HouseMode generell mit Locations umgehen?

Gruß Michael

Zitat von: l2r am 08 Dezember 2016, 12:02:09
bezüglich PRESENCE und Location-Steuerung habe ich evtl. noch eine Anregung. Vielleicht muss ich auch nur in die richtige Richtung geschubst werden.

Zu meiner Konfig:
Ich habe 2 Unifi-Access Points, einer im 1.OG und einer im EG (Raum). Außerdem noch eine Fritzrepeater für den Hof. Die AccessPoints greife ich über die entsprechenden Module ab und kriege so raus, welches Gerät sich gerade wo angemeldet hat. Die Auswertung übernimmt ein DOIF und setzt anschließend die passende Location (1.OG, Raum, Hof oder underway).

Das läuft wunderbar, irgendwie ist die Sache für mich aber nicht ganz rund.

Jetzt meine Frage: Würdet ihr das so lassen? Ob ich jetzt für jedes Device ein DOIF oder ein PRESENCE-Device anlege, ist ja egal. Oder würdet ihr versuchen das über das PRESENCE-Modul abzubilden, damit das dann auch im HouseMode weiterverarbeitet werden kann?  Bzw. kann HouseMode generell mit Locations umgehen?

Gruß Michael

Das ist EINE mögliche Lösung.
Du könntest auch mehrere PRESENCE Devices pro Resident anlegen! Mit mehreren dieser Devices kann HouseMode schon umgehen (in der kommenden Version).
Die location möchte ich auch gerne noch mit einbauen. Das kommt dann im nächsten Schritt. Dazu muss ich mich aber erst einmal noch näher mit location der Residents auseinandersetzen und von Euch dazu Anregungen bekommen... ;)

Gruß
Dan

ok, ich glaube ich lasse es erstmal so. Anbei mal das DOIF von mir:

([unifi_controller:IPhone7] eq "connected" and  [unifi_controller:IPhone7_accesspoint] eq "AP_1.OG") (set rr_Michael location 1.OG)
DOELSEIF ([unifi_controller:IPhone7] eq "connected" and  [unifi_controller:IPhone7_accesspoint] eq "AP_EG") (set rr_Michael location Raum)
DOELSEIF ([FritzRepeater01:mac_IPhone7] ne "inactive" and [FritzRepeater01:mac_IPhone7] ne "0") (set rr_Michael location Hof)
DOELSEIF ([unifi_controller:IPhone7] ne "connected" and [rr_Michael] ne "asleep" and ([FritzRepeater01:mac_IPhone7] eq "inactive" or [FritzRepeater01:mac_IPhone7] eq "0")) (set rr_Michael location underway)

und dann muss im ROOMMATE noch folgendes gesetzt sein:

attr rr_Michael rr_locationHome home 1.OG Raum Hof
attr rr_Michael rr_locations home,1.OG,Raum,Hof,underway

man muss zum einen dem ROOMMATE die verfügbaren locations bekannt machen und als zweites muss man sagen, welche locations als "anwesend" betrachtet werden soll.
Das hat den Vorteil, dass ich nicht mehr present/absent setzen muss (das wird vom Modul nachgezogen), sonder nur die aktuelle location. Das hat wiederum den Vorteil, dass ich abhängig von der Location des ROOMATES andere Devices (Heizung etc.) schalten kann. Außerdem kann beim msg-Befehl die Follow-Me-Funktion genutzt werden (damit zb. Sprachausgaben nur an den Geräten in den Passenden Räumen wiedergegeben werden, wo sich der aktuelle ROOMMATE befindet).

Da MSG, RESIDENTS und ROOMMATE alles Module von Loredo sind läuft das alles sehr gut ineinander. Du "erweiterst" quasi diese Module, deswegen frage ich nach der Kompatibilität.

Gruß Michael

Gestern haben sich noch ein paar Fehler beim Testen herausgestellt!
Das Modul konnte ich natürlich so nicht veröffentlichen.
Nun bin ich krank geworden und mir fehlen ganz einfach gerade die Nerven um Fehler zu suchen.
Sobald der Kopf es wieder zulässt werde ich weiter machen und euch das neue Modul vorstellen.
Vielleicht schaffe ich schon mal ein Wenig Dokumentation so lange...

Schönen gesunden 3. Advent Euch!!! 8)

Gruß
Dan

Mal ein kleiner Zwischenbericht von mir.

Ich habe mich nun dazu entschieden das Modul so vorzubereiten dass es evtl. offiziell in FHEM aufgenommen werden kann.
Dazu waren wieder einige Umbauten nötig.

Um es kurz zu machen:
Es wird ein neues Modul geben!
Dieses neue Modul wird einen neuen Namen bekommen!
Die Attribute dieses neuen Moduls werden einen anderen Prefix bekommen.
Für das neue Modul werde ich eine entsprechende Doku zur Verfügung stellen.
In das neue Modul kommen für den Anfang nur wenige Funktionen, aber dafür werden diese ausreichend getestet und erprobt sein.
Stück für Stück werden dann neue Funktionen aus meiner Dev-Version in die Beta Version übernommen und Euch zur Verfügung gestellt.

Ausführlich Testen und Erproben nimmt leider am meisten Zeit ein! 8)
Darum wird es noch ein paar Tage dauern bis zur nächsten Beta Version, denn ich möchte sicherstellen dass diese wirklich stabil ist und genau das macht was sie soll! Nicht mehr und nicht weniger!

Gruß
Dan

Es geht langsam voran mit dem neuen Modul.
Wie schon erwähnt dauert das Testen am längsten an der Sache.

Um Euch aber ein Wenig teilhaben zu lassen, anbei mal ein aktueller Screenshot von meinem HomeKit Device aus der Eve App!
Oben das ist die integrierte Alarmanlage (relativ simpel gehalten).
Darunter ein evtl. erzeugter Alarmstatus.
Mit Stumm lässt sich der Modus "Do Not Disturb" einstellen, wobei z.B. Alarm, Klingel usw. deaktiviert werden.
Die Temperatur und Luftfeuchtigkeit kommt von meinem Aussensensor, der Luftdruck von meinem Weather Device.
Die Werte von Verbrauch und Gesamtverbrauch sind durch mein Modul zusammengerechnete Werte aller Geräte mit energy/power Readings.

Gruß
Dan

P.S. Ich möchte nicht zu viel versprechen, aber evtl. wird es noch vor Silvester etwas mit einer Veröffentlichung des neuen Moduls. 8)

EDIT: Dateianhang entfernt.

Das Modul ist soweit fertig und werkelt die letzten Tage ohne Fehler in meinem Live-System.
Ich habe in den letzte Tagen und Wochen täglich an dem Modul entwickelt, alles immer wieder getestet (im Live-System) und noch viele kleine Nebeneffekte dadurch aufgedeckt und behoben.

Die Veröffentlichung wird aber nichts mehr dieses Jahr, da die Dokumentation noch in großen Teilen vor mir liegt.
Zur Veröffentlichung des Moduls möchte ich eine vollständige commandref (EN) und einen zugehörigen Forenbeitrag mit Dokumentation in deutsch (+ zugehörige Beispiele) bereitstellen.
Sobald diese letzte Mammut-Aufgabe gestemmt ist, werde ich euch das neue Modul präsentieren.

So viel schon mal im Voraus:
Im neuen Modul ist alles drin was diese Alpha-Version des Moduls hier auch mitbringt! ABER: noch viel mehr!!! ;)

Ich wünsche allen die hier mitlesen eine tolle Silversterfeier und einen guten Rutsch in's neue Jahr.
Das neue Jahr wird aus FHEM Sicht großartig mit meinem neuen Modul beginnen! 8)

Gruß
Dan

Etwas weniger Geheimniskrämerei und mehr Abstimmung hätte ich gut gefunden, da es ja wohl eng mit meinen Modulen zusammenarbeiten soll und ich wie erwähnt ohnehin an Erweiterungen dort arbeite.


Gruß

Julian

Zitat von: Loredo am 30 Dezember 2016, 15:43:41
Etwas weniger Geheimniskrämerei und mehr Abstimmung hätte ich gut gefunden, da es ja wohl eng mit meinen Modulen zusammenarbeiten soll und ich wie erwähnt ohnehin an Erweiterungen dort arbeite.


Gruß

Julian

Das ist keine Geheimniskrämerei!
Was soll hier mit Features prahlen??
Ich zeige dann lieber das Modul wenn es soweit ist...

Ja, das Modul arbeitet eng mit Deinen Modulen zusammen bzw. funktioniert ohne diese gar nicht.
Es soll auch noch gar kein finales Modul sein/werden! Ick kippe erst einmal alles hinein was aus meiner Sicht Sinn macht und dem Endanwender helfen könnte. Und ganz ehrlich, wenn das Modul keinem gefällt, dann ist es eben nur für mich, denn mir erleichtert es die Arbeit mit FHEM jeden Tag! 8)
Und um auf Deinen ursprünglichen Einwand zurückzukommen: Alles was mein Modul macht ist "Kann", nichts davon "Muss".
Zeit zur Diskussion wird es nach VÖ noch reichlich geben...

Gruß
Dan

Hallo DeeSPE!

Also das Modul hört sich verlockend an. Ich bin seit einiger Zeit dabei zu überlegen, wie ich die Modi anwesend/abwesend/Urlaub/Sommer/Winter verwalte. Ich werde noch warten bis das Modul in FHEM integriert ist und es dann mal ausprobiern.

Gruß und Danke, Matthis

Zitat von: Matthis am 04 Januar 2017, 13:16:37
Hallo DeeSPE!

Also das Modul hört sich verlockend an. Ich bin seit einiger Zeit dabei zu überlegen, wie ich die Modi anwesend/abwesend/Urlaub/Sommer/Winter verwalte. Ich werde noch warten bis das Modul in FHEM integriert ist und es dann mal ausprobiern.

Gruß und Danke, Matthis

Hey Matthis,

danke für Dein Interesse an diesem Modul.

Mittlerweile ist das Modul fertig programmiert!
Zumindest ist erst einmal alles drin was mir wichtig war. ;)
Die commandref ist auch schon fertig.
Das Einzige was noch nicht fertig ist ist der neue Forenbeitrag dazu mit entsprechender Dokumentation! Bin aber dran!!!
Da mir die Dokumentation für den Forenbeitrag sehr wichtig ist werde ich noch 1-2 Tage brauchen um diese mit entsprechenden Beispielen fertig zu stellen.
Wer hätte gedacht dass eine ordentliche Dokumentation fast genau so lange braucht wie das Programmieren und Testen!!?  8)

Da es sich um ein völlig neues Modul handelt, wird dieses wohl nicht so schnell offiziell in FHEM integriert!
Bevor das passieren kann, werde ich mich hier sämtlichem Feedback aussetzen, evtl. Fehler beseitigen und evtl. noch neue Funktionen dazugesellen.
Du bist herzlich eingeladen an der bald startenden Testphase teilzunehmen.
Ich werde hier in diesem Beitrag berichten (und verlinken) sobald der neue Beitrag mit dem neuen Modul online ist.

Gruß
Dan

Es ist endlich vollbracht!
Die erste wirklich neue Version des Moduls ist verfügbar (https://forum.fhem.de/index.php?topic=64317).
Das Modul heißt nun 22_HOMEMODE.pm .

Freue mich auf Euer Feedback.

Gruß
Dan

Ich schliesse mal das Thema hier wegen Eröffnung des neuen!

Gruß
Dan