Hallo zusammen,
ich hatte heute folgend komische Meldung im LOG:
[ROLLLADEN_SZ_LINKS_hoch_we] DST offset=53998.2178440094
CUL_HM set ROLLLADEN_SZ_LINKS on
[ROLLLADEN_GAST_TEST_auf_we] DST offset=59398.3758399487
[ROLLLADEN_GAST_1_hoch_we] DST offset=59398.032959938
Die beiden unteren devices sind nur Testdummies, das obere ist ein Rollladenfunkschalter.
Gruß
Jens
Nein das ganze tritt auch bei dem dummy auf. Hat also erstmal nichts mit dem device zu tun.
Gruß
Jens
Gesendet von meinem iPhone mit Tapatalk
... Allerdings sind die devices alle per weekdaytimer gesteuert. Die anderen devices, wo das Problem nicht auftrat, sind über ein at kommando bzw notify gesteuert.
Gesendet von meinem iPhone mit Tapatalk
Ich vermute das die weekdaytimer Funktion die Meldung verusacht. Weil es unabhängig von einem hatdwaredevice auch ab einem dummy auftrat.
Gesendet von meinem iPhone mit Tapatalk
Sorry für mich ist als Anfänger nicht klar erkennbar welches Modul die Ursache ist. Es ist nur eine Vermutung. Deshalb habe ich es zunächst hier geschrieben. Mir war nur klar das es nicht an irgendeiner Hardware liegen kann, da auch das dummy gerat das gleiche gemacht hat.
Leider bin ich der englischen sprach nicht so mächtig, und unterwegs ist es noch schwierige die mainzainer txt per iPhone durchzusuchen.
Für mich war das zunächst mal eine Anfänger Frage , ich wusste nichts woher die Meldung kommt.
Aber ich stelle die Frage gern auch noch mal da wo sie hingehört, sobald ich genau weiß ob weekdaytimer dafür verantworlich ist, allerdings wusste ich nicht wie ich das als Anfänger genauer untersuchen kann.
Gruß
Jens
Gesendet von meinem iPhone mit Tapatalk
Es könnte durchaus sein, dass wdt eine solche Meldung verursacht. Ich schaue nachher nach was die Meldung zu bedeuten hat.
Es etwas mit der Sommerzeit zu tun.
Poste bitte mal deine Definitionen!
Willkommen bei "Puschels Steilvorlagen" ... 8)
Die Meldung kommt übrigens aus 98_Heating_Control.pm
Es ist leider ein bedauerlicher Fehler in der Behandlung der Sommerzeit.
Eigentlich sollte es der große Wurf werden - ist aber leider noch ein bug enthalten.
Ich versuche diese Sommerzeitumstellung zu nutzen, das Problem zu lösen.
An diesem Wochende wir dieser bug leider dafür sogen, dass die eine oder andere Schaltung durch WDT und Heating_Control nicht zum richtigen Zeitpunkt durchgeführt werden.
Dein Pawlowscher Reflex hier:
ein HM-Funkschalter?
Dann verschieb ich in den Homematic-Bereich da martin sicher mehr damit anfangen kann.
obwohl in der Fehlerbeschreibung und dem Logauszug eindeutig erkennbar war, dass der Aktor ROLLLADEN_SZ_LINKS überhaupt nicht das Thema ist.
Und in Folge dann die mehrfache Schulmeisterei des Fragestellers, und Dein innerer Zwang, den Beitrag irgendwohin verschieben zu müssen, anstatt dem fragenden Anfänger (nach eigener Aussage!) pragmatisch zu helfen und schnell nachzuschauen, aus welchem Modul die Meldung stammt (bei mir hat die Suche keine 10 Sekunden gedauert, um herauszufinden, welches Modul verantwortlich ist).
Statistik: Der Thread hat nun 14 Beiträge. Davon sind vier von Dir, und diese vier haben alle vier nichts mit dem Thema oder gar der Problemstellung zu tun, sondern nur damit, dass der Thread vielleicht nicht in die Anfängerfragen gehören könnte. Das ist doch schizophren.
Hallo Zusammen,
es ist überhaupt nicht mein Absicht hier solchen Wirbel zu verursachen.
@Dietmar63: ich wußte nicht das der Fehler bekannt ist.
@betateilchen danke, das Du das für mich so schnell recherchiert hast.
Haben wir uns alle wieder lieb und schließen den Beitrag (Wie macht man das? -> nächste Anfängerfrage ;-))
Gruß
aus Wendeburg
Jens
Du kannst den Thread schließen, indem Du in den erweiterten Optionen des Editorfenster den entsprechenden Haken setzt.
Aber warte doch mit dem Schließen erstmal, bis das Problem gelöst ist.
Der Fehler war nicht bekannt.
Skeptisch wurde ich bei der Größe des offset.
Ansich sollte er nicht größer als 3600 betragen.
Wenn ich einen Fix für das Problem habe, stelle ich das reparierte Modul ein. Ich werde es aber nicht überstürzen.
Was möchtest Du da eigentlich ermitteln?
sub Heating_Control_DSTOffset($$$) {
my ($hash,$t1,$t2)= @_;
my @lt1 = localtime($t1);
my @lt2 = localtime($t2);
# wenn t2 in der ersten Stunde der dst liegt darf nicht gleich 3600 Sekunden abgezogen werden.
# dstEin ist immer am letzten Sonntag im M‰rz.
my $dstEin = timelocal_nocheck(0,0,2,31,2,$lt2[5]); # 31. Maerz aktuelles Jahr
my @aNow = localtime($dstEin);
$dstEin += -$lt2[6]*24*3600; # letzen Maerzsonntag ermittlen.
my $offset = $t2 - $dstEin + 1; # $secsSinceDstEin
$offset = 3600 if ($offset >3600); # maximal 3600 Sekunden
$offset *= ($lt1[8] - $lt2[8]); # nur wenn Wechsel der dst
Log 3, "[$hash->{NAME}] DST offset=$offset" if ($offset != 0);
return $offset;
}
Ich habe auch die besagte Meldung im Logfile von FHEM. Hier mal meine Meldungen, falls es was hilft.
2014.03.29 19:00:00 3: [HCJeanettew] DST offset=72899
2014.03.29 19:00:00 3: [HCNadinew] DST offset=72899
2014.03.29 20:00:00 3: [HCBadwe] DST offset=62999
2014.03.29 20:00:00 2: FHT set FHT_Bad desired-temp 20.0
2014.03.29 20:00:00 3: [HCBuerow] DST offset=72899
2014.03.29 20:00:00 3: [HCSchlafenwe] DST offset=62999
2014.03.29 20:00:00 2: FHT set FHT_Schlafen desired-temp 15.0
2014.03.29 20:00:00 3: [HCBadw] DST offset=73799
2014.03.29 20:00:00 3: [HCBuerowe] DST offset=62999
2014.03.29 20:00:00 2: FHT set FHT_Buero desired-temp 16.0
2014.03.29 20:00:00 3: [HCWZwe] DST offset=62999
2014.03.29 20:00:00 2: FHT set FHT_Wohnen desired-temp 16.0
2014.03.29 20:00:00 3: FS20 set FS20_LEDLicht on
2014.03.29 20:00:00 3: [HCWCwe] DST offset=62999
2014.03.29 20:00:00 2: FHT set FHT_GaesteWC desired-temp 15.0
2014.03.29 20:00:00 3: [HCJeanettewe] DST offset=62999
2014.03.29 20:00:00 2: FHT set FHT_Jeanette desired-temp 15.0
2014.03.29 20:00:00 3: [HCNadinewe] DST offset=62999
2014.03.29 20:00:00 2: FHT set FHT_Nadine desired-temp 15.0
2014.03.29 20:00:00 3: [HCWZw] DST offset=72899
2014.03.29 20:00:00 3: [HCWCw] DST offset=72899
2014.03.29 20:00:00 3: [HCSchlafenw] DST offset=72899
2014.03.29 20:00:00 3: [HCFlurw] DST offset=72899
2014.03.29 20:00:00 3: [HCFlurwe] DST offset=62999
2014.03.29 20:00:00 2: FHT set FHT_Flur desired-temp 16.0
Und hier noch als Beispiel meine Definition für HCFlur...
define HCFlurw Heating_Control FHT_Flur 04:45|21.0 1245|07:15|18.0 3|08:30|18.0 14|13:00|21.0 23|14:15|21.0 5|13:45|21.0 20:00|16.0 { fhem ("set @ desired-temp %") if(!$we) }
define HCFlurwe Heating_Control FHT_Flur 12345|04:45|21.0 67|07:30|21.0 20:00|16.0 { fhem ("set @ desired-temp %") if($we) }
@betateilchen:
Wenn man mit absoluten Zeitangaben die epochs über den Zeitpunkt der Sommerzeitzeitumstellung rechen will, muss man eine Korrektur einfügen - Rudi hat so etwas ähnliches auch im at gebastelt, ist aber auch nicht universell und immer richtig.
In der folgenden Nacht liegen die zwei Epochs 2:00Uhr und 3:00 Uhr nur eine Sekunde auseinander.
Dies muss man berücksichtigen, wenn man so gegen Mitternacht einen Timer setzen will, der gegen 6:00 feuerern soll.
Wenn man nichts macht, dann feuert der Timer zu spät, nähmlich um 7:00 Uhr. Deshalb müssen 3600 Sekunden vom Ergebnis abgezogen werden, und zwar immer dann wenn dst-bit(24:00) = 0 und dst-bit(06:00) = 1.
Kompliziert wird es wenn der Timer genau zwischen 2:00 und 3:00 während der Zeitumstellung feuer soll, dann müssen alle Timer auf 3:00 Uhr gestellt werden. Dazwischen gibt es im Grunde keine Sekunden.
my $dstEin = timelocal_nocheck(0,0,2,31,2,$lt2[5]); # 31. Maerz aktuelles Jahr
my @aNow = localtime($dstEin);
$dstEin += -$lt2[6]*24*3600; # letzen Maerzsonntag ermittlen.
soll für ein beliebiges Jahr die Stunde der Zeitumstellung berechen dstEin=daylightSavingTimeEin. Stimmt aber um einen Tag nicht - verrechnet.
lt1[8] und lt2[8] sind die dst-bits. Aus ihrer Differenz erreche ich ein Vorzeichen(+1,-1), das ursprünglich automatisch bei SommerzeitEin bzw. SommerzeitAus die korrekte Verschiebung sowol im März als auch im Oktober sicherstellen sollte: von 0 auf 1 ==> -1, also im März 3600 abziehen, im Oktober von 1 auf 0 ==> +1, also 3600 addieren. Es hat sich aber später herausgestellt, dass im Okober nicht korrigeirt werden muss.
Die Lösung habe ich schon. So wäre es richtig gewesen:
# wenn t2 in der ersten Stunde der dst liegt darf nicht gleich 3600 Sekunden abgezogen werden.
# dstEin ist immer am letzten Sonntag im März.
my $dstEin = timelocal_nocheck(0,0,2,31,2,$lt2[5]); # 31. Maerz aktuelles Jahr
my $daysToLastSunday = $lt2[6]+1;
$dstEin -= $daysToLastSunday*24*3600-3600; # letzen Maerzsonntag ermittlen.
Zitat von: Dietmar63 am 29 März 2014, 20:50:49
Stimmt aber um einen Tag nicht - verrechnet.
Danke. Das bestätigt meine Vermutung und meine Fehlersuche, nachdem ich die Werte einfach mal in Relation zu 86400 gesetzt hatte :)
Hallo zusammen,
so wie sehe, hat Dietmar das Problem schon eingekreist, und ich brauche jetzt nicht noch meine Definition zu posten.
Heute übrigens sind die Rollladen wohl 1 Stunde später hochgefahren als eingtragen (Logisch).
Gruß
Jens