[Gelöst]Automatischer Neustart nach Uhrzeitumstellung

Begonnen von Xell1984, 15 März 2018, 10:36:58

Vorheriges Thema - Nächstes Thema

Xell1984

Guten Morgen

am 25.03. werden ja bekanntlich die Uhren wieder mal umgestellt und ich möchte gerne mein FHEM automatisch Neustarten.

Ich hatte es Testweise probiert jedoch funktioniert es nicht.

Folgendes ist angedacht:

1. DOIF stellt fest ob Winter oder Sommer und schreibt Winter oder Sommer dann auf einen Dummy


Internals:
   DEF        (([02:00] or [03:00]) and $isdst == 0) (set SommerWinter.Dummy Winter)
DOELSEIF
(([02:00] or [03:00]) and $isdst == 1) (set SommerWinter.Dummy Sommer)
   NAME       SommerzeitWinterzeit
   NR         236
   NTFY_ORDER 50-SommerzeitWinterzeit
   STATE      cmd_1
   TYPE       DOIF
   READINGS:
     2018-03-15 10:26:21   cmd             1
     2018-03-15 10:26:21   cmd_event       set_cmd_1
     2018-03-15 10:26:21   cmd_nr          1
     2018-03-15 10:24:48   mode            enabled
     2018-03-15 10:26:21   state           cmd_1
     2018-03-15 10:24:48   timer_01_c01    16.03.2018 02:00:00
     2018-03-15 10:24:48   timer_02_c01    16.03.2018 03:00:00
     2018-03-15 10:24:48   timer_03_c02    16.03.2018 02:00:00
     2018-03-15 10:24:48   timer_04_c02    16.03.2018 03:00:00
   Regex:
   condition:
     0          (DOIF_time_once($hash,0,$wday) or DOIF_time_once($hash,1,$wday)) and $isdst == 0
     1          (DOIF_time_once($hash,2,$wday) or DOIF_time_once($hash,3,$wday)) and $isdst == 1
   days:
   devices:
   do:
     0:
       0          set SommerWinter.Dummy Winter
     1:
       0          set SommerWinter.Dummy Sommer
     2:
   helper:
     DOIF_Readings_events
     DOIF_eventas
     globalinit 1
     last_timer 4
     sleeptimer -1
     triggerDev
   internals:
   itimer:
   localtime:
     0          1521162000
     1          1521165600
     2          1521162000
     3          1521165600
   readings:
   realtime:
     0          02:00:00
     1          03:00:00
     2          02:00:00
     3          03:00:00
   time:
     0          02:00:00
     1          03:00:00
     2          02:00:00
     3          03:00:00
   timeCond:
     0          0
     1          0
     2          1
     3          1
   timer:
     0          0
     1          0
     2          0
     3          0
   timers:
     0           0  1
     1           2  3
   triggertime:
     1521162000:
       localtime  1521162000
       hash:
     1521165600:
       localtime  1521165600
       hash:
   uiState:
   uiTable:
Attributes:
   room       Rolladenautomatik


List Dummy

Internals:
   CHANGED   
   NAME       SommerWinter.Dummy
   NR         238
   STATE      Winter
   TYPE       dummy
   READINGS:
     2018-03-15 10:26:21   state           Winter
Attributes:
   event-on-change-reading .*
   room       Rolladenautomatik



2. Ein weiteres DOIF prüft den Dummy und NUR bei Änderung soll dann das zweite DOIF FHEM Neustarten


Internals:
   DEF        ([SommerWinter.Dummy] eq "Winter") (shutdown restart)
DOELSEIF
([SommerzeitWinterzeit] eq "Sommer") (shutdown restart)

   NAME       WinterSommer_Initialisierung
   NR         237
   NTFY_ORDER 50-WinterSommer_Initialisierung
   STATE      initialize
   TYPE       DOIF
   READINGS:
     2018-03-15 10:26:21   Device          SommerzeitWinterzeit
     2018-03-15 10:26:21   e_SommerzeitWinterzeit_STATE cmd_1
     2018-03-15 09:02:53   mode            enabled
     2018-03-15 09:02:53   state           initialize
   Regex:
   condition:
     0          InternalDoIf($hash,'SommerWinter.Dummy','STATE') eq "Winter"
     1          InternalDoIf($hash,'SommerzeitWinterzeit','STATE') eq "Sommer"
   devices:
     0           SommerWinter.Dummy
     1           SommerzeitWinterzeit
     all         SommerWinter.Dummy SommerzeitWinterzeit
   do:
     0:
       0          shutdown restart
     1:
       0          shutdown restart
     2:
   helper:
     DOIF_Readings_events
     DOIF_eventas
     event      cmd_nr: 1,cmd: 1,cmd_event: set_cmd_1,cmd_1
     globalinit 1
     last_timer 0
     sleeptimer -1
     triggerDev SommerzeitWinterzeit
     triggerEvents:
       cmd_nr: 1
       cmd: 1
       cmd_event: set_cmd_1
       cmd_1
     triggerEventsState:
       cmd_nr: 1
       cmd: 1
       cmd_event: set_cmd_1
       state: cmd_1
   internals:
     0           SommerWinter.Dummy:STATE
     1           SommerzeitWinterzeit:STATE
     all         SommerWinter.Dummy:STATE SommerzeitWinterzeit:STATE
   itimer:
   readings:
   trigger:
   uiState:
   uiTable:
