OH3 (Possible) DSL Rules, received update not firing from different files

Setup, Configuration and Use Scripts & Rules
21

“me too” doesn’t move us much further along.

It is possible to create symptoms like non-triggering rules by having duplicate rule “names”.
It is possible to create symptoms like non-triggering rules by having invisible control characters in the text. (That can give many and various errors,or silently mess up,depending on where exactly.)
And of course it is possible to overlook small errors like typing mySmallBedRoomLight instead of mySmallBedroomLight and spend a long time wondering what’s wrong.
Errors in an earlier rule with brackets or quotemarks can prevent later rules in the file being parsed properly.
Careful with Group based triggers - the parser sorts out ‘Member of’ triggers at rule load time. If you then edit Items group membership, it will mess up, until the rule is reloaded.

Take a measured approach to investigating.
Focus on one simple rule that does not trigger, where you can easily recreate or simulate the trigger.
Check in your events.log for that event, if a changed or command type trigger.
Make sure you really know if the rule is triggered, rather than just not getting the results you expect.
Maybe make the first line in the rule a logInfo() to tell you about that.
Cut-and-copy that rule to its own file.
Check in your openhab.log to see that rules file loads without error.
Can you trigger it now? Check the events.log again - does it really match? Item names are case sensitive.
Edit the rule “name”, add something unique.
Try it all again.
Still no go, then delete the whole rule and type it all in by hand.
Try it again.
Don’t start messing with anything else until you sort out this one issue.

3 Likes
22

I have the same behavior here. Now, I also checked for duplicate rule names and found two matches. I renamed those and will observe it over the next days.

My setup uses jython and there are mostly @when("Item/Member of/Descendent of **** received update") rules in place.

23

Hi @rossko57,

I am fairly certain this isn’t a typo in the rules/items itself. Like I said, I took this directly from an Openhab2 instance, and I’ve run into this issue in a few different places. Just to be clear, some rules run just fine!

That being said, I would love to try to nail down the issue, but I’ve not had a ton of success. Here is a failure that I stepped on when I sat back down to look a this.

climate_control.items (about 30 lines into the file):

Switch Run_Main_Damper_Motor                          "Run Motor"                             (ClimateControl)        {channel="mqtt:topic:mainDamper:relay1", autoupdate="false"}
Switch Main_Damper_Direction_1                                "Direction"                   (ClimateControl)          {channel="mqtt:topic:mainDamper:relay2 ", autoupdate="false"}
Switch Main_Damper_Direction_2                          "Direction 2"                 (ClimateControl)                {channel="mqtt:topic:mainDamper:relay3", autoupdate="false"}

climate_control.rule file:

rule "Main_Damper_Direction_1_On"
        when
                Item Main_Damper_Direction_1 changed to ON
        then
                logInfo("Main Damper Rules:", "Main Damper 1 Rule On")
                sendCommand(Main_Damper_Direction_2, ON)
        end


rule "Main_Damper_Direction_1_Off"
        when
                Item Main_Damper_Direction_1 changed to OFF
        then
                sendCommand(Main_Damper_Direction_2, OFF)
        end

So this is pretty simple, if direction1 gets turned on, I want direction2 to copy. In the configuration above, the rule would not trigger, my log entry did not show up in the log.

So I moved the three item lines above to its own items file. Called it climate.items. Lets everything refresh, then turned on direction. The rule fired off, I could see my log entry. I moved the items back into the original file, removed the new file. Rule would not fire again. Moved it BACK to its own items file. Rule will still not fire.

I tried modifying climate_control.rule to force an update, I see the reload in the log, but the rule still does not fire.

I then created a new rule file with just the above rules, called climate2.rules. Loads the rules according to the logs, but they do not fire off.

I also tried changing the item names. Same thing.

One last note: when I see the rules file load. It loads them twice, is this correct behavior? I do not recall it doing this in openhab3 (edit: meant to say openhab2).


21:42:53.317 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'climate_damper.rules'
21:42:55.201 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'climate_damper.rules'

Update: I also checked to make sure I don’t have duplicate rule names.

24

Okay, follow a different investigative path with Items.
Missing from your experiments is observation from your events.log. It’s be really helpful to be sure the event reaches the events bus (else rules will not trigger).

An experiment of my own:
Create a test logging rule triggered from completely imaginary Item, load rule.
Obviously nothing happens, even if you send a command via API to the imaginary Item (except an HTTP error).
Equally obviously there’s no events.log for the command.
Now create the imagined Item, and send it a command.
This time there is a command events.log.
Voila, rule triggers without further reload. (But this is OH2)
Editing the Item without touching rule, rule trigger continues to function.

This is invariably about remote editor behaviour, touching file timestamp when starting to save, and again when complete. openHAB spots both.
I suppose there may be an opportunity there to parse a partly-complete file first and miss the second update,in case of bad luck. Seems unlikely.
OH2 I believe checks for file updates periodically, with a configurable period.
I don’t know what OH3 does, it may have an event listener.

25

I really appreciate the help. But what do you mean by another path with items? I’ve tried creating new items file and new names…

