Habmin2 charting issue with timezones

Setup, Configuration and Use Runtime
,
1

Hi @chris

I have an issue with charting in habmin2 in oh2 where it only charts up to GMT, not GMT-10 (my timezone). Habmin seems to think the last 24 hours is in fact 34-10 hours ago. Can’t figure it out, not sure if it is a bug or some kind of misconfiguration.

  1. Using rrd4j and data appears to be in unix time and correct.

  2. Rest query gives data back correctly with expected unix time.

  3. habmin2 displays correct data at correct time on chart, but only displays data up to 10 hours ago (my timezone is GMT-10, but set correctly as Australia/Melbourne).

I have done things like forced temp or humidity on a sensor high to be sure the data presented is correct. As an example, I force humidity to 90% at midnight. I look at the habmin2 graph at 1am, and the last data presented only goes up to 3pm, there is no spike at 12pm (so the data is not being displayed with the wrong time representation, it’s just not displaying the last 10 hours of data. I wait until 11am, and I can see data up to 1am, with a spike in the Humidity to 90% at 12am, which was when it actually occurred.

  1. Timezone appears to be set correctly and all other timestamps on box, within openhab, in logs etc, are all correct to local time.

CONCLUSION: habmin2 is querying rrd4j for data and converting to localtime correctly, but the calculation for the start and end of the “last day” or whatever period it is asked to chart is NOT having the local timezone applied. When asked to chart the last 24 hours, it is actually charting the period 34-10 hours ago.

What I don’t know is if this is due to a misconfiguration somewhere or a bug. OS is Centos 7 and openhab2 with HABmin2 snapshot Version 0.15, 2016-05-07T15:54:47

2

In theory, all times should be exchanged in UTC, but either that’s not happening somewhere in the system, or you have something configured wrong…

The only thing I can think of that might be an issue is if you had your OH2 server configured to run local time, but somewhere on the server configuration it was set to UTC. Please double check that, and if not let’s discuss here for a bit to see where the issue lies…

3

@skeksil did you have a chance to look at the timezones your machines are running on?

HABmin passes times to the server in the following format 2016-05-28T13:18:51.728Z. Times are passed in UTC. Responses are returned with timestamps using a number that represents the time in milliseconds (again - it should be UTC).

It would be good if you could enable the debugger in your browser, then look at the network messages sent during these requests so that we can try and isolate where in the system the issue is…

4

Hi @chris,

Thanks for the followup. I can’t find anything wrong with the timezone on the machine. Everything is set to “Australia/Melbourne” and date and all logs etc show correct time. openhab log timstamps show correct time. karaf’s “date” command shows correct time.

Using the Chrome debug console i looked at the network requests when loading/refreshing the graph. I just selected one item and hit ok, didn’t change any other graph parameters. Local time here was 11.52am ish, graphs shows data up to 01.52am (from 01.52am yesterday morning). Ie, 10 hours behind (my offset from UTC).

The request in the debug console is:

Z_Office_Temp?endtime=2016-05-29T01:52:38.517Z&servicename=rrd4j&starttime=2016-05-28T01:52:38.517Z

That looks correct for my current time for UTC. but habmin is displaying the x-axis with those times.

Of the 109 points returned, the last element is:

{
  "time": 1464450758000,
  "state": "23.199999999999992184029906638897955417633056640625"
}

which seems to equal: Sat, 28 May 2016 15:52:38 UTC. That is 10 hours behind the 10 hours behind of UTC! (perhaps here is the problem)

If I use the rest interface directly to get the latest data:

curl -X GET --header "Accept: application/json" "http://eye:8081/rest/persistence/Z_Office_Temp?servicename=rrd4j"

The last item returned is:

 {
      "time": 1464488015337,
      "state": "25.699999999999999289457264239899814128875732421875"
    }

Which is Sun, 29 May 2016 02:13:35 UTC, which is the data from just a minute ago.

So, this seems to suggest Habmin is requesting an endtime of localtime in UTC (ie, -10 hours), but the request is returning data 10 hours behind that again, then Habmin is correctly displaying that data in localtime but due to applying the time offset twice, the data is still out by my timezone offset. This suggests to me the issue is not necessarily with Habmin but the data returned. - ie, the openhab persistence API for RRD4J is assuming the request is in localtime, and we’re therefore applying timezone offset twice. Let me know if my interpretation is correct or what else I can do to debug.

If it is a misconfiguration on my part I’m not sure what it could be (system was a pretty vanilla CentOS 7 and fresh OH2/Habmin2 install from a week or two ago. Haven’t really hacked anything in it. I have tried adding -Duser.timezone=Australia/Melbourne to java options, enuring /etc/timezone /etc/localtime env variables like TZ are all set and consistent, but nothing has made a difference…

5

Thanks David. I think your assessment is correct.

I’ve just had a quick look at the ESH code that processes this (which I also wrote) and it looks ok. It converts times using the DateTimeType (ie the standard ESH/OH2 time class) so this should be fine.

The other possibility is that the store itself is doing something “wrong” with the dates (ie RRD4J) - I had a quick look in this code as well, but it also looks ok.

I’m assuming this isn’t a common problem, or everyone not in Europe would have this issue (and in fact probably most people in Europe as well at this time of the year).

However, I’m also sure you’re not alone as this issue does pop up from time to time - I wonder if others with this problem can comment on their system configuration so we can narrow down the problem.

If you’re still playing around with OH, can I suggest something to try. Can you try a different persistence service other than RRD4J. Install the JDBC H2 persistence store and see if that makes any difference. In HABmin you should then be able to swap between them and see if there is any difference (IMHO H2 is much better than RRD4J as it will store your data without changing it!). It will be interesting to see if the problem exists here as well and it might help to narrow things down…

Cheers
Chris

6

Hi @chris,

I installed JDBC H2 yesterday. exactly the same symptoms. Had to wait until today to confirm. Double checked the REST query is for JDBC etc too.

I too found a few threads with people having what appears to be the same problem - some from OH1 too I think. However, I would concur that if this was an issue affecting everyone more people should be reporting it - unless very few people both use habmin2 charting, look at current rather this historical data, and are far enough from UTC to notice it. If you were only a few hours from UTC it might go unnoticed. You would have a better idea of how many people use habmin (I would expect enough to rule this out).

I’m at a bit of a loss on how to proceed from here. It is not a dealbreaker for me, despite the OCD part of my brain wanting it to work. I am more than happy to assist where I can in testing/debugging if you want to continue to pursue it.

7

Strange - I’m not sure where this issue lies. For sure, it works fine here even though I’m only 1 hour off UTC. I agree you could miss that on a ‘wide view’, but when you zoom in, it becomes pretty obvious.

I’d like to resolve this one, but just not sure where it lies - it seems from what you’ve stated above that the issue is somewhere in OH rather than HABmin - if you have any way to work it through in a debugger it would possibly be the best way?

8

Same problem here. Raspbian install. Timezones set to UTC +3 (Moscow)
OH2 installed via the repo - mysql persistance.
OH2 logs are showing correct timestamps.
But in habmin the charts are back lagging 3 hours and displaying in UTC. And it’s not only the problem with the display of X axis times. The data in the charts is actually 3 hours behind!

OH2 charts diplay correctly. Wish i could be of more help if you explain where to look at

9

This is probably an issue in OH rather than in HABmin. The problem was fixed in OH2 - it was associated with time conversions in the DateTimeType