Modul YAAHM - Versionsgeschichte

Andies: /* Umstellung Sommer- zu Winterzeit */weblink Zeitumstellung

2021-03-28T18:53:58Z

Umstellung Sommer- zu Winterzeit: weblink Zeitumstellung

← Nächstältere Version		Version vom 28. März 2021, 20:53 Uhr
Zeile 207:		Zeile 207:
	Das Reading Astro hat derzeit ein Problem, wenn von Sommer- zu Winterzeit umgestellt wird. Dann verrutscht die Aktualisierung des YAAHM-Geräts in den vorigen Tag und die Termine werden nicht korrekt synchronisiert. Um wieder in den Gleichklang zu kommen, genügt eine einmalige Ausführung des Befehls		Das Reading Astro hat derzeit ein Problem, wenn von Sommer- zu Winterzeit umgestellt wird. Dann verrutscht die Aktualisierung des YAAHM-Geräts in den vorigen Tag und die Termine werden nicht korrekt synchronisiert. Um wieder in den Gleichklang zu kommen, genügt eine einmalige Ausführung des Befehls
	set <YAAHM-Device> initialize		set <YAAHM-Device> initialize
			Siehe dazu https://forum.fhem.de/index.php?topic=74914.0

Andies: /* Sperrung */ https://forum.fhem.de/index.php/topic,75206.msg990555.html#msg990555

2019-11-06T16:53:37Z

Sperrung: https://forum.fhem.de/index.php/topic,75206.msg990555.html#msg990555

← Nächstältere Version		Version vom 6. November 2019, 18:53 Uhr
Zeile 202:		Zeile 202:
	==Sperrung==		==Sperrung==
	Das Reading ''lockstate'' muss den Wert ''unlocked'' haben, damit durch Anklicken der Start-Buttons für die Timer diese auch gestartet werden. Das ist in der Regel beim ersten Laden des Moduls '''nicht''' der Fall, hierzu muss also das Reading von Hand auf den richtigen Wert gesetzt werden. Dazu muss der Befehl '''set ... unlocked''' ausgeführt werden.		Das Reading ''lockstate'' muss den Wert ''unlocked'' haben, damit durch Anklicken der Start-Buttons für die Timer diese auch gestartet werden. Das ist in der Regel beim ersten Laden des Moduls '''nicht''' der Fall, hierzu muss also das Reading von Hand auf den richtigen Wert gesetzt werden. Dazu muss der Befehl '''set ... unlocked''' ausgeführt werden.


			==Umstellung Sommer- zu Winterzeit==
			Das Reading Astro hat derzeit ein Problem, wenn von Sommer- zu Winterzeit umgestellt wird. Dann verrutscht die Aktualisierung des YAAHM-Geräts in den vorigen Tag und die Termine werden nicht korrekt synchronisiert. Um wieder in den Gleichklang zu kommen, genügt eine einmalige Ausführung des Befehls
			set <YAAHM-Device> initialize

Andies: /* Wochen-Profile */

2019-04-10T04:31:37Z

Wochen-Profile

