Habmin timestamp is wrong / Any suggestions?

Setup, Configuration and Use Beginners
,
1

Hi folks,

during inclusion of my latest zwave device (Fibaro FGSD002 smoke sensor), I noticed that the timestamp in habmin doesn’t match with the timestamp of OH/Raspian. For example, the zwave log (I’m using a dedicated log for zwave) shows a wakeup of the device this morning at 05:34. The wakeup-status in habmin for this device shows 03:34, so it’s two hours earlier.

Maybe this is a timezone problem? But I can’t find any options in habmin to change the timezone. Any suggestions?

Thanks,
Stefan

2

HABmin displayes the times that come from OH, but should account for timezones on the PC. In theory, the times returned by OH should be UTC and the PC should display the right time, but maybe there’s a timezone issue somewhere…

3

As my time zone (Germany, summer time) is UTC+2 at the moment, at least the two hours difference seem to be related to the timezones.

The question is: Where is the issue? Raspian? OH1? HABmin? Or even an individual problem of my installation? Is the timestamp in the log files based on the Raspian time or the OH1 time? At least everything seems to be correct there.

4

Good question - I’ve no good answer…

Well, I hope that given OH1 is running under Raspian, that the times are the same?

When you say the log timestamp is correct - what does that mean? Is it logging local time, or UTC?

5

Yes, the log timestamp is “correct” (for my location) and it’s logging local time.

6

@chris I’m also seeing UTC times rather than local time. This is on a Win7 install. Is time/date conversion to local available under Windows?

7

Er… really? Seems to me that I’m getting the opposite… logs are local time, habmin is in UTC:

2016-06-21 08:46:40.192 [INFO ] [g.openhab.model.script.openhab] - Upstairs hall PIR CLOSED, downstairs hall PIR CLOSED, but bright (60) and not virtually dark.  Ignoring.
2016-06-21 08:46:49.857 [INFO ] [g.openhab.model.script.openhab] - Upstairs hall PIR OPEN, downstairs hall PIR CLOSED, but bright (60) and not virtually dark.  Ignoring.

habmin.png919×213 67.9 KB

(Right now I’m on CDT, which is -5 UTC.)

8

Well, the timestamps that are sent by OH should use the ISO8601 standard. This standard defines the time, and also the timezone. If I look at the times coming from OH right now, I see this -: 2016-06-21T15:05:07.596+0100. Time now is 15:05, and being in the UK we are 1 hour head of UTC.

This is then interpreted by HABmin using a standard library called momentjs. It’s a standard library used on many projects.

I don’t know what time goes into logs. It might also depend on the logback configuration - I’m not sure.

9

I’ve found some time to have a bit more of a look at this and found some JS methods are assuming local time when I assumed they used UTC. This will account for some of the error at least…

10

On following this through further, there also appears to be a problem with the time conversion in OH itself…

1 Like
11

Thanks chris for your research. I am a beginner, so I do not understand half of the stuff which is written in the issue thread, but it seems that this will only be fixed in ESH/OH2, not in OH1?

12

I’m not sure the problem will exist in HABmin in OH1, but the problem probable does exist in the core - unless someone copies the fix into OH1, then it won’t be fixed in OH1. You could try raising an issue in OH1 and see if someone will do this.