Configuration model 'somefile.rules' is either empty or cannot be parsed correctly!

Tutorials & Examples
, ,
1

This comes up quite frequently so I’m creating another topic here so I can reference it later instead of typing the same thing over and over.

tl;dr - You can ignore this WARN level log statement so long as it is immediately followed by

 Loading model 'somefile.rules'

or log statements specifically referring to syntax errors in the file. This applies to all files in /etc/openhab2

Full Explanation:

OH uses file events to know when to reload files that are modified while OH is running. However, some editors and all editors that edit a file over SAMBA share from Windows (perhaps any OS) generate two file events every time they save a file.

The first event occurs after the editor empties out the file and readies it for writing and the second occurs when the editor is done writing the file. I suspect what is happening is the editor is deleting the existing file or moving it to a temporary backup and then creating a new blank file which causes the first file event. Thus, when OH reacts to this first event it encounters a blank or partially written file and generates the warning:

Configuration model 'somefile.rules' is either empty or cannot be parsed correctly!

Once the file is done being written a second file event occurs and OH tries to read the file again and this time it is complete and it can successfully parse it and you see:

 Loading model 'somefile.rules'

Any errors you see after the first warning are caused by real problems with your file.

6 Likes
2

For my rules, I always have this on every rule file:

Top of file:

val ruleFilename = "xxx.rules"

Bottom of file:

rule "Rule file parsed - xxx"
when
        System started
then
        logInfo("RuleParsed", ruleFilename);
end

If any part of the file has any error in terms of parsing, you will not see this in the log

1 Like
3

Has it been stated somewhere that rules are guaranteed to be processed and executed in order?

If not, then this is not a reliable indicator.

4

Rules are definitely not guaranteed to be processed in order. That is one of the joys of multi-threaded programming.

However, I do think that Lucky’s approach would still work.

We do know that if there is a fatal syntax error the .rules file is rejected. We also know that the System started rule won’t be executed until at least that one rule gets loaded and parsed. By putting the rule at the bottom of the file we can assume that that rule never gets read into memory upon a syntax error further up in the file. Therefore if you see the log statement you know that the full .rules file was parsed and there were no fatal syntax errors.

With the newish (2.2 release) behavior of OH rejecting the whole file on a syntax error, I suspect the approach would work no matter where in the file you put the System started rule, but putting it last would be more foolproof.

One gotcha is that it could be some seconds after the file is loaded and the System started rule executes so the confirmation log will not be terribly timely. But for this that probably doesn’t matter.