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).
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:
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.
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:
Then remove the entire “slots” section:
Then add the item in the main “config” section:
(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.
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:
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.
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:
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.
I made the same experience, but after an update the charts are empty again. Do you have any recommendation?
I changed the default to InfluxDB and back to rrd4j, but no improvement. I also checked the presence of the rrd files for items.
As of today I noticed that when I go to a graph it comes up blank. But if I refresh the page it works. But I’m using rrd4j still. If rrd4j and the built in charts work, I’ll be able to eliminate three separate services (InfluxDB, Grafana, Grafana Image Renderer) so I’m heading down that path. So far it looks like I’ll be able to get rid of them.
Same problem here - if I’m zooming in I see a few datapoints - but no conncetionlines between them.
