This is a several years old post. I’ve long since moved the code to it’s own design pattern posting and have tried to maintain that. Please review Design Pattern: Cascading Timers and make any updates necessary.
The error is occurring in a lambda somewhere, most likely the Timer but it could be any of them. Usually, when you see a null exception it is because of a problem with a type conversion (e.g. trying to cast or use the state of a Number Item in a calculation but the Item’s state is actually NULL).
I have concerns including the following.
-
The System started Rule was there for a reason. Removing it to solve an error breaks one of the assumptions the other Rules depend upon and besides, it’s always better to fix errors than to eliminate code that does something to get rid of an error.
-
The code above was written for OH 1.8. Over the years that code has had numerous bugs fixed and it’s been rewritten at least twice. I couldn’t even guarantee that that code above exactly as it is written would even be valid.
You will need to add logging to verify which lambda (i.e. which [ | ] chunk of code) is throwing the error. Then wrap the code in that lambda with a try/catch and log the actual error. Sometimes this is very informative.
In general, when Rules have worked for a long time and suddenly stop working the cause is almost always because for some reason an Item was changed, restoreOnStartup didn’t reset an Item on time or for some other reason an Item is NULL or UNDEF and the Rule doesn’t know how to handle it.
Don’t discount rossko57’s observation also. If you have a Timer running and then reload a .rules file, the Timer keeps running. And when it finally goes off the error usually looks just like what you posted. Waiting for the “Refreshing model …” before triggering the rule again and all the rest does nothing to get rid of the orphaned Timer. It’s still there and will still throw an error when it goes off.