Ah, good point. I’m using Influxdb running locally on the pi. I have 9 temperatures and 6 humidities that I log every 10 min. I have a few rules, but nothing I would consider heavy, and not relating to the persistence.
I have not installed anything else on the pi that should slow it down. When I look at processor usage during the opening of a chart, one processor works at 100 percent, but the others seem free.
Another thing I could mention is that each update of the temperature and humidity is updated tons of times with the same value. I counted around 75 updates within less than a second:
I’m using the tellstick binding for this (over the cloud, Telldus Live), and my assumption has been that the devices simply send the same value over and over to ensure at least one reaches the bridge.
I don’t think it’s related, since these bursts happen with minutes in between, and the long loading times of the charts are very consistent.
Going to need to be very careful about what that is causing. First guess, you have default rrd4j alongside your influxdb, with default “persist everything”, and its trying to deal with.
But it’s going to be hammering all parts of openHAB, needs containing.
Ok, so maybe this symptom is relevant after all… I don’t have rrd4j installed, so that should not be it. Anything I can do to dig further into this? Maybe enable some more logging?
The problem is here. You are persisting way too may measurements.
I don’t know what the tellstick binding does…
For a fast fix you could change the strategy to “everyChange” or log it in a fixed interval like every 5 minutes.
From that point your charts will load a lot faster.
Of course! All 75 updates are saved every 10 min. I didn’t see it on the chart because they are so close to each other. Thanks a lot for pointing it out!
I prefer to keep the everyUpdate setting if I can though, since I want information in the graph if something was actually sent from the device. If I go with everyChange, I cannot differentiate between it being the same temperature for a long time, and the device silently stopping to send updates.
It seems I need to solve the problem with the Telldus binding… Any ideas? Or perhaps I should create a new post?
No it is not every 10 min. It is every second. I don’t know where you have the 10 min from.
You should really change the strategy. You can also put seconds if you like.
This i don’t know. Yes open a new topic where you describe your problem separate.
I thought the everyUpdate setting saves the state of the item every time it updates, rather than at fixed time intervalls? This would explain my issue since the temp and humidity values are sent every 10 min from the sensors, but for some reason the update is duplicated 75 times. Where does the every second update come from?
There’s a better solution than changing the sampling rate and changing the data resolution: you can use continuous queries in influx.
They allow you to periodically pre-aggregate data for faster loading times.
For example, I am calculating and persisting energy consumption every minute and charting energy consumption per month and per year. For monthly consumption this means 60x24x30, i.e. 43,200 data points for one month, and 518,400 data points for annual charts.
Chart loading time on a Pi 5 with influx on a SSD is thus between 10 an 15 seconds.
When you use a continuous query instead, where you calculate daily aggregates once a day, you end up with 30 data points per month and 365 data points per year, thus no delay in loading times.