Neues Modul: 22_HOMEMODE.pm - grundlegende Automationen und mehr

[DeeSPe]

Ja, das stimmt wohl.... 

hab aber einen work-around schritt weitergedacht und dachte damit das Thema der FensterOffen-Warnungen die im Modul Jahreszeiten orientiert betrachtet werden anzugehen ...

ein anderer Ansatz, bei den FensterOffen-Warnungen wäre da wohl sinnvoller....

das total simple Modul für Alles&Jeden gibts nicht, Dan hat für sich was tolles gemacht & uns zur Verfügung gestellt, Danke dafür! darüberhinaus mag er sich auch noch unsere Meinung, Wünsche & Verbesserungsvorschläge anhören. Mein  volles Verständnis dafür, dass er davon nur das coded was er für sinnvoll&nützlich erachtet.

schönen Tag, A.

Du triffst den Nagel auf den Kopf.
Meine Überlegung war Anfangs auch ein extra Modul für die Fensterüberwachung zu bauen.
Aber ganz ehrlich scheue ich mich bei einer solchen, doch immer individuellen, Komplexität davor so etwas zu programmieren.
Alle Faktoren werden sicherlich nie für jeden abgedeckt sein.
Man sollte solche Module m.E. halt immer auch so allgemein wie möglich halten damit die unbedarften User nicht sofort von der Komplexität abgeschreckt werden, für die solche Module eigentlich gemacht werden.
Denn seien wir doch mal ehrlich, wenn sich jemand mit FHEM auskennt und solchen Individualitätsbedarf hat, dann programmiert er/sie sich das genau so wie er/sie es haben will selbst, oder?

Ja klar, am Ende obliegt es dem Modulprogrammierer was und wie er es in sein Modul einbaut.
Gute Programmierer gehen m.E. aber auf "Wünsche der Kunden" ein und versuchen ihr Bestes zu geben.
Ich stehe noch sehr weit am Anfang mit der Perl Programmierung und habe sicherlich bisher mit meinen Funktionen nur ein Wenig an der Oberfläche von Perl gekratzt. Ich bin selbst gespannt wie weit das noch geht und was ich noch dazulernen werde.
Bisher macht es mir jedenfalls Spaß meine gewonnenen Programmierkenntnisse in, für andere Benutzer, sinnvolle FHEM Module zu "gießen".

Denn Eins sollte niemand jemals hier vergessen:
Alle die am Code von FHEM und dessen Modulen mit programmieren machen das aus purer Lust und Laune.
Ohne jegliche Bezahlung und letzten Endes für alle kostenlos und werbefrei.
Sowas geht nur in solch guten Open-Source-Communities.

Gruß
Dan

[Martin Fischer]

Das msg Beispiel ist gut, denn ich habe mich selbst auch darüber geärgert alle Informationen aus einem ellenlangen Thread heraussuchen zu müssen. Ich bekenne mich ja sozusagen als Fan von Loredos Modulen und hatte ihn da auch schon, leider vergebens, um Besserung gebeten.

Dem schliesse ich mich an!

Ich bin mir nur nicht sicher ob wirklich auch all die hier im ersten Beitrag genannten Beispiele zu den jeweiligen Attributen in die commandref sollten.

Es müssen ja nicht alle Beispiele rein. Wichtig sind alle möglichen Attribute sowie eine Beschreibung der logischen Abläufe. DOIF ist jedoch ein sehr gutes Beispiel für eine Topdokumentation (in der deutschen commandref Version).

Vorschlag:
Beim Beispiel Tageszeiten könnte ich mir das innerhalb eines Attributes (damit nicht mehrere Attribute benötigt werden) so vorstellen dass die Tageszeiten vollkommen frei konfigurierbar wären in der Form "Text|Startzeit" und diese mit Leerzeichen voneinander getrennt werden, also etwa:

Code Auswählen Erweitern

attr HomeDaytimes Morgen|7:00 Vormittag|10:00 Mittag|12:30 Nachmittag|15:00 Vorabend|17:30 Abend|19:30 Nacht|23:00
Ich denke das könnte in dieser Form Sinn machen und verständlich sein.

Nun, es gibt viele Möglichkeiten. Dein Weg wäre ein Beispiel.. Ein weiteres Beispiel wäre das Format aus "tempListTmpl" bei CUL_HM, welches Deinem aber sehr ähnelt:

Code Auswählen Erweitern

07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
Tausche Temperaturangaben durch "Tageszeit".

Egal auf welches Format Du Dich einschiesst; gut wäre wenn Du nicht reglementierst, wieviele "Tagesabschnitte" es gibt. So könnte nämlich jeder etwas anderes nutzen. Per default hast Du Deine "Blöcke" drin. Wer die Zeiträume ändern will, der paßt es dann halt an. Wer einen Block mehr benötigt fügt ihn hinzu.

Nur so als Idee. Ich persönlich benötige es (noch) nicht   Mir ist wichtiger zu verstehen, welche Abläufe Du "hardcoded" hast, ohne das ich in den Quelltext schauen oder jedesmal im Forum / Wiki schauen muss.

Hintergrund:
Ich habe seit Jahren ein sehr komplexes Konstrukt entwickelt, das viele Deiner Funktionen bereits umsetzt. Anwesenheitsüberwachung, abhängige Vorgänge, Fenster- / Türüberwachung, Alarmanlage (Kontakte / Bewegung), eigenes Benachrichtigungssystem (nicht MSG) mit fallweisem Routing über Push, eMail, Audible, Visible, Zeitsteuerung, etc. Das umfasst eine Menge Funktionalitäten und arbeitet mit vielen Modulen zusammen. Ich will mal schauen, ob und was ich evtl. durch Dein Modul ablösen kann. Warum, wenn meins läuft? Einfach mal testen was sonst noch so geht

[DeeSPe]

Nur so als Idee. Ich persönlich benötige es (noch) nicht   Mir ist wichtiger zu verstehen, welche Abläufe Du "hardcoded" hast, ohne das ich in den Quelltext schauen oder jedesmal im Forum / Wiki schauen muss.

Danke Martin.
Ich freue mich wirklich sehr über Dein konstruktives Feedback.

Ich will mal schauen, ob und was ich evtl. durch Dein Modul ablösen kann. Warum, wenn meins läuft? Einfach mal testen was sonst noch so geht

Das freut mich umso mehr wenn selbst ein alter FHEM Hase der Saat eines Jünglings eine Chance gibt.
Desto mehr sollte ich mich wohl anstrengen...

Gruß
Dan

[C0mmanda]

Moin,

Zunächst mal vielen Dank dass du soviel Mühe in Zeit in dieses Modul investierst.
Aufgrund der größe des Moduls war ich zunächst, ehrlich gesagt, erst mal abgeschreckt.
Jetzt habe ich mich aber doch mal getraut mich in das Modul einzuarbeiten und die Begeisterung wächst!

Es wird noch dauern bis ich mich da komplett durchgearbeitet und alles verstanden habe.

Ein paar Dinge habe ich aber:

- Wo liegt z.B. der Unterschied zwischen: (asleep ist nur ein Beispiel).

• HomeCMDmode-asleep
• HomeCMDmode-asleep-resident

Was triggert nur "asleep" und was "asleep-resident" ?
Das habe ich noch nicht verstanden.

- Wäre es möglich ähnlich des "HomeAutoAwoken" Attributs ein "HomeAutoAbsent" einzubauen?
Hintergrund ist der dass ich in Verbindung mit RESIDENTS meine Heizung 30min nachdem alle das Haus verlassen habe absenke.
Kommt innerhalb der 30min. jemand zurück bleibt die Heizung wie sie ist. So wird nicht wie wild reguliert wenn man mal 10min. weg ist.
Ich könnte mir hierdurch einen weiteren dummy und einen watchdog sparen.

Und: Wo kann ich sehen welchen Status das Haus gerade hat? (home, absent, awoken) oder ist das nicht vorgesehen?
(Eventuell übersehe ich das auch einfach..)

- Mir ist aktuell nicht ganz klar ob ich in den HomeCMD-Attributen jetzt noch perl + FHEM-Code mischen kann.
Wenn ja, könntest du mal ein Beispiel posten?
Bei mir funktioniert das nämlich nicht, ich erhalte dann immer Fehlermeldungen sobald perl anfängt.
Bin daher jetzt erstmal dazu übergegangen alles in perl zu schreiben...

- Vielleicht ein Luxuswunsch:
Wenn gerade Timer laufen (z.B. eben HomeAutoAwoken) kann man das irgendwo sehen?

Das sollte es erstmal gewesen sein!
Sicher kommen noch ein paar mehr Fragen wenn ich mich weiter einarbeite

Vielen Dank und weiter so! Ich hoffe das Modul schafft es offiziell zu werden!

grtz
CmdA
Vielen Dank

[Martin Fischer]

Danke Martin.

Danke für die Blumen... aber lass mal die Kirche im Dorfe..

Dank Deiner Mühen gehört der Strauß Dir 

Einen habe ich noch:

