That could be since at least @cweitkamp and me are using the rrd4j database, which needs a strategy for every minute. I would search in that direction first.
How about the setup, I’m on OH2, more precisely on Openhabian, how about the others?
I agree . Restart solves the problem at the moment. But doesn’t solve the problem at its origins. Let’s open an issue or look for an existing one.
In my live environment I am using Raspbian Jessie with OH2 installed from Stable repository.
Same here. Openhab2 on OpenHABian on Pi2.
rrd4j database stopped logging when GMT changed to BST last night.
Displayed current values are correct, just no logged data.
Restarting Openhab fixed it.
Not sure how to report this as an issue that needs fixing.
Maybe someone else can confirm the following observation (I’m using influxdb):
Items with
strategy = every10Minutes
after 3:00 had no new datapoints until I restarted openHAB.
Items with
strategy = everyUpdate
have still data points after 3:00
So it seems for me it has something to do with the internal scheduler.
Regards,
André
I’m pesisting only everyMinute and had the issue. I also assume it is the scheduler.
I’m using every 5 minute.
And no datapoints from 3:00 -> Openhab restart.
I would file the issue, but where?
It looks like it is related only to rrd4j or persistence. Would that be Eclipse Smarthome or OpenHAB Core?
Thank you.
That is a good question. I think it should be placed in the Eclipse Smarthome project.
As it is also a problem with InfluxDB (as mentioned above), the issue is in the cron scheduler - I hope @kgoderis will find a fix within the next 6 months before the bug can hit us again 
I guess I had a bit too much of the sun yesterday. That statement of mine should have read “…related not only…”!
Speeking for all the other posters in this thread, we do hope that @kgoderis can find a way to simulate such a time-switch on his system.
Are we all prepared for this tonight? The clock is turned back again to match wintertime. At 3 o’clock in the morning. The issue in ESH hasn’t been closed, yet. What will await us this time?
Just to give you any feedback. I faced no problems this time.
Glad to hear that there was no major issues this time. My system went to a load average of 205 tonight, but this stayed like this even after fully stopping openHAB - so there’s a good chance that this wasn’t the culprit then 
Next shift to DST, old problem again.
It looks like the shift from DST to normal worked (as reported in Oct’17) however tonigth shifting to DST again rrd4j stopped again.
I’m running on OH1.2 (rrd4j 1.11.0)
The binding reporting the values (in my case Tankerkoenig) is confirmed working.
Checking the rrd4j with the REST API: A Persistence/Get request showed the rrdj, however the reguest for persistence/items/itemname gave a 400.
Stopping and Starting the bundle did resolve the problem.
Would be great if this issue is checked and eventually resolved.
Same problem again with rrd4j charts stopping at 2am. Also had my RPi3 cooking itself with OH 2.2 running constantly over 100% CPU usage.
Same problem here. RPI3, OH 2.2, 100% CPU…
Have to correct the statement from above, it needed at restart of
OH, the restart of the rrd4j bundle only changed the behaviour of displaying the time series ( the chart showed times up to now again but NOT actual values).