Configuration of openHAB cloud connector triggers startup rules

I’ve just configured the openHAB cloud connector (changed the mode). This appearently refreshed all of my rule files, which in turn triggers the startup rules to be executed. Actually this does not only trigger the startup rules, but discards running schedulers and also reinitialized all variables with their default value.
I think I’ve seen a similar behaviour when installing/deinstalling new bindings.

I don’t think this should happen. Is this an issue with my setup, is there maybe already an open ticket, or is this the expected behaviour?

Here is a part of the log:

2017-09-28 22:39:06.964 [DEBUG] [o.openhabcloud.internal.CloudService] - openHAB Cloud connector deactivated
2017-09-28 22:39:06.981 [INFO ] [io.openhabcloud.internal.CloudClient] - Shutting down openHAB Cloud service connection
2017-09-28 22:39:07.009 [DEBUG] [io.openhabcloud.internal.CloudClient] - Socket.IO disconnected
2017-09-28 22:39:07.016 [DEBUG] [o.openhabcloud.internal.CloudService] - openHAB Cloud connector activated
2017-09-28 22:39:07.026 [INFO ] [io.openhabcloud.internal.CloudClient] - Disconnected from the openHAB Cloud service 
2017-09-28 22:39:07.254 [DEBUG] [         ] - ServiceEvent REGISTERED - {, org.eclipse.smarthome.model.script.engine.action.ActionService}={, expose=[myOpenHAB], baseURL=, service.config.category=io, service.config.description.uri=io:openhabcloud, mode=notification,, service.config.label=openHAB Cloud,,, service.bundleid=194, service.scope=bundle} -
2017-09-28 22:39:07.619 [DEBUG] [io.openhabcloud.internal.CloudClient] - Socket.IO connected
2017-09-28 22:39:07.642 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service
2017-09-28 22:39:09.225 [DEBUG] [el.core.internal.ModelRepositoryImpl] - Refreshing resource 'presence.rules'
2017-09-28 22:39:09.399 [DEBUG] [el.core.internal.ModelRepositoryImpl] - Refreshing resource 'voice.rules'
2017-09-28 22:39:09.602 [DEBUG] [el.core.internal.ModelRepositoryImpl] - Refreshing resource 'mail.rules'
2017-09-28 22:39:09.741 [DEBUG] [el.core.internal.ModelRepositoryImpl] - Refreshing resource 'alarms.rules'
2017-09-28 22:39:09.867 [DEBUG] [el.core.internal.ModelRepositoryImpl] - Refreshing resource 'lighting.rules'

This might be expected behavior. System started rules will always fire when OH loads your .rules files. This obviously occurs during OH startup and whenever you make a change to a .rules file. When the .rules files get reloaded everything gets reset, which is as it should be because OH has no way to know whether you made a change to your .rules files which invalidates or even removes your global vars and vals and Timers and such.

I can’t say whether starting the openHAB Cloud service typically causes .rules files to be reloaded. I’ve not noticed it to do so but I’ve also never really looked that hard nor have I ever disabled and reenabled Cloud Connector like this.

Also, I write my rules, and strongly recommend to all users, to also write their rules to handle restarts of the rules like this in a sane manner because you really have no control over when OH crashes and when OH comes back up it should be in as close of the same state as it was in before it went down (of course with tasks to go out and get updates that may have occurred while OH was down). This means

  • use Expire binding Timers instead of Timers
  • store state in Items with restoreOnStartup instead of global vars and vals
  • use System started rules to recalculate, discover, or query for the current state of devices, sensors, etc.

Tl;dr, I can’t say one way or the other whether this is expected but you should write your rules so that these reloads don’t really matter because even if Cloud Connector didn’t cause the .rules files to be reloaded you need to handle that anyway.

@rlkoshak thanks for the extensive answer!
I understand your points and I’ll try to adjust my openHAB setup to work the way you suggested (actually I was once using restoreOnStartup in OH1 but then replaced it with system started rules because I had a concurrency issue. Probably this issue doesn’t exist in OH2 anymore).

Thanks again!