HomeAutoAlarmModes
Als nächstes sollte man sich entscheiden ob die Alarm Modus evtl. nicht automatisch zum jeweiligen Modus des HOMEMODE Device geschaltet werden sollen. Standardmäßig werden die Alarm Modus automatisch gesteuert. Ist das nicht erwünscht, so ist der Wert dieses Attributs auf 0 zu setzen.
Bei Modus "absent" des HOMEMODE Device wird automatisch auf "armaway" geschaltet.
Bei Modus "home" des HOMEMODE Device wird automatisch auf "disarm" geschaltet.
Bei Modus "asleep" des HOMEMODE Device wird automatisch auf "armnight" geschaltet.
Alarm Modus "armhome" kann nur manuell gesetzt werden.
Werte: 0 oder 1
Standardwert: 1

Hier vermischt Du zwei Zustände. Zum einen in Abhängigkeit der An- bzw. Abwesendheit (disarm|armaway) und zum anderen in Bezug zur Zeit (armnight). Dazu kommt noch der "manuelle" Modus zur Aktivierung, wenn man zu Hause ist (armhome).

Die Vermischung ist aus meiner Sicht etwas ungünstig. Es gibt durchaus Szenarien bei der "Man(n)" zeitgesteuert schalten will, unabhängig von der Präzens.

Ich würde das evtl. anders definieren:
disarm = Alarm Mode ausgeschaltet. Es findet kein Automatismus statt.
armaway = wenn 'residentsTotalAbsent' gleich 'residentsTotal' ist, also alle sind ausser Haus.
armhome = wenn 'residentsTotalPresent' > 0 und der Alarm Mode manuell (über Taster) oder zeitgesteuert eingeschaltet wurde.

armnight würde ich verwerfen und stattdessen eine Zeitsteuerung spendieren, die dann noch nach Wochentag und Wochenende, bzw. Feiertag aufbrechen.

Dadurch könntest "Man(n)" den Alarm Mode entweder manuell oder per Zeitschaltung gezielt übersteuern.

Zur Steuerung empfehlen sich mehrere (manuell sowie automatisch auslösenden) Schaltzustände:
"Scharfschaltung": "absent", "present", "unsharp"  entspräche in etwa den Zuständen "armaway", "armhome", "disarm"
"Aktivierung bei An- / Abwesendheit": "on", "off" => Steuert den Automatismus für das Setzen "armaway", wenn "off", dann erfolgt keine Zustandsänderung.
"Zeitschaltung": "on", "off" => Steuert wann "Scharfschaltung: present" (=ähnlich armnight) an und ausgeschaltet wird.

So kann man viele Szenarien abbilden und ggf. übersteuern.
Ist "Aktivierung bei An- / Abwesendheit" aus und "Zeitschaltung" an, dann wird automatisch die "Scharfschaltung" auf "absent" also "armaway" in einem definierten Zeitfenster gesetzt. Hier übersteuert die "Zeitschaltung" die "Aktivierung bei An- / Abwesendheit".
Ist "Aktivierung bei An- / Abwesendheit" an und "Zeitschaltung" an, dann wird automatisch die "Scharfschaltung" auf "present" also "armhome" in einem definierten Zeitfenster gesetzt.
Ist "Aktivierung bei An- / Abwesendheit" aus und "Zeitschaltung" aus, dann kann der Zustand "absent", "present", "unsharp" bzw. "armaway", "armhome", "disarm" dennoch manuell über Taster / Dummys geschaltet werden. Zum Beispiel von unterwegs ohne Berücksichtigung der PRESENCE Devices.

Ich habe zusätzlich noch ein "Delay" eingebaut. D.h. wenn bei mir auf "absent" oder "present" geschaltet wird, dann ist der Zustand erst mal "delayed". Die Zeit ist frei wählbar, bei mir derzeit 240 Sekunden. Dann erfolgt eine Ansage auf diversen Geräten in diversen zentralen Räumen: "Die Alarmanlage wird in 240 Sekunden scharf geschaltet.". So hat man noch Zeit um das eine oder andere noch zu erledigen oder aber auch um den Vorgang manuell abzubrechen.

Ich arbeite schon viele Jahre mit PRESENCE Devices über Bluetooth, Wlan, Geofancing, G-Tags, etc. Pro Person gibt es 4 Instanzen die in Summe steuern wann jemand als Abwesend gekennzeichnet wird. Und dennoch gibt es Tage an denen man manuell eingreifen muss, da mal wieder etwas vollkommen aus dem Ruder läuft.

Das mal als Anregung.

An dieser Stelle auch nochmal ein Lob für Deine Arbeit.

Viele Grüße
Martin

[DeeSPe]

Aufgrund der größe des Moduls war ich zunächst, ehrlich gesagt, erst mal abgeschreckt.

Wieso, es sind doch nur 140kB.

