Scenes throwing Java errors every minute

🛎️ Get Help
1

I have a couple of scenes. I see in the logs that they are throwing a Java exception every minute. The string in question is the level in the Lifx bulb in the scene. Any thoughts/ideas/fixes? Is this a straight up bug in the Scene code, the Lifx code or ?? Logs entry samples follow:
app:10122021-05-06 10:37:04.205 am errorjava.lang.NumberFormatException: For input string: "87.37" on line 627 (checkScene)

[app:1014](http://192.168.4.136/logs#pastapp1014)2021-05-06 10:37:04.200 am [error](http://192.168.4.136/installedapp/configure/1014)java.lang.NumberFormatException: For input string: "87.37" on line 627 (checkScene)

[app:1012](http://192.168.4.136/logs#pastapp1012)2021-05-06 10:36:04.248 am [error](http://192.168.4.136/installedapp/configure/1012)java.lang.NumberFormatException: For input string: "87.39" on line 627 (checkScene)

[app:1014](http://192.168.4.136/logs#pastapp1014)2021-05-06 10:36:04.245 am [error](http://192.168.4.136/installedapp/configure/1014)java.lang.NumberFormatException: For input string: "87.39" on line 627 (checkScene)

[app:1012](http://192.168.4.136/logs#pastapp1012)2021-05-06 10:35:04.234 am [error](http://192.168.4.136/installedapp/configure/1012)java.lang.NumberFormatException: For input string: "87.4" on line 627 (checkScene)

[app:1014](http://192.168.4.136/logs#pastapp1014)2021-05-06 10:35:04.207 am [error](http://192.168.4.136/installedapp/configure/1014)java.lang.NumberFormatException: For input string: "87.4" on line 627 (checkScene)

[app:1012](http://192.168.4.136/logs#pastapp1012)2021-05-06 10:34:04.215 am [error](http://192.168.4.136/installedapp/configure/1012)java.lang.NumberFormatException: For input string: "87.42" on line 627 (checkScene)

[app:1014](http://192.168.4.136/logs#pastapp1014)2021-05-06 10:34:04.195 am [error](http://192.168.4.136/installedapp/configure/1014)java.lang.NumberFormatException: For input string: "87.42" on line 627 (checkScene)
3

Yes, levels are expected to be Integers

4

Here we go again. :slight_smile:

I still maintain that Hubitat should document preferred/allowed/prescribed attribute types more thoroughly. The only documentation I know of says "NUMBER" is valid for attributes. The "NUMBER" variable type includes decimals.

I am not arguing that having decimals in a "level" or "humidity", etc, attribute are useful - I don't think they are - but I don't think the system should throw an error on a valid data type either.

https://docs.hubitat.com/index.php?title=Attribute_Object

Regardless, the right fix/path of least resistance from a driver or app standpoint is to have only integers in fields expecting integers.

5

So the problem is that I have no control over that. I have the level set to 30 (or 60) and then capture the scene. Somehow it gets automagically converted to a float in the guts somewhere.

value
value1088×796 53.4 KB

6

I really wish I could get the integer to stick. I kind of guessed this was the problem (was a Sun Certified Have Developer some 20 years ago...) but don't see how I would change it.

7

But what is the level on the actual lights? If the scene is reading the current level from the lights, and there is a decimal there, that could throw the error too (maybe - no idea what is on line 627 of the scene app code).

9

image

60, believe it or not...

10

Not 60... 60.0....

60 = integer
60.0 = decimal, not an integer.

Not saying that is the issue for sure, but very well could be.

Normally a level looks like this (notice no decimal):
image

11

Good point. So, the problem is that in adjust scene they look like integers (shows 60). When I go into the device itself. Even when I enter an int it looks like a float. I think this is a LIFX driver issue.

image
image1154×650 23.1 KB

12

That is my GUESS as well. I don't have any LIFX bulbs to test it against though.

That said, I think the scenes app should handle it more gracefully anyway. Similar to the changes Bruce recently put in the Simple Automation Rules app to handle getting floats when integers were expected.

Like this:

13

Agree. The point of throwing exceptions in Java is that the code can catch them and do something smart when the condition happens. Your code fragment is what they should have done. For now, I'm removing these scenes and hard coding the behavior in a rule.

14

Would probably be really easy to just change the driver to use int as its event value, too. It can't set that event TOO many places I wouldn't think.

15

Thanks for taking the time to let me bounce this off of you and help work through it.

16

Level, saturation and hue are all defined to be integers. Drivers that throw decimals are just wrong, and should be fixed.

17

I agree, but where is that documented?

18

Thought of that. The problem is that it will get overwritten if I do a code update using Hubitat Package Manager.

19

True. Best to feed that back to the dev, and get them to fix the driver permanently. :+1:

20

I don't know about the documentation. Just that the hub implementation has always expected integers for these values.

21

:+1:

22

I agree they should be integers.

My only point is that we can't really blame developers for doing something that isn't documented... The only documentation I know of says NUMBER is a valid attribute variable type, and NUMBER includes floats.