Is this one of those teaching moments where you see the issue and you want me to find it myself? :smirk:

I was tinkering and changed the climate2.rules to:

rule "Main_Damper_Direction_1_On_Christmas"
        when
                Item mainDamperDirection1 changed to ON
        then
                logInfo("Main Damper Rules:", "Main Damper 1 Rule On")
                sendCommand(mainDamperDirection2, ON)
        end


rule "Main_Damper_Direction_1_Off_Dude"
        when
                Item mainDamperDirection1 changed to OFF
        then
                sendCommand(mainDamperDirection2, OFF)
        end

The rule started firing off again, I can see the log entry and such. Tried the trigger over and over again, worked great. Then all I did was save the climate2.items file again (added a return character) and now the rule won’t fire! I saved the rules file again. And it fires again. Save the items file, rules stops firing…

I am really confused but at least at this moment it is reproduceable.

I am not really sure I follow the “grouping” issue, discussed above. Is that a seperate thing?

26

My suggestions were all about experimenting with rules, to eliminate known issues.
You went off on another path editing Items. I don’t know whether that’s adding enlightenment or confusion yet :crazy_face:

You’re using OH3? Would you reproduce my OH2 imaginary Item experiment, lets find out if an existing OH3 rule will “pick up” a newly created Item without itself needing a kick in the pants.
This may be the key difference.
I begin to suspect -
OH3 rules engine uses some indirect link to Items, like a hashcode.
Reloading an Item changes its key/hash.
Existing triggers are now broke, until rule reloaded.
Speculation, but we can test.

Yes. Possibly similar source, but not unexpected.
To expand - when we use “Member of (group)” triggers, the rules parser goes off and buildsa list of members. The trigger is really a fixed list of individual Items - at the moment of parsing.
If you later add a new member,no trigger. Until you reload the rule. Expected behaviour really.

27

Sorry for the delay! Here is what I tried in OH3.

created test.rules:

rule "test1 rule"
        when
                Item test1Item changed to ON
        then
                logInfo("test rule:", "test1Item changed to ON")
        end

test1Item does not exist. I see the rule being loaded, no complaints. I tried sending a command to the test1Item:

openhab> openhab:send test1Item ON
Error: Item 'test1Item' does not exist.

I don’t get the HTTP error, should I have?

Created test.items:

Switch test1Item

Loads happily. I send the command to turn it on from the console:

openhab> openhab:send test1Item ON
Command has been sent successfully.

Although the item does turn on. The rule does not trigger…so nothing in the log.

I resave the item file again. Still won’t trigger. I resave the rule. Triggers!

At least the process is reproduceable…any ideas?

Just to note, I am turning the item off to ensure the trigger happens each time. Also, I never added what I understand as a group to the item (see above) so it wasn’t even listed in my sitemap. I could only access the item through the console. So this can’t be a grouping issues right?

28

No no, I was using API to tickle the (imaginary) Item, you’ve used console, doesn’t matter here, we just want the command.

That’s the important thing, and its a major departure from OH2 behavior.
It seems in OH3 an existing rule will not now “pick up” an Item initialized after the rule.

To complete the picture, with your Item working and triggering the rule, could you now try editing the test Item. My expectation here is that triggering will cease. If true, this situation is likely the cause behind generally observed trigger problems.

If you’ve found out how to render a file-based rule silent … the next test would be to see how a UI created rule performs. I suspect the same triggering framework, suffering the same problem.

That’s fine, but using command as trigger is pretty foolproof; send as many commands the same as you like,the trigger is supposed to catch them all.

Absolutely, that’s the point of keeping the tests dead simple.

29

I tried messing around with GUI created items/rules. I can’t seem to get the rule to fail to trigger. Seems to trigger even after updating the item.

30

Okay,maybe it is specific to file based rules and/or files based Items.

What happened with a file based rule and an edited file based Item, di that stop triggering?

31

please see linked thread here

because was nasty buggy and may not be fully flushed out, sounds same ish
see github issue in linked thread

32

Yes. If I do anything to that simple items file (even just saving) the rule will stop firing. I have to resave the rule file to get it to fire again.

33

That goes a long way to explain many troubles people have had, thanks for playing with this.
While a rule that does not trigger from a newly created Item can be waffled away, I don’t think editing Items causing rules to break is expected behaviour.
I’ve updated an existing Issue with your findings, clearly removing Groups from the picture.

2 Likes
34

I see we got another welcome new release today with loads of new goodness but alas, this, and the original bug in GitHub, remain open and unresolved.

Given the time invested by so many in 2.something upwards in text-based rules, this has caused me to park the whole automated home idea as it’s a breaking change I cannot work around. Each edit of an item or restart of docker container means I need to do CPR on the rules to bring them back to life.

How might we get the rules issue looked at?
All for adding new features but seems unfortunate to leave this regression bug in play.

As always, if I knew how, I would do it myself.

1 Like
35

You have some other unrelated problem.

The circumvention is not to edit … how often are doing this? (Why?)
It is a great nuisance while developing, but edits during normal use are the exception.
Impact can be contained by subdividing rules and Items in several files.(This has benefits in grouping by theme anyway)