Rules Reloading But Not Executing

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

It’s fine, really It’s just that when you follow an issue with an idea about where the problem lies, it still pays to share apparently irrelevant details and clues for the extra pair of eyes. Different people’s experiences lead them to consider things you might not have.

Don’t see any problems with this rule and global variables by the way.

Can you actually see that happening in your events.log at the appropriate time?

I’m guessing that you do not see the “Parent WakeUp started” message in openhab.log

27

When it doesn’t work, I do not see that log. When I re-save the file and re-trigger the rule, I do.

I moved the rule into a different file and, without re-saving, ran it three consecutive times triggering it manually (a switch sends the ON command to the triggering item) and then two consecutive times triggering by a CRON job at a certain minute.

The other rules file has another copy of this rule, with the global variables re-named to match it, and a couple other innocent rules (if item change item - no timers, etc.)

This has not been my behavior with the other rules file, unless something happens overnight to disrupt the file.

I’m going to have these two rules run in the AM and see which, if either, fail.

Thanks again… dedicated testing time is hard, which makes all of this more frustrating…

28

Just be sure the rules are named differently. Also, you might as well post your other cron rule that is turning on V_WakeUpSwitch.

29

Careful when copy pasting rules around. Every rule must have a unique name. System wide unique, not just in that file. (or they don’t work)
EDIT - snap!

2 Likes
30

Possibly the issue! There were two rules in the file with the same name, but in my test both rules ‘worked’ (could be coincidence). Just did a system-wide audit to fix, but these were the only ones.

31

Trust me, only one worked at a time - after any given reload. Last one to load wins. You might begin to see how editing a rules file might magically bring a rule back to life.

1 Like
32

I believe it. Thanks for the help and patience.

The text strings don’t look like they need to be unique:

  • as the logs don’t report issues when saved
  • as VSC does not indicate duplicates like it does with item names
  • as item labels (the main string I regularly interact with) does not have to be unique
  • it looks like it is just a helpful string for the logs

But it makes sense and is in the docs, and I’m appreciative of everyone for the help. If you can help with my Catalina problem that Apple Engineering is yet to solve, let me know!

33

and oh, yeah, rules ran fine this morning…

2 Likes