Modulfamilie für das Zuhause / 00_HOMESTATE, 01_ZONESTATE, 02_ROOMSTATE

Begonnen von Loredo, 08 Mai 2017, 10:51:48

Vorheriges Thema - Nächstes Thema

Loredo

Hallo zusammen,

mit Hinweis auf die inzwischen etablierte Modulfamilie für Bewohner startet nun die Preview-Phase für die komplementäre Modulfamilie für das Zuhause:

00_HOMESTATE
01_ZONESTATE
02_ROOMSTATE

(00_HOMESTATE wurde ja auch bereits schonmal vorangekündigt  ;) )

Auch hier werden die Module wieder hierarchisch aufeinander aufbauen und entsprechend ihrer Bezeichnung einzelne Räume, Flure und Wohneinheiten repräsentieren. Außerdem ist eine enge Verzahnung mit den vorhandenen Funktionen der Module RESIDENTS, ROOMMATE, PET und GUEST (sowie deren Unterfunktionen wie z.B. dem Wakeuptimer) gegeben.
Alle Module sind Multi-Language und können sowohl in Englisch als auch gleichzeitig in Deutsch verwendet werden (weitere Sprachen können einfach hinzugefügt werden, sofern sich Übersetzer finden).

Den Anfang macht 00_HOMESTATE, welches in einer ersten Ausbaustufe im Anhang dieses Beitrags herunterladbar ist. Gesucht sind nun Freiwillige zwecks ausprobieren und Feedback.

Nachdem die Datei ins FHEM Verzeichnis nach /opt/fhem/FHEM kopiert wurde, wird das Gerät wie folgt in FHEM definiert:


define Home HOMESTATE


Wichtig: Voraussetzung ist eine FHEM Installation, die auf dem aktuellsten Stand sein muss, da große Teile des Moduls in einer zentralen Datei gespeichert sind, die sich alle Module teilen.

Sofern vorhanden, wird ein RESIDENTS, ROOMMATE oder PET Device direkt verknüpft und auch dessen Spracheinstellung übernommen (ansonsten wird ein neues RESIDENTS Gerät angelegt). Sofern eine globale Spracheinstellung gewählt wurde, wird diese verwendet.
Sind mehrere RESIDENTS, ROOMMATE, PET oder GUEST Geräte vorhanden, kann man dies über das Attribut "ResidentsDevices" ändern und auch weitere hinzufügen, sofern ein anderes Gerät oder auch mehrere berücksichtigt werden sollen.
Außerdem setzt das Modul auf die Attribute altitude, longitude und holiday2we des global-Devices, welche man optimalerweise zuvor bereits konfiguriert hatte (Beschreibung siehe Commandref).

Die konfigurierbaren Attribute am HOMESTATE Device sind übersichtlich:

       
  • DebugDate: setzt den Gerätestatus auf ein bestimmtes Datum und eine feste Uhrzeit, um zu überprüfen, wie sich das Gerät zu diesem Zeitpunkt verhält.
    Beispiele:
    05-09
    05-09 13:00
    05-09 13:00:30
    2017-05-09
    2017-05-09 13:00
    2017-05-09 13:00:30
  • HolidayDevices: kann eine Liste von Geräten des Typs "holiday" enthalten, welche als Urlaubstage gewertet werden sollen. Diese sind ergänzend zu der Definition des Attributs "holiday2we" beim global-Device zu sehen.
  • Lang: setzt explizit eine Spracheinstellung, unabhängig des Attributs "language" am global-Device
  • ResidentsDevices: gibt an, welche RESIDENTS, ROOMMATE, PET und GUEST Devices für den Aktivitäts- und Anwesenheitsstatus verwendet werden. Achtung: Es ist nicht notwendig ROOMMATE, PET oder GUEST Geräte hier mit anzugeben, die bereits einem RESIDENTS Gerät zugeordnet sind, welches man bereits hier mit angibt. Ansonsten wird deren Status doppelt gewertet. Derzeit ist noch kein Schutz eingebaut, der doppelt zugewiesene Geräte erkennt und verhindert.

