Just showing dots for the present data, avoiding any connecting lines would also work, as I can see what is stored.

First of all, charting has not knowledge about the persistence strategy. All it sees are points.

The charting servlet that generates the charts for the sitemap Chart element is very basic and simple. I don't know how feasible it is to actually provide any sort of configuration like that.

The standard approach to solve this issue is to add a periodic strategy in addition to the everyChange strategy. That will add points to the graph in between the changes and flatten out the chart.

For even more configurability there is Grafana (there are lots of tutorials on the forum).

My suggestion is: when the persistence strategy for an item is everyChange use in the charts only horizontal lines (no tilted lines). With other persistence strategies keep the current logic.

Since charting knows nothing about the persistence strategy, this idea is not possible.

Thanks for your answer.

The standard approach to solve this issue is to add a periodic strategy in addition to the everyChange strategy. That will add points to the graph in between the changes and flatten out the chart.

I want to avoid this for performance reasons. In this concrete case it is even not predictable what the period shall be, perhaps 30seconds, and this will create a lot of unnecessary load.

I actually considered inserting (persisting) the old value from within openhab-js, at the moment when the new value arrives, but as far as I could see it is not possible to persist a value from the for the past (1second ago, or alike)

What performance problems are you having where configuring these few Items to save every minute or every five minutes makes any difference?

The amount of time for how often to save the value depends on the time ranges of the charts desired.

I actually considered inserting (persisting) the old value from within openhab-js, at the moment when the new value arrives, but as far as I could see it is not possible to persist a value from the for the past (1second ago, or alike)

This is an approach that could work but you'd need to use a proxy Item. Lets say we have an Item named "Raw" linked to the Channel and another names "Proxy". Note this won't work with rrd4j, but rrd4j requires an everyMinute strategy anyway so you wouldn't see this problem in the first place.

• Exclude Raw from persistence or just ignore it, you'll use Proxy on the sitemap and for charting
• Configure Proxy with an everyChange strategy
• Trigger a rule when the "raw" Item linked to the Channel changes. In this rule, first call Proxy.persist() (or the equivalent in your language of choice) and then call Proxy.postUpdate(Raw.state) (or the equivalent in your language of choice)

The system has already a load average of 1.2 (120%).

The simplest solution would be if the dots are connected only with horizontal lines, as an option.

I will give that proxy in the next days a try.

I doubt it. A system load tells one nothing about what is causing the CPU to be stuck waiting (that's what the load means). Without out other evidence, saving a couple hundred extra data points every few minutes is unlikely to impact that one bit. It's at best a stab in the dark or just an assumption.

And this assumes that this would be simple to implement which I am assuming it is not or else this would have been implemented by now. Keep in mind that the charting servlet has been around for at least ten years. It's not new code and has heavy dependencies on third party libraries.

Using a Proxy and Raw item, as suggested above, is a functioning workaround.

Irrespective of this I fetch data as fast as possible from a device, with a delay in between, so that my system has a load average around 1.0. That is, if I can reduce any forms of load, so that the system has more free CPU cycles, then I will decrease the aforementioned delay.

This repesitory contains the word diagonal on two places: in org.openhab.core.io.rest.core/src/main/java/org/openhab/core/io/rest/core/internal/persistence/PersistenceResource.java and in org.openhab.core.ui/src/main/java/org/openhab/core/ui/internal/chart/defaultchartprovider/DefaultChartProvider.java. At least the latter inserts a point just before the current moment, in order to avoid tilted lines, thus to have only horizontal conneting lines.

My suggestion would be to offer a chart option like

linestyle=connecting (default)
linestyle=horizontal

in order to enable this behavior. As @dilyanpalauzov pointed out, this is already implemented for OnOff types:

           // For 'binary' states, we need to replicate the data
           // to avoid diagonal lines
           if (state instanceof OnOffType || state instanceof OpenClosedType) {
               xData.add(Date.from(historicItem.getTimestamp().toInstant().minus(1, ChronoUnit.MILLIS)));
               yData.add(convertData(state));

So the task would only be to insert the option and to distribute it to the addItem method where these code lines are from.

BTW, I find it absolutely no good idea to add additional data to the persistence data in order to display it better. This information is redundant and only solves the issue partly as there will be always a diagonal line between the last update and the next new state.