at statement spinnt nach Raspi Neustart ?? Problem mit RAspi Uhrzeit ?

[AnonymousHolger]

Hallo, ich habe im Garten einen Raspi mit FHEM und einer Anbindung ans Internet über einen UMTS Stick.

Alle 10 Minuten soll die Luftfeuchtigkeit gemessen und gelogged werden.

Code Auswählen Erweitern


# Logpunkt alle 10 Minuten setzen, und entscheiden (99_myUtils) ob Lüfter/Entfeuchter geschaltet werden soll
define KellerLogSet at +*00:10:00 {my $Tinnen = ReadingsVal("ASH2200_Innen","temperature",0) ;; my $Hinnen = ReadingsVal("ASH2200_Innen","humidity",0) ;; my $Taussen = ReadingsVal("ASH2200_Aussen","temperature",0) ;; my $Haussen = ReadingsVal("ASH2200_Aussen","humidity",0) ;; my $Entfeuchter = ReadingsVal("KellerEntfeuchterSchalter","state",0) ;; my $Entluefter = ReadingsVal("KellerEntluefterSchalter","state",0) ;; my $AutoAktiviert = ReadingsVal("SteuerungsAktivator","state",0) ;;my $HA2HI = shiftRelHumidity($Taussen, $Haussen, $Tinnen) ;; fhem("trigger EntfeuchtungsSkript ;; set KellerLog_Readings TI: $Tinnen HI: $Hinnen TA: $Taussen HA: $Haussen HA2HI: $HA2HI EF: $Entfeuchter EL: $Entluefter AUTO: $AutoAktiviert");;}
attr KellerLogSet room 2_SYSTEM,0_VORSCHAU

Das funktioniert soweit auch prima, aber wenn ich den Raspi vom Strom trenne und dann wieder anschliesse, generiert er massenhaft der at readings. Im grunde zählt er fast im 10ms hoch und zählt. Irgendwann normalisiert es sich dann.

Kommt das von der ggf. noch nicht synchronisierten Uhrzeit des RAspi ?

Wie lässt sich das verhindern ? Irgendwelche Ideen ? Ich will für die Übertragung über UMTS die Logfiles und die Graphiken natürlich mit möglichst wenig Daten haben.

[KölnSolar]

Kommt das von der ggf. noch nicht synchronisierten Uhrzeit des RAspi ?

Bin nicht ganz sicher,  aber bekanntes "Phänomen".

Ich will für die Übertragung über UMTS die Logfiles und die Graphiken natürlich mit möglichst wenig Daten haben.

Wie oft startest Du den Rpi denn durch und nach wie viel Pausenzeit ? 

Wie lässt sich das verhindern ? Irgendwelche Ideen ?

Du könntest den FHEM-Start verzögern. Kann aber auch sein, dass das at die letzte Zeit aus der fhem.save als Startpunkt nimmt. Dann könntest vor dem shutdown das at inactive setzen und nach dem Start wieder active.

[nils_]

wie wäre es mit einem log auszug von dem verhalten??

[Ma_Bo]

Dieses Verhalten kann ich bestätigen, wenn ich mein Testsystem für ein paar Tage abschalte und dann wieder starte, dann triggert ein +*00:01:00 quasi so oft, vom abschaltzeitpunkt bis einschaltzeitpunkt, bis die jetzige Zeit erreicht ist... sprich wenn ich um 15:00 ausschalte und um 16:00 wieder ein, dann 60x

Gruß Marcel


Tapatalk mit Handy geschrieben, daher kurz gehalten.

[Otto123]

Hallo,

die Ursache ist ja klar denke ich. Der Pi startet mit der alten Zeit vom Shutdown, ntp gleicht diese nach dem Start schrittweise an.
Du könntest mit einem notify über den Event global:INITIALIZED beim neustart des System Dein at erstmal für einen Zeitraum lahmlegen.

Gruß Otto

[Frank_Huber]

Steck dir nen rtc Chip auf den i2c bus und alles ist gut. Gibt's in der bucht für ganz kleines Geld.

Die hier z.B. hab ich auf jedem Raspberry:
http://www.ebay.de/itm/3-3V-5V-DS3231-High-Precision-RTC-Real-Time-Clock-Module-Arduino-Raspberry-Pi-/401371719635

[nils_]

die Ursache ist ja klar denke ich. Der Pi startet mit der alten Zeit vom Shutdown, ntp gleicht diese nach dem Start schrittweise an.

so eine vermutung hatte ich auch, kenne aber ntp nicht wirklich gut.

erklärt das wirklich dieses verhalten

dann triggert ein +*00:01:00 quasi so oft, vom abschaltzeitpunkt bis einschaltzeitpunkt, bis die jetzige Zeit erreicht ist... sprich wenn ich um 15:00 ausschalte und um 16:00 wieder ein, dann 60x

ich dachte (achtung gefährliches halb, evtl. sogar nur viertelwissen) das die nächste-zeit-triggerung von einem at erst bei eintritt berechnet wird ?!?
ntp gleich die zeit an, aber das nachtriggern würde dann wohl  mehr juttern und nicht exakt die 60x sein. oder?

[Otto123]

so eine vermutung hatte ich auch, kenne aber ntp nicht wirklich gut.

erklärt das wirklich dieses verhalten
ich dachte (achtung gefährliches halb, evtl. sogar nur viertelwissen) das die nächste-zeit-triggerung von einem at erst bei eintritt berechnet wird ?!?
ntp gleich die zeit an, aber das nachtriggern würde dann wohl  mehr juttern und nicht exakt die 60x sein. oder?

Das ist von mir auch bloß vermutet. Ich kann mir das aber vorstellen, wenn das Zeitraster zufällig stimmt. Von exakt 60 hat doch keiner gesprochen oder?

Dieses Verhalten kann ich bestätigen, wenn ich mein Testsystem für ein paar Tage abschalte und dann wieder starte, dann triggert ein +*00:01:00 quasi so oft, vom abschaltzeitpunkt bis einschaltzeitpunkt, bis die jetzige Zeit erreicht ist... sprich wenn ich um 15:00 ausschalte und um 16:00 wieder ein, dann 60x

Ich meine: at soll in 10 min triggern, ntp dreht an der Uhr (macht er bei bestimmten Zeitabweichungen langsam um die Systeme nicht zu sehr zu verwirren) und schwupps ist die Zeit um. Das passt doch von der Logik her?

Wenn er den Raspi vom Strom trennt (ohne shutdown), dann hatte fake-hwclock keine Chance die Zeit aktuell zu schreiben, dann ist es quasi bis zu einer Stunde her (glaube ich).
Wenn fake-hwclock gar nicht existiert (warum auch immer), beginnt das Spiel im Jahre 1970 (wobei da ntp erstmal härter vorgeht).

Gruß Otto

[Ma_Bo]

Exakt 60 weiß ich nicht, aber er triggert sehr oft.


Tapatalk mit Handy geschrieben, daher kurz gehalten.

[nils_]

Exakt 60 weiß ich nicht, aber er triggert sehr oft.

ok, dann hab ich das mal interpretiert das es genau 60 wären 
dann hilft vielleicht doch nen logfile/-auszug weiter.

Ich meine: at soll in 10 min triggern, ntp dreht an der Uhr (macht er bei bestimmten Zeitabweichungen langsam um die Systeme nicht zu sehr zu verwirren) und schwupps ist die Zeit um. Das passt doch von der Logik her?

jo passt alles soweit. bin voll und ganz deiner meinung

[Beta-User]

Ich habe das als Aussage von Rudi  so im Kopf, dass "verpaßte" at nachgeholt werden, finde aber leider den entsprechenden Beitrag nicht mehr. Danach wären die 60/61 aus dem Beispiel exakt zutreffend.

Gruß, Beta-User

[nils_]

in der commandref ( https://fhem.de/commandref_DE.html#at ) wird u.a. auf
https://forum.fhem.de/index.php/topic,56706
verwiesen.

das ist mAn aber nen anderes "Problem" (wie schon gesagt: gefährliches viertelwissen!! )



bisher haben wir auch noch kein list von dem at gesehen.
nicht das da noch was schlummert....

[Wernieman]

beginnt das Spiel im Jahre 1970 (wobei da ntp erstmal härter vorgeht)]

Sorry aber das ist gefährliches Halbwissen.

Wenn die Abweichung größer als X (default 1000 s), gleicht ntp die Uhr nicht mehr ab, sondern beendet sich. Eventuell machen dieses von der Distri gestellte Scripte anders, aber (im Normalfall) ntp nicht.

Außerdem gleicht ntp nicht die Uhrzeit in schritten an, sondern lässt die Systemuhr schneller/langsamer laufen. Deshalb kann es natürlich sein, das ein at häufiger getrickert wird, wenn es alle min. laufen soll, aber die Uhrzeit in 30 sec. schon diese eine minute "durch" ist, aber ich weiß nicht, wie schnell ntp die Uhr max laufen lässt.

Edit:
Man Pages sollte man lesen:
innerhalb von 2000sec wird im Normallfall maximal 1sec korrigiert, aus der man page:

Note: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, each second of adjustment requires an amortization interval  of  2000 s.  Thus, an adjustment as much as 600 s will take almost 14 days to complete.

Edit2:
Wenn ntp einmalig richtig setzen soll:

-g     Normally,  ntpd  exits  with  a  message  to  the system log if the offset exceeds the panic threshold, which is 1000 s by default.  This option allows the time to be set to any value without
              restriction; however, this can happen only once.  If the threshold is exceeded after that, ntpd will exit with a message to the system log.  This option  can  be  used  with  the  -q  and  -x
              options.

[Otto123]

Hallo Werner,

ja ich weiß Du hast Recht  In meinem Kopf hängt das alles immer mit "ntp" zusammen, deswegen purzelt das Halbwissen dann so raus.
Aber beim Raspberry wird das auf Grund fehlender RTC beim Start eben ziemlich hart gemacht und wenn ich die Logs richtig lese, erst von fake-hwclock und dann von ntp. Wie ganz genau kann ich auch nicht sagen.

Gruß Otto

[frank]

ich würde ja mal ins syslog schauen.
mit jessie und der fake-clock, sollte doch eigentlich gar nichts bemerkt werden beim reboot. oder ist die fake-clock hardware abhängig?

[Otto123]

hängt von der Situation ab.
fake-hwclock setzt nach dem Neustart des Pi die Zeit auf den letzten Eintrag, der liegt entweder beim ordentlichen shutdown (/etc/init.d/fake-hwclock) oder in der letzten Stunde (/etc/cron.hourly/fake-hwclock)
Wenn er eine Stunde Pause hatte geht er also jetzt eine Stunde nach, wenn kein Internet vorhanden ist ändert sich das auch nicht.
Wenn dann Internet vorhanden ist versucht "einer" die Zeitserver zu erreichen und die Zeit aktuell zu setzen. Wer genau "einer" ist weiß ich nicht, im Log sieht man dann, dass "er" es mit ntp macht.

Also in dem Fall: Beim Start kein Internet vorhanden, läuft FHEM erstmal los, in der "alten" Zeit. Dann irgendwann (Internet erreichbar) ändert "das System" die Zeit auf aktuell.

Gruß Otto

[frank]

, aber wenn ich den Raspi vom Strom trenne und dann wieder anschliesse,

ok..., mit dieser prozedur ist dann wahrscheinlich immer ein sprung in der zeit, wenn fhem vor der synchronisierung startet.

[Frank_Huber]

Deswegen rtc Chip drauf und ruhe ist. 😉

Gesendet von meinem S3_32 mit Tapatalk

[Wernieman]

Oder alternativ sich ein Script schreiben, was VOR fhem die Zeit richtig setzt .. und fhem erst startet, wenn die Zeit bekannt ...

[Frank_Huber]

Oder alternativ sich ein Script schreiben, was VOR fhem die Zeit richtig setzt .. und fhem erst startet, wenn die Zeit bekannt ...

Oder das. wobei mir ein RTC immer lieber ist. So läuft FHEM dann auch weiter wenn das Internet / NTP server nicht erreichbar ist.
Aber Generell ja, das geht auch.
Wichtig ist nur dass FHEM beim Start schon eine brauchbare Uhrzeit hat.

[frank]

Oder alternativ sich ein Script schreiben, was VOR fhem die Zeit richtig setzt .. und fhem erst startet, wenn die Zeit bekannt ...

mit systemd gibt es ja quasi ein solches script, mit dem man den start von fhem bis zum erreichen bestimmter vorbedingungen verzögern kann.

ausserdem sollte man das "steckerziehen" beim pi unterlassen.

[Otto123]

ausserdem sollte man das "steckerziehen" beim pi unterlassen.

Ganz einfach vorm Steckerziehen in FHEM ohne viel Aufwand den Pi mit einen "Ausschalter" aus machen.

Gruß Otto