I have gotten a null pointer in all handler method, Trying to determine what is going on.
I looks like one of the devices I have in the trigger is somehow invalid.
I can rebuild this rule or remove device, etc to debug. But I'd like to understand better how to debug when something like this occurs other than "does this look right to you?" screenshots
search
app:5592021-10-10 08:01:12.612 am errorjava.lang.NullPointerException: Cannot invoke
method parse() on null object on line 7982 (method allHandler)
app:5592021-10-10 08:01:12.500 am infoAction: Set HouseBattery to %value% as integer
app:5592021-10-10 08:01:12.425 am infoSync: Last Battery Level Triggered
app:5592021-10-10 08:01:12.326 am infoSync: Last Battery Level: [Sunroom] Backdoor battery 9
I think you'd need to see the underlying code to figure out what line 7982 refers to. With a custom driver or app you can look at the code. With RM, not so much. Though perhaps you could so a search on it and see if someone else makes reference to it in a post?
In this case, though, there would seem to be an easier way to accomplish what you're trying to do, either with @bptworld's Device Watchdog or the notification app. Or am I missing something?
Well.. The watchdog app is cool, but I'm using sharptools a lot and playing with way to get info over to it.
this is really about learning a lot. I think I found the issue was my virtual device wasn't capable of actual method calls, changed to a build in generic virtual device to see if that solves it.
The weirdest thing I can see in your screenshot is that there is "null" listed under Connector instead of an actual device (or so it appears--does anything happen when you click "null," which would normally be either a link to create a connector or a link that takes you to the device page for a connector already created?). However, if you're not actually using the connector in the rule (just the variable directly), I'm not sure if that's really the problem. Still, it can't help to make sure that either the connector exists or that removing and re-creating the variable doesn't fix the problem.
Otherwise it looks like maybe one of your devices is sending a null value instead of a numeric battery value, and that's causing problems with you're trying to set the variable. But it is hard to say for sure--as mentioned above, the line number refers to the RM app code, which we can't see, not your rule (though it wouldn't necessarily be that helpful even if you could see it; Java/Groovy errors, if not all errors, are sometimes unhelpful like that ).
@bertabcd1234 is correct. The error is coming from that null connector. You probably have to remove that variable and recreate it. Doing so will trash the actions that use it, so you'll have to fix those up to use the new variable.
Whenever anyone gets an error from a Rule, please ping me. These should not happen, and always reflect something that needs to be fixed in the code. Please use screenshots of logs as opposed to copy/paste, to post logs here (much easier to read).
So, the answer to "How to debug rules by line number" is: get Bruce's attention by pinging me in your post with @bravenel.
Ah - that totally makes sense.
I've got something werid going on with my rules engine install.
Sometime when I make a local variable it doesn't even create the place holder col in the display for connector.
Evidently this was one of those times I think.
Ohhh.. I see. I've not done much on my hubitat in a while. So 90% of my existing rules are now 5.0. When I went to add a new rule ,(not realizing it was 5.1), I was quickly baffled. lol
Thanks for the help!
I gottta say I'm envious of your job, (I think). I've got a TON of interest in this ,(and blockchain/web3) , but too many home projects and coding for a living doesn't leave enough free time. it really seems to me there is room for some overlap between hubitat hubs and a bunch of service based "miners" I've been looking at/buying (Helium/MatchX etc..). if nothing else I'll be trying to make some drivers /apps to get information from them later this year/early next.
Sorry - early morning ramble. Just excited to have found sometime to get back to this.
).
