In short: YES 
It really seems to be an issue in M4 which does not restore values from rrd4j at startup.
2 Likes
Hey,
I upgraded to 4.1.0M4, since then my threads continue to rise. Before I had no problem.
I also don’t know where to look. So if there is someone that can help? Memory is stable also is the cpu load.
I have already tried clearing cache memory and fix permission so far no succes
System:
RPI 4 4GB ram openhabian and fix premissions
I also experienced this with my battery powered zigbee devices (2 Yale locks and 3 Sengled door sensors)
I reverted to M3 and the issue disappeared
I’ve been experiencing this threadcount issue for a couple years now. Using rpi4 with openhabian, always current milestone version at the time. Spent some time removing and re-adding bindings in an attempt to identify the cause but no result. So I ended up making a rule to restart the system at 4am when the threadcount exceeds 1500 or so. But would love to know if anyone has identified a root cause.
Has someone created an issue in GitHub for the mentioned problem about restoreOnStartup from RRD4j ?
Exposing clearly the issue to all maintainers could help to have someone figuring what could suddenly happen.
upgraded from what version please
What bindings do you use? What rules language do you use? Rules file or UI ?
is anything else running on the Pi?
4.0 stable
homewizard,ipcamera,homeconnect,meater,systeminfo,spotify,nest,ntp,remoteopenhab,network,volvooncall,yamahareceiver,chromecast,astro,weathercompany,icalendar,mqtt,somfytahoma,buienradar,lgwebos,exec,icloud
I use the rules file and I use the openhab rule code (if, when, then, else)
Zigbee2mqtt is the only other software and that runs without issues
The only thing I now see is that openterm is an external file so i will delete it en install it from te bindings list.
Thx for the help!!
1 Like
Are you seriously running openHAB 3 bindings with openHAB 4.
This should be the rootcause of your issues.
Please do not mix major versions!
I even see a binding for OH 3.1, meaning built with framework dated more than 2 years and a half !
I can confirm that the M4 build seems to have issues with ZigBee battery devices not being discovered when using the Openhab ZigBee binding and also the persistence not repopulating on startup with previous values. This is a clear behavioral change from all previous versions expected or not.
My build uses all native bindings from the latest. 4.1 so there does appear to be some functional behavior change for rrd4j and a quirk in the ZigBee discovery process I also allowed it to run for 8 hours to see if it would eventually pick up the battery devices, but it did not, and you can see a recurring exception error in the logs each time it tries to initialize those battery devices. I then quickly flipped back to M3 and everything worked fine again.
Does not matter if it is Linux build or Windows build behavior is the same.
Also, upgrade or fresh build does not change the Zigbee discovery quirk.
2 Likes
Yes because I don’t know how to update them. If could I would. I will try to make a openhab 3.1 to use them on that. I do not maintain them and I can’t delete them because they are used in a lot of rules.
These bindings are not part of the official OH4 release. You need to contact their developers if they have updated the binding to OH4.
In some cases OH3 bindings might still work on OH4, but better ask the developers.
Ok will do thx for the info!
I can confirm that I am also encountering the problem with restoring item states from the RRD4j database.
In my setting, the affected items are also “artificial” with no connection to a channel.
I did not have this problem with 4.1.0M3 but I have it observed with 4.1.0M4.
I also encounter this problem. With the update to the latest milestone some of my items are not restored from the persistence as they were before on startup. They just remain undefined.
If I remember correctly, there is an open issue for that. Only restoreOnStartUp for rrd4J is affected. As it only stores numerical values, I have moved restoreOnStartUp to mapDB persistence long time ago, which can store strings as well. Having this, no issue over here.
I was on MapDB for restore (all items) for a long time, then since rrd4j became default persistence, I had this (not so 
) bright idea to leverage that for restoring numerical values and create a MapDB.persist file with only the non-rrd4j capable items, saving some space. That worked until 4.1M4 when the numerical values weren’t restored. I’m back to MapDB for all items at least until issue is resolved.
In an unrelated finding I found the MapDB file apparently contains an entry for every item ever created, even if subsequently deleted. I had about a 60MB ‘p’ file. After deleting and restarting MapDB with the item subset (strings and images) it was 12MB. It is now just back to 16MB
Given the way that Items get created and destroyed when loading .items files I’m not sure there is any way that these could be cleaned up automatically. You’d lose the values every time you reloaded a .items file and as a result the restoreOnStartup would fail on that reload.
I’m not complaining. It was just an observation that after 4-5 years the file had grown. I just did a one time uninstall of MapDB and deleted the folder, then reinstalled. Waited about a month before any restart or upgrade, plus at that time rrd4j would restore the numbers and on-off items