There are a couple of issues here.
Drivers only make the distinction of decimal vs integer values in order to interface properly with apps. In apps, the UI can enforce a number's type by disallowing a decimal point in integers, or allowing one in decimals. The app author has to make a choice, decimal or integer. So there has to be a convention in place between apps and drivers.
AFAIK, There are only five sensor capabilities in Hubitat that return a decimal value. These are:
- Temperature Measurement
- Thermostat Cooling Setpoint
- Thermostat Heating Setpoint
- Energy Meter
- Power Meter
In all other drivers the event value is converted to integer before being sent in the event. As a practical matter for 'home automation' (as opposed to, say, 'process control)' there is no meaningful distinction between 20% and 20.45% (battery or humidity), or illuminance of 87 lux vs 87.32 lux. And, for temperatures in °C, one degree C is 1.8 degrees F, which is more of a step than is comfortable -- so non-US thermostats are set and report in half degrees, and US thermostats are set and report only in full degrees.
3 Likes
For my purposes, these virtual devices and the decimal accuracy don't matter to Hubitat. It is ONLY for Home Assistant, which is what people (me, wife, kids, dashboards) interact with or for the sake of logging or trend info.
As far as Hubitat is concerned, it's only purpose in my ecosystem is to do the behind the scenes stuff, like automations or hosting devices. In automations from Rule Machine, I would never bother with decimals. Everything is always based on whole numbers.
But again, that is all besides the point. There's no reason why it should matter. All number inputs should be able to accept decimals. There is no reason at all to explicitly limit anything to integers only. No other platform seems to enforce this type of limitation on any particular sensor type vs another sensor type. It is just some completely arbitrary decision to enforce integers only here while accepting decimals elsewhere.
Sure there is: users. There's no point arguing it... sort of like the arguments for and against strong typing. We are on the strong typing side.
I have no idea what that even means... But it doesn't really matter. As long as the system remains flexible enough for me to work around arbitrary limitations, then those limitations are merely just inconveniences that I can accept.
2 Likes