Charts in OH3

Tags: #<Tag:0x00007fe7361f36d0>

I like the charting-possibilities of OH3 very much!
But I don’t get it to work with group-items.

I have 3 power-phases grouped in a group-item that sums up the members.

But this item is not displayable in a chart:


Is this an unfinished feature or should I use an extra numberitem that stores the summed values?

Depends on the persistence service & item type.
For instance I think rrd4j doesn’t support persisting groups:

Even if the UI doesn’t provide features to open the Analyzer window for every item, you can customize the charts in dedicated pages and open them from other pages, or customize the default widgets to make them open the Analyzer (it’s available as a type of action in most widgets).

1 Like

Thank you. Then I’ll use a helperitem that sums up the three values.

At the risk of hijacking this thread. When I first installed OH 3 I uninstalled rrd4j, not realizing that it’s used for these Analysis charts. I’ve since reinstalled it and let it run for a good amount of time. I don’t appear to get anything in the charts. I’ve added a rrd4j.persist file and set it to save * using all updates and every minute and still I get nothing in the charts.

Clearly I broke something. Any ideas how to fix it or at least verify one way or the other whether I’m just doing it wrong? If I did break it, I should file an issue as we should be able to restore the anayalsis functionality by reinstalling rrd4j or we should not be allowed to unintstall it in the first place.

The charts in the UI are not really tied to rrd4j per se (even though I didn’t test them with any other, rrd4j does the job for me). It queries the persistence API without specifying a service, so the configured default will be used. If you go to the API Explorer, open /persistence/items/{itemName} and use the “try out” feature with an item’s name that you know should yield data - then you should end up with said data in the response. If not, then something’s wrong, but apart from setting some logs to the DEBUG level (i.e. log:set DEBUG org.openhab.persistence.rrd4j) I don’t know how to help.

I think that’s the clue. I’ve always had MapDB set as my default. I tried switching to InfluxDB as the default and the chart came up blank. I switched the default to rrd4j and the charts started working.

I need to think a bit on this to figure out how the confusion I fell into can best be avoided:

  • clarify in the docs
  • require rrd4j to always be there
  • open an issue to see how to make it work with other database
  • something I can’t even think of right now

But I’m happy to finally see charts when I click analyze. Thanks!

Regarding other persistence providers, I tried to use “analyse” on a rollershutter item that is persisted to jdbc (my only persistence service, I deleted rrd4j), which did not display anything. I can see the data in the db. Is there any special requirement to make it work with jdbc? The persistence rest call works and shows the same data is in the db.

I used influxdb in OH2 - but the new Analyze-Features of OH3 are so great, that I just use rrd4j so far.
But there are ~400 items in my setting - will this be a problem or is there a good strategy for persistence?
As far as I understand all of them are persisted by default in OH3.

If I’m analyzing a switch-item, I can see the on/off-phases in the chart.
But I didn’t get it to work in a custom made page chart…
How to configure a chart to display the ON/OFF-State?

The Analyzer is just trying to be smart and considers the rollershutter states as “discrete” when in fact they can be integers - I just tried it myself.

image

So for now you’ll have to adjust the config, to do that save a new Chart Page from the Analyzer window (upper-right corner Save button), or create a new one from scratch.

Then in the chart page editor, edit the series’ YAML with the button:

image

Then remove the entire “slots” section:

image

Then add the item in the main “config” section:

image

(You can also do this with the Configure Series dialog).
Then it will hopefully show the integer values correctly.

See above - add the markArea slot manually in YAML, there’s no better way of doing it yet.

1 Like

Thank you very much, I did manage to get a number via removing the slot / adding the item. The problem (maybe because its jdbc) is that I can see the dots where the state changes in a scatter plot, but using anything else seems strange:

  • line just connects the dots which is very wrong as there is only a value when the value changes. So if I set my blinds to 0 on the beginning of the day and 100 at the end of the day, it looks like they are gradually changing during the whole day
  • bar somehow just shows a red line when the value is 100 and the background when there is no entry or its 0

Is there a way to somehow have a “hanging line” chart where the last value is extended horizontally until the next value appears? Probably how it would look with rrd4j (I guess) but with the precision of jdbc ms time values and only having to store state changes instead of periodically aggregated states?

Try adding step: end to the oh-time-series config.

1 Like

Thanks a lot for that!

using step: end does show the correct chart between updated values in a chart. But I ran into another problem while trying to display jdbc provided data:

  • The value of the last change is somehow not used. This means that if the state was set to 100 5d ago and I am looking at today, I do not see a line coming in at 100 from the left. It only starts displaying data that is actually in the time range to display which misses the state it was in before
  • The last value in the chart is not extended to the right. As the last value represents the state until now (even if its days old) it should be extended to “now”.

After sifting through echarts docs I tried experimenting with filterMode: none in oh-chart-datazoom->config but it somehow does not do anything. But maybe I am adding it at the wrong place or data is just not available for the chart from persistence?

Don’t know whether this is really helpful or whether it points in the wrong direction:

I had the same issues once a year ago in Grafana with InfluxDB data. When I had a time series which updates only very seldom and I had the wrong time window, it displayed nothing. That was because the query brought up no datasets for that specific time and even it could not draw a line from the most recent value. When I increased the timeframe to one which really contained data, everything was fine.

I myself solved it with a cronjob which always took the last value and copied it every minute. That was fine for me with respect to granularity and even I catched the right timepoint of the Switch, as it always took the last one.

Maybe some thoughts to think about.

Cheers

Yep, that sounds like the same issue. It’d a good idea, but I don’t really like to actually go and add data points without knowing if this was inserted just for data augmentation or an actual sensor report.
I could try modifying the queries for jdbc data to always include a) the first datapoint out of range in the past and b) a “virtual” datapoint that “unions” the latest one but with a timestamp of “now”. Not sure how complex this is, will have to see.
The simpler way to solve it is probably to use two persistence providers, one precise (JDBC) to not to lose data, and one aggregated (rrd4j) so the platform works as intended with the graphing etc. It does mean that I would have to somehow overlay the two to have continuous state graphs but also see fast changes (like a sensor opening and closing again in under a second).

This is standard behavior. Grafana works the same way. you would need to resave that value periodically to always have it show up on your charts.

you can set this up on the . persist file. no need to set up a cron job.

I keep them separated. one item for charts and another for historic data. The kitchen is the charting algorithm has no way to know how far back it should go. A day, month, year? It would basically have to keep going back farther and farther until it find a value, eventually giving up at some point.

I’m really happy with the charting-functions!
Now I can understand, when my heating is producing warm water and when it’s heating.
The grey areas are showing times the pump is running and the small red areas are displaying times, when the bad 3kW-extra-heater is neccessary.
On top the temperature of the warm water in the storage…

There’s still a little bug: If zooming into the chart with the mousewheel only the linecharts are changing while the areacharts stay fixed.