I’m an OpenHAB newbie and today I tried to add email notifications into my rules script and found my rules no longer fired, even though the events log clearly showed the events were arriving. I commented out my sendMail() call but found things still weren’t working. After banging my head against the wall for a couple of hours I finally realized that it was just the presence of the import at the top of my script that made the difference of whether the rules fired or not:
import org.openhab.action.mail-1.8.3.*
No errors are reported in any of the logs, it just stops firing rules. I looked at the debug logs a long time and nothing I could find indicated any problems.
I had seen an import like this in an example of using sendMail(). I finally figured out I didn’t need the import, I took it out and things worked again, and sendMail() works without the import so I’m.
It seems like a pretty user-unfriendly behavior. Shouldn’t there be some kind of error reported? Has anyone seen this before?
Unfortunately, useful errors is one of openHAB’s weak points. There are certain types of errors that do not get reported in the logs. In this case there must have been some problem in the Rules Engine interpreter handling the imports, probably having to do with the fact that those classes are already imported, that caused it to fail completely loading the rules file. It is entirely possible that it was stuck in an infinite loop or a deadlock so never even had the opportunity to report an error.
I’ve seen other situations where if there is an error/exception in a lambda, unless you catch it yourself in the lamba, fails silently.
But usually the default exception is a NullPointerException. This exception can mean anything from your Item is undefined, you failed to cast it to the right Type, you are trying to send an incompatible command to an Item (e.g. a String value that cannot be parsed into a Number to a Number Item), etc.
But all of this is not a result of sloppy coding. It is a natural and unfortunate side effect of how the Xbase framework, which is loosely typed, translates itself into Java which is strongly typed. Basically, any time the Rules Interpreter fails to convert and/or determine the proper type of an Object, it throws a NullPointerException.
