Good to know! Thanks for that! I'll watch out for this in the future in my drivers.
You must have missed the previous parties about this. It comes up every 4 or 5 months.
2 Likes
Just butting in to say thanks for the clarification! there a way to tell this from the docs? For example, for RelativeHumidityMeasurement's humidity attribute, it simply says:
Attributes
humidity- NUMBER, unit:%rh
On SmartThings (I know, I know, different platform...) I believe they've loosely defined "number" as any numeric type, with it being up to the DTH to determine which. I've basically assumed this to be any Groovy/Java subclass of Number, which would include the common Integer or BigDecimal types. But if there's some way stop me from guessing, that would be even better. 
(On a related integer-vs.-decimal note, do Lutron dimmers accept decimal values for setLevel() values and/or report them as such in the level attribute? I seem to remember them being a bit special but might be thinking of something else...)
1 Like
What ST did/does is entirely irrelevant.
'Number' as an attribute definition in a driver is ambiguous. In an app it matters. All Number device attributes except for a few are assumed by apps to be integer. Lutron dimmer driver and all dimmer drivers deliver integer values only. The only attributes among standard device types where apps support decimal are temperature related (including thermostat attributes) or energy/power related. All others should be reported as integers, and the apps count on this as a general rule. So the apps are going to throw errors for non-integer values in all other cases.
About drivers: Number is the supported attribute, and it is ambiguous. Drivers don't support Decimal and Integer as attribute definitions.
I don't think so.
Decimal humidity values work in RM rules. 
(OK, now I'm just being intentionally cheeky. 
- It is an undocumented coincidence, I'm sure.)
I've already changed user drivers I'm using to integer for humidity. 
I just made a RM rule to do it, and it worked... Again, who cares, though? I'm not arguing that is how it SHOULD work. I'll crawl back under my rock now. lol
I'm not sure what you're talking about. You can't enter a decimal point when creating a trigger or condition for humidity.
1 Like
No, but if you make an RM rule with a humidity trigger, and the trigger is a humidity as a decimal, the rule still works whereas it crashes in SAR and BR. I assume that RM just has different type casting/conversion/checking.
On all you can only specify the comparator threshold as an integer.
OK, so this will go away and stop coming up, I put in changes to Basic Rule and Simple Automation Rule for both humidity and illuminance events so they don't throw an error for a decimal event value.
So you if you really want to report 45.7 lux, knock yourself out!
1 Like
LOL. On a nice sunny afternoon my outside lux meter goes >100K. That decimal may be super important for some reason though... (sarcasm!!)
Thanks for all your work Bruce. I wasn't trying to open a can of worms.
1 Like
Took less time to put in the change than explain it here.
was
if(evt.value.toInteger() > value) doActions(evt)
now
if(evt.value.toDouble().toInteger() > value) doActions(evt)
2 Likes
That's interesting. I've never done mutliple ".toXYZ"s before. Learn something new every day.
EDIT: Oh, duh, I see what you did there. Had to go look it up though. lol
BigDecimal has this issue if IIRC
Got it to work.
As Bruce an Jason said it was because the driver was sending the numbers with decimals.
It is a user driver for "Xiaomi Temperature Humidity Sensor", the driver have the option to report in integer, so it worked after i turnede it on.
I had it running in RM for a long time until i decide to do some spring cleaning, to get rid of all the odd rules i been playning around with. So the driver was not the place i belived the error was
And thanks for all the reply's and help
