Couldnt get a battery level rule to work... until I started to think

Setup, Configuration and Use Scripts & Rules
1

Maybe this will help some people
I had a couple of rules reading battery levels and sending me an email. They were all in one file and for some reason I didnt get them to work.
Tried a lot of “If” statements such as:

if (LipoVolt <=3)
if (LipoVolt.state <=3)
if ((Lipovolt.state as DecimalType) <=3)
if ((Lipovolt.state as DecimalType).intValue <=3)
if ((Lipovolt.state as Number) <=3)

Went through about every battery rule posting in this community

All didnt work, but only when I added a logInfo statement before my if statement, I got the impression that my rule just wasnt running at all, as the logInfo wasnt logging anything.
Anyway, make a long story short, I had several rules in that one file, all checking batteries and all the way up the end, I had been working on a rule to check an entire group.
That rule still had an error. I wasnt too worried about that, that happens, apparently couldnt import a function, who cares, worry for later right?

Well, only when I removed the erroneous rule at the bottom of the file, my other rules started working flawlessly.
I had never known/expected that a slight error on a rule could prevent the entire file from running. Now I know!!!
Two things I learned:
Cannot stress enough the importance of the logfiles
Error in a rule can prevent the entire file from loading
and now you know too

1 Like
2

This one should work. I use the same. What is the error?

3

Thank you, but maybe you misunderstood, there was an error (loading a library) in a rule I was still working on in the same rules file. That prevented the entire rules file to run and that is why it didnt work So yes, your suggestion would work and even
((LipoVolt.state as Number) <=3) does work.
My post wasnt to ask for a solution (though I sincerely appreciated your comment), it was to post a solution to a problem some other people might encounter

4

Another hint: I usually break up my rules to individual *.rules files to perform easier troubleshooting on them.
This helps a lot (on top of what you wrote already which is very correct, especially with regards to the log files). I usually advise people to avoid using a looooong rules file with multiple rules in it.

1 Like
5

There is a slight difference in behavior between earlier versions of OH (i.e. before 2.1) and later versions of OH.

In older versions when the Rules parser encounters an error it stops reading the file but everything that was successfully parsed up to that point in the file is kept. So if you have an error in a rule halfway down the file all the rules before that point will be loaded and everything after that will be rejected.

In newer versions of OH the checking is more strict. So we now get more exact and specific error messages when OH loads a .rules file (i.e. actual line and column numbers of the syntax error). But we pay for that with the fact that if there is a syntax error in a .rules file, the entire file is rejected.

To me, the lesson is to never ignore syntax errors when a rules file is loaded.

Thanks for posting. I’m certain it will help lots of users.

1 Like
6

@Dim I usually do that too, but it just seemed to make sense to keep all my ‘battery’ rules together. All in all it wasnt that long of a file, but it just never dawned on me there could be a problem… as it used to work :slight_smile:
Anyway, it shows the importance of using logInfo because only then I started to realise the rule just never started, while before I was trying to find the error in the way I defined my ‘types’

Tnx @rlkoshak that explains why it was working before. I spent lot of time breaking my head on it and was about to give a cry for help on the forum when I thought: “No, this is so basic, try again, think, be sytematical”

1 Like