- Wo liegt z.B. der Unterschied zwischen: (asleep ist nur ein Beispiel).

• HomeCMDmode-asleep
• HomeCMDmode-asleep-resident

Was triggert nur "asleep" und was "asleep-resident" ?
Das habe ich noch nicht verstanden.

Das Erste wird getriggert wenn man manuell den mode auf asleep setzt.
Das Zweite wird nur getriggert wenn der mode indirekt durch einen RESIDENT gesetzt wurde.

- Wäre es möglich ähnlich des "HomeAutoAwoken" Attributs ein "HomeAutoAbsent" einzubauen?
Hintergrund ist der dass ich in Verbindung mit RESIDENTS meine Heizung 30min nachdem alle das Haus verlassen habe absenke.
Kommt innerhalb der 30min. jemand zurück bleibt die Heizung wie sie ist. So wird nicht wie wild reguliert wenn man mal 10min. weg ist.
Ich könnte mir hierdurch einen weiteren dummy und einen watchdog sparen.

Sowas hatte ich bisher nicht vorgesehen!
Ich überlege mir mal das evtl. mit aufzunehmen als konfigurierbares "delayed absent".
Aber wieso ein dummy?
Ich starte bisher bei absent ein at welches nach der konfigurierten Zeit prüft ob immer noch der mode absent ist. Wenn ja wird die Heizung heruntergeregelt.

- Mir ist aktuell nicht ganz klar ob ich in den HomeCMD-Attributen jetzt noch perl + FHEM-Code mischen kann.
Wenn ja, könntest du mal ein Beispiel posten?
Bei mir funktioniert das nämlich nicht, ich erhalte dann immer Fehlermeldungen sobald perl anfängt.
Bin daher jetzt erstmal dazu übergegangen alles in perl zu schreiben...

Ja, das ist mir leider auch nicht ganz klar.
Das Mischen kann klappen, muss aber nicht. Ich habe dafür leider noch keine allgemeingültige Erklärung gefunden in welchem Zusammenhang es funktioniert und in welchem nicht.
Das hat aber nichts speziell mit HOMEMODE zu tun sondern unterliegt den selben Bedingungen wie auch der Code eines at oder notify.
Ich denke der beste Tipp den ich hier geben kann lautet:
Wenn Perl in einem HomeCMD Attribut benötigt wird, dann den ganzen Code für dieses Attribut in Perl schreiben. Kommt man ohne Perl aus, also nur FHEM Code, so ist auch dieses möglich.

- Vielleicht ein Luxuswunsch:
Wenn gerade Timer laufen (z.B. eben HomeAutoAwoken) kann man das irgendwo sehen?

Nö, im Device selbst ist das nicht zu sehen.
Alle Timer erstellen aber immer temporäre at(s) die mit "atTmp" beginnen.
Diese kannst mit folgendem Befehl in der FHEM Eingabezeile anzeigen:

Code Auswählen Erweitern

list TYPE=at:FILTER=NAME=atTmp.*




@Martin:
Das muss ich mir morgen nochmal in Ruhe durchlesen, das überfordert meinen jetzigen Geisteszustand gerade etwas.
Das mit dem Delay habe ich bereits verstanden und das macht m.E. auch Sinn.

Gruß
Dan

[C0mmanda]

Wieso, es sind doch nur 140kB.

Das Erste wird getriggert wenn man manuell den mode auf asleep setzt.
Das Zweite wird nur getriggert wenn der mode indirekt durch einen RESIDENT gesetzt wurde.

Aktuell ist "HomeCMDmode-awoken" gefüllt.
Durch ein at wird morgens RESIDENT auf awoken gesetzt.
Homemode führt die Aktionen aus.
Fällt der Fall unter manuell, also ersteres? Oder ist da was nicht i.O.?
Sorry wenn ich da etwas auf dem Schlauch stehe...
Stellt für mich aktuell überhaupt kein Problem dar, mir ist nur leider nicht klar ob es auch so vorgesehen ist.

Sowas hatte ich bisher nicht vorgesehen!
Ich überlege mir mal das evtl. mit aufzunehmen als konfigurierbares "delayed absent".
Aber wieso ein dummy?
Ich starte bisher bei absent ein at welches nach der konfigurierten Zeit prüft ob immer noch der mode absent ist. Wenn ja wird die Heizung heruntergeregelt.

Das ist natürlich auch eine Möglichkeit!
Daran hatte ich gar nicht gedacht.
Danke für den Tip, das löst mein Problem schon.

Dennoch wäre es meiner Ansicht nach nur konsequent, da autoAwoken und autoAsleep ja bereits integriert sind.

