Rules Reloading But Not Executing

Setup, Configuration and Use Scripts & 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.

21

Scary, perhaps, but nobody made that comment or reported issues with the code on this post in the Tutorials & Solutions section:

https://community.openhab.org/t/yet-another-wakeup-light-rule/41941

Happy to try alternate light ramp up rules, but the rule doesn’t even trigger and log that it was triggered before it gets to any of the timer code.

22

Nobody knew you were using that code.
We can only go on what you tell us, in this case “the rule runs over 20 minutes”.

It would clarify the issues we’re talking about to look at why that’s not quite true.

The example rule triggers, creates a timer, and finishes in a few milliseconds.
That will queue for, use, and then release a “rules” thread.
The pending timer is scheduled for a future time and left in the care of the timer manager. No thread is used while timing.
At the appointed time, the timer’s execution block queues for one of the manager’s threads, then begins executing. There is nothing unpleasant in the example’s code, again this will be over in a few milliseconds, and the timer thread released.
Of course, part of the execution block was to reschedule itself for another future time, so round we go again.

In terms of threads, we need a normal rules thread just to begin the process, then a timer thread repeatedly for each dimming-step timer run.

There is an omission in the example, declaring a global variable to hold the timer handle. How did you fix that? I have a little worry that your version is spawning many timers.

Bear in mind we can’t see your rule variant, can’t see any logging it produces, can’t see the events in your events.log that you expect to trigger it, unless you show us.

1 Like
23

Thanks for the detailed reply and I apologize if that sounded snarky - that wasn’t the intent. My point was that I didn’t see anything in the comments that would discourage me from using the code, and in testing it works fine, as long as I only run it that one time. When it is supposed to run the next morning, I don’t even get a log entry that it was triggered.

I am unsure about the issue with the global variable that needs to be fixed…sorry. I just copied the script, tested to see that it worked and moved on, only to find it wouldn’t work the next day. Not sure what I need to do here.

My rule is exactly the same, other than item names. The V_WakeUpSwitch is set to ON by a CRON rule in a different script.

rule "Wake-Up Light"
when
  Item V_WakeUpSwitch changed to ON
then
  logInfo("WakeUp", "Parent WakeUp started")
  V_WakeUpSwitch.sendCommand(OFF)
  dimmer = 0
  wakeUpTimer = createTimer(now.plusSeconds(1), [|
      if(V_AllBedroomLights.state==100) {
  logInfo("WakeUp", "WakeUp ended")
  dimmer = 0
  dimmer_step = 1
  wakeUpTimer = null
  sendCommand(V_WakeUpSwitch,OFF) 
      } else {
  if(V_AllBedroomLights.state==10) {
    dimmer_step = 10
  }
  dimmer += dimmer_step
  if(dimmer > 100) { dimmer = 100 }
        sendCommand(V_AllBedroomLights, dimmer)
              wakeUpTimer.reschedule(now.plusSeconds(60))
      }
    ])
end

I am going to do some additional testing with different files, shorter timers and see what I can report.

24

At the top of your rule file, do you have these variables defined as in the example?

var Timer wakeUpTimer = null
var Number dimmer = 0
var Number dimmer_step = 1

If the example is not working for you, it might be best to reply in that topic to ask the OP to help implement their example.

1 Like
25

Ahh, yes. I’m sorry… I didn’t realize I didn’t copy those over with the rest of the code. Rushing and I’ve been fighting with a Catalina issue with Apple at the same time. Super frustrating!

I moved the code into a different rules file and have triggered it successfully three times in a row (changing the reschedule to 5 seconds from 60).

My gut is that it doesn’t have to do with the code, but with something in the guts of the OH code and filesystem, but I clearly could be wrong.

I have another way of achieving the same results if using a different file doesn’t work tomorrow morning, but I prefer to use other peoples tried and true code instead of creating it myself.

Thanks for everyone’s processor cycles trying to help me out!

1 Like