Charts is doing strange interpolation if period M or longer is choosen

[der-dag]

Which UI are you reporting an issue for?

• Basic UI
• HABPanel
• HABot
• CometVisu

The problem

Just upgraded my openhab from 4.0.4 to 4.3.2 and now some charts are looking strange. I’m using Chart in BasicUI sitemap:

E.g. I have a chart showing the daily gas consumption of the last month. Values are from rrd4j. Every night the value is updated with the consumption of the previous day.

Chart item=Consum_Gas24h period=M refresh=300000

The chart for one month (period=M) now looks like this, somehow it is interpolating:

Expected behavior

If I switch the chart period to show the values of the past two weeks only chart looks as it was in the older openhab versions and in my eyes it is correctly displayed:

Steps to reproduce

Your environment

runtimeInfo:
  version: 4.3.2
  buildString: Release Build
locale: de-DE
systemInfo:
  configFolder: /opt/openhab4/current/conf
  userdataFolder: /opt/openhab4/current/userdata
  logFolder: /opt/openhab4/current/userdata/logs
  javaVersion: 17.0.13
  javaVendor: Debian
  osName: Linux
  osVersion: 6.1.0-29-amd64
  osArchitecture: amd64
  availableProcessors: 4
  freeMemory: 539401568
  totalMemory: 872415232
  uptime: 242139
  startLevel: 100
addons:
  - automation-jsscripting
  - binding-mqtt
  - persistence-rrd4j
  - transformation-jsonpath
  - transformation-map
  - transformation-regex
  - transformation-scale
  - ui-basic
  - ui-habpanel
clientInfo:
  device:
    ios: false
    android: false
    androidChrome: false
    desktop: true
    iphone: false
    ipod: false
    ipad: false
    edge: false
    ie: false
    firefox: true
    macos: false
    windows: true
    cordova: false
    phonegap: false
    electron: false
    nwjs: false
    webView: false
    webview: false
    standalone: false
    os: windows
    pixelRatio: 1
    prefersColorScheme: light
  isSecureContext: true
  locationbarVisible: true
  menubarVisible: true
  navigator:
    cookieEnabled: true
    deviceMemory: N/A
    hardwareConcurrency: 8
    language: de
    languages:
      - de
      - en-US
      - en
    onLine: true
    platform: Win32
  screen:
    width: 2560
    height: 1440
    colorDepth: 24
  support:
    touch: false
    pointerEvents: true
    observer: true
    passiveListener: true
    gestures: false
    intersectionObserver: true
  themeOptions:
    dark: light
    filled: true
    pageTransitionAnimation: default
    bars: light
    homeNavbar: default
    homeBackground: default
    expandableCardAnimation: default
    blocklyRenderer: null
  userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101
    Firefox/134.0
timestamp: 2025-01-18T08:39:17.523Z

[lolodomo]

Charts for sitemap UIs are generated by the core framework. So it should not be specific to Basic UI.
As you were on an old version, it is possible that the library version we rely on was updated.

[lolodomo]

The last change of version for XChart (3.1.0) was in OH 3.2. So no recent changes.

[der-dag]

I see that problem is already in OH 4.1.0 and you are right problem seems to be in core framework. I guess problem came up when new sitemap chart period parameter were introduced: openhab/openhab-core@f71ebfb
Before that all the periods durations where calculated using Duration.ofDays like entry("M", Duration.ofDays(30)) now the periods are parsed somehow. I see also in the latest version 4.3.2 if the periods are given in days the chart is as expected:

If I generated the chart using period 'M'
http://localhost:8080/chart?items=Consum_Gas24h&period=M

it's bad:

If I use period '30D'
http://localhost:8080/chart?items=Consum_Gas24h&period=30D

it's good:

But if I used '31D' it's bad again.

@lolodomo Can this issue be moved to core repo or do I have to recreate there?

[lolodomo]

@lolodomo Can this issue be moved to core repo or do I have to recreate there?

I have no rights to do that.
@kaikreuzer or @wborn : please move this issue to core repo

[wborn]

I have no rights to do that.

Me neither as I'm no webui maintainer. 😉