I recently spent quite some time on identifying the cause of a strange “bug” in my system.
The effect was that one particular rule simply would not fire. I checked, doubled checked and triple checked everything - without finding any errors.
To cut to the chase, I finally noticed something that was a bit suspect: The rule in question had the same “name” (*) as another rule in another .rules-file. Don’t ask how long time it took me to actually notice this!!!
After renaming the rule that would not fire, everything worked fine from there on.
(*) rule name is the text part between “” as in
rule "Test rule #1"
Then I went on to perform a few basic tests to confirm my findings, and it appears that the following is to be expected:
Rules of the same name in different .rules-files causes problems. If two rules have the same name, only one of the rules are executed. I have not tested with more than two rules.
Rules of the same name in the same .rules-files is apparently OK. Both rules fire.
Anyone else that have noticed this?
There might be a good explanation for this behavior (although none comes to mind) - and it may certainly be considered bad practice to have rules of the same name in a system - but given the possible hardship in finding such a problem in a system with lot’s of rules in lot’s of files, I thought it could be good to spread the word.
Come to think of it, it would probably be quite simple to create a Python script to scan through all .rules-files to look for rules with same name. However, given that openHAB apparently cares about this, maybe it could/should be part of the rules parser to warn about this kind of thing?
That’s odd. It normally causes problems. I would avoid that.
Absolutely! My point by mentioning this was that it was a bit counter-intuitive; I would maybe expect rules with the same name in the same file (sort of same scope) to be problematic, and maybe rules with the same name in different files to be OK. However, the opposite seems to be the case.
I am in no way advocating for having rules of the same name. My point is mostly that one should be careful about this (i.e. pay special attention to naming of rules) since this situation is very hard to track down in a large system.
It is actually explicitly documented that all Rules should have a unique name:
<RULE_NAME> - Each rule must have a unique name (given within quotes). It is recommended that you choose a name that has meaning when spoken.
The behavior you list is unexpected though. I would expect that it would behave the same no matter where the Rule is defined.
I think it might be worth filing a feature request at ESH for this. It should be something that the parser checks.
How about a shell command. It’s not full proof but should be good enough:
grep '^[[:space:]]*rule[[:space:]]*\\".*\\".*' *.rules | cut -d "\"" -f 2 | uniq -c | grep '^[[:space:]]*[2-9][[:space:]].*'
Grep through the .rules files and extract the lines with
rules "some text", cut out the Rule name, count the number of times that name appears, and cut out any that starts with a count of between 2 and 9.
It won’t work if you have 10 or more instances. It won’t work if you don’t put the Rule name in quotes. But the likelihood of the former is relatively low and the latter is a violation of the documented syntax.
Unix was made for this sort of thing.