← Nächstältere Version		Version vom 10. April 2019, 06:31 Uhr
Zeile 41:		Zeile 41:
	Ein Wochenprofil definiert dabei diejenigen Ereignisse, die an jedem Wochentag ausgeführt werden sollen. Es ist möglich, mehrere Wochenprofile zu definieren. Zwei Standard-Wochenprofile ''Wecken'' und ''Schlafen'' sind vordefiniert und können nicht gelöscht werden; weitere Wochenprofile können angelegt und wieder gelöscht werden.		Ein Wochenprofil definiert dabei diejenigen Ereignisse, die an jedem Wochentag ausgeführt werden sollen. Es ist möglich, mehrere Wochenprofile zu definieren. Zwei Standard-Wochenprofile ''Wecken'' und ''Schlafen'' sind vordefiniert und können nicht gelöscht werden; weitere Wochenprofile können angelegt und wieder gelöscht werden.

	Für jedes Wochenprofil kann eine manuelle Auslösezeit (im Beispiel oben wären dies montags 5:40, dienstags 5:50, mittwochs bis freitags 6:10 sowie samstags und sonntags off) eingegeben werden. Ist die Auslösezeit später als der gegenwärtige Zeitpunkt, wird sie für den aktuellen Tag verwendet. Ist die Auslösezeit früher als der gegenwärtige Zeitpunkt, wird sie erst am nächsten Tag als Ausnahmezeit verwendet. Lautet die manuelle Auslösezeit 'off', wird der heutige Auslösezeitpunkt abgeschaltet, wenn er noch nicht verstrichen ist - sonst der morgige Auslösezeitpunkt. Nach ~~einmaliger~~ Ausführung wird der manuelle Eintrag gelöscht.		Für jedes Wochenprofil kann eine manuelle Auslösezeit (im Beispiel oben wären dies montags 5:40, dienstags 5:50, mittwochs bis freitags 6:10 sowie samstags und sonntags off) eingegeben werden. Ist die Auslösezeit später als der gegenwärtige Zeitpunkt, wird sie für den aktuellen Tag verwendet. Ist die Auslösezeit früher als der gegenwärtige Zeitpunkt, wird sie erst am nächsten Tag als Ausnahmezeit verwendet. Lautet die manuelle Auslösezeit 'off', wird der heutige Auslösezeitpunkt abgeschaltet, wenn er noch nicht verstrichen ist - sonst der morgige Auslösezeitpunkt. Nach Ausführung wird der manuelle Eintrag anscheinend nicht gelöscht.

	Das Modul ermöglicht mit dem Attribut ''timeHelper'' die Angabe einer Perl-Hilfsfunktion, die für die beiden ersten (Standard-)Wochenprofile bei Eintritt des Events mit den entsprechenden Argumenten aufgerufen wird, siehe [[#Attribute \| Attribute]].		Das Modul ermöglicht mit dem Attribut ''timeHelper'' die Angabe einer Perl-Hilfsfunktion, die für die beiden ersten (Standard-)Wochenprofile bei Eintritt des Events mit den entsprechenden Argumenten aufgerufen wird, siehe [[#Attribute \| Attribute]].

Andies: /* Wochen-Profile */

2019-04-09T02:49:47Z

Wochen-Profile

← Nächstältere Version		Version vom 9. April 2019, 04:49 Uhr
Zeile 41:		Zeile 41:
	Ein Wochenprofil definiert dabei diejenigen Ereignisse, die an jedem Wochentag ausgeführt werden sollen. Es ist möglich, mehrere Wochenprofile zu definieren. Zwei Standard-Wochenprofile ''Wecken'' und ''Schlafen'' sind vordefiniert und können nicht gelöscht werden; weitere Wochenprofile können angelegt und wieder gelöscht werden.		Ein Wochenprofil definiert dabei diejenigen Ereignisse, die an jedem Wochentag ausgeführt werden sollen. Es ist möglich, mehrere Wochenprofile zu definieren. Zwei Standard-Wochenprofile ''Wecken'' und ''Schlafen'' sind vordefiniert und können nicht gelöscht werden; weitere Wochenprofile können angelegt und wieder gelöscht werden.

	Für jedes Wochenprofil kann eine manuelle Auslösezeit (im Beispiel oben wären dies montags 5:40, dienstags 5:50, mittwochs bis freitags 6:10 sowie samstags und sonntags off) eingegeben werden. Ist die Auslösezeit später als der gegenwärtige Zeitpunkt, wird sie für den aktuellen Tag verwendet. Ist die Auslösezeit früher als der gegenwärtige Zeitpunkt, wird sie erst am nächsten Tag als Ausnahmezeit verwendet. Lautet die manuelle Auslösezeit 'off', wird der heutige Auslösezeitpunkt abgeschaltet, wenn er noch nicht verstrichen ist - sonst der morgige Auslösezeitpunkt.		Für jedes Wochenprofil kann eine manuelle Auslösezeit (im Beispiel oben wären dies montags 5:40, dienstags 5:50, mittwochs bis freitags 6:10 sowie samstags und sonntags off) eingegeben werden. Ist die Auslösezeit später als der gegenwärtige Zeitpunkt, wird sie für den aktuellen Tag verwendet. Ist die Auslösezeit früher als der gegenwärtige Zeitpunkt, wird sie erst am nächsten Tag als Ausnahmezeit verwendet. Lautet die manuelle Auslösezeit 'off', wird der heutige Auslösezeitpunkt abgeschaltet, wenn er noch nicht verstrichen ist - sonst der morgige Auslösezeitpunkt. Nach einmaliger Ausführung wird der manuelle Eintrag gelöscht.

	Das Modul ermöglicht mit dem Attribut ''timeHelper'' die Angabe einer Perl-Hilfsfunktion, die für die beiden ersten (Standard-)Wochenprofile bei Eintritt des Events mit den entsprechenden Argumenten aufgerufen wird, siehe [[#Attribute \| Attribute]].		Das Modul ermöglicht mit dem Attribut ''timeHelper'' die Angabe einer Perl-Hilfsfunktion, die für die beiden ersten (Standard-)Wochenprofile bei Eintritt des Events mit den entsprechenden Argumenten aufgerufen wird, siehe [[#Attribute \| Attribute]].

Pahenning: /* (Sicherheits-)Zustand */

2018-12-09T15:01:39Z

(Sicherheits-)Zustand

← Nächstältere Version		Version vom 9. Dezember 2018, 17:01 Uhr
Zeile 58:		Zeile 58:
	== (Sicherheits-)Zustand ==		== (Sicherheits-)Zustand ==
	Der '''housestate''' (bzw. (Sicherheits-)Zustand) besagt, dass sich das SmartHome in einem der vier Zustände ''Nicht gesichert'', ''Gesichert'', ''Geschützt'' oder ''Überwacht'' befindet. Die Festsetzung des Zustands bleibt bestehen, bis eine erneute manuelle Änderung durchgeführt wird. Ausnahme: Wenn das Attribut ''stateAuto'' gesetzt wird, kann sich der Zustand auch bei bestimmten Events ändern. Dabei bedeutet (beispielsweise !)		Der '''housestate''' (bzw. (Sicherheits-)Zustand) besagt, dass sich das SmartHome in einem der vier Zustände ''Nicht gesichert'', ''Gesichert'', ''Geschützt'' oder ''Überwacht'' befindet. Die Festsetzung des Zustands bleibt bestehen, bis eine erneute manuelle Änderung durchgeführt wird. Ausnahme: Wenn das Attribut ''stateAuto'' gesetzt wird, kann sich der Zustand auch bei bestimmten Events ändern. Dabei bedeutet (beispielsweise !)
	**''~~Nicht gesichert~~'' (Readingswert unsecured) = Türen sind unverschlossen, Fenster dürfen geöffnet sein		**''Ungesichert'' (Readingswert unsecured) = Türen sind unverschlossen, Fenster dürfen geöffnet sein
	**''Gesichert'' (Readingswert secured) = Türen sind verschlossen, Fenster dürfen nur in Ausnahmefällen geöffnet sein		**''Gesichert'' (Readingswert secured) = Türen sind verschlossen, Fenster dürfen nur in Ausnahmefällen geöffnet sein
	**''Geschützt'' (Readingswert protected) = Türen sind verschlossen, Fenster dürfen nur in Ausnahmefällen geöffnet sein, die Alarmanlage ist scharf geschaltet		**''Geschützt'' (Readingswert protected) = Türen sind verschlossen, Fenster dürfen nur in Ausnahmefällen geöffnet sein, die Alarmanlage ist scharf geschaltet

Pahenning: /* Wochen-Profile */

2018-12-09T15:01:23Z

Wochen-Profile

← Nächstältere Version		Version vom 9. Dezember 2018, 17:01 Uhr
Zeile 36:		Zeile 36:
	== Wochen-Profile ==		== Wochen-Profile ==
	Es gibt Ereignisse, die an jedem Wochentag ausgeführt werden sollen. Allerdings variiert möglicherweise die Startzeit je Wochentag. Beispielsweise soll an jedem Tag der Woche das Gartentor öffnen; Montags soll dies aber um 5:40, dienstags um 5:50 und Mittwochs bis Freitags um 6:10 geschehen, am Wochenende soll das Gartentor geschlossen bleiben. Da der Befehl an jedem Wochentag derselbe ist und nur die Startzeit variiert, eignet sich dafür das ''Wochenprofil''.		Es gibt Ereignisse, die an jedem Wochentag ausgeführt werden sollen. Allerdings variiert möglicherweise die Startzeit je Wochentag. Beispielsweise soll an jedem Tag der Woche das Gartentor öffnen; Montags soll dies aber um 5:40, dienstags um 5:50 und Mittwochs bis Freitags um 6:10 geschehen, am Wochenende soll das Gartentor geschlossen bleiben. Da der Befehl an jedem Wochentag derselbe ist und nur die Startzeit variiert, eignet sich dafür das ''Wochenprofil''.

			Für jedes Wochen-Profil kann man angeben, ob es auch an einem ''Urlaubstag'' (=Url) und an einem ''Feiertag'' (=Fei) gültig sein soll, siehe [[#Einstellung der Wochen-Profile \| Wochen-Profile]].

	Ein Wochenprofil definiert dabei diejenigen Ereignisse, die an jedem Wochentag ausgeführt werden sollen. Es ist möglich, mehrere Wochenprofile zu definieren. Zwei Standard-Wochenprofile ''Wecken'' und ''Schlafen'' sind vordefiniert und können nicht gelöscht werden; weitere Wochenprofile können angelegt und wieder gelöscht werden.		Ein Wochenprofil definiert dabei diejenigen Ereignisse, die an jedem Wochentag ausgeführt werden sollen. Es ist möglich, mehrere Wochenprofile zu definieren. Zwei Standard-Wochenprofile ''Wecken'' und ''Schlafen'' sind vordefiniert und können nicht gelöscht werden; weitere Wochenprofile können angelegt und wieder gelöscht werden.

Pahenning: /* Tages-Typ */

2018-12-09T14:44:26Z

Tages-Typ

← Nächstältere Version		Version vom 9. Dezember 2018, 16:44 Uhr
Zeile 19:		Zeile 19:
	Ein Tagestyp wird Befehle bestimmen, die im Laufe eines Tages ausgeführt werden sollen. Am Anfang eines Tages (nach Mitternacht) sollen beispielsweise doppelte Einträge in einer Datenbank gelöscht werden, zu Sonnenaufgang werden Rollläden hochgefahren und zur Weckzeit schaltet sich die Kaffeemaschine ein. Dabei soll man aber bei den einzelnen Befehlen unterscheiden können, ob wir einen Arbeitstag, ein Wochenende oder einen Feiertag haben: An einem Werktag soll der Rollladen zu Sonnenaufgang hochfahren, an einem Feiertag dagegen erst später.		Ein Tagestyp wird Befehle bestimmen, die im Laufe eines Tages ausgeführt werden sollen. Am Anfang eines Tages (nach Mitternacht) sollen beispielsweise doppelte Einträge in einer Datenbank gelöscht werden, zu Sonnenaufgang werden Rollläden hochgefahren und zur Weckzeit schaltet sich die Kaffeemaschine ein. Dabei soll man aber bei den einzelnen Befehlen unterscheiden können, ob wir einen Arbeitstag, ein Wochenende oder einen Feiertag haben: An einem Werktag soll der Rollladen zu Sonnenaufgang hochfahren, an einem Feiertag dagegen erst später.

	In YAAHM wird dies durch Tagestypen gelöst. Es sind immer die beiden Tagestypen ''Wochenende'' und ''Werktag'' definiert. Weitere Tagestypen, die dann die Steuerung anderer Befehle erlauben, kann man mit den Attributen ''vacationDevices'' (für Ferientage) und ''holidayDevices'' (Feiertage) hinzufügen. Dabei ist jeweils eine Semikolon-separierte Liste aus holiday-Devices oder Calendar-Devices anzugeben (da die Eingaben direkt in fhem("") eingetragen werden, sind die Regeln der [[Klammerebenen]] zu beachten). Der letztendliche Tagestyp wird dann in einer Priorisierung festgelegt: ''Feiertag'' hat die höchste Priorität, gefolgt von ''Wochenende'', ''Ferientag'' und ''Werktag''. Welcher Tagestyp vorliegt, wird durch YAAHM jeden Morgen kurz nach Mitternacht fixiert.		In YAAHM wird dies durch Tagestypen gelöst. Es sind immer die beiden Tagestypen ''Wochenende'' und ''Werktag'' definiert. Weitere Tagestypen, die dann die Steuerung anderer Befehle erlauben, kann man mit den Attributen ''vacationDevices'' (für Ferientage) und ''holidayDevices'' (Feiertage) hinzufügen. Dabei ist jeweils eine Semikolon-separierte Liste aus holiday-Devices oder Calendar-Devices anzugeben (da die Eingaben direkt in fhem("") eingetragen werden, sind die Regeln der [[Klammerebenen]] zu beachten). Der letztendliche Tagestyp wird dann in einer Priorisierung festgelegt: ''Feiertag'' hat die höchste Priorität, gefolgt von ''Wochenende'', ''Ferientag'' und ''Werktag''. Welcher Tagestyp vorliegt, wird durch YAAHM jeden Morgen kurz nach Mitternacht fixiert.

	~~Für jedes Wochen-Profil kann man angeben, ob es auch an einem ''Ferientag'' (=Fer) und an einem ''Feiertag'' (=Fei) gültig sein soll, siehe [[#Einstellung der Wochen-Profile \| Wochen-Profile]]~~.

	== Tages-Profil ==		== Tages-Profil ==

Pahenning: /* Wochen-Profile */

2018-12-09T14:43:30Z

Wochen-Profile

← Nächstältere Version		Version vom 9. Dezember 2018, 16:43 Uhr
Zeile 39:		Zeile 39:
	Es gibt Ereignisse, die an jedem Wochentag ausgeführt werden sollen. Allerdings variiert möglicherweise die Startzeit je Wochentag. Beispielsweise soll an jedem Tag der Woche das Gartentor öffnen; Montags soll dies aber um 5:40, dienstags um 5:50 und Mittwochs bis Freitags um 6:10 geschehen, am Wochenende soll das Gartentor geschlossen bleiben. Da der Befehl an jedem Wochentag derselbe ist und nur die Startzeit variiert, eignet sich dafür das ''Wochenprofil''.		Es gibt Ereignisse, die an jedem Wochentag ausgeführt werden sollen. Allerdings variiert möglicherweise die Startzeit je Wochentag. Beispielsweise soll an jedem Tag der Woche das Gartentor öffnen; Montags soll dies aber um 5:40, dienstags um 5:50 und Mittwochs bis Freitags um 6:10 geschehen, am Wochenende soll das Gartentor geschlossen bleiben. Da der Befehl an jedem Wochentag derselbe ist und nur die Startzeit variiert, eignet sich dafür das ''Wochenprofil''.

	Ein Wochenprofil definiert dabei diejenigen Ereignisse ~~(Events)~~, die an jedem Wochentag ausgeführt werden sollen. Es ist möglich, mehrere Wochenprofile zu definieren. Zwei Standard-Wochenprofile ''Wecken'' und ''Schlafen'' sind vordefiniert und können nicht gelöscht werden; weitere Wochenprofile können angelegt und wieder gelöscht werden.		Ein Wochenprofil definiert dabei diejenigen Ereignisse, die an jedem Wochentag ausgeführt werden sollen. Es ist möglich, mehrere Wochenprofile zu definieren. Zwei Standard-Wochenprofile ''Wecken'' und ''Schlafen'' sind vordefiniert und können nicht gelöscht werden; weitere Wochenprofile können angelegt und wieder gelöscht werden.

	Für jedes Wochenprofil kann eine manuelle Auslösezeit (im Beispiel oben wären dies montags 5:40, dienstags 5:50, mittwochs bis ~~freitag~~ 6:10 und ~~samstag und sonntag~~ off) eingegeben werden. Ist die Auslösezeit später als der gegenwärtige Zeitpunkt, wird sie für den aktuellen Tag verwendet. Ist die Auslösezeit früher als der gegenwärtige Zeitpunkt, wird sie erst am nächsten Tag als Ausnahmezeit verwendet. Lautet die manuelle Auslösezeit 'off', wird der heutige Auslösezeitpunkt abgeschaltet, wenn er noch nicht verstrichen ist - sonst der morgige Auslösezeitpunkt.		Für jedes Wochenprofil kann eine manuelle Auslösezeit (im Beispiel oben wären dies montags 5:40, dienstags 5:50, mittwochs bis freitags 6:10 sowie samstags und sonntags off) eingegeben werden. Ist die Auslösezeit später als der gegenwärtige Zeitpunkt, wird sie für den aktuellen Tag verwendet. Ist die Auslösezeit früher als der gegenwärtige Zeitpunkt, wird sie erst am nächsten Tag als Ausnahmezeit verwendet. Lautet die manuelle Auslösezeit 'off', wird der heutige Auslösezeitpunkt abgeschaltet, wenn er noch nicht verstrichen ist - sonst der morgige Auslösezeitpunkt.

	Das Modul ermöglicht mit dem Attribut ''timeHelper'' die Angabe einer Perl-Hilfsfunktion, die für die beiden ersten (Standard-)Wochenprofile bei Eintritt des Events mit den entsprechenden Argumenten aufgerufen wird, siehe [[#Attribute \| Attribute]].		Das Modul ermöglicht mit dem Attribut ''timeHelper'' die Angabe einer Perl-Hilfsfunktion, die für die beiden ersten (Standard-)Wochenprofile bei Eintritt des Events mit den entsprechenden Argumenten aufgerufen wird, siehe [[#Attribute \| Attribute]].

Pahenning: /* Tages-Profil */

2018-12-09T14:17:36Z

Tages-Profil

← Nächstältere Version		Version vom 9. Dezember 2018, 16:17 Uhr
Zeile 24:		Zeile 24:

	== Tages-Profil ==		== Tages-Profil ==
	Das Tagesprofil besteht aus einer Kette von Ereignissen ~~(Events)~~, die an jedem Tag ~~zeitgesteuert ablaufen~~. Für jedes ~~Event~~ kann eine Liste von FHEM-Kommandos angegeben werden, die dann ausgeführt werden. Welches ~~Event~~ als ~~letztes durchgeführt wurde~~ steht im Reading '''housetime''', ~~der~~ vorhergehende ~~Event~~ im Reading ''prev_housetime'' und ~~der~~ vom gegenwärtigen Zeitpunkt aus nächste ~~Event~~ im Reading ''next_housetime''.		Das Tagesprofil besteht aus einer Kette von Ereignissen, die an jedem Tag aufeinander folgen. Für jedes Ereignis kann eine Liste von FHEM-Kommandos angegeben werden, die dann ausgeführt werden. Welches Ereignis als Letztes eintrat, steht im Reading '''housetime''', das vorhergehende Ereignis im Reading ''prev_housetime'' und das vom gegenwärtigen Zeitpunkt aus nächste Ereignis im Reading ''next_housetime''.

	Wenn man mit jedem ~~aufgerufenen Event~~ eine weitere selbst definierte Funktion ausführen möchte, kann man dazu das folgende Attribut verwenden		Wenn man mit jedem eingetretenen Ereignis eine weitere selbst definierte Funktion ausführen möchte, kann man dazu das folgende Attribut verwenden
	attr <Modulname> timehelper {hier_die_Perl_Funktion_eintragen(Argumente)}		attr <Modulname> timehelper {hier_die_Perl_Funktion_eintragen(Argumente)}
	Die angegebene Perl-Hilfsfunktion wird dann bei jedem ~~Event~~ aufgerufen. Die entsprechenden Argumente, die je nach aktueller Zeit vom Modul automatisch eingefügt werden, lauten dann wie folgt (siehe auch [[#Attribute \| Attribute]]):		Die angegebene Perl-Hilfsfunktion wird dann bei jedem Ereignis aufgerufen. Die entsprechenden Argumente, die je nach aktueller Zeit vom Modul automatisch eingefügt werden, lauten dann wie folgt (siehe auch [[#Attribute \| Attribute]]):

	*aftermidnight, beforemidnight: ''Nach Mitternacht'' und ''Vor Mitternacht'' sind ~~Events~~, die mit einem Offset an jedem Tag nach bzw. vor Mitternacht ausgeführt werden.		*aftermidnight, beforemidnight: ''Nach Mitternacht'' und ''Vor Mitternacht'' sind Ereignisse, die mit einem Offset an jedem Tag nach bzw. vor Mitternacht ausgeführt werden.
	*sunrise, beforesunrise, aftersunrise: ''Sonnenaufgang'', ''Vor Sonnenaufgang'' und ''Nach Sonnenaufgang'' sind ~~Events~~, die an jedem Tag zu Sonnenaufgang bzw. mit einem Offset davor und danach ausgeführt werden. Der Zeitpunkt des Sonnenaufgangs wird aus dem Modul 95_Astro.pm berechnet. Mit dem Attribut ''sunrise'' kann ausgewählt werden, welcher Horizontwinkel für den Sonnenaufgang genommen wird, siehe dort.		*sunrise, beforesunrise, aftersunrise: ''Sonnenaufgang'', ''Vor Sonnenaufgang'' und ''Nach Sonnenaufgang'' sind Ereignisse, die an jedem Tag zu Sonnenaufgang bzw. mit einem Offset davor und danach ausgeführt werden. Der Zeitpunkt des Sonnenaufgangs wird aus dem Modul 95_Astro.pm berechnet. Mit dem Attribut ''sunrise'' kann ausgewählt werden, welcher Horizontwinkel für den Sonnenaufgang genommen wird, siehe dort.
	*sunset, beforesunset, aftersunset: ''Sonnenuntergang'', ''Vor Sonnenuntergang'' und ''Nach Sonnenuntergang'' sind ~~Events~~, die an jedem Tag zu Sonnenuntergang bzw. mit einem Offset davor und danach ausgeführt werden. Der Zeitpunkt des Sonnenuntergangs wird aus dem Modul 95_Astro.pm berechnet. Mit dem Attribut ''sunset'' kann ausgewählt werden, welcher Horizontwinkel für den Sonnenuntergang genommen wird, siehe dort.		*sunset, beforesunset, aftersunset: ''Sonnenuntergang'', ''Vor Sonnenuntergang'' und ''Nach Sonnenuntergang'' sind Ereignisse, die an jedem Tag zu Sonnenuntergang bzw. mit einem Offset davor und danach ausgeführt werden. Der Zeitpunkt des Sonnenuntergangs wird aus dem Modul 95_Astro.pm berechnet. Mit dem Attribut ''sunset'' kann ausgewählt werden, welcher Horizontwinkel für den Sonnenuntergang genommen wird, siehe dort.
	*morning, noon, afternoon, evening, night: ''Morgen'', ''Mittag'', ''Nachmittag'', ''Abend'' und ''Nacht'' sind ~~Events~~, die zu einer einstellbaren Zeit an jedem Tag ausgeführt werden. Das Reading '''housephase''' nimmt zwischen ''Morgen'' und ''Nacht'' den Wert ''Tageszeit'' an, sonst den Wert ''Nachtzeit''.		*morning, noon, afternoon, evening, night: ''Morgen'', ''Mittag'', ''Nachmittag'', ''Abend'' und ''Nacht'' sind Ereignisse, die zu einer einstellbaren Zeit an jedem Tag ausgeführt werden. Das Reading '''housephase''' nimmt zwischen ''Morgen'' und ''Nacht'' den Wert ''Tageszeit'' an, sonst den Wert ''Nachtzeit''.
	*wakeup, sleep: ''Wecken'' und ''Schlafen'' sind ~~Events~~, die durch die beiden Standard-Wochenprofile gleichen Namens ausgelöst werden. Die entsprechenden Zeiten können von Tag zu Tag beliebig variieren.		*wakeup, sleep: ''Wecken'' und ''Schlafen'' sind Ereignisse, die durch die beiden Standard-Wochenprofile gleichen Namens ausgelöst werden. Die entsprechenden Zeiten können von Tag zu Tag beliebig variieren.

	== Wochen-Profile ==		== Wochen-Profile ==

Pahenning: /* Einführung */

2018-12-09T13:22:01Z

Einführung

← Nächstältere Version		Version vom 9. Dezember 2018, 15:22 Uhr
Zeile 12:		Zeile 12:

	=Einführung=		=Einführung=
	Viele Kommandos in FHEM orientieren sich an Tageszeiten. Beispielsweise sollen Rollläden zu Sonnenaufgang hochgefahren werden, morgens die Kaffeemaschine und die Heizung eingeschaltet und bei Sonnenuntergang kontrolliert werden, ob das Garagentor geschlossen ist. ~~Jede~~ dieser Befehle könnte mit einem zeitgesteuerten at-Device definiert werden. Das Modul ''95_YAAHM.pm'' stellt für diese Aufgaben eine einheitliche und komfortable zu steuernde Oberfläche bereit. Man benötigt somit nicht mehrere at, sondern sammelt alle Befehle in YAAHM. Der Titel '''YAAHM''' ist das Akronym für ''Yet Another Auto Home Module'', denn es gibt ja schon verschiedene Module, die den Zeitablauf in einem SmartHome vereinfachen sollen.		Viele Kommandos in FHEM orientieren sich an Tageszeiten. Beispielsweise sollen Rollläden zu Sonnenaufgang hochgefahren werden, morgens die Kaffeemaschine und die Heizung eingeschaltet und bei Sonnenuntergang kontrolliert werden, ob das Garagentor geschlossen ist. Jeder dieser Befehle könnte mit einem zeitgesteuerten at-Device definiert werden. Das Modul ''95_YAAHM.pm'' stellt für diese Aufgaben eine einheitliche und komfortable zu steuernde Oberfläche bereit. Man benötigt somit nicht mehrere at, sondern sammelt alle Befehle in YAAHM. Der Titel '''YAAHM''' ist das Akronym für ''Yet Another Auto Home Module'', denn es gibt ja schon verschiedene Module, die den Zeitablauf in einem SmartHome vereinfachen sollen.

	Die Philosophie von YAAHM ist die einfache Bedienbarkeit im Frontend, mit Eingabefeldern und Visualisierungselementen und ohne Unmengen von Attributen. Dafür gilt es zunächst, verschiedene Begriffe zu verstehen.		Die Philosophie von YAAHM ist die einfache Bedienbarkeit im Frontend, mit Eingabefeldern und Visualisierungselementen und ohne Unmengen von Attributen. Dafür gilt es zunächst, verschiedene Begriffe zu verstehen.