Ja, das ist mir leider auch nicht ganz klar.
Das Mischen kann klappen, muss aber nicht. Ich habe dafür leider noch keine allgemeingültige Erklärung gefunden in welchem Zusammenhang es funktioniert und in welchem nicht.
Das hat aber nichts speziell mit HOMEMODE zu tun sondern unterliegt den selben Bedingungen wie auch der Code eines at oder notify.
Ich denke der beste Tipp den ich hier geben kann lautet:
Wenn Perl in einem HomeCMD Attribut benötigt wird, dann den ganzen Code für dieses Attribut in Perl schreiben. Kommt man ohne Perl aus, also nur FHEM Code, so ist auch dieses möglich.

Auch damit kann ich leben! Danke
Ist ja eh schon FHEM-weit so, dann ist es in deinem Modul auch kein Problem!

Nö, im Device selbst ist das nicht zu sehen.
Alle Timer erstellen aber immer temporäre at(s) die mit "atTmp" beginnen.
Diese kannst mit folgendem Befehl in der FHEM Eingabezeile anzeigen:

Code Auswählen Erweitern

list TYPE=at:FILTER=NAME=atTmp.*

Und nochmal:
Danke für den Hinweis.

Die Möglichkeiten deines Moduls erschliessen sich einem erst nach und nach aber ich würde es jetzt schon nicht mehr missen wollen!
Allein schon die Tatsache das man alle Vorgänge sieht welche bei home/absent/awoken etc. geschaltet werden dient enorm der Übersichtlichkeit!

Eine weitere Frage ist noch aufgekommen:
In deinem Code für die Bewegungsmelder (HomeCMDmotion) rufst du die sub? "HOMEMODE_hourmaker" auf ich konnte aber keine Erklärung dazu finden?! (Vielleicht bin ich auch nur ein weiteres mal blind... sorry falls es so ist).

grtz
CmdA

[DeeSPe]

Aktuell ist "HomeCMDmode-awoken" gefüllt.
Durch ein at wird morgens RESIDENT auf awoken gesetzt.
Homemode führt die Aktionen aus.
Fällt der Fall unter manuell, also ersteres? Oder ist da was nicht i.O.?
Sorry wenn ich da etwas auf dem Schlauch stehe...
Stellt für mich aktuell überhaupt kein Problem dar, mir ist nur leider nicht klar ob es auch so vorgesehen ist.

Sorry, hab mich wohl etwas missverständlich ausgedrückt.
Die HomeCMDmode-awoken/asleep/.... Attribute werden AUCH ausgeführt wenn man den mode manuell setzen würde.
Alle anderen sind eben nur RESIDENT spezifisch.

Das ist natürlich auch eine Möglichkeit!
Daran hatte ich gar nicht gedacht.
Danke für den Tip, das löst mein Problem schon.

Dennoch wäre es meiner Ansicht nach nur konsequent, da autoAwoken und autoAsleep ja bereits integriert sind.

Wie gesagt, dafür werde ich eine konfigurierbare Erweiterung einbauen.

Und nochmal:
Danke für den Hinweis.

Bitte!

Eine weitere Frage ist noch aufgekommen:
In deinem Code für die Bewegungsmelder (HomeCMDmotion) rufst du die sub? "HOMEMODE_hourmaker" auf ich konnte aber keine Erklärung dazu finden?! (Vielleicht bin ich auch nur ein weiteres mal blind... sorry falls es so ist).

Die Funktion habe ich nicht weiter erklärt.
Ich dachte, wenn es jemanden interessiert, dann wird er/sie schon fragen.
Das ist die Funktion die die übergebene Minuten (bis 5999.9) in einen Zeitstempel passend für ein at umrechnet.
Aus HOMEMODE_hourmaker(100) wird dann z.B. 01:40:00.

Danke für Dein Interesse an dem Modul.

Gruß
Dan

[Martin Fischer]

@Martin:
Das muss ich mir morgen nochmal in Ruhe durchlesen, das überfordert meinen jetzigen Geisteszustand gerade etwas.
Das mit dem Delay habe ich bereits verstanden und das macht m.E. auch Sinn.

Hallo Dan,

ich fasse es (hoffentlich  ) mal etwas übersichtlicher zusammen. So habe ich es seit einigen Jahren bei mir mit einer (unveröffentlichten) Lösung implementiert. Damit sind einige Kombinationen denk- und viele "Szenarien" abbildbar. Einen Teil steuerst Du ja schon ähnlich / gleich.

Zustände (reading "modeAlarm"):

modeAlarm	Zustand	Beschreibung
off	aus	Deaktiviert. Keine (automatischen) Aktionen erfolgen.
unsharp	aus	Modus, wenn "im Standby".
absent	an	Modus, wenn niemand zu Hause ist.
present	an	Modus, wenn jemand zu Hause ist.

