@stefaanbolle Post both your addons.cfg and addons.config files…maybe something there is an issue.
I experienced the same.
For my particular box I solved it by 1) removing restdocs from misc in addons.cfg and restarting OH.
Surprisingly that fixed my zwave binding restarting issues
Same setup and behaviour here. My addons.cfg file is as defaults with all commented out (/etc/openhab2/services/addons.cfg, right?). I cleared cache and reseted a dozen of times. I receive the System started notification ramdomly, nothing special in the logs
I’m rolling back to my well proven and stable 2.4 by now… 
- Hardware: Rapsberry pi 3b+
- OS: Raspbian GNU/Linux 9 (stretch)
- Java Runtime Environment: openjdk version “1.8.0_222”
- openHAB version: 2.5.0.1
Need to verify addons.config also. Location is /var/lib/openhab2/config/org/openhab/addons.config
Do not make a change to this file with OH running. Stop OH, make change, clean cache, and restart.
Does this work like other 1.x style config files? i.e. don’t mess with it … just stop OH, delete addons.config, make sure addons.cfg is as you want it, reboot (addons.config recreated automatically)
With restdocs getting moved there has been several issues with upgrades and a need to verify both files are correct. Yes, addons.config should be auto created based on addons.cfg.
Don’t see anything suspicious on /var/lib/openhab2/config/org/openhab/addons.config. No restdocs references
After upgrade there where some errors in the log files about a “mqtt1” binding not being installed, I thought it was trying to be created as duplicate and removed it from addons.config file (before that binding list was “network,samsungtv,zwave,astro,nest,systeminfo,mptt1,mihome,gpio1,mqtt”)
This is content of mine:
:org.apache.felix.configadmin.revision:=L"2"
action=“telegram”
binding=“network,samsungtv,zwave,astro,nest,systeminfo,mihome,gpio1,mqtt”
felix.fileinstall.filename=“file:/var/lib/openhab2/etc/org.openhab.addons.cfg”
misc=""
package=“standard”
persistence=“mapdb,rrd4j”
service.pid=“org.openhab.addons”
transformation=“jsonpath,map”
ui=“basic,paper,habmin”
Did you read any of the update notices?
Stop OH and remove systeminfo binding as I’m sure this one was has changed.
I did read them all. I wouldn’t be so brave of upgrading without reading them beforehand!!
I saw sysinfo binding has changed si I had to modify my cpu load item as this channel no longer exist. Updated to cpuload1, it is true that now it reports much lower load than before, but I did not read it is necessary to remove the binding anywhere nor it explains why I get system started events so often. Or am I missing something??
Also did all of above, but issue still remains
My observation is that if I downgrade to 2.5 m5 the problem goes away. If I upgrade to 2.5 the problem comes back. I tried changing sd cards, reinstalling openhabian, clearing the cache etc. Nothing works. I think a change was introduced in 2.5 m6 that makes openhab reload the rule files when certain things get updated. As I am not a programmer, I have no idea what this was, or what to do about it. For my part I see no other option than to downgrade to 2.5 m5.
@Dixon Try this: From PaperUI uninstall gpoi 1 and systeminfo bindings. Verify that you do not have them listed in etc/openhab2/services/addons.cfg. Now stop OH, go to /var/lib/openhab2/config/org/openhab/addons.config and use text editor and remove the two bindings if they are still listed. While OH is stopped clean the cache and reboot. Have a browser open with frontail log and watch the startup. You will see errors but give it a few minuets. After everythig has loaded, OH is running, and you still have errors then stop and restart OH. You may need to stop and restart a few times as I restarted 3 times on my system.
Once OH is running, without all the errors you can go and reinstall the 2 bindings.
No luck. I not only removed this two bindings but all, deleted cache, reinstalled them. No errors but system started event gets fired ramdomly. If it is something introduced in 2.5 m6 as @mark_leonard_tuil states, I guess many others will suffer the same issue. I’m rolling back to 2.4 as I’m unable to stabilise my system with 2.5
2.5M6, is that the same as 2.5 stable?
No, M6 is milestone 6. After that came RC1, then came 2.5 stable.
Then what does M6 have to do with this topic?
Please read the first message in this topic.
At least the zwave binding required to delete and recreate all zwave things when updating from 2.4 to 2.5 Mx. Perhaps that was not done and now the bugs appear?
“System started” also is triggered on every rule modification and every item change. When doing development that is not - well - funny at times. Due to the not predictable start up order I also delay all rule execution by 5 minutes - hopefully after all bindings are loaded and the system is stable.
Below is the workaround code I am using. Basically all rule execution is blocked while
viTimeEvent_System_Starting == ON
Anything which needs to run at system startup is triggered on viTimeEvent_System_Starting changed to OFF
The code should catch those other “System started” events as well.
var int iSystemAlreadyStarted = 0
val int ciStartUpTime = 300
rule "rTimeEventSystemStart"
when System started
then
// Delay all rule execution and trigger generation until system is stable
// but only on the first call
// System started is triggered on every rule or item change
if (iSystemAlreadyStarted == 0)
{
viTimeEvent_System_Starting.postUpdate(ON)
createTimer(now.plusSeconds(ciStartUpTime)) [|
viTimeEvent_System_Starting.postUpdate(OFF)
]
}
iSystemAlreadyStarted = iSystemAlreadyStarted + 1
end
Note: this reply was accidentally posted in another thread as well.
Really??!! I have 50+ zwave items, do I need to delete and recreate them all? Why? Is there any way to be sure this is the cause before such an annoying task? or better a workaround to avoid it
Zigbee and Z-Wave manual install script has a script to do it all for you.
You definitely need to delete and recreate your Zwave Things when upgrading from 2.4 to 2.5.