Attributes:
   room       Rolladenautomatik


Ich hab Testweise das erste DOIF mal nach CMD1 und CMD2 gebracht. Das Dummy Element wird verändert aber das zweite DOIF springt nicht an. Jemand einen Tipp für mich? Immer wenn ich denke ich steige langsam aber sicher bei FHEM durch dann lande ich anschließend doch wieder hier  :o

Gruß,

Xell1984
Razpberry on Raspberry Pi 3 mit Raspian Jessy

abc2006

Hi,
NUR bei Änderung -> event-on-change-reading

Brauchst du aber nicht.
Wenn du in deinem DOIF "do always" NICHT aktivierst, schaltet das DOIF nur ein einziges mal, nämlich dann, wenn die andere Bedingung wahr wird.

soll heissen

doif (ist es sommerzeit)( starte fhem neu)
doelseif (ist es winterzeit)(starte fhem auch neu, oder so)


die Doelseif-Bedingung brauchst du eigentlich gar nicht, kannst auch schreiben

DOELSE (starte fhem auch neu, oder so)

Für mich ist das aus zwei Gründen nur in speziellen Fällen akzeptabel:
1. DOELSE fängt ALLE anderen Fälle ab. Also auch wenn in deiner Bedingung Antworten vorkommen, mit denen du nicht gerechnet hast
2. ist wesentlich schneller erkennbar, wann du warum schalten willst.

Grüße,
Stephan
FHEM nightly auf Intel Atom (lubuntu) mit VDSL 50000 ;-)
Nutze zur Zeit OneWire und KNX

Xell1984

Zitat von: abc2006 am 15 März 2018, 10:43:46
Hi,
NUR bei Änderung -> event-on-change-reading

Brauchst du aber nicht.
Wenn du in deinem DOIF "do always" NICHT aktivierst, schaltet das DOIF nur ein einziges mal, nämlich dann, wenn die andere Bedingung wahr wird.

Habe das event-on-change-reading wieder raus genommen. Hatte ich nicht bedacht. Danke!

Zitat von: abc2006 am 15 März 2018, 10:43:46
soll heissen

doif (ist es sommerzeit)( starte fhem neu)
doelseif (ist es winterzeit)(starte fhem auch neu, oder so)


die Doelseif-Bedingung brauchst du eigentlich gar nicht, kannst auch schreiben

DOELSE (starte fhem auch neu, oder so)

Für mich ist das aus zwei Gründen nur in speziellen Fällen akzeptabel:
1. DOELSE fängt ALLE anderen Fälle ab. Also auch wenn in deiner Bedingung Antworten vorkommen, mit denen du nicht gerechnet hast
2. ist wesentlich schneller erkennbar, wann du warum schalten willst.

Grüße,
Stephan

Hab absichtlich wegen dem in Fall 1 das Seperate DOELSEIF eingefügt. Hab/Hatte etwas sorge FHEM mal in einer Schleife bzgl. Neustart fest hängen zu haben. Daher auch oben das event-on-change-reading.
Razpberry on Raspberry Pi 3 mit Raspian Jessy

Wernieman

Eine grundsätzliche Fratge:
Warum willst Du bei der Umstellung FHEM neu starten?

Habe meinen immer durchlaufen lassen (ohne Probleme)
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Xell1984

#4
Zitat von: Wernieman am 15 März 2018, 10:55:00
Eine grundsätzliche Fratge:
Warum willst Du bei der Umstellung FHEM neu starten?

Habe meinen immer durchlaufen lassen (ohne Probleme)

Hab in meinem DOIF Twilight in Verbindung mit Sunrise drin und das führt leider dazu dass die Timer die Nachts erzeugt werden nach der Zeitumstellung nicht mehr richtig sind.

