Uhrzeit am HM-CC-TC

[Guest]

Originally posted by: <email address deleted>

Hallo Zusammen,

nach dem letzten Update geht mein Wandthermometer wieder zwei Stunden nach.
Das PRoblem hatte ich schonmal und heute wollte ich die Zeile wieder
ändern, allerdings sieht die Stelle jetzt irgendwie anders aus. Damals
musste ich folgende Zeile so anpassen:

$s2000 = sprintf("%02X", time()-946681200);

dann hat es wieder gestimmt.
Wie genau mache ich das denn jetzt?

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> $s2000 = sprintf("%02X", time()-946681200);

secSince2000() ist in fhem.pl, und zieht 946684800 ab (== ein Stunde mehr).
Verwendest Du CUL oder HMLAN? Muss diese Anpassung nur fuer die Sommerzeit
gemacht werden?

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo,

ich verwende ein HMLAN und es war Sommerzeitunabhängig.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[eppi]

                                               

Hallo
Ich verwende CUL_HM und habe das selbe Problem mit den HM-CC-TC. Ob das Problem erst seit der Sommerzeitumstellung vorhanden ist, kann ich nicht sagen, da ich diese erst seit ein paar Wochen in Betrieb habe.

Danke für die Hilfe!
Gruss Dani


Am Sonntag, 1. Juli 2012 19:34:58 UTC+2 schrieb Rudolf Koenig:
> > $s2000 = sprintf("%02X", time()-946681200);
>
> secSince2000() ist in fhem.pl, und zieht 946684800 ab (== ein Stunde mehr).
> Verwendest Du CUL oder HMLAN? Muss diese Anpassung nur fuer die Sommerzeit
> gemacht werden?

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

@Rudolf König
Sorry, aber ich hatte mich in meinen ersten Post geirrt. Es war
doch 946688400 und nicht 946681200.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Muss wohl doch was anderes sein.
Falls Logs oder so gebraucht werden, dann einfach Bescheid sagen.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ich habe die Offset-Berechnung in fhem.pl rausgenommen:

#$t += fhemTzOffset($t);

Seitdem stimmt die Zeit auf den CCs wieder. Nur so ins blaue geraten: FHEM
berücksichtigt nicht die lokale Zeiteinstellung bei der Offset-Berechnung
(z.B. export TZ=Europe/Berlin)?

Gruß
Sven

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Nur so ins blaue geraten: FHEM berücksichtigt nicht die lokale
> Zeiteinstellung bei der Offset-Berechnung (z.B. export TZ=Europe/Berlin)?

Doch, aber das scheint eher kontraproduktiv zu sein. Ich fuerchte die Aenderung
vom 2012-06-17, von alt:
  $t -= 946684800;
  $t -= 1*3600; # FIXME/HARDCODED
  $t += 3600 if $isdst;
nach neu:
  $t -= 946684800
  $t -= fhemTzOffset($t);

ist nicht equivalent, fhemTzOffset ist z.Zt 7200.

Nach etwas nachdenken verstehe ich aber beide Varianten nicht,
die obere Version lieferte im Sommer UTC, im Winter UTC-1.
Die untere/aktuelle UTC-2 im Sommer, und UTC-1 im Winter.
Lokalzeit ist doch UTC+1 im Winter und UTC+2 im Sommer.
Wenn man fhemTzOffset auskommentiert, dann kriegt man immer UTC.
Also entweder hat die alte Version auch nie funktioniert, oder ich verstehe was
nicht.

@Gong: steuerst Du dein CC-TC ueber HMLAN oder CUL?

Wenn wir schon dabei sind / aus aktuellen Anlass:
  946684800 = ((2000-1970)*365+7) * 24*60*60
7 ist Anzahl der Shaltjahre zw. 1970 und 2000.  Weiss jemand wo hier die
Schaltsekunden versteckt sind? Oder werden diese in der Zaehlung ignoriert?

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[LuckyDay]

                                         

TAI (Internationale Atomzeitskala) läuft durch
UTC (Koordinierte Weltzeitskala) wird korigiert um die Schaltsekunden
unterschied der 2 Uhren seit 1 Juli 2012 nach Schaltsekunde jetzt 25
Sekunden.

