I set up a "Christmas lights" Rule to turn on a single Tadfri outlet 1/2 hr after sunset, and another rule to turn that same switch off at midnight.
Got exactly one log entry, and the lights were still on when I got up at 5:30am:
2020-12-07 01:45:37.289 pm errorjava.lang.NullPointerException: Cannot get property 'n' on null object on line 1476 (atCertainTime)
The rule at issue is simple - On:
...and Off:
The off-time setting of midnight, and the sole error being at 1:45pm means that the "off"rule died when created, but no visible error appeared when setting the rule up using the phone app.
How can this simplest of rule sets silently crash and burn and leave the user unaware that there is such as basic and catastrophic error as the classic "java.lang.NullPointerException" ?
How might one "debug" this?
What's property 'n'?
How could one have a null object, when this "program" was created by simply clicking on choices presented by the GUI?
What mechanism should have made the user aware that there was an issue here? This is not "Wife Acceptance Factor", this is now escalated to "HUSBAND Acceptance Factor".
"Elevated Home"? Can it turn off a single freakin' outlet without a 1/2 hour debugging session?
Sorry to hear that you're having trouble. I know it won't help you, but I was able to create a simple rule triggered at midnight without problem:
So, something must be different (and given the error I'd assume it's not our actions). Given the time of your error, my guess is that RM had trouble creating the "subscription" based on your trigger (the thing that should wake it up at the specified time to run the actions) at the time the rule was saved via either "Done" or "Update Rule." One thing you could try that might help is removing that trigger and re-adding it. Alternatively, since your rule is quite simple, you could just remove the rule and re-create it. No guarantees, but I definitely got the time subscription to work, so maybe it will help you. Still no explanation for why it happened in the first place, but if this helps you, at least the problem will have been resolved.
Also, what hub firmware version are you on? I'm on the latest as of my writing, 2.2.4.158. There may have been bug fixes for something like this recently if you're on an older version, though I don't remember seeing anything in the release notes for such a fix.
Finally, as you may know, Rule Machine is probably overkill here. To turn something on or off at a specific time, Simple Automation Rules will work with a bit less clicking (though this rule is also pretty simple, set up correctly, and should still work--not trying to deny that there is a problem, just suggesting something else you could use to get this working).
If nothing else helps, we can tag Bruce if he doesn't see this already, and he can hopefully track down the problem. Good luck!
I haven't seen this particular error/failure before, and can't say I immediately know what caused it. My suggestion would be to remove the rule that threw the error, and recreate it. There is nothing odd about your rule, but I suspect something went off the rails somewhere along the way.
Yes, the rule died when you created it, that much is clear for sure. Please try it again...
All code was up to date, and the failure is clear enough, but I don't see where the rule machine code is published anywhere, so I can't look at line line 1476 in the "atCertainTime" subroutine to see how it got passed a null it wasn't expecting.
Let it alone, and it again did turn "on", but did not turn "off", so the rule never got created.
Suggestion - some sort of on-screen warning of at least catastrophic app failures, to let the user know that what he thinks he properly and successfully set up using the GUI had an actual crash-and-burn result. Having to pour through the log to see if something was successful seems somehow.... less-than optimal.
"Simple Automation Rules" OK, I'll give that a try, although I am a veteran of many versions of "Simple Network Management Protocol", and that use of the term "Simple" was a highly creative and hitherto unknown application of the term "simple", so please forgive my wariness.
As I said before, this is an error I've never seen before, in 4+ years of this app's existence. So it's hardly possible to anticipate it. It wouldn't be possible in the code to protect against every conceivable error to provide a warning. So, the logs are your friend when something doesn't work as expected.
Rule Machine should not throw the error you saw. I'd try to create that rule again from scratch, removing the old one completely. If it were to throw the same error again, then there would be a repeatable problem that could be investigated.
So, some sort of generic "any error" notice is not possible?
Not so important to explain the specifics, more important to raise a flag that an error has happened.
Yes, the logs tell all. The idea here is to give the user a clue that he needs to go look at the logs.
Recreated the same thing with Rule Machine, no repeat of the error, which puzzles me.
Re-built the functionality with Simple Automation, no problems there.
The original error you reported is what puzzled me, not that you didn't get it again. Not at all clear how that error was even possible. But, you know, stuff happens with computers/software that is never really fully explained. Shrug.
There is a mechanism by which selected specific errors can be intercepted in code. But it doesn't generalize to all errors that our platform can throw. The idea generally is to fix the root causes of errors that we become aware of, so they just don't happen in the first place. For the most part, unseen errors will show themselves in failed automations -- things that should have happened but didn't, or things that happened that shouldn't have. There is a Past Logs feature to look back to see what might explain one of these failures. But, the awareness of the failure really comes from what happens in your home and system.
![Log entry from rule at 12:00:00.162 am: [info] Actions ran!](https://community.hubitat.com/uploads/default/original/3X/1/3/1320e80eaedfde442e9323ba122bc61a353ac6d5.png){kind=small}