Readings


Das HOMESTATE Gerät stellt direkt eine Vielzahl von Readings bereit:

       
  • autoMode: erlaubt es den Hausmodus unabhängig der Tageszeit zu setzen
  • cal[Tod|Tom]: Datum in langer Schreibweise
  • cal[Tod|Tom]S: Datum in kurzer Schreibweise
  • cal[Tod|Tom]DaytimeStageLn: Länge eines Tageszeitabschnitts
  • cal[Tod|Tom]DaytimeT: Gesamtlänge des lichten Tages zwischen Sonnenauf- und Sonnenuntergang
  • cal[Tod|Tom]Desc: Beschreibung zum Tag
  • cal[Tod|Tom]DST: gibt an, ob die Uhr auf Sommerzeit oder Normalzeit gestellt ist
  • cal[Tod|Tom]Holiday: ist 1, wenn der Tag ein Feier- oder Urlaubtstag ist
  • cal[Tod|Tom]Leapyear: ist 1, wenn das Jahr ein Schaltjahr ist
  • cal[Tod|Tom]TodWeekend: ist 1, wenn der Tag ein Wochenendtag ist
  • cal[Tod|Tom]Monthday: Tag des Monats
  • cal[Tod|Tom]MonthdayRem: verbleibende Tage bis zum Monatswechsel
  • cal[Tod|Tom]MonthN: Monat als Zahl
  • cal[Tod|Tom]Month: Monat in langer Schreibweise
  • cal[Tod|Tom]MonthS: Monat in kurzer Schreibweise
  • cal[Tod|Tom]Rel: Bezeichnung des Tages relativ zu heute
  • cal[Tod|Tom]SAstroChng: ist 2, wenn am Folgetag ein Wechsel der astronomischen Jahreszeit stattfindet. 1 bedeutet, dass es der erste Tag der neuen Jahreszeit ist
  • cal[Tod|Tom]SAstro: astronomische Jahreszeit
  • cal[Tod|Tom]SMeteoChng: ist 2, wenn am Folgetag ein Wechsel der meteorologischen Jahreszeit stattfindet. 1 bedeutet, dass es der erste Tag der neuen Jahreszeit ist
  • cal[Tod|Tom]SMeteo: meteorologische Jahreszeit
  • cal[Tod|Tom]SPheno: (noch nicht enthalten) - phenologische Jahreszeit, berechnet basierend auf einer Mischung aus astronomischer und meteorologischer Jahreszeit. Frühlungs- und Herbstanfang wird dynamisch für den eigenen Standort über die Bezugspunkte Süd-West Portugal (Frühling) sowie Helsinki (Herbst) berechnet.
  • cal[Tod|Tom]Sunrise: Uhrzeit des Sonnenaufgangs (nutzt 99_SUNRISE_EL in Standardeinstellung HORIZON=CIVIL; kann derzeit noch nicht angepasst werden)
  • cal[Tod|Tom]Sunset: Uhrzeit des Sonnenuntergangs (nutzt 99_SUNRISE_EL in Standardeinstellung HORIZON=CIVIL; kann derzeit noch nicht angepasst werden)
  • cal[Tod|Tom]WeekdayN: Wochentag als Zahl in ISO Format (1=Mo, 2=Di, 3=Mi, 4=Do, 5=Fr, 6=Sa, 7=So)
  • cal[Tod|Tom]Weekday: Wochentag in langer Schreibweise
  • cal[Tod|Tom]WeekdayS: Wochentag in kurzer Schreibweise
  • cal[Tod|Tom]Week: Woche des Jahres
  • cal[Tod|Tom]Yearday: Tag des Jahres
  • cal[Tod|Tom]YeardayRem: Verbleibende Tage des Jahres
  • cal[Tod|Tom]Year: Jahr
  • daytime: aktuelle Tageszeit, berechnet aus dem aktuellen Tageszeitabschnitt
  • daytimeStage: der aktuelle Tageszeitabschnitt. 0 bedeutet Nacht.
  • daytimeStages: Gesamtzahl der Tageszeitabschnitte, in die der lichte Tag eingeteilt wird. Ist fest auf 12 Abschnitte eingestellt. Siehe auch Temporale Stunden bei Wikipedia.
  • mode: aktueller Hausmodus; wird automatisch mit daytime synchronisiert, wenn autoMode=on gesetzt ist. Zu einem späteren Modus kann manuell oder durch Fremdmodule gesteuert vorzeitig gewechselt werden. Ein Wechsel in die Vergangenheit ist nicht möglich = die Tageszeit in daytime gibt den Mindestmodus an.
  • security: Sicherheitsstatus, abgeleitet vom aktuellen Status der Bewohner aus dem Attribut ResidentsDevices
  • state: kombinierter Status aus mode und security, abhängig vom Status der Bewohner aus dem Attribut ResidentsDevices. Der homealoneSubtype aus den ResidentsDevices wird als Präfix übernommen.

set Befehle


Den Gerätestatus kann man über die folgenden set Befehle beeinflussen:

       
  • autoMode: gibt an, ob die fortschreitende Tageszeit automatisch den Mindeststatus für den Hausmodus bestimmen soll.
  • mode: setzt den Hausmodus vorab auf einen zukünftigen Modus bevor die Tageszeit erreicht wurde. Wenn autoMode=off steht, kann jede Tageszeit gewählt werden und wird durch die fortschreitende Tageszeit nicht beeinflusst.
  • toggle: wechselt zum nächsten Hausmodus

get Befehle


       
  • schedule: Zeigt den Event Zeitplan für den aktuellen Tag an. Darin kann man sehen, wann welcher Tageszeitabschnitt beginnt und bei welchem Tageszeitabschnitt sich die Tageszeit (daytime) mit verändern wird. Optional kann man ein bestimmtes Datum sowie Uhrzeit angeben, um den berechneten Zeitplan für einen anderen Zeitpunkt anzusehen. Das nächste anstehende Event kann man außerdem immer im INTERNAL "NEXT_EVENT" sehen, welches die Uhrzeit und Beschreibung aus dem Event Zeitplan enthält.
    Beispiele:
    05-09
    05-09 13:00
    05-09 13:00:30
    2017-05-09
    2017-05-09 13:00
    2017-05-09 13:00:30
Für den heutigen Tag wurde für meinen Standort beispielsweise folgender Zeitplan errechnet:


1494194400:
      DESC       Begin night time and new calendar day
      TIME       2017-05-08 00:00:00
    1494212975:
      DESC       Begin morning time and daytime stage 1
      TIME       2017-05-08 05:09:35
    1494217791:
      DESC       Begin daytime stage 2
      TIME       2017-05-08 06:29:51
    1494222607:
      DESC       Begin daytime stage 3
      TIME       2017-05-08 07:50:07
    1494227422:
      DESC       Begin midmorning time and daytime stage 4
      TIME       2017-05-08 09:10:22
    1494232238:
      DESC       Begin daytime stage 5
      TIME       2017-05-08 10:30:38
    1494237054:
      DESC       Begin noon time and daytime stage 6
      TIME       2017-05-08 11:50:54
    1494241870:
      DESC       Begin daytime stage 7
      TIME       2017-05-08 13:11:10
    1494246686:
      DESC       Begin afternoon time and daytime stage 8
      TIME       2017-05-08 14:31:26
    1494251502:
      DESC       Begin daytime stage 9
      TIME       2017-05-08 15:51:42
    1494256317:
      DESC       Begin daytime stage 10
      TIME       2017-05-08 17:11:57
    1494261133:
      DESC       Begin daytime stage 11
      TIME       2017-05-08 18:32:13
    1494265949:
      DESC       Begin evening time and daytime stage 12
      TIME       2017-05-08 19:52:29
    1494270765:
      DESC       End of daytime
      TIME       2017-05-08 21:12:45
    1494280800:
      DESC       End calendar day and begin night time
      TIME       2017-05-08 24:00:00


Wie man sieht, ist bestimmten Tageszeitabschnitten eine bestimmte Tageszeit zugeordnet. Diese Verbindung zwischen Tageszeitabschnitt (daytimeStage) und der Tageszeit (daytime) ist derzeit noch fest hinterlegt. Es ist geplant diese konfigurierbar zu haben. Es gibt unterschiedliche Zuordnungen je nach Jahreszeit und Normal-/Sommerzeit, um die unterschiedliche Länge des lichten Tages zu berücksichtigen. Über den get-Befehl "schedule" kann man sehr gut vorab überprüfen, wie die Tageszeitabschnitte sich verteilen.

Wichtig ist zu betonen, dass die Tageszeit natürlich fortlaufend weiterberechnet wird und dass diese quasi den "Mindest-Modus" für den Hausmodus angibt. Man kann aber jederzeit einen Modus weiter in der Zukunft anwählen (während des Tages bis maximal zur Nacht, während der Nacht bis maximal zum Nachmittag).
Wenn man also beispielsweise über einen Helligkeitssensor, dem Twilight Modul oder einfach einer festen Uhrzeit früher in den Abendmodus springen möchte, kann man das unbehelligt über ein Notify/DOIF tun.



Liste der Tageszeiten / Hausmodi

es werden 7 Hausmodi im Reading "mode" unterschieden:

       
  • Morgen (morning)
  • Vormittag (midmorning)
  • Mittag (noon)
  • Nachmittag (afternoon)
  • Vorabend (evening)
  • Abend (midevening)
  • Nacht (night)

Liste der Sicherheitsmodi


Es werden folgende Sicherheitsmodi im Reading "security" unterschieden:

       
  • unverriegelt (unlocked) - bei Anwesenheit der Bewohner in den Hausmodi Morgen, Vormittag, Mittag, Nachmittag und Vorabend
  • verriegelt (locked) - bei Anwesenheit der Bewohner in den Hausmodi Abend und Nacht
  • geschützt (protected) - während die Bewohner schlafen ODER wenn ein Haustier alleine zuhause ist
  • gesichert (secured) - während vorübergehender Abwesenheit der Bewohner
  • überwacht (guarded) - während längerer Abwesenheit der Bewohner
Sobald 00_HOMESTATE weitestgehend Feature-complete ist, werden die Sub-Module 01_ZONESTATE und 02_ROOMSTATE entsprechend angegangen.



Viele Grüße
Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

l2r

danke!

ich hab's mal runtergeladen und werde testen. Bis jetzt funktioniert alles wie gewünscht.

Da ich auch Dan's Modul HOMEMODE verwende bin ich mal gespannt ob die sich irgendwann in die quere kommen  ;)

Gruß Michael
Wissen ist Macht.
Ich weiß nix.
Macht nix.

Phiolin

Sieht gut aus, werde mir das auch nachher mal anschauen.
Vor allem die Einteilung in die daytimeStages gefällt mir ganz gut, das könnte nützlich sein. :)

ralfix

Hallo Julian,
Modul ist im Einsatz und hat das erste Sonnenstatus-Dummy abgelöst.
Grüble gerade über use cases für phenologische Jahreszeiten und temporale Stunden.

Viel Erfolg beim entwicklen
Ralf

ComputerZOO

Moin,
sobald ich mein Holiday-Device per attr sys.homestate HolidayDevices sys.holiday.mv einfügen will stürzt mir FHEM ab.

CoolTux

Hilfreiche Informationen für den Entwickler findest Du im FHEM Logfile.
Diese Infos bitte hier in Codetags posten.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

l2r

das FHEM abstürzt kann ich auch bestätigen.

viel mehr als:
Undefined subroutine &main::AttVal called at FHEM/HOMESTATEtk.pm line 1094.

sagt das log auch nicht.

ich würde sagen klassischer Tippfehler ;-)

Gruß Michael
Wissen ist Macht.
Ich weiß nix.
Macht nix.

Loredo

Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Phiolin

Mein Haus hat heute nicht auf "evening" geschaltet, sondern ist auf "afternoon" in DaytimeStage 11 stehen geblieben. Laut Schedule hätte gegen 20:39 auf Stage 12 gewechselt werden sollen. Das Umschalten auf "midevening" um 22:05 hingegen hat funktioniert. Eine Idee, warum er die eine Stage ausgelassen hat?

Internals:
   CHANGED
   NAME       Haus
   NEXT_EVENT 2017-05-19 22:05:44 - Begin midevening time
   NOTIFYDEV  global,Haus,rgr_Bewohner
   NR         178
   NTFY_ORDER 50-Haus
   READY      1
   RESIDENTS  rgr_Bewohner
   STATE      secured
   TYPE       HOMESTATE
   Readings:
     2017-05-19 00:00:00   calTod          Friday, May 19
     2017-05-09 08:07:42   calTodDST       daylight
     2017-05-19 00:00:00   calTodDaytimeStageLn 01:26:05
     2017-05-19 00:00:00   calTodDaytimeT  17:13:09
     2017-05-19 00:00:00   calTodDesc      Holland
     2017-05-19 00:00:00   calTodHoliday   1
     2017-05-09 08:07:42   calTodLeapyear  0
     2017-05-09 08:07:42   calTodMonth     May
     2017-05-09 08:07:42   calTodMonthN    5
     2017-05-09 08:07:42   calTodMonthS    May
     2017-05-19 00:00:00   calTodMonthday  19
     2017-05-19 00:00:00   calTodMonthdayRem 12
     2017-05-09 08:07:42   calTodRel       today
     2017-05-19 00:00:00   calTodS         May 19
     2017-05-09 08:07:42   calTodSAstro    Spring
     2017-05-09 08:07:42   calTodSAstroChng 0
     2017-05-09 08:07:42   calTodSMeteo    Spring
     2017-05-09 08:07:42   calTodSMeteoChng 0
     2017-05-19 00:00:00   calTodSunrise   04:52:35
     2017-05-19 00:00:00   calTodSunset    22:05:44
     2017-05-19 00:00:00   calTodTodWeekend 2
     2017-05-15 00:00:00   calTodWeek      20
     2017-05-19 00:00:00   calTodWeekday   Friday
     2017-05-19 00:00:00   calTodWeekdayN  5
     2017-05-19 00:00:00   calTodWeekdayS  Fri
     2017-05-09 08:07:42   calTodYear      2017
     2017-05-19 00:00:00   calTodYearday   138
     2017-05-19 00:00:00   calTodYeardayRem 227
     2017-05-19 00:00:00   calTom          Saturday, May 20
     2017-05-09 08:07:42   calTomDST       daylight
     2017-05-18 00:00:00   calTomDesc      Holland
     2017-05-18 00:00:00   calTomHoliday   1
     2017-05-09 08:07:42   calTomMonth     May
     2017-05-09 08:07:42   calTomMonthN    5
     2017-05-09 08:07:42   calTomMonthS    May
     2017-05-19 00:00:00   calTomMonthday  20
     2017-05-19 00:00:00   calTomMonthdayRem 11
     2017-05-09 08:07:42   calTomRel       tomorrow
     2017-05-19 00:00:00   calTomS         May 20
     2017-05-14 00:00:01   calTomWeek      20
     2017-05-19 00:00:00   calTomWeekday   Saturday
     2017-05-19 00:00:00   calTomWeekdayN  6
     2017-05-19 00:00:00   calTomWeekdayS  Sat
     2017-05-19 00:00:00   calTomWeekend   3
     2017-05-09 08:07:42   calTomYear      2017
     2017-05-19 00:00:00   calTomYearday   139
     2017-05-19 00:00:00   calTomYeardayRem 226
     2017-05-19 16:21:21   daytime         afternoon
     2017-05-19 19:13:33   daytimeStage    11
     2017-05-09 08:07:42   daytimeStages   12
     2017-05-19 16:21:21   lastMode        noon
     2017-05-19 11:16:11   lastSecurity    unlocked
     2017-05-19 11:16:11   lastState       midmorning
     2017-05-19 16:21:21   mode            afternoon
     2017-05-19 11:16:11   security        secured
     2017-05-19 11:16:11   state           secured