Quelle zum Nachlesen
http://www.ptb.de/cms/index.php?id=1818


On 2 Jul., 12:23, Rudolf Koenig wrote:
> > Nur so ins blaue geraten: FHEM ber cksichtigt nicht die lokale
> > Zeiteinstellung bei der Offset-Berechnung (z.B. export TZ=Europe/Berlin)?
>
> Doch, aber das scheint eher kontraproduktiv zu sein. Ich fuerchte die Aenderung
> vom 2012-06-17, von alt:
>   $t -= 946684800;
>   $t -= 1*3600; # FIXME/HARDCODED
>   $t += 3600 if $isdst;
> nach neu:
>   $t -= 946684800
>   $t -= fhemTzOffset($t);
>
> ist nicht equivalent, fhemTzOffset ist z.Zt 7200.
>
> Nach etwas nachdenken verstehe ich aber beide Varianten nicht,
> die obere Version lieferte im Sommer UTC, im Winter UTC-1.
> Die untere/aktuelle UTC-2 im Sommer, und UTC-1 im Winter.
> Lokalzeit ist doch UTC+1 im Winter und UTC+2 im Sommer.
> Wenn man fhemTzOffset auskommentiert, dann kriegt man immer UTC.
> Also entweder hat die alte Version auch nie funktioniert, oder ich verstehe was
> nicht.
>
> @Gong: steuerst Du dein CC-TC ueber HMLAN oder CUL?
>
> Wenn wir schon dabei sind / aus aktuellen Anlass:
>   946684800 = ((2000-1970)*365+7) * 24*60*60
> 7 ist Anzahl der Shaltjahre zw. 1970 und 2000.  Weiss jemand wo hier die
> Schaltsekunden versteckt sind? Oder werden diese in der Zaehlung ignoriert?

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

>
> @Gong: steuerst Du dein CC-TC ueber HMLAN oder CUL?
>
> Habe hier zwei HM-LANs und ein CUL, alle meine CCs haben derzeit als
>  LASTIODev den CUL gesetzt.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Oskar]

                                                     

Am 02.07.2012 um 12:23 schrieb Rudolf Koenig:

>> Nur so ins blaue geraten: FHEM berücksichtigt nicht die lokale
>> Zeiteinstellung bei der Offset-Berechnung (z.B. export TZ=Europe/Berlin)?
>
> Doch, aber das scheint eher kontraproduktiv zu sein. Ich fuerchte die Aenderung
> vom 2012-06-17, von alt:
>  $t -= 946684800;
>  $t -= 1*3600; # FIXME/HARDCODED
>  $t += 3600 if $isdst;
> nach neu:
>  $t -= 946684800
>  $t -= fhemTzOffset($t);
>
> ist nicht equivalent, fhemTzOffset ist z.Zt 7200.
>
> Nach etwas nachdenken verstehe ich aber beide Varianten nicht,
> die obere Version lieferte im Sommer UTC, im Winter UTC-1.

Das mag ja sein, dafür haben die HM-CC-TC die Zeitinformation "richtig" interpretiert.
Es ist also nach dem experimentellen Stand der Dinge so, dass Homematic UTC-1 als MEZ definiert.
Um nicht zu sagen Homematic UTC ist die echte UTC-2.
Mein HM-CC-TC zeigt mit der alten Variante sowohl im Winter als auch im Sommer die
korrekte Zeit an (wahrscheinlich um die Schaltsekunden zwischen 1970 und 2000 falsch).

> Die untere/aktuelle UTC-2 im Sommer, und UTC-1 im Winter.

Also ganz falsch

> Lokalzeit ist doch UTC+1 im Winter und UTC+2 im Sommer.

Das ist verwirrend formatiert, vielleicht besser so:

Alt:   Sommer UTC,   Winter UTC-1
Neu:   Sommer UTC-2, Winter UTC-1
Lokal: Sommer UTC+2, Winter UTC+1

Also müßte man für Homematic folgendes kodieren:

$t -= 946684800
$t -= 7200 # correct for Homematic deviance from UTC
$t += 32 # correct for leap seconds between 1970 and 2000 ?
$t += fhemTzOffset($t);

