[openHAB 3 Main UI] How to configure my charts?

Add-ons UIs
1

The new charting is quite powerful. Would be nice to set the default appearance used when clicking on “Analyze”.

I know, there is a save button in the top right corner which creates a chart object which can be accessed e.g. via the sidebar.

image
image1304×833 31.9 KB

Is there a way already to store the current setting as the default appearance?

Stored properties should be:

  • time-period
  • area/line
  • major/minor separators
  • enable min/max

Maybe this is possible already somehow and I simply missed it so far… :thinking:

EDIT: @ysc May I ask you directly? You might be currently the only one who can answer this :wink:

1 Like
2

While still exploring the possibilities of the new chart features, I’m struggling with

Charting of derived values from ever rising counters

Obvious examples:

  • energy meters which count the consumed energy
  • rain gauges counting rain
  • …

How to adjust the persistence of such items to get the “energy per hour/day/week/…” or “rain per day/week/month/…” charted?

3

I don’t think it is possible out of the box.

I think you have to create a new item and calculate the ‘consumption’ in a given time interval (e.g. 15 min).
consumption = counter value (now) - counter value (-15 min).
This you can show in a chart.

4

Thanks, Sebastian,

I hope this is not neccessary :thinking:
At least is was not in the past. Even when using “just” rrd4j instead of InfluxDB/Grafana, such aggregation for counters were possible through the rrd4j.cfg in */services, e.g. this way:

rain.def=COUNTER,1800,0,U,3600
rain.archives=TOTAL,0.5,1,168:TOTAL,0.5,24,730:TOTAL,0.5,7,520
rain.items=RFXCOMRainSensor_RainTotal,RFXCOMTemperatureRainSensor_RainTotal

I’d assume, that a similar thing definition is needed in openHAB3 too …

Mmmh. Probably I should just try configuring this in openHAB3 again? Maybe this is considered for the counter items while all others are still treated by the default settings…

5

Oh, I was not aware of that. Looks very interesting.
I will watch this thread curiously.

6

Indeed: It seems, that openHAB3’s rrd4j has picked up my rrd4j.cfg and (re-) created the *rrd files for the two rain gauges with a different size than all the others which are still covered by the default:

image
image762×162 6.7 KB

I needed to delete the old *rrd files of the two counter items to force rrd4j creating new ones with the different setup.

Let’s wait for the aggregation to kick in and check the charts then :wink:

7

You can, to some extent. If you configure an aggregate chart in the analyzer (in the coords tab) then you can go back to the series tab and select another aggregation function than average in the table like “difference of lasts”.

About the storing of defaults there’s none of that yet but if you open the analyzer as a widget action you can preconfigure some stuff like the period.

8

Hi Yannick,

thanks for clarifying.

Regarding the counters:
I think I found a way which works for me… :slight_smile:
When I set up a specific database/aggregation definition in rrd4j.cfg as posted above, I can simply chart from that persisted time series like this:

image
image1069×718 55.2 KB

I’m quite happy with that :+1:

Yannick, thanks a lot for your work and the numerous new possibilities!
The new charting and of course the new UI as a whole is a giant step forward. Really love it!

1 Like
9

It seems to me, that the above aprove just works well until openHAB3 gets restarted :frowning:

I suspect the restore on startup causing messed charts because it restores derived values from rrd4j persistence instead of the last counter readings:

image
image880×636 41.4 KB

Explanation:
When using such persistence definition (example taken from openHAB3 rrd4j documentation):

ctr24h.def=COUNTER,900,0,U,60
ctr24h.archives=AVERAGE,0.5,1,480:AVERAGE,0.5,10,144
ctr24h.items=Item1,Item2

… then openHAB persists actual counter values but retrieves derived values which equals the difference of the persisted item value per time slot.

If these retrieved values are used for restore on startup, then a item will be set to a derived value instead of the last known counter value! This low derived value afterwards gets persisted (policy every-change/every-minute) and when the next real reading from the counter comes in, the difference to the former value will be huge compared to the tiny (derived) increments to be retrieved from the persistence service.

This messes up any counter-charting when openHAB’s startup is included in the chart’s period …

Well, the documentation already warns about that behaviour:

Please note that the persistence extensions will return difference instead of the actual values if you use this type; this especially leads to wrong values if you try to restoreOnStartup!

O.k., I think I understood what’s causing the issue. But how to circumvent?
In openHAB2 I simply would not have included these items in restore on startup.

Is there an option in openHAB3 to prevent an item getting “restored”?

EDIT: solved here [solved] [openHAB3 persistence] How to PREVENT "restore on startup"? - #4 by curlyel

10

How can I configure the charts to refresh themselves when new value is received/calculated? I didn’t find such option anywhere and the chart just sits there and it’s not updating. In OH2.x there was refresh in ms as an option.

11

Greetings! I am facing the same problem. In OpenHab 2 was possible to get a chart to perform live update by setting “refresh” in ms. So far I could not figure out a way to get a chart to display in real time (automatic refresh) in OH3. I’ve tried to enter refresh manually in the chart code but I could not see any effect. Does any one know how to do it? Is it supported in OH3? I can get live update for my MQTT messages in OH3, but charts are not updated. Have you come up with a solution?

1 Like
12

Hello, I would be interested to know if there has been an answer or solution to this.

Thanks

13

Unfortunately, no solution thus far.