Attributes:
   ResidentsDevices rgr_Bewohner
   alias      Mode
   devStateIcon {(HOMESTATEtk_devStateIcon($name),"toggle")}
   group      Home State
   icon       control_building_control
   room       Residents
   webCmd     mode

Phiolin

Da scheint bei mir öfter vorzukommen.

Laut Schedule müsste ich in Stage 5 sein.

DESC       Begin daytime stage 5
      TIME       2017-05-20 10:36:27


Jedoch aktuell steht in DaytimeStage eine 4. (Uhrzeit gerade 11:21)

Prof. Dr. Peter Henning

#10
Guter Ansatz, hier ein erstes Feedback:

Ein paar kleine Fehler: Zeile 362 im Toolkit macht eine Fehlermeldung, wenn keine Residents definiert sind. Die deutsche Übersetzung "Flurstatus" sollte wohl eher "Geschossstatus/Etagenstatus" sein.

Die wichtigste Ergänzung wäre die zeitliche Konfigurierbarkeit der einzelnen Stufen - weil es doch z.B. sehr unterschiedlich ist, wann "midevening time" anfängt.

Wenn die Benennung so bleiben soll, tritt dasselbe Problem wie schon bei RESIDENTS auf: Eine Familie von Modulen, die sehr eng zusammenarbeiten - aber an ganz unterschiedlichen Stellen in der CommandRef stehen, und deren Zusammengehörigkeit nicht ohne Weiteres erkennbar ist. Ich plädiere dafür, sich einen generischen Namen auszudenken. Sagen wir HOMESTATE (oder etwas Kürzeres, sagen wir HS) und das zum Anfang des Modulnamens auch bei den Untermodulen zu machen. Also HSMAIN, HSFLOOR, HSROOM oder so.


LG

pah

Phiolin

Mir fehlt gerade wieder eine DaytimeStage.
Hier die Schedule für heute:

1495317600.02332:
      DESC       Begin night time and new calendar day, holiday: Holland
      TIME       2017-05-21 00:00:00
    1495334966:
      DESC       Begin morning time and daytime stage 1
      TIME       2017-05-21 04:49:26
    1495340164:
      DESC       Begin daytime stage 2
      TIME       2017-05-21 06:16:04
    1495345362:
      DESC       Begin daytime stage 3
      TIME       2017-05-21 07:42:42
    1495350561:
      DESC       Begin midmorning time and daytime stage 4
      TIME       2017-05-21 09:09:21
    1495355759:
      DESC       Begin daytime stage 5
      TIME       2017-05-21 10:35:59
    1495360957:
      DESC       Begin noon time and daytime stage 6
      TIME       2017-05-21 12:02:37
    1495366155:
      DESC       Begin daytime stage 7
      TIME       2017-05-21 13:29:15
    1495371353:
      DESC       Begin afternoon time and daytime stage 8
      TIME       2017-05-21 14:55:53
    1495376551:
      DESC       Begin daytime stage 9
      TIME       2017-05-21 16:22:31
    1495381750:
      DESC       Begin daytime stage 10
      TIME       2017-05-21 17:49:10
    1495386948:
      DESC       Begin daytime stage 11
      TIME       2017-05-21 19:15:48
    1495392146:
      DESC       Begin evening time and daytime stage 12
      TIME       2017-05-21 20:42:26
    1495397344:
      DESC       Begin midevening time
      TIME       2017-05-21 22:09:04
    1495404000.02332:
      DESC       End calendar day and begin night time, holiday: Urlaub
      TIME       2017-05-22 24:00:00


