Selectable chart visibility causes high CPU load

Setup, Configuration and Use Items & Sitemaps
, ,
1
  • Platform information:
    • Hardware: Raspberry Pi 3B
    • OS: Raspbian Buster
    • Java Runtime Environment: Zulu (openjdk version “1.8.0_152”)
    • openHAB version: 2.4.0 (Build)
    • basicUI

I’m running a fresh repository installation of openHAB 2.4 on a Raspberry Pi 3B. Only two bindings have been installed (TCP/UDP and Systeminfo), some rules to extract the data from UDP are used.

I’m using a browser running on the PC to display the sitemaps (basicUI).

When adding charts with different visibility for different time periods the CPU load and RAM usage goes up quite a bit. Also, updating of the sitemap and response time to the switch is very slow.

load

The chart shows that

  • around 10:00 the charts with selectable visibilities are added
  • around 14:00 the visibility is changed by clicking the the button
  • then these charts are deleted from the sitemap
  • RAM usage remains high after deleting the charts from the sitemap

Note that the CPU chart is not the one with selectable visibility!
The switch item is active and included in the sitemap all the time.

The selector looks like this (sitemap):

Switch item= nWaterMeterChartPeriod label=“Zeitraum” icon=“time” mappings=[0=“Stunde”, 1=“Tag”, 2=“Woche”, 3=“Monat”]

switch

The switch item has been declared in an .items file.

The part of the sitemap which is commented in and out:

    Chart item= nWaterUsageToday        period=h    refresh=10  legend=true visibility=[nWaterMeterChartPeriod==0]
    Chart item= nWaterUsageToday        period=D    refresh=10  legend=true visibility=[nWaterMeterChartPeriod==1, nWaterMeterChartPeriod==NULL]
    Chart item= nWaterUsageToday        period=W    refresh=10  legend=true visibility=[nWaterMeterChartPeriod==2]
    Chart item= nWaterUsageToday        period=M    refresh=10  legend=true visibility=[nWaterMeterChartPeriod==3]

So my questions are:

  • Have I missed some setting when adding chart visibility?
  • How can the CPU load and RAM usage be reduced?

I hope to get some insights from the community.
Thank you very much!

2

Your setup looks right.

I think you can avoid having the charts precalculated by putting them in an openable “sub-frame” on your sitemap, click-to-view.

You might give the charting less work to do by reducing persistence frequency.

3

This means a refresh every 10ms…in my experience OH2 is rather resource hungry when the refresh rate is set so low…I was able to jack up my system to impressive loads with refresh rates that short.
Not sure if you need an updated chart every 10ms…try something like 10000 (every 10s) that very likely will resolve your issue

1 Like
4

Somewhere I’ve read that the refresh period is interpreted differently:

  • BasicUI: refresh in sec
  • ClassicUI: refresh in milli sec

Using BasicUI with refresh = 10 would mean 10 seconds.

I’m not sure how to implement the charts in a sub-frame. And I’m afraid this wouldn’t solve the problem either. Once the sub-frame is opened the CPU usage will go up.

The only way to free the RAM after deleting the charts from the sitemap seems to stop and restart openHAB.

5

Maybe…it would be news to me though, and I believe when I ran into this issue I was using BasicUI.
Although the docs do not mention anything about that difference (and a 3 orders of magnitude would be a rather significant difference in behavior): https://www.openhab.org/docs/configuration/sitemaps.html#element-type-chart
Be all of that as it may, what would you have to lose to simply try it out…

6

It would be interesting to see where you read that because they all use the same sitemap standard and the standard says it’s msec.

I suspect what you read is either very old or incorrect.

Text label="Water Usage Chart" {
    Frame label="Water Usage" {
        // your charts here.
    }
 }

Another thing to realize is whether or not OH is showing the Chart based on it’s visibility, it will render all of the charts at the given refresh rate. So you are probably trying to force OH to render four different charts 100 times a second. That would bring almost any system to it’s knees.

7

Oh, I really need to apologize:
A long time ago there was a bug that caused refresh rates to be interpreted depending on the UI:

The Embarassment is that this bug was reported by myself and I totally forgot about it being fixed. Now I’ve just copied parts of old sitemap files with a corresponding note which now caused to system to overload.

Changing the refresh interval to a value of 10000 everthing is fine now!
Thanks for pointing this out!

If I may add another question:
When starting the system a default chart is selected. However the selection buttons all are grey and the pre-selection is not indicated by a highlighted button.

switch

How can this be achieved, i.e. highlight the button corresponding to the default chart period?

8

Simplest way is to restoreOnStartup your selection Item

9

That would require to add the selection item

Number nWaterMeterChartPeriod

to the persistence service.
Would it also be possible to create a startup rule to initialize the item?

10

Sure. There is a System started rule trigger and a postUpdate() method for Items.
This method will not remember what you were last interested in, of course.

11

It’s not a problem that the last state isn’t remembered. I just want to avoid that the buttons are uninitialized.
I’ve setup a startup rule and it seems to work.
Thanks!