Rules Reloading But Not Executing

Setup, Configuration and Use Scripts & Rules
1
  • Platform information:
    • Hardware: Pi 4
    • OS: OpenHABian
    • Java Runtime Environment: Default
    • openHAB version: 2.5.1
  • Issue of the topic: please be detailed explaining your issue

I’m in the process of doing a lot of rule development, and have my rules broken out into about 10 files.

I keep finding myself frustrated that a rule won’t trigger, even though the logs say that the particular rule file was reloaded and experienced no errors. Exasperated, I eventually copy the code into another rule file and low-and-behold, it works…

all files have appropriate permissions, as far as I can tell…

I’m going to do some more attempts at isolation, but wanted to see if anyone else has experienced a similar problem.

1 Like
2

Hi,

I have experienced the same with Time Cron based rules - same HW + OH Version like you.

Kurt

3

Thanks, Kurt - Have you implemented a work-around?

Neither the file having the issue, nor the file I moved the rule to for successful execution have any CRON commands in them. I have one file with all CRON-based rules.

4

Anyone else? Or suggestions of things to try? Morning rules did not trigger this morning - by schedule or forced trigger. I opened the file and added a space character at the end of the file and forced it to re-execute and it worked fine.

5

This sounds like a known problem for “next gen” rules, now fixed. Could you confirm you are talking about DSL rules?

6

Just old-school, text-based rules… some started in 1.8.3, I think…

I’m thinking of offloading them, creating new files with new names, and pasting the data back in…

7

Newer versions of OH are less tolerant of errors in configuration. I would think normal log levels should show that there is an error. You may need to turn on some Debug level logging to help isolate the issue. Another way would be to carefully compare your configuration rules and items with the current documentation.

8

In the case of uhh “legacy” rules files, consder any imports that you might have carefully. Many were required in OH1, but some would mess things up in OH2. I have a suspicion that some more recent changes in OH core may have caused the list of problematic ones to grow, which might have passed unnoticed until recently.

1 Like
9

Also check for conditions that could consume your threads, which are limited to 5 by default in the old rule engine. Once used up, rules will trigger and queue up, waiting for a thread.

Read through this and make sure your executeCommandLines and HTTP Actions have timeouts…

Saving/touching your .rules files reloads the rules and frees up any threads hung by the rules in that file.

1 Like
10

Thanks all…

My rules do not have any import commands, and I only have a few ‘thread:sleep’ commands that just delay a half-second max… mostly coordinating lights. The rules in question do start a loop to brighten lights over a 10 minute period using a rule found on the boards here.

I am cleaning up some executeCommandLine rules… but I believe all have a short timeout.

Is there a way to see/log how many threads are running? (I’ll go read that thread if it is there)…

Thanks again… starting to aggravate the wife!

11
1 Like
12

Cool, thanks.

Not sure what is happening when I try to run the command(s) but if I don’t break them into individual lines I get an error. I assume I am only looking for thread processes and only need the first result anyway…

openhab> shell:threads --list | grep "RuleEngine" | wc -l
> shell:threads --list | grep "safeCall" | wc -l
> shell:threads --list | grep "discovery" | wc -l
> shell:threads --list | grep "thingHandler" | wc -l
1
1
6
6
openhab> shell:threads --list | grep "RuleEngine" | wc -l shell:threads --list | grep "safeCall" | wc -l shell:threads --list | grep "discovery" | wc -l shell:threads --list | grep "thingHandler" | wc -l
wc: invalid option '--list'
                           wc: invalid option '--list'0

wc: invalid option '--list'
13

Very rarely (and I mean very rarely) I’ve noticed that a rule doesn’t fire. If I just make a minor edit to the rule file that contains that rule(s) (such as adding a new line), the rule start working again. It happens so infrequently it hasn’t become something I’ve tried to debug. Besides, DSL rules are going away in OH3.

14

If you want to execute more than one command at a time on the console, separate them with a semicolon.

1 Like
15

cool - thanks. I thought it was one of those fancy multiple commands on one line commands I generally struggle to understand!

16

So, the rule didn’t trigger this morning, again.

I checked RuleEngine threads and it showed only one running.
I then forced the rule to start, which has timers, and it didn’t trigger at all. No log entry that it started.
I then edited the rule and added a single space at the end of the file and tried again. The rule worked and there was still only one RuleEngine thread running while the rule runs over 20 minutes, increasing light brightness.

While it seems reproducible, I’m happy to troubleshoot tomorrow morning if anyone can tell me what to look for. Otherwise, I’m going to do some rebuilding/rearranging of rules later today.

17

I add this to every rule file

// Indikator, dass diese rule geladen ist
rule "System started file test.rules"
    when
		System started
	then
		logInfo("Logger", "System started has triggered in test.rules")
end

This indicates me, that the rule file is fully (re)loaded. Very helpful. Only if this message appears the rule can be tested, before you do not know if old or new rule is used.

18

The functions run by createTimer() do not use threads from the “rules” pool at execution time.
They each use a thread belonging to the Quartz timer management pool I think, but for sure that is limited. It’s in the linked “Why have my rules stopped” thread.

Scary.

19

Cool - I added it to the file. I assume that this is more definitive than the standard log entry?

Refreshing model 'bedroom.rules'

I check to make sure it is reloaded and error-free each save. After save, the rule runs when triggered by button, but not automatically in the morning. While one would think this is a scheduling thing, when it doesn’t trigger I immediately trigger it manually and it still doesn’t work. Resaving the rule file resolves the issue (for 23 hours)

20

If you save a .rules-file OH detects this and reports it via “Refreshing model 'bedroom.rules”. After successful loading .rules file this message will come “System started has triggered in test.rules” due to the startup rule.

This is very helpful for me to know the time the changed rule is loaded correctly.