Hilfszustände (extra reading):

reading	setzt voraus / löst aus	Beschreibung
delayed	unsharp	Signalisiert, das nach Ablauf von <n> Sekunden eine Scharfschaltung stattfindet.
locked	(absent|present)	Wird gesetzt wenn Modus absent oder present aktiv ist (die "Anlage scharf" ist). Nur ein unsharp kann den Zustand ändern. Dient zum Schutz vor unbefugten / unbeabsichtigten Zustandswechsel(n).
wayhome	unsharp	Wird gesetzt wenn "An- und Abwesenheit überwachen" aktiv ist und sich ein Bewohner dem Haus / der Wohnung nähert.

Regeln:

• (absent|present) kann nur gesetzt werden, wenn Zustand unsharp gesetzt und locked nicht gesetzt ist.
• Ein direkter Wechsel von absent auf present ist somit nicht möglich.
• delayed kann durch unsharp abgebrochen (übersteuert) werden.
• off kann nur im Zustand unsharp gesetzt werden.

manuelle Steuerung von modeAlarm per FHEM Device (physikalischer Taster, Fernbedienung, Dummy-Device):

Trigger	löst aus
off	ausschalten.
unsharp	unscharf schalten / delayed abbrechen.
absent	scharf schalten beim Verlassen des Hauses / der Wohnung. Berücksichtigt locked, aktiviert delayed.
present	scharf schalten bei Anwesenheit. Berücksichtigt locked, aktiviert delayed.

Hilfssteuerung per FHEM Device (physikalischer Taster, Fernbedienung, Dummy-Device):

Steuerung	Zustände
An- / Abwesenheit überwachen	(an|aus)
Zeitschaltung	(an|aus)

Steuerung über Trigger (werden bei Zustand modeAlarm:off und An- / Abwesenheit überwachen:aus ignoriert):

modeAlarm	Auslöser
unsharp	Bewohner kommen nach Hause; unscharf schalten. Gesteuert über PRESENCE, Geofancing, Script, Timer, etc.
absent	Bewohner sind abwesend; scharf schalten. Gesteuert über PRESENCE, Geofancing, Script, Timer, etc. Berücksichtigt locked, aktiviert delayed.
present	Bewohner sind anwesend; scharf schalten. Gesteuert über Timer in Kombination mit PRESENCE, Geofancing, Script, etc. Berücksichtigt locked, aktiviert delayed.

Steuerung über Zeitschaltung(en) (werden bei Zustand modeAlarm:off und Zeitschaltung:aus ignoriert):

• Wenn Zeitschaltung:an wird Modus absent oder present unter Berücksichtigung der An- / Abwesenheit gesetzt.
• Unterschiedliche Zeiten (optional) für Wochentage, Wochentags und Wochenende / Feiertage, Beispiel:
• 
  
  • weekday [22:30 - 07:30]
  • weekend [22:30 - 08:30]
  • day_monday [23:30 - 07:30]
  • day_friday [23:30 - 07:30]
  • Benannte Wochentage übersteuern die Tage, die unter "weekday" / "weekend" fallen.

In Abhängigkeit von absent / present werden motions(Inside|Outside), contacts(Doors(Inside|Main|Outside)Open) bzw. contacts(Outside|Windows)Open überwacht.

Bei mir läuft das in Kombination mit eigenen Funktionen, notify, DOIF, Dummy-Devices, structure, PRESENCE, GEOFANCY, RESIDENTS, ROOMMATE. Ich hoffe, ich habe nichts vergessen, bzw. es haben sich keine Fehler eingeschlichen.

Ich denke, das obige Funktionen / Zustände allgemein nützlich sind und Dein Modul diesbzgl. sehr "mächtig" werden könnte. Da ich das selber so seit Jahren am Laufen habe, kann ich nur positiv über die Möglichkeiten berichten. Auch der WAF ist gegeben.

Bei mir gibt es zwei an zentralen Stellen (EG|OG) platzierte Taster (Homematic, 6fach) mit denen folgendes manuell geschaltet wird / werden kann:
Taste 1 - kurz: manuelle Scharfschaltung bei Anwesenheit (nach "delayed" => "present")
Taste 1 - lang: manuelle Scharfschaltung vor Verlassen des Hauses (nach "delayed" => "absent"). Diese Taste wird dank PRESENCE so gut wie nie genutzt. 
Taste 2 - kurz/lang: manuelle Unscharfschaltung. Falls Zeitschaltung aktiv und man z.B. Besuch hat oder PRESENCE mal nicht so will wie es soll 
Taste 3 - kurz: "An- / Abwesenheit überwachen" einschalten
Taste 4 - kurz: "An- / Abwesenheit überwachen" ausschalten
Taste 5 - kurz: "Zeitschaltung" einschalten
Taste 6 - kurz: "Zeitschaltung" ausschalten

