Philips Hue Indoor Motion Sensor v2 Device Driver Error

Hello all. I am using a C8 runing 2.4.0.145. I have multiple Philips Hue v2 indoor motion sensors. They work really well except when changing . I get the error below anytime I attempt to change the lux reporting, temperature reporting or motion retrigger. I am assuming it is using it's default values however I would like to change those with the options given. Anyone have any ideas?

java.lang.NumberFormatException: Character n is neither a decimal digit number, decimal point, nor "e" notation exponential mark. on line 280 (method updated)

Were you in any of the 2.4.0 platform betas? There were some UI glitches that may have caused problems with some preferences, which could result in this problem.

Regardless: the first thing I'd look at is your "Reference temperature" value--make sure it's set to an actual number (this is what could have been messed up in the beta), see if blanking it out works if you don't actually intend to use this feature, or try entering the current reading if you don't and blanking it out still causes the error (shouldn't--but it's possible there are still lingering issues with the new UI).

1 Like

No, I wasn't a part of any platform betas.
The error does not show up when I enter any number but if I leave it blank the error does show up. I assume this is intended. Thank you for the quick and helpful reply. I will keep testing and report back if I need additional help.

No, it should let you leave it blank, though that is a workaround, so it should help for now (entering the same temperature as the current temperature should give you 0 offset like it is by default). I'll do some digging to figure out if this a new UI problem or something in the driver...

1 Like

I'm having some strange Hue behavior as well. I've had ONE v2 Hue Motion that has been operating on my network great for some time... But I added two additional ones tonight and am getting a ton of errors. #1 is still fine, #2 and #3 are churning out a bunch of errors that I don't know how to address. Any help would be appreciated. I've attached pics of #1 logs which are fine, and #2 and #3 logs that are not.


PS. I tried turning off debug logging, and then this error came up.
dev:10632025-01-02 10:46:34.869 PM

error

java.lang.NumberFormatException: Character n is neither a decimal digit number, decimal point, nor "e" notation exponential mark. on line 280 (method updated)

You must have been using a custom driver for this at some point. While the error is harmless in terms of regular device operation, to stop it, go to Logs > Scheduled Jobs, find the job named "recoveryEvent" listed for this device (or likely anything listed for it), and delete it.

I suspect there are still UI oddities in the current buiod with numeric preferences (unrelated to your turning off debug,logging, though the save for that triggered a save for all preferences; debug logging will turn off on its own after 30 minutes, so you don't need to worry about that for now if you don't want to). I have to look more closely at this driver to see, but with others recently, the "reference temperature" preference has been the problem. Assuming you want to keep the default of no offset, putting in the current temperature as displayed under Current States would work around this for now.

1 Like

Awesome. Thanks for the help. I tried entering the current temp, though I didn't use the decimals, it looks like it offset the temp by 0.12 degrees (lower in the screen shot), lots of updates without errors, then I walked down to the sensor and saw a bunch more errors pop up. I suppose it doesn't matter if it is all working the way it is supposed to. I imagined a bunch of unnecessary errors bogging down the hub, but maybe that's not the case. :slight_smile:

All the errors above look the same as each other and the same as the one mentioned in your other post; the solution I posted above will work to get rid of them (probably a good idea so logs that are actually important are easier to find, but again, not really harming anything).

For what it is worth, this issue is not isolated to the Philips Hue sensor driver. I also have the same issue with the few older Bosch motion/temp sensors I have.
Workaround is still applicable for those also.

I have an idea of what is causing this.

The next update is likely to have a fix. In the meantime, filling a typical decimal input with 0.0 rather than leaving it blank, before hitting "Save," should work around the problem -- but for these "reference temperature" ones, you'd probably still need a workaround like the above where you trick it into calculating a zero offset. If you don't have any preferences you care to save, you can also just ignore this; if you do, the error happens pretty early on and would prevent most from taking effect if they require changes sent to the device (e.g., motion timeout).

I've tried the Temp Offset. At first I typed 0, but then it reported it as negative 53.20 (etc). Then I intentionally set it so it would be an offset of -0.01 but the errors continue. I've attached logs from earlier today when there has been no motion or lux change, just temps, and the error throws every time the temp is reported to the hub. Are you saying I should put 0.0 in the temp offset box? If it is 53.20 Temp, then it would report at -53.20.





No:

By this, I mean you'd need to put in the currently reported actual temperature -- thus forcing it to calculate a zero difference between your reference reading and the current temperature.

Or wait until the next update when hopefully this will all be resolved. :slight_smile: (Or I guess temporarily downgrade and save the preference there.) It's a UI problem that prevents a truly null value from getting saved if left empty, and it's messing up the driver that expects a number or nothing.

It's just that these inputs aren't the only ones affected; it's anything that can take a decimal value as an input.

1 Like

I think the error you are seeing is different then what I am posting about. I have seen that error for a few of myHue sensors as well. It happened for the Hue sensors that replaced Sonoff sensors. I used the "swap device" feature. It appeared that when swapping, the Hue sensors held on to a recoveryEvent() method that shouldn't be there. I had to make a virtual sensor then add it to the rules and apps where the Hue sensor was used. Unpair, factory reset, then pair the Hue sensor again. After that I then replaced the virtual sensor I just made in all the rules and apps with the newly paired Hue sensor...manually. I haven't trusted the "Swap Device" feature since then.

The most recent update appeared to do the trick. I am no longer seeing errors. Thanks for your help.

1 Like