Autor Thema: FHEM reporting wrong time, timezone problem ?  (Gelesen 1149 mal)

Offline claudio

  • New Member
  • *
  • Beiträge: 19
FHEM reporting wrong time, timezone problem ?
« am: 27 Oktober 2017, 19:25:13 »
This is my first post, so, I'm happy to say thank you to FHEM devs and community members.

I'm also new to Fhem in general, so please excuse my ignorance.

I've setup a home automation system with Enocean Eltako modules (FAM14, FSB14, FSR14-2x) in the electrical cabinet. My Fhem is running on my home router (netgear R7000 with tomato shibby firmware), this work great, even better than my previous test with a raspberry pi. However, I've a problem with time. The router show the correct time in the SSH terminal and in the web interface, but fhem keep displaying an offset of 2 hours from my localtime, thus breaking all time related functions.

if I run :
perl -le 'print join " =L:G= ", scalar localtime, scalar gmtime'
result is :
Fri Oct 27 19:18:13 2017 =L:G= Fri Oct 27 17:18:13 2017
Seem's fhem is using gmtime where I want it to use my localtime. What can I do about it ? I've already looked at many place but haven't found a solution so far.

Offline RaspiLED

  • Hero Member
  • *****
  • Beiträge: 1634
  • Es begann alles so klein ;-)
Antw:FHEM reporting wrong time, timezone problem ?
« Antwort #1 am: 27 Oktober 2017, 20:36:19 »
Hi,
I found a thread where the perl modul delivered wrong times:
https://forum.fhem.de/index.php/topic,52074.msg440327.html#msg440327

Could you give us these three mktime values?
fhem> { mktime(0,1,0,13,3,116,0,0,-1) }
fhem> { mktime(0,1,0,13,3,116,0,0, 1) }
fhem> { mktime(0,1,0,13,3,116,0,0, 0) }
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 18628
Antw:FHEM reporting wrong time, timezone problem ?
« Antwort #2 am: 27 Oktober 2017, 23:03:38 »
I surmise that FHEM ist started without a TZ environment variable set.

Offline claudio

  • New Member
  • *
  • Beiträge: 19
Antw:FHEM reporting wrong time, timezone problem ?
« Antwort #3 am: 27 Oktober 2017, 23:08:32 »
Hi,
I found a thread where the perl modul delivered wrong times:
https://forum.fhem.de/index.php/topic,52074.msg440327.html#msg440327

Could you give us these three mktime values?
fhem> { mktime(0,1,0,13,3,116,0,0,-1) }
fhem> { mktime(0,1,0,13,3,116,0,0, 1) }
fhem> { mktime(0,1,0,13,3,116,0,0, 0) }
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

this is the result :

fhem> { mktime(0,1,0,13,3,116,0,0,-1) }
1460505660
fhem> { mktime(0,1,0,13,3,116,0,0, 1) }
1460505660
fhem> { mktime(0,1,0,13,3,116,0,0, 0) }
1460505660

Offline claudio

  • New Member
  • *
  • Beiträge: 19
Antw:FHEM reporting wrong time, timezone problem ?
« Antwort #4 am: 28 Oktober 2017, 00:14:01 »
I surmise that FHEM ist started without a TZ environment variable set.

I've inserted a TZ var in my profile and rebooted the router. This line now appear in my environment :

export TZ='CET-1CEST,M3.5.0,M10.5.0/3'
the date command report the correct time

root@routeur] root $ date
Sat Oct 28 00:05:16 CEST 2017

but fhem is still showing a -2 hours offset

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 18628
Antw:FHEM reporting wrong time, timezone problem ?
« Antwort #5 am: 29 Oktober 2017, 10:43:20 »
Can you please check, if FHEM is using the TZ with:
{ $ENV{TZ} }

The date functions use the file /etc/localtime on a "normal" Unix distribution (or more precisely, on the ones I know), if the TZ variable is missing. /etc/localtime is a copy of one of the files found in /usr/share/zoneinfo. Do you have a file named /etc/localtime? If you have strace installed, try the following in the shell:
$ export TZ=

$ strace -e open date
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/etc/localtime", O_RDONLY|O_CLOEXEC) = 3
Sun Oct 29 10:37:42 CET 2017
+++ exited with 0 +++

$ export TZ=MET

$ strace -e open date
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/usr/share/zoneinfo/MET", O_RDONLY|O_CLOEXEC) = 3
Sun Oct 29 10:37:53 MET 2017
+++ exited with 0 +++


Offline claudio

  • New Member
  • *
  • Beiträge: 19
Antw:FHEM reporting wrong time, timezone problem ?
« Antwort #6 am: 29 Oktober 2017, 17:44:14 »
Can you please check, if FHEM is using the TZ with:
{ $ENV{TZ} }

The date functions use the file /etc/localtime on a "normal" Unix distribution (or more precisely, on the ones I know), if the TZ variable is missing. /etc/localtime is a copy of one of the files found in /usr/share/zoneinfo. Do you have a file named /etc/localtime? If you have strace installed, try the following in the shell:
$ export TZ=

$ strace -e open date
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/etc/localtime", O_RDONLY|O_CLOEXEC) = 3
Sun Oct 29 10:37:42 CET 2017
+++ exited with 0 +++

$ export TZ=MET

$ strace -e open date
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/usr/share/zoneinfo/MET", O_RDONLY|O_CLOEXEC) = 3
Sun Oct 29 10:37:53 MET 2017
+++ exited with 0 +++


thanks for your help.

After running { $ENV{TZ} } in the fhem console, I saw that the env variable was empty, although I had added it in the .profile file. Guess it was not at the right place or timming issue.

then I've added :
echo "TZ='CET-1CEST,M3.5.0,M10.5.0/3'; export TZ" >> /root/.profile
TZ='CET-1CEST,M3.5.0,M10.5.0/3'
export TZ

in the script launching fhem, before launching it actually and it worked; now the time is correct

Thanks again for the help and hints

 

decade-submarginal