Neben dem Schalter hängt eine Statusanzeige (Homematic Statusanzeige LED16), die - wie der Name bereits verrät - den jeweiligen Status anzeigt:

Beschriftung	Zustand	LED
Alarmanlage	(unsharp|off)	aus
Alarmanlage	delayed	orange
Alarmanlage	present	grün
Alarmanlage	absent	rot
An- / Abwesenheit überwachen	an	grün
An- / Abwesenheit überwachen	aus	aus
Zeitschaltung	an	grün
Zeitschaltung	aus	aus

WAF! 

Viele Grüße
Martin

[C0mmanda]

Sorry, hab mich wohl etwas missverständlich ausgedrückt.
Die HomeCMDmode-awoken/asleep/.... Attribute werden AUCH ausgeführt wenn man den mode manuell setzen würde.
Alle anderen sind eben nur RESIDENT spezifisch.

Jetzt habe auch ich es verstanden

Wie gesagt, dafür werde ich eine konfigurierbare Erweiterung einbauen.

Die Funktion habe ich nicht weiter erklärt.
Ich dachte, wenn es jemanden interessiert, dann wird er/sie schon fragen.
Das ist die Funktion die die übergebene Minuten (bis 5999.9) in einen Zeitstempel passend für ein at umrechnet.
Aus HOMEMODE_hourmaker(100) wird dann z.B. 01:40:00.

Danke für Dein Interesse an dem Modul.

Gruß
Dan

Nochmals:
Danke.
Nun habe ich alles verstanden

Werde mich sicherlich noch melden je tiefer ich mich in das Modul einarbeite

grtz
CmdA

NACHTRAG:

Eine Frage habe ich dann doch noch:

"HomeAutoAwoken" ist gesetzt, sagen wir 30Min.
Vor Ablauf der 30min. Verlassen nun alle Mitbewohner aus irgendeinem Grund das Haus.

Was passiert bei Ablauf der 30min. ?

Danke.

[alex885]

FYI

Beim Versuch attr HomeAutoAwoken auf 0 zu setzen:

Code Auswählen Erweitern

Invalid value 0 for attribute HomeAutoAwoken. Must be a number from 0 to 5999.9.

hab dann gelöscht

A.

[DeeSPe]

NACHTRAG:

Eine Frage habe ich dann doch noch:

"HomeAutoAwoken" ist gesetzt, sagen wir 30Min.
Vor Ablauf der 30min. Verlassen nun alle Mitbewohner aus irgendeinem Grund das Haus.

Was passiert bei Ablauf der 30min. ?

Danke.

Es passiert genau: gar nichts!
Schau Dir doch einfach das erstellte at an!

Code Auswählen Erweitern

set $dev:FILTER=state=awoken state home

Gruß
Dan

[DeeSPe]

FYI

Beim Versuch attr HomeAutoAwoken auf 0 zu setzen:

Code Auswählen Erweitern

Invalid value 0 for attribute HomeAutoAwoken. Must be a number from 0 to 5999.9.

hab dann gelöscht

A.

Danke für den Hinweis.
Ich werde das anpassen!
0 ist letztendlich das Selbe wie nicht gesetzt und darum im Moment nicht erlaubt! Der minimale Wert muss momentan mindestens 0.1 betragen.
Ich werde aber die 0 als gültigen Wert erlauben da es ja auch so beschrieben steht.

HomeAutoAwoken
Ist hier ein Wert größer 0 angegeben, so wird beim Erwachen ("awoken" oder "home nach asleep") jedes ROOMMATE/GUEST dieser auf "awoken" gesetzt und ein Timer gestartet der den jeweiligen ROOMMATE/GUEST nach der hier angegeben Zeit in Minuten auf "home" setzt.
Ich persönlich habe diesen Wert auf 10 gesetzt.
Werte: 0 bis 5999.9
Standardwert: 0

Gruß
Dan

[DeeSPe]

Ich habe meinen GitHub Account wiederbelebt.

Eins vorweg, ich bin mit den ganzen dort verwendeten Termini noch nicht vertraut.
Dafür muss ich mich noch weiter in diese, für mich neue, Materie einarbeiten.

Was ich vorerst gemacht habe, ich hoffe das entspricht einer gängigen Vorgehensweise:

Ich habe einen master Branch erstellt und dieser beinhaltet die aktuelle stabile Version dieses Moduls.
Diese Version ist aktuell identisch mit der aus dem ersten Beitrag.

