[SOLVED] OH2: updating a specific rule set triggers reload of another (is this by design)?

Setup, Configuration and Use Scripts & Rules
1

Version: 2.5.6 (Build)

I have rules and items files for a specific purpose; what I mean is; e.g. I have a PumpStation1 controller and a Battery monitor controller. There is a dedicated rules and items file for each.

When I update rules in the PumpStation1.rules I also see the battery monitor rules are initialised.

This will disturb battery monitoring variables that are running when I save the PumpStation1.rules.

Is this behaviour by design?

Why would OH refresh a rule set when updating/saving another, which have no relationship whatsoever. E.g. no item or rule addresses something in the other set.

Here is an example, but with other names, but the same principle:

2020-10-05 10:15:36.769 [INFO ] [marthome.model.script.Irrigation1.24] - ... current Valve Minutes (int) .......: 15
2020-10-05 10:15:37.289 [INFO ] [marthome.model.script.Irrigation1.25] - ... Volume Previous (meter 1) ....... -> 125
2020-10-05 10:19:15.511 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'irrigation2.items'
2020-10-05 10:19:42.493 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Battery last update': The name 'Battery_LastUpdated' cannot be resolved to an item or type; line 33, column 3, length 19
2020-10-05 10:19:44.964 [INFO ] [pse.smarthome.model.script.Weather.0] - System start or rule file reload for weather sensor rules
2020-10-05 10:19:44.968 [INFO ] [pse.smarthome.model.script.network.2] - Internet is ON (command)
2020-10-05 10:19:50.234 [INFO ] [smarthome.model.script.watersystem.0] - loading rule and initialise state(s)
2020-10-05 10:19:52.560 [INFO ] [clipse.smarthome.model.script.shed.0] - System start or rule file reload for Shed rules
2020-10-05 10:20:04.480 [INFO ] [ipse.smarthome.model.script.Zeva.0.0] - System Start: Zeva BMS rules
2020-10-05 10:20:04.493 [INFO ] [.eclipse.smarthome.model.script.init] - initialise states...
2020-10-05 10:20:31.116 [INFO ] [smarthome.model.script.Irrigation2.0] - System Start: Irrigation 2 rules
2020-10-05 10:20:31.120 [INFO ] [smarthome.model.script.Irrigation1.0] - System Start: Irrigation 1 rules
2020-10-05 10:20:32.765 [INFO ] [marthome.model.script.Irrigation1.24] - ... current Valve Minutes (int) .......: 15

In thie example above, the irrigation2.rules save is triggering the following rules files:
weather
network
watersystem
shed
Zeva


 they do not share items and do not address ‘external’ items in their rules.

2

Yes.

It’s not really possible for openHAB to determine that, who knows what interactions happen through Items and external services.

3

Hmm, why is it then not reloading all rule files?
Because it isn’t reloading all rule files, it must have some idea?!
Sometimes less files are reloaded; sometimes only irrigation2.rules (when saving it)
 the latter is what I’d expect.

4

I don’t think it does reload rule files. Triggering a general ‘System started’ event is not the same thing.

5

Example here:

2020-10-04 17:22:57.331 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'irrigation2.rules'
2020-10-04 17:22:57.901 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'max01.sitemap'
2020-10-04 17:23:04.299 [INFO ] [smarthome.model.script.Irrigation2.0] - System Start: Irrigation 2 rules
2020-10-04 18:00:00.038 [INFO ] [xtr064.internal.FritzboxTr064Binding] - Fritzbox Reconnect Job executed
2020-10-04 18:00:00.043 [INFO ] [g.fritzboxtr064.internal.CallMonitor] - Lost connection to Fritzbox because of interrupt


 no loading of other files or system started.

OK then, why does it then trigger system started events causing other rule files to start??

6

I don’t know what your example is demonstrating.

You do seem to be updating multiple files at once - sitemap and rules? Is that some consequence of your editing tool?

Exactly what happens in response to in-flight edits has varied over the life of openHAB. There is always tension between “I edited X so I need Y to re-initialize!” and “I only edited X and don’t want Y to re-initialize!!”. What would you like to happen?

So far as I know there is only one ‘System started’ event that triggers any and all rules looking for it. That should include non xxx.rules originated rules (NGRE) as well, I think.
Most would want that event to be triggered for rules that you just edited.
The current price is triggering all such rules.

7

I should have taken out the sitemap update, as it is inconsequential; in that case I saved both files; here changing a rule and also including an item I forgot in the sitemap.

The example demonstrates that I updated irrigation2.rules and nothing else got ‘restarted/reloaded’
 adding to my initial questions, where other rule files did reload, asking why that is the case (that OH comes up with a different reload/restart approach when saving I single rule file that has no relationship or overlap with any other rule files).

Or in the most simplistic form:
I have car items and rules, with rules only pertaining the car items.
I have dog items and rules, with rules only pertaining the dog items.

When saving dogs, why does car get reloaded/restarted?

 and sometimes other rule files that also have no relationship with dogs?

I am not arguing with you; I appreciate any feedback; this OH behaviour simply puzzle me, as in I classify it as unpredictable behaviour.

It makes it very difficult to update a rule while OH is running; as I cannot predict which file(s) OH will reload.

