Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[jdbc.mysql] First two hours of any chart always flat #8502

Closed
thinkfat opened this issue Sep 20, 2020 · 4 comments · Fixed by #9445
Closed

[jdbc.mysql] First two hours of any chart always flat #8502

thinkfat opened this issue Sep 20, 2020 · 4 comments · Fixed by #9445
Labels
bug An unexpected problem or unintended behavior of an add-on PR pending There is a pull request for resolving the issue

Comments

@thinkfat
Copy link

When adding any chart to the sitemap (classic ui), the first two hours are always a flat line. Doesn't seem to be an issue with persistence, if I switch to a longer period, the data is there and displayed. Just for each chart, not depending on displayed period, first two hours display a flat line. For hourly charts, of course the trace is then entirely flat.

I use the mysql persistence. No other persistence services enabled.

How to reproduce:
Every chart in a sitemap is affected. For example:
"Chart item=SomeNumberItem period=h refresh=30000" should produce a flat line.

I'm using openhab2 with docker, using the following docker file:

version: '2.2'

volumes:
    db:

services:
  db:
    image: mariadb
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    restart: always
    volumes:
      - db:/var/lib/mysql
    environment:
      - MYSQL_USER=openhab
      - MYSQL_DATABASE=OpenHAB
      - MYSQL_ROOT_PASSWORD=XXX
      - MYSQL_PASSWORD=XXX

  knxd:
    image: "welteki/knxd:latest"
    restart: always
    network_mode: host
    command: knxd -D -R -T -S -e 0.0.1 -E 0.0.2:32 -u /tmp/knxd --send-delay=30 -b ipt:192.168.2.101

  openhab:
    image: "openhab/openhab:latest-debian"
    restart: always
    volumes:
      - "/etc/localtime:/etc/localtime:ro"
      - "/share/Container-Data/openhab/addons:/openhab/addons"
      - "/share/Container-Data/openhab/conf:/openhab/conf"
      - "/share/Container-Data/openhab/userdata:/openhab/userdata"
    environment:
      OPENHAB_HTTP_PORT: "8080"
      OPENHAB_HTTPS_PORT: "8443"
      EXTRA_JAVA_OPTS: "-Duser.timezone=Europe/Berlin"
    ports:
      - "2080:8080"
      - "2443:8443"
      - "2101:8101"
    links:
      - db
@thinkfat thinkfat added the bug An unexpected problem or unintended behavior of an add-on label Sep 20, 2020
@CSchlipp
Copy link
Contributor

I noticed the same quite some time ago, but didn't investigate further.
Whenever there's an offset of 1-2h, this tends to be some kind of timezone problem. The DB entries (at least in my case) are stored with UTC time, guess that's not correctly converted to the local timezone when creating the graphs...

@thinkfat
Copy link
Author

That sounds like a plausible explanation. Is there any way I could check this?

@thinkfat
Copy link
Author

Ok, well, yes. The container the database is running in has timezone UTC. OpenHAB container is on CEST. The mysql.cfg has "localtime=true", though. Should that not work around the difference?

@DiKaY1969
Copy link

I can confirm the problem too.

Unfortunately, the charts only show a static value in the period of 1 hour and not a trend! From a period of 4 hours and higher, the course is displayed correctly in the chart. This is also the case in the HabPanel's chart widget. I have not given a range but the course of the current hour should be given. I use mysql as a database. The time stamps of the data records are entered correctly.

Chart4h
Chart1h

Dierk

@cweitkamp cweitkamp changed the title First two hours of any chart always flat [jdbc.mysql] First two hours of any chart always flat Dec 12, 2020
@cweitkamp cweitkamp added the PR pending There is a pull request for resolving the issue label Dec 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An unexpected problem or unintended behavior of an add-on PR pending There is a pull request for resolving the issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants