I did another test. I use the Max! binding. It is a system to control heating radiators. Max! uses a local hub called the cube. The various radiotors get their imput form the cube. With the binding you can reset the cube. This results in the same reloading of rules behaviour. I have attached the log. I do not think there are entries that (should) account for the rules reloading behaviour. What I see is lines like:
2019-12-23 15:15:22.581 [hingStatusInfoChangedEvent] - 'max:bridge:KEQ0536973' changed from ONLINE to OFFLINE: Rebooting
2019-12-23 15:15:22.593 [hingStatusInfoChangedEvent] - 'max:wallthermostat:KEQ0536973:OEQ1035689' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
2019-12-23 15:15:38.142 [me.event.ThingUpdatedEvent] - Thing 'max:bridge:KEQ0536973' has been updated.
2019-12-23 15:15:38.641 [me.event.ThingUpdatedEvent] - Thing 'max:wallthermostat:KEQ0536973:OEQ1035689' has been updated.
2019-12-23 15:15:38.684 [vent.ItemStateChangedEvent] - WallmountedThermostatSlaapkamer_SetTemperature changed from NULL to 16.0
2019-12-23 15:15:39.487 [hingStatusInfoChangedEvent] - 'max:wallthermostat:KEQ0536973:OEQ1035689' changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE
2019-12-23 15:15:40.052 [vent.ItemStateChangedEvent] - ThermostatRadiatorWoonkamerRechts_SetTemperature changed from 20.5 to 0.0
However, I don’t think these events should cause the rules to reload. Nothing is changing about the things and items. All that is happening is things going offline and online and (as a result) things being updated.
2019-12-24 08:38:14.811 [WARN ] [o.internal.handler.SysteminfoHandler] - No information for channel battery#remainingCapacity with device index 0 :
2019-12-24 08:38:14.813 [WARN ] [o.internal.handler.SysteminfoHandler] - No information for channel battery#remainingTime with device index 0 :
2019-12-24 08:38:34.016 [INFO ] [.smarthome.model.script.System Rules] - System (re)started
I have also the same behaviour with my fibaro motion sensor since openhab 2.5. After a thing update from my fibaro motion sensor my “system start” rule is triggered.
2019-12-25 14:38:12.393 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:f7e712f7:node25' has been updated.
2019-12-25 14:38:27.905 [INFO ] [e.smarthome.model.script.Systemstart] - Das System wurde neu gestartet
It seems like updates to things or things configurations or properties trigger the startup rules.
I tried to retrace the call stack (manually, not sure if this is 100% correct) and is something like this:
I assume this is a desired behaviour by openHab (?) so the issue might be the bindings updating the things periodically. Now clear why this started apprearing with OH 2.5 though…
I notice the same, every few minutes thje system started rule is fired. However I do not see anything weird in the logs or events files. Did not occur with 2.5.Mx versions, only with the release version
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”
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”)
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??
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