Zusätzlich habe ich einen dev Branch erstellt, dort habe ich z.b. schon die custom HomeDaytimes eingebaut (noch nicht vollumfänglich getestet).
Der dev Branch könnte aber unter Umständen nicht stabil sein, da wenig bis gar nicht getestet. Ich nutze den dev Branch nämlich manchmal einfach auch nur zum Sync zwischen meinen Computern und da kann auch mal ein Funktion nur halb fertig sein.
Oder sollte ich dafür nochmal einen separaten Branch erstellen? Mir fehlt hier die Erfahrung!
UPDATE: Klar, das Update steht in FHEM erst bereit wenn ich die controls_HOMEMODE.txt aktualisiere! Somit erübrigt sich die Frage nach einem extra Branch für meinen Sync.

Die stabile Version des Moduls kann nun über folgenden Befehl innerhalb FHEM aktualisiert werden:

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/deespe/fhem-HOMEMODE/master/controls_HOMEMODE.txt

Wer möchte kann das Repository auch dauerhaft hinzufügen mit:

Code Auswählen Erweitern

update add https://raw.githubusercontent.com/deespe/fhem-HOMEMODE/master/controls_HOMEMODE.txt

Den dev Branch (bitte mit Vorsicht genießen) gibt es hiermit:

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/deespe/fhem-HOMEMODE/dev/controls_HOMEMODE.txt

Ich hoffe das ich's für's Erste vernünftig eingerichtet habe. Auch wenn mir noch 1-3 Dinge nicht ganz klar sind.
z.B.: Muss ich die controls_HOMEMODE.txt immer manuell bearbeiten? Wie machen das Andere?
Hab noch viel zu lesen...

@Martin:
Vielen Dank für Deine Vorschläge und Erklärungen, ich werde diese sobald es geht berücksichtigen.
Vorher nehme ich mich mal der Dokumentation an und werde die möglicherweise fehlenden Informationen ergänzen.

Gruß
Dan

[DeeSPe]

Könntest Du bitte noch in die Dokumentation aufnehmen, welche Konstanten und Automatismen Du intern nutzt.

Konstanten wären z.B. die Zeitfenster für die Tageszeiten. Das hast Du zwar hier im Thread schon geschrieben, jedoch steht es nicht in der Doku. Evtl. gibt es ja auch noch weitere Konstanten die Du nutzt.

Es wäre auch hilfreich, wenn in der Dokumentation noch aufgeführt wird, welche internen "hardcoded" Auslöser, Timer, Entscheidungen, etc. Du nutzt.

Zum Beispiel, das der Alarmmode gesetzt wird, wenn alle Bewohner abwesend sind. Bei der Vielzahl der Möglichkeiten die Dein Modul bietet - und es soll ja nach Möglichkeit verhindern das man notifys, doifs, dummys baut - sollte die Logik gut dokumentiert sein. Sonst definiert man dann doch etwas und das macht Dein Modul eigentlich schon von Haus aus..

Viele Grüße
Martin

Hallo Martin,

ich habe (hoffentlich) alle geforderten Informationen in der commandref ergänzt und den dev Branch aktualisiert.

Für meinen persönlichen Sync habe ich nun doch noch einen weiteren Branch auf gemacht.
Sobald ich die im sync Branch gemachten Änderungen so weit funktionieren und genau getestet werden müssen, werde ich diese mit dem dev Branch mergen.
Somit sollte der dev Branch auf jeden Fall eine bessere Stabilität erhalten. Vom Einsatz in einem Produktivsystem rate ich aber weiterhin ab (auch wenn ich persönlich das natürlich tun muss)!

Eins nach dem Anderen...

Erst sollten diese bekannt sein und dann könnte man sie konfigurierbar machen

Mit der nächsten master Version werden die Informationen zu daytime und season bekannt(er) gemacht und daytime wird auch konfigurierbar sein.
Bis dahin wird es sicher auch ein "delayed absent" mit passendem HomeCMD Attribut geben.
Die gewünschten Änderungen zu modeAlarm werde ich bis dahin sicher noch nicht bringen können, denn dazu muss ich mir erst einmal eine Strategie ausdenken um kompatibel mit den bisherigen modeAlarm Settings zu bleiben.

Was aber noch in der Dokumentation Erwähnung finden sollte, ist eine Auflistung der generierten Events.

Das ist mir tatsächlich noch nicht ganz klar!
Jede Erzeugung eines Readings erzeugt auch ein Event sofern es nicht durch die event-on-.... Attribute verändert wurde.
Soll ich die alle nochmal einzeln auflisten? Das wird eine ellenlange Liste...

Gruß
Dan