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
> $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
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
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
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
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
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
> 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
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
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
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
> 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
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
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
>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
Hallo zusammen
Ich möchte gerne das Thema nochmals aufgreifen.
Heute morgen habe ich die nachfolgenden Zeilen in meine fhem.pl eingetragen:
$t -= 946684800;
$t -= 7200; # correct for Homematic deviance from UTC
$t += 32; # correct for leap seconds between 1970 and 2000 ????
$t += fhemTzOffset($t);
Dann einen shutdown restart durchgeführt. Danach bei einem meiner HM-CC-TC
die Batterien entfernt und wieder eingesetzt, die Uhr manuell auf 23.40h
gesetzt. Kurz nach dem der HM-CC-TC 00:00h anzeigte, hat er die Uhrzeit auf
die korrkete, aktuelle korrigiert.
Ich verwende CUL im Homematic Mode, keine HMLAN Adapter.
Wäre es möglich diese Zeilen in die fhem.pl einzuchecken, sofern keine
sonstigen (unerwarteten) Probleme aufteten, zBsp bei der Umstellung auf die
Winterzeit?
Vielen Dank für die Prüfung und Gruss, Dani
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> $t += 32; # correct for leap seconds between 1970 and 2000 ????
Das ist laut div. Doku und etwas nachdenken nicht noetig/falsch. Da es aber
auf dem HM-CC-TC keine Sekunden zu sehen sind, faellt es nicht auf.
> Wäre es möglich diese Zeilen in die fhem.pl einzuchecken,
gerne aber ich warte noch auf die Bestaetigung, dass das gleiche Code fuer
HMLAN und CUL als IODev funktioniert. Und ich werde es aus fhem.pl nach
10_CUL_HM.pm und 00_HMLAN.pm packen, da es mir mit diesem Offset zu speziell
und damit irrefuehrend ist.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Rudi
Ich habe mir von einem Bekannten einen HMLAN Adapter ausgelehnt und in FHEM
integriert.
Ich habe alle meine CUL im Homematic Mode deaktiviert dass nur der HMLAN
aktiv ist.
Wieder die gleiche Prozedur durchgeführt, Batterien aus HM-CC-TC entfernt,
etc...
Die Uhrzeit wird ebenfalls nach dem der HM-CC-TC "Mitternacht" erreicht hat
mit der korrekten Uhrzeit/Datum von FHEM versorgt.
Mein zweiter Versuch war eine Mischumgebung bestehend aus HMLAN und CUL im
HM Mode mit selber hmId, dabei habe ich geachtet, dass einmal das CUL und
ein anderes mal der HMLAN als LastIO DEV angeben wurden (Umplatzierung des
HM-CC-TC).
Auch diese Versuche waren erfolgreich.
Könntest du nun bitte dies korrgieren in 10_CUL_HM.pm und 00_HMLAN.pm?
Vielen Dank! Gruss Dani
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Könntest du nun bitte dies korrgieren in 10_CUL_HM.pm und 00_HMLAN.pm?
Habs korrigiert und eingecheckt. Kannst Du bitte deinen Test nach der
Zeitumstellung bitte wiederholen? :)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
>
>
> Habs korrigiert und eingecheckt. Kannst Du bitte deinen Test nach der
> Zeitumstellung bitte wiederholen? :)
>
Ja klar, habe es mir eingeschrieben.
Gruss Dani
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Moin zusammen,
ich habe ein HM-CC-TC mit fhem (auf Raspberry Pi) gepaired laufen. Als ich
ihn vor drei Tagen manuell konfiguriert hatte, hat er noch die richtige
Uhrzeit angezeigt. Jetzt ist mir aufgefallen, dass der HM-CC-TC eine Stunde
zurück ist.
In allen logfiles ist die Uhrzeit richtig; auch "date" auf dem Raspi
liefert die richtige Uhrzeit.
Grüße
Peter
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Das Problem hatte ich auch.
Da der RPi bei mir noch in der Testphase ist (weil ziemlich instabil), hab
ich dafür gesorgt, das die HM-CC-TC sich ihre Zeit von der FritzBox holen,
indem ich die HMid auf dem RPi geändert habe.
Ich hab das ursprüngliche Thema leider aus den Augen verloren, aber ich
meine mich zu erinnern, das Rudolf das gleiche Problem hatte.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Scheint ein bekanntes Problem auf allen Debian Systemen zu sein!
siehe auch
https://groups.google.com/forum/#!topic/fhem-users/5HNaMEx3GQw%5B26-50%5D
Siehe Beitrag:
Ich habe seit 2 Tagen auch dieses Problem und habe mir geholfen mit
folgendem Workaround:
10_CUL_HM.pm, (Zeile 1964) & 00_HMLAN.pm (Zeile 387)
$t -= 7200; # HM Special
durch
$t -= 3600; # HM Special
ersetzen
So läuft es bei mir auch.
Gruss Billy
Am Samstag, 13. Oktober 2012 09:36:53 UTC+2 schrieb Fladdy:
>
> Moin zusammen,
>
> ich habe ein HM-CC-TC mit fhem (auf Raspberry Pi) gepaired laufen. Als ich
> ihn vor drei Tagen manuell konfiguriert hatte, hat er noch die richtige
> Uhrzeit angezeigt. Jetzt ist mir aufgefallen, dass der HM-CC-TC eine Stunde
> zurück ist.
>
> In allen logfiles ist die Uhrzeit richtig; auch "date" auf dem Raspi
> liefert die richtige Uhrzeit.
>
> Grüße
> Peter
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Ahh, Danke für den Tipp.
Hatte ich verpasst, da ich den HM-CC-TC erst seit Donnerstag habe ... ;-)
Am Samstag, 13. Oktober 2012 10:04:42 UTC+2 schrieb littlebilly:
>
> Scheint ein bekanntes Problem auf allen Debian Systemen zu sein!
> siehe auch
> https://groups.google.com/forum/#!topic/fhem-users/5HNaMEx3GQw%5B26-50%5D
>
> Siehe Beitrag:
> Ich habe seit 2 Tagen auch dieses Problem und habe mir geholfen mit
> folgendem Workaround:
>
> 10_CUL_HM.pm, (Zeile 1964) & 00_HMLAN.pm (Zeile 387)
>
> $t -= 7200; # HM Special
> durch
> $t -= 3600; # HM Special
> ersetzen
>
> So läuft es bei mir auch.
>
> Gruss Billy
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo!
Ich hatte bis jetzt immer wie unten beschrieben gehandelt und die Zeit war
dann richtig eingestellt, nun habe ich mir einen neuen HM-CC-TC dazu geholt
, in fhem angelernt doch nur bei diesem stellt er die Stunde wieder vor bei
den anderen aber nicht.
Restart und nochmal gepairt immer das gleiche.
Woran könnte das liegen???
Mfg Steffen
Am Samstag, 13. Oktober 2012 12:28:43 UTC+2 schrieb Fladdy:
>
> Ahh, Danke für den Tipp.
> Hatte ich verpasst, da ich den HM-CC-TC erst seit Donnerstag habe ... ;-)
>
> Am Samstag, 13. Oktober 2012 10:04:42 UTC+2 schrieb littlebilly:
>>
>> Scheint ein bekanntes Problem auf allen Debian Systemen zu sein!
>> siehe auch
>> https://groups.google.com/forum/#!topic/fhem-users/5HNaMEx3GQw%5B26-50%5D
>>
>> Siehe Beitrag:
>> Ich habe seit 2 Tagen auch dieses Problem und habe mir geholfen mit
>> folgendem Workaround:
>>
>> 10_CUL_HM.pm, (Zeile 1964) & 00_HMLAN.pm (Zeile 387)
>>
>> $t -= 7200; # HM Special
>> durch
>> $t -= 3600; # HM Special
>> ersetzen
>>
>> So läuft es bei mir auch.
>>
>> Gruss Billy
>>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Steffen,
ich habe nach der Zeitumstellung wieder auf $t -= 7200; # HM Special
zurückgestellt.
Jetzt laufen alle 5 TC's wieder richtig.
Gruss Billy
$t -= 7200; # HM Special
>>> durch
>>> $t -= 3600; # HM Special
>>> ersetzen
>>>
>>> So läuft es bei mir auch.
>>>
>>> Gruss Billy
>>>
>>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Sollte eigentlich automatisch gehen.
- haben manche TCs eine andere Uhrzeit im gleiche system?
- kann jemand die events aus seinen Logs suchen 'time-request'?
Wie oft fragt der TC nach?
- Fragen alle TCs nach und haben dann verschieden Zeiten?
Wichtig ist, das aktuelle fhem.pl zu haben - das ist die Quelle der
Zeitrechnung.
Gruss
Martin
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Wichtig ist, das aktuelle fhem.pl zu haben - das ist die Quelle der
> Zeitrechnung.
Ich haette nichts dagegen, dies aus fhem.pl zu entfernen, zu gross ist meine
Sorge, dass unterschiedliche Systeme in diesem Fall unterschiedliche
Sondermacken haben. Und es geht um ganz wenige Zeilen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Ich denke, ich kenne den Fehler. Es wird die Sommerzeit von vor 30 Jahren
und 2 Stunden beruecksichtigt...
wird angepasst.
Dennoch sollten alle TCs die gleiche Uhrzeit haben...
Gruss
Martin
Am Donnerstag, 15. November 2012 10:30:25 UTC+1 schrieb Martin:
>
> Sollte eigentlich automatisch gehen.
> - haben manche TCs eine andere Uhrzeit im gleiche system?
> - kann jemand die events aus seinen Logs suchen 'time-request'?
> Wie oft fragt der TC nach?
> - Fragen alle TCs nach und haben dann verschieden Zeiten?
>
> Wichtig ist, das aktuelle fhem.pl zu haben - das ist die Quelle der
> Zeitrechnung.
>
> Gruss
> Martin
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
ok - werde es lokal erledigen (CUL_HM und HMLAN).
Am Donnerstag, 15. November 2012 10:38:57 UTC+1 schrieb Rudolf Koenig:
>
> > Wichtig ist, das aktuelle fhem.pl zu haben - das ist die Quelle der
> > Zeitrechnung.
>
> Ich haette nichts dagegen, dies aus fhem.pl zu entfernen, zu gross ist
> meine
> Sorge, dass unterschiedliche Systeme in diesem Fall unterschiedliche
> Sondermacken haben. Und es geht um ganz wenige Zeilen.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Hallo,
muss es hier nicht +7200 sein?
Meine Uhr ging heute morgen 4 Stunden nach, als ich es auf -7200 hatte.
Gruß
Gregor
Am Dienstag, 3. Juli 2012 12:59:57 UTC+2 schrieb oskar:
>
>
> Am 02.07.2012 um 12:23 schrieb Rudolf Koenig:
>
> 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