Grüße
   Oskar

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Das mag ja sein, dafür haben die HM-CC-TC die Zeitinformation "richtig"
> interpretiert.

Kann das jemand mit einem HMLAN gesteuerten HM-CC-TC auch bestaetigen?


> $t += 32 # correct for leap seconds between 1970 and 2000 ?

Das ist wohl nicht notwendig, dank dem Link von fhem-hm-knecht weiss ich, dass
UTC die Schaltsekunden ignoriert. Btw die Differenz ist 25 und nicht 32

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Oskar]

                                                     

Am 03.07.2012 um 14:13 schrieb Rudolf Koenig:

>> Das mag ja sein, dafür haben die HM-CC-TC die Zeitinformation "richtig"
>> interpretiert.
>
> Kann das jemand mit einem HMLAN gesteuerten HM-CC-TC auch bestaetigen?

Bitte jemand anderes als ich;-)
>
>> $t += 32 # correct for leap seconds between 1970 and 2000 ?
>
> Das ist wohl nicht notwendig, dank dem Link von fhem-hm-knecht weiss ich, dass
> UTC die Schaltsekunden ignoriert.

Hmm.  Stimmt, time() liefert UTC.  

Aber warum stimmt dann die aktuelle Zeit mit TAI überein?
Weil, wie im link recht nebulös beschrieben, in UTC Schaltsekunden eingefügt werden.  
Das konnte man erst kürzlich sehr schön sehen;-)
Die Zeitmechanik in perl (und auf den meisten Systemen) ist deswegen in der Rückrechnung falsch,
die Sekunde 0 (1.1.1970) ist 35 Sekunden verschoben (weil UTC mit 10 Sekunden Differenz zu TAI
erstmals 1972 korrigiert wurde).  Deswegen auch die 32 (UTC Differenz von 1970-2000)

> Btw die Differenz ist 25 und nicht 32

Bis heute insgesamt, ohne die 10 Sekunden Ausgabeaufschlag, ja

Grüße
   Oskar (der dieses Jahr das erste Mal gelassen zuschauen konnte, weil nicht mehr verantwortlich...)

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Seit geraumer Zeit finde ich folgende Einträge in der LOG Datei.

Was hat es damit auf sich? Habe ich etwas verpasst?

Gruß Klaus

FHEM Neustart

2012.07.06 20:32:17 0: Server shutdown
2012.07.06 20:32:19 1: Including /etc/fhem.cfg
2012.07.06 20:32:20 3: WEB: port 8083 opened
2012.07.06 20:32:20 3: WEBS: port 8084 opened
2012.07.06 20:32:20 3: Opening CUL device /dev/ttyACM0
2012.07.06 20:32:20 3: CUL device opened
Use of implicit split to @_ is deprecated at /usr/share/fhem/FHEM/95_FLOORPLAN.pm line 410, <$fh> line 76.
2012.07.06 20:32:22 1: OWX: Serial device /dev/ttyUSB0 defined
2012.07.06 20:32:22 1: OWX: 1-Wire bus master DS2480 detected for the first time
2012.07.06 20:32:22 3: OWID:   Device OWXID defined.
2012.07.06 20:32:22 3: OWTEMP: Device 1W.T_Gartenhaus defined.
2012.07.06 20:32:22 3: OWTEMP: Device 1W.T_Dach defined.
2012.07.06 20:32:22 3: OWTEMP: Device 1W.T_Garage defined.
2012.07.06 20:32:22 3: OWTEMP: Device 1W.T_Wasser defined.
2012.07.06 20:32:22 3: OWTEMP: Device 1W.T_Zirko defined.
2012.07.06 20:32:22 3: OWTEMP: Device 1W.T_F_Heizung_.V defined.
2012.07.06 20:32:22 3: OWTEMP: Device 1W.T_F_Heizung_R defined.
2012.07.06 20:32:22 3: OWTEMP: Device 1W.T_K_Heizung_.V defined.
2012.07.06 20:32:22 3: OWTEMP: Device 1W.T_K_Heizung_R defined.
2012.07.06 20:32:22 3: OWCOUNT:   Device Zaehler defined.
2012.07.06 20:32:22 3: OWSWITCH:   Device IO defined.
2012.07.06 20:32:25 3: telnetPort: port 7072 opened
2012.07.06 20:32:25 1: Including /var/log/fhem/fhem.save
Use of uninitialized value in concatenation (.) or string at /usr/bin/fhem.pl line 389.
2012.07.06 20:32:25 0: Server started (version , pid 9749)
2012.07.06 20:32:42 1: OWX: Warning, IO is defined with improper family id 1D, correcting to 3A
2012.07.06 20:32:42 1: OWX: 1-Wire devices found (1W.T_F_Heizung_R,1W.T_Zirko,1W.T_Garage,1W.T_Gartenhaus,1W.T_Dach,1W.T_K_Heizung_.V,1W.T_F_Heizung_.V,1W.T_Wasser,1W.T_K_Heizung_R,IO,OWXID,Zaehler)
2012.07.06 20:33:17 2: dummy set D_Kaffeemaschine off
Use of uninitialized value in numeric ne (!=) at (eval 25) line 1.