D.h. die Uhren werden ja von 2 auf 3 umgestellt, aber der Timer für das schließen der Jalousie wird durch Twilight nachts vor der Umstellung auf ca 18:45 Uhr an dem Tag liegen. Nach der Umstellung müsste es aber 19:45 Uhr nach neuer Zeit sein. Das tut es leider nicht. Erst nach Neuinitialisierung der DOIF erstellt er den neuen richtigen Timer. usw.
Razpberry on Raspberry Pi 3 mit Raspian Jessy

abc2006

evtl reicht es, das DOIF neu zu initialisieren ...
Ich könnte mir vorstellen, dass ich mich nächstes Jahr frage, warum FHEM bei der Zeitumstellung neustartet ... :P

Hatte ich unten jetzt nicht explizit geschrieben: Mach das ganze nicht mit zwei DOIF und einem Dummy... das sind mindestens 1 DOIF und 1 Dummy zuviel ... :)



Grüße,
Stephan
FHEM nightly auf Intel Atom (lubuntu) mit VDSL 50000 ;-)
Nutze zur Zeit OneWire und KNX

Xell1984

#6
Zitat von: abc2006 am 15 März 2018, 12:57:41
Hatte ich unten jetzt nicht explizit geschrieben: Mach das ganze nicht mit zwei DOIF und einem Dummy... das sind mindestens 1 DOIF und 1 Dummy zuviel ... :)

Ja, ist im Moment noch Absicht. Im ersten DOIF sollte dann eigentlich direkt das shutdown restart stehen. Hab es einige male schon umgeworfen. Mit dem Dummy habe ich erst getestet ob das von mir angedachte verhalten funktioniert.


Internals:
   DEF        (([02:00] or [03:00]) and $isdst == 0) (shutdown restart)
DOELSEIF
(([02:00] or [03:00]) and $isdst == 1) (shutdown restart)
   NAME       SommerzeitWinterzeit
   NR         236
   NTFY_ORDER 50-SommerzeitWinterzeit
   STATE      initialized
   TYPE       DOIF
   READINGS:
     2018-03-15 13:16:29   cmd             0
     2018-03-15 13:16:29   mode            enabled
     2018-03-15 13:16:29   state           initialized
     2018-03-15 13:16:29   timer_01_c01    16.03.2018 02:00:00
     2018-03-15 13:16:29   timer_02_c01    16.03.2018 03:00:00
     2018-03-15 13:16:29   timer_03_c02    16.03.2018 02:00:00
     2018-03-15 13:16:29   timer_04_c02    16.03.2018 03:00:00
     2018-03-15 13:16:41   wait_timer      no timer
   Regex:
   condition:
     0          (DOIF_time_once($hash,0,$wday) or DOIF_time_once($hash,1,$wday)) and $isdst == 0
     1          (DOIF_time_once($hash,2,$wday) or DOIF_time_once($hash,3,$wday)) and $isdst == 1
   days:
   devices:
   do:
     0:
       0          shutdown restart
     1:
       0          shutdown restart
     2:
   helper:
     DOIF_Readings_events
     DOIF_eventas
     globalinit 1
     last_timer 4
     sleeptimer -1
   itimer:
   localtime:
     0          1521162000
     1          1521165600
     2          1521162000
     3          1521165600
   realtime:
     0          02:00:00
     1          03:00:00
     2          02:00:00
     3          03:00:00
   time:
     0          02:00:00
     1          03:00:00
     2          02:00:00
     3          03:00:00
   timeCond:
     0          0
     1          0
     2          1
     3          1
   timer:
     0          0
     1          0
     2          0
     3          0
   timers:
     0           0  1
     1           2  3
   triggertime:
     1521162000:
       localtime  1521162000
       hash:
     1521165600:
       localtime  1521165600
       hash:
   uiState:
   uiTable:
Attributes:
   room       Rolladenautomatik
   wait       60:60


Bootet er so jede Nacht oder nur bei der Umstellung?

Zitat von: abc2006 am 15 März 2018, 12:57:41
evtl reicht es, das DOIF neu zu initialisieren ...
Ich könnte mir vorstellen, dass ich mich nächstes Jahr frage, warum FHEM bei der Zeitumstellung neustartet ... :P

Ich muss mehrere Neu Initialisieren. Solange keine neuen dazu kommen könnte ich die fest rein nehmen. Oder kann man alle DOIF im Raum Rolladenautomatik neu initialsieren lassen ohne diese konkret anzusprechen?
Razpberry on Raspberry Pi 3 mit Raspian Jessy

nils_

