@bravenel Also, FYI, it errors if humidity is a decimal/number format in Basic Rules, too.
So in summary, if humidity has decimal:
- works in RM
- doesn't work in Simple Automations
- doesn't work in Basic Rules
The bug is the driver. Humidity is defined to be integer. Seriously, think about 43.7% relative humidity, vs. 43.5% ????
The virtual humidity driver allows decimals. 
It should not. Actually, the driver doesn't enforce integer. None of the apps should work right if decimal used for humidity. It has to be integer.
So do at least 3 user drivers that support humidity I've found so far.
I don't disagree that it is useless to have that resolution. But it seems that multiple drivers report it as decimal already...
They are all wrong. If these are built-in, tell me which ones so they can be fixed. If they are user, let the author know...
1 Like
OK, no worries. I'm just reporting the findings. I'm ok either way - I can change the user drivers I found (I didn't write any of them).
Might be worth doing a search on the in-box drivers, too. Only one I know of that uses decimal is the virtual humidity driver though. I verified that the NYCE driver is correct. (the only other humidity sensor I have).
1 Like
I just fixed the virtual drivers. We've been chasing this one for quite some time. No device or driver should report a non-integer value, as it will error in the apps.
That can't possibly be true, otherwise you couldn't have thermostats in Celsius? And many in-box driver report temperatures with decimals.
Or do you mean just for humidity readings? If so, I agree/that makes perfect sense/
.
I meant for humidity.
The only devices that support decimal are temperature related, and power/energy.
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