Aufruf von Floorplan
Invalid conversion in sprintf: "%<" at /usr/share/fhem/FHEM/99_Utils.pm line 140.
Use of uninitialized value $_ in split at /usr/share/fhem/FHEM/99_myFloorplanList.pm line 68.
Use of uninitialized value $cssTitle in substitution (s///) at /usr/share/fhem/FHEM/99_myFloorplanList.pm line 70.
Use of uninitialized value $cssTitle in concatenation (.) or string at /usr/share/fhem/FHEM/99_myFloorplanList.pm line 71.
Use of uninitialized value $title in concatenation (.) or string at /usr/share/fhem/FHEM/99_myFloorplanList.pm line 71.
Use of uninitialized value $cssTitle in concatenation (.) or string at /usr/share/fhem/FHEM/99_myFloorplanList.pm line 71.
Use of uninitialized value $value in concatenation (.) or string at /usr/share/fhem/FHEM/99_myFloorplanList.pm line 71.



--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[LuckyDay]

                                         

>Kann das jemand mit einem HMLAN gesteuerten HM-CC-TC auch bestaetigen?

Ich würde ja gerne, leider ist meine 7390 zur Rep., da einfach nach
Strom aus und ein , -->TOT

Ist ja Sommer, zu Glück  

Hary

On 3 Jul., 18:49, Jan-Hinrich Fessel wrote:
> Am 03.07.2012 um 14:13 schrieb Rudolf Koenig:
>
> >> Das mag ja sein, dafür haben dieHM-CC-TCdie Zeitinformation "richtig"
> >> interpretiert.
>
> > Kann das jemand mit einem HMLAN gesteuertenHM-CC-TCauch bestaetigen?
>
> Bitte jemand anderes als ich;-)
>
>
>
> >> $t += 32 # correct for leap seconds between 1970 and 2000 ?
>
> > Das ist wohl nicht notwendig, dank dem Link von fhem-hm-knecht weiss ich, dass
> > UTC die Schaltsekunden ignoriert.
>
> Hmm.  Stimmt, time() liefert UTC.
>
> Aber warum stimmt dann die aktuelle Zeit mit TAI überein?
> Weil, wie im link recht nebulös beschrieben, in UTC Schaltsekunden eingefügt werden.
> Das konnte man erst kürzlich sehr schön sehen;-)
> Die Zeitmechanik in perl (und auf den meisten Systemen) ist deswegen in der Rückrechnung falsch,
> die Sekunde 0 (1.1.1970) ist 35 Sekunden verschoben (weil UTC mit 10 Sekunden Differenz zu TAI
> erstmals 1972 korrigiert wurde).  Deswegen auch die 32 (UTC Differenz von 1970-2000)
>
> > Btw die Differenz ist 25 und nicht 32
>
> Bis heute insgesamt, ohne die 10 Sekunden Ausgabeaufschlag, ja
>
> Grüße
>         Oskar (der dieses Jahr das erste Mal gelassen zuschauen konnte, weil nicht mehr verantwortlich...)

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com