du musst nicht DOIF neu initialisieren, sondern Twilight... das ist doch der Zeitgeber, oder nicht?


und für 2 Tage im Jahr so ein aufwand  ::)

da gabs doch letztens erst nen thread. suchfunktion?
viele Wege in FHEM es gibt!

Wernieman

Weiß jetzt momentan auch nicht, ob man mittels FHEM heute noch FHEM neustarten kann .. wurde da nicht etwas umgebaut?

Würde dann auch eher die Innitiallisierung der Module neu machen. Also:
Twilight nachts vor der Umstellung auf ca 18:45
Also einen 2. der Twilight bei einer Zeitumstellung aktuallisiert. Kann Dir da aber schlecht weiterhelfen, weil ich DOIF (mit Absicht) nicht benutze.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Xell1984

#9
Zitat von: nils_ am 15 März 2018, 14:02:07
du musst nicht DOIF neu initialisieren, sondern Twilight... das ist doch der Zeitgeber, oder nicht?


und für 2 Tage im Jahr so ein aufwand  ::)

da gabs doch letztens erst nen thread. suchfunktion?

Stört mich halt. Außerdem lernt man auch so dazu.

Ehrlich gesagt kam ich noch nicht auf die Idee Twilight neu zu starten. Wie startet man das Modul denn neu? mit
set TC_TWILIGHT initialize
bekomme ich nur den Hinweis das set nicht für Twilight implementiert ist.

Ah grad gefunden, mit reload 59_Twilight.pm
Razpberry on Raspberry Pi 3 mit Raspian Jessy

betateilchen

So etwas würde ich - wenn überhaupt - in einem at lösen, das in der Nacht der Zeitumstellung ein "rereadcfg" ausführt. Und ausserdem denke ich, dass sich hier jemand Gedanken über etwas macht, das ein Nachdenken überhaupt nicht wert ist.

Zitat von: Xell1984 am 15 März 2018, 10:59:28
Hab in meinem DOIF Twilight in Verbindung mit Sunrise drin und das führt leider dazu dass die Timer die Nachts erzeugt werden nach der Zeitumstellung nicht mehr richtig sind.

Erzeuge die Timer doch einfach nach 3 Uhr nachts, also z.B. um 03:05 Uhr. Das passt sowohl für das Vorstellen im Frühjahr, als auch beim Zurückstellen im Herbst, denn der Zeitpunkt 03:05 Uhr tritt in beiden Nächten nur ein einziges Mal auf.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Xell1984

Ich hab mich jetzt für die Lösung DOIF / Dummy entschieden. Die Variante Funktioniert soweit. Vielen Dank für die Hilfreichen Beiträge, das eine oder andere konnte ich in dem Zuge wieder lernen.
Razpberry on Raspberry Pi 3 mit Raspian Jessy

betateilchen

Zitat von: Xell1984 am 15 März 2018, 14:21:48
Ehrlich gesagt kam ich noch nicht auf die Idee Twilight neu zu starten. Wie startet man das Modul denn neu? mit
...
Ah grad gefunden, mit reload 59_Twilight.pm

Mit "reload" wird nur die Moduldatei selbst neu gelesen und verarbeitet. Das bewirkt aber in Deinen devices und anderem Code, der darauf aufbaut überhaupt nix. Es werden weder irgendwelche vorhandenen devices neu angelegt, geschweige denn, deren bestehende Werte verändert.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Und diesen Thread bitte nicht wieder voreilig schließen. Danke.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Frank_Huber

Zitat von: betateilchen am 15 März 2018, 14:25:49
So etwas würde ich - wenn überhaupt - in einem at lösen, das in der Nacht der Zeitumstellung ein "rereadcfg" ausführt. Und ausserdem denke ich, dass sich hier jemand Gedanken über etwas macht, das ein Nachdenken überhaupt nicht wert ist.

Erzeuge die Timer doch einfach nach 3 Uhr nachts, also z.B. um 03:05 Uhr. Das passt sowohl für das Vorstellen im Frühjahr, als auch beim Zurückstellen im Herbst, denn der Zeitpunkt 03:05 Uhr tritt in beiden Nächten nur ein einziges Mal auf.
IMHO kann man es nicht beeinflussen wann die timer neu berechnet / gesetzt werden.

Ich habe mich bisher damit abgefunden dass am Tag nach zeitumstellung die timer falsch laufen.
Beeinflusst bei mir nur die Rollos.
Die Variante mit dem rereadcfg klingt aber auch nicht sooo verkehrt. Mal noch überlegen. Sind ja noch paar Tage. [emoji3]

Mit dem Handy online, daher kurz gefasst...