Aktuell ist es 08:43, demnach müsste ich in Stage 3 sein. Das Device steht aber in Stage 2:

Internals:
   NAME       Haus
   NEXT_EVENT 2017-05-21 09:09:21 - Begin midmorning time and daytime stage 4
   NOTIFYDEV  global,Haus,rgr_Bewohner
   NR         178
   NTFY_ORDER 50-Haus
   READY      1
   RESIDENTS  rgr_Bewohner
   STATE      guarded
   TYPE       HOMESTATE
   Readings:
     2017-05-21 00:00:00   calTod          Sunday, May 21
     2017-05-09 08:07:42   calTodDST       daylight
     2017-05-21 00:00:00   calTodDaytimeStageLn 01:26:38
     2017-05-21 00:00:00   calTodDaytimeT  17:19:38
     2017-05-19 00:00:00   calTodDesc      Holland
     2017-05-19 00:00:00   calTodHoliday   1
     2017-05-09 08:07:42   calTodLeapyear  0
     2017-05-09 08:07:42   calTodMonth     May
     2017-05-09 08:07:42   calTodMonthN    5
     2017-05-09 08:07:42   calTodMonthS    May
     2017-05-21 00:00:00   calTodMonthday  21
     2017-05-21 00:00:00   calTodMonthdayRem 10
     2017-05-09 08:07:42   calTodRel       today
     2017-05-21 00:00:00   calTodS         May 21
     2017-05-09 08:07:42   calTodSAstro    Spring
     2017-05-09 08:07:42   calTodSAstroChng 0
     2017-05-09 08:07:42   calTodSMeteo    Spring
     2017-05-09 08:07:42   calTodSMeteoChng 0
     2017-05-21 00:00:00   calTodSunrise   04:49:26
     2017-05-21 00:00:00   calTodSunset    22:09:04
     2017-05-20 00:00:00   calTodTodWeekend 3
     2017-05-15 00:00:00   calTodWeek      20
     2017-05-21 00:00:00   calTodWeekday   Sunday
     2017-05-21 00:00:00   calTodWeekdayN  7
     2017-05-21 00:00:00   calTodWeekdayS  Sun
     2017-05-09 08:07:42   calTodYear      2017
     2017-05-21 00:00:00   calTodYearday   140
     2017-05-21 00:00:00   calTodYeardayRem 225
     2017-05-21 00:00:00   calTom          Monday, May 22
     2017-05-09 08:07:42   calTomDST       daylight
     2017-05-21 00:00:00   calTomDesc      Urlaub
     2017-05-18 00:00:00   calTomHoliday   1
     2017-05-09 08:07:42   calTomMonth     May
     2017-05-09 08:07:42   calTomMonthN    5
     2017-05-09 08:07:42   calTomMonthS    May
     2017-05-21 00:00:00   calTomMonthday  22
     2017-05-21 00:00:00   calTomMonthdayRem 9
     2017-05-09 08:07:42   calTomRel       tomorrow
     2017-05-21 00:00:00   calTomS         May 22
     2017-05-21 00:00:00   calTomWeek      21
     2017-05-21 00:00:00   calTomWeekday   Monday
     2017-05-21 00:00:00   calTomWeekdayN  1
     2017-05-21 00:00:00   calTomWeekdayS  Mon
     2017-05-21 00:00:00   calTomWeekend   2
     2017-05-09 08:07:42   calTomYear      2017
     2017-05-21 00:00:00   calTomYearday   141
     2017-05-21 00:00:00   calTomYeardayRem 224
     2017-05-21 04:49:26   daytime         morning
     2017-05-21 07:42:42   daytimeStage    2
     2017-05-09 08:07:42   daytimeStages   12
     2017-05-21 04:49:26   lastMode        night
     2017-05-20 03:16:10   lastSecurity    secured
     2017-05-20 03:16:10   lastState       secured
     2017-05-21 04:49:26   mode            morning
     2017-05-20 03:16:10   security        guarded
     2017-05-20 03:16:10   state           guarded
Attributes:
   ResidentsDevices rgr_Bewohner
   alias      Mode
   devStateIcon {(HOMESTATEtk_devStateIcon($name),"toggle")}
   group      Home State
   icon       control_building_control
   room       Residents
   webCmd     mode

Loredo

Zitat von: Phiolin am 19 Mai 2017, 22:07:45
Mein Haus hat heute nicht auf "evening" geschaltet, sondern ist auf "afternoon" in DaytimeStage 11 stehen geblieben. Laut Schedule hätte gegen 20:39 auf Stage 12 gewechselt werden sollen. Das Umschalten auf "midevening" um 22:05 hingegen hat funktioniert. Eine Idee, warum er die eine Stage ausgelassen hat?


Danke, das Log war hilfreich. Tatsächlich hat es da nichts ausgelassen, aber die Neuberechnung erfolgt zur exakten Sekunde, in der auch das neue Ergebnis dann herauskommt. Es kann aber aufgrund von Nachkommastellen vorkommen, dass eine leichte Abweichung beim Ergebnis da ist, welches dann noch für den Bruchteil einer Sekunde den alten Tageszeitabschnitt als Ergebnis liefert.


Das habe ich jetzt gefixt denke ich. Ein Update gibt es morgen zusammen mit dem normalen FHEM Update.


Zitat von: Prof. Dr. Peter Henning am 21 Mai 2017, 03:19:33
Ein paar kleine Fehler: Zeile 362 im Toolkit macht eine Fehlermeldung, wenn keine Residents definiert sind.


Danke dir, das habe ich gerade gleich mit korrigiert.


Zitat von: Prof. Dr. Peter Henning am 21 Mai 2017, 03:19:33
Die deutsche Übersetzung "Flurstatus" sollte wohl eher "Geschossstatus" sein.


Eigentlich ist Flur nicht nur als Geschoss gemeint, sondern auch als Abschnitt/Bereich (ein Geschoss sollte man auch in mehrere Abschnitte unterteilen können; für einige fängt sprachlich gesehen je nach Kontext auch nach jeder Abbiegung ein neuer "Flur" an). Dafür aber wieder einen eigenen TYPE zu definieren erschien mir nicht lohnenswert. Ich habe das Modul intern schonmal auf SECTIONSTATE (resp. "Bereichstatus" bzw "Section State") umbenannt, vielleicht ist das allgemeingültiger.


Zitat von: Prof. Dr. Peter Henning am 21 Mai 2017, 03:19:33
Wenn die Benennung so bleiben soll, tritt dasselbe Problem wie schon bei RESIDENTS auf: Eine Familie von Modulen, die sehr eng zusammenarbeiten - aber an ganz unterschiedlichen Stellen in der CommandRef stehen, und deren Zusammengehörigkeit nicht ohne Weiteres erkennbar ist. Ich plädiere dafür, sich einen generischen Namen auszudenken. Sagen wir HOMESTATE (oder etwas Kürzeres, sagen wir HS) und das zum Anfang des Modulnamens auch bei den Untermodulen zu machen. Also HSMAIN, HSFLOOR, HSROOM oder so.


Das ist ein guter Punkt, über den ich mal nachdenken muss. Generische Ausdrücke finde ich eher nicht so gut, da man die Abkürzung erstmal kennen muss um zu verstehen, wofür das Modul in etwa da ist. Das ist bei ganz vielen Modulen inzwischen so, dass man aus dem kryptischen Namen nicht mehr immer unbedingt etwas ableiten kann, ohne die Kurzbeschreibung zu lesen (und zu verstehen).


Vielleicht dreht man das ganze einfach um und nennt es dann STATEHOME, STATESECTION, STATEROOM. Ist sprachlich nicht so geschickt, lässt aber mehr Rückschlüsse auf die Funktion zu.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER


ComputerZOO

Moin,
so richtig scheint der Wechsel auch nach dem Update nicht zu funktionieren: