Using system driver for a Zen72 dimmer that I've been using for years. Now getting this error:
dev:3412025-10-13 05:43:22.337 PM
error
java.lang.NullPointerException: Cannot get property 'value' on null object on line 368 (method parse)
Just noticed it in the logs.
I switched to @jtp10181 excellent advanced driver and eliminated the error.
Are you running Zwave JS or legacy ZIP?
@bcopeland or @bertabcd1234 driver may need a fix?
Maybe something in Z-Wave JS? Line 368 is a zwave.parse(), so changing drivers was probably just coincidence if it eliminated an error. Might be helpful to see Z-Wave logs around this time, though probably too late for that now. Bryan may have some ideas.
I'm on Zwave JS and have been for quite a few months. I guess I might have missed this error before. But since I had gotten it more than a dozen times in the past two days, I doubt it. If you need me to put the standard driver back I can do that. Don't know how to reproduce the error though. That dimmer is basically on all day when anyone is awake. It's over the kitchen sink.
There have been lots of Z-Wave JS changes in recent builds. I didn't mean to imply that it would have been there the whole time.
Would the driver log the incoming message BEFORE the parse? If so, turning on debug logging and then deleting the scheduled job that turns off debug might be able to uncover why the parse is bombing out.
Yep! You should see the full data (starts with "parse:") if debug logging is enabled.
Excuse me being dense here, but are you guys asking me to do something or is this an academic discussion?
Without seeing a debug log to be sure, but I think this is already fixed in one of the beta builds.. I think this build is going out public today 
Sorry for being unclear; the goal would be for you to enable debug logging and see what it spits out just before this error (that log entry should start with "parse:") -- if you switch back to the built-in driver (though given the cause being elsewhere, the custom driver would probably show the error, too) and still have this error after updating. So, I'd probably wait for that release first. 
Also if not reproducible easily you would need to go to the system Logs > Scheduled Jobs, and then find the task to turn off debug logging for that device and delete it (so debug logging stays on after 30 minutes).
As Robert said though, it is odd a driver switch fixed it. My driver possibly changed a setting on the device behind the scenes to change what messages it sends though, I do have that built in for some of the Zooz switches, usually to help distinguish between digital/physical events.
If the error comes back on my driver you can go to the settings and enable Trace logging indefinitely. Trace is needed to see the full message for my drivers.
I should not have said that changing drivers "fixed it." The error hadn't returned. The errors seemed to happen when rules fired to turned that light off last night when we went to bed and again this morning when another rule turned it on. I've tried to reproduce it with the old driver back in place but no dice. Sorry.
Just checking. The "fix" for this error hasn't gone into production yet, right? I still see the error - infrequently but it still appears. I'm switching back to the @jtp10181 driver.
I believe he thought .137 would fix it. There is more changes in beta right now so maybe wait for the next release and test again if you want. You will need to turn on debug logging so it stays on forever (delete the job to turn it off as explained), and capture the debug logs. Otherwise they are just guessing.
Understood. The switch works fine and I only get 1-2 errors a day. It's not a big deal.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
Download the Hubitat app
