Receiving a recurring java error; doesn't seem to effect functionality but I'm not sure what it might do.
java.lang.NullPointerException: Cannot get property '0' on null object on line 396 (method parse)
Any updates?
Any thoughts @bcopeland ?
This happens when I do a configure (and possibly other times):
...Rob
Yes its all sorted out;
John
I'm still getting the error in the logs. PLUS it seems to be sending the "sound" command TWICE--which really screws up sending a second sound after a delay.
I've disabled "command retry" for the ZSE50, but you can see where it is sending the first speaker sound twice. The second one is about 0.6 seconds after the first.
For a specific situation, I wanted to send two consecutive chime sounds (e.g., "Disabling" then "Motion Front"). However, when I put a 1.2 second delay after the first sound (that is WELL shorter than 1.2 seconds long), the second sound gets clobbered by the repeat of the first.
Oddly, I only hear the sounds play one time. If if I put a long enough delay in, the second one doesn't show in the logs with a "Speaker sound: xxx.mp3" line, but plays once as well (it does show the RM command to play the second one--but the driver doesn't show it. The driver seems to possibly be stepping on itself a bit??
Any thoughts?
Thanks,
There will be a fix in a future build for the NullPointerException error (even though it really shouldn't happen at all if the device reports everything back correctly the first time around -- but this should at least prevent errors if it doesn't).
For the sounds, I haven't seen that with manually running commands, which is also all an app should do. But in general, nothing in the driver is going to stop you from playing a second tone while a first is still ongoing, though what the device does (ignores, overlaps, waits, etc.) in response to that is up to the device. If you're not actually trying to send a double command, first make sure that whatever app (rule, etc.) you're using isn't and maybe see what happens if you leave that out of the picture and just run things manually.
For more troubleshooting, the driver should log (hub/driver) commands with debug logging enabled, or "Events" for the device will show command history and where it came from (sounds like you might have looked there, but it would be good to see; the logs you've shared don't have debug logging, just info logging, which is generally events and may happen after a command but is too late for what you're really after at this point).
Thanks!
I'll work on the debug logs.
I'm def NOT trying to double up the sounds. I want to play one, wait for it to finish, then play the second. The app is only issuing one command according to the logs above--but the driver is showing two sound events about .6 secs apart for the first sound. So, it appears to be something in the driver. The app is pretty simple. It plays one chime sound, then the next line plays the second one with a delay.
The timing of its erroneous second attempt then clobbers MY second sound unless I stretch out the delay. The logs will def be useful.