I have a daily window from 16:00 to 18:00-ish were nothing happens and it is the time I do rule updates, to prevent other things from falling over (as in timers reset, lost or whatever interfered with).

[edit] I updated my initial post to include a few more log lines which show saving irrigation2.rules reloaded a bunch of other (unrelated) rule files, including irrigation1, which was running at the time. This led to this ‘faulty’ behaviour, due to reload:

2020-10-05 11:16:09.602 [INFO ] [ome.model.script.Irrigation1_4.off.3] - ... valveVolume (calculated) ........ -> 144
2020-10-05 11:16:09.618 [INFO ] [ome.model.script.Irrigation1_4.off.4] - ------------------------------------------------------------
2020-10-05 11:16:24.582 [INFO ] [e.smarthome.model.script.Irrigation1] - Irrigation group 1 finished.
2020-10-05 11:16:24.604 [INFO ] [marthome.model.script.Irrigation1.41] - Irrigation1 -> reset Auto Switch
2020-10-05 11:16:24.627 [INFO ] [marthome.model.script.Irrigation1.30] - Irrigation1: stopping = cancelling timer(s)
2020-10-05 11:16:24.634 [INFO ] [marthome.model.script.Irrigation1.31] - Irrigation1: turning OFF all valves regardless of state
2020-10-05 11:16:24.649 [INFO ] [marthome.model.script.Irrigation1.33] - Irrigation1: turning ON pump failsafe and timer
2020-10-05 11:21:05.528 [INFO ] [ome.model.script.Irrigation1.timer.1] - ..< turning ............................ Irrigation1_4 OFF 
2020-10-05 11:21:05.540 [INFO ] [ome.model.script.Irrigation1_4.off.1] - ... valve flow rate ................. -> 0
2020-10-05 11:21:05.546 [INFO ] [ome.model.script.Irrigation1_4.off.2] - ... current meter reading ........... -> 725
2020-10-05 11:21:05.550 [INFO ] [ome.model.script.Irrigation1_4.off.3] - ... valveVolume (calculated) ........ -> 146
2020-10-05 11:21:05.558 [INFO ] [ome.model.script.Irrigation1_4.off.4] - ------------------------------------------------------------
2020-10-05 11:21:05.574 [INFO ] [marthome.model.script.Irrigation1.50] - Irrigation1: Pump is still running! Sending email.
2020-10-05 11:21:20.536 [INFO ] [e.smarthome.model.script.Irrigation1] - Irrigation group 1 finished.
2020-10-05 11:26:11.983 [INFO ] [marthome.model.script.Irrigation1.51] - Irrigation1: swich to enable email again; and delete timer.
2020-10-05 11:26:24.660 [INFO ] [marthome.model.script.Irrigation1.34] - Irrigation1: turning OFF pump failsafe and timer


 here sending an email that the pump was still running despite being off, which is related to a timer in the irrigation1 rule file.

8

Most of us don’t know exactly what happens. As I said, it has been changed over time and I reckon ‘designed by committee’. You will find other discussions about this but I would caution against treating any old details as gospel due to evolution.

Yes, it is difficult to in-flight edit the controlling parts of an essentially real-time system. Clearly some things must be reinitialized. Defining “some” is very difficult in any non-trivial system, you are welcome to help.

That’s not the only consideration.
Let’s have dogs.rules run a system started rule with “doggy rides today = 0”
Let’s have cars.rules run a system started rule with “car rides given today = 0”
In this case we would want those in step.

I repeat I do not think openHAB does that at all. Firing system started rules is not same as reloading rules.
The underlying mechanism is a simple file watcher looking at timestamps - say if your editor ‘touches’ a file then openHAB will reload it, actually edited or not. And of course go on to fire system started. Maybe there is that effect for you?

1 Like
9

Thanks :slight_smile:

Do I understand this correctly that having a system started rule in my .rules files it will reload these.
I added these to see when and whether OH loaded the .rules files on system (re)start.

I also believed that system started is an OH start and not a .rules file triggering it.

It seems I should have a duplicate of PROD for TEST and upgrade purposes


10

Correct.

When the rules file is saved, openHAB will run any rules in that file which have the System started trigger.

System started is triggered upon openHAB startup, after the rule file containing the System started trigger is modified, or after item(s) are modified in a .items file.
1 Like
11

Comment 
 wait until you start editing Items and Things for considerations of what needs reinitializing :crazy_face:

1 Like
12

I don’t think this is the case for the NGRE. At least it’s not the case for Jython. There has to be an actual change to the file for it to reload. A touch might still be sufficient for Rule DSL though.

To see when openHAB actually reloads a .rules file (as opposed to just executing System started rules) look for log statements like

2020-10-05 10:19:15.511 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'irrigation2.items'

The last part tells you which file was reloaded. As mentioned, just because a System started rule runs does not mean that the .rules file was reloaded. A System started event can be created in a number of circumstances.

And for reference, in the NGRE (what will be just the Rules Engine in OH 3) there is an actual event put on the event bus indicating when a rule is loaded, enabled, disabled, etc. I don’t know if you can trigger another Rule with these events (I think so) but you can definitely see them occurring in events.log.

1 Like