This calculates an average with an exponential decay based on the last 5 samples (this runs on a 2 minute timer). My application is I want to know whether humidity is raising or decreasing (I compare the current value to the recent average).
It appears that the Virtual Humidity Sensor has only integer precision for humidity. Is there a possibility to use a decimal for it, as calculating an average isn't really working well when the result is rounded
Note: I am aware of "average this" app, but it does not do what I want, as it triggers a calculation only when the value reported by the physical device changes, while a real rolling average is time-based, not event-based.
I don't believe so, but it would be possible to write a custom virtual driver that does this. However, I believe humidity is generally regarded to be an integer value across apps that use it (due to the fact that decimal-point precision is rarely required for any application of these values), so you may run into unexpected behavior with other data types. I'm not sure I'd recommend it for that reason, but it is an option, and it may not necessarily be a problem for the particular apps you use.
Another option is using a hub variable and storing this value there. Rule Machine (and many other apps) can use hub variables, and it sounds like you're using Rule Machine already, so this may be the easiest option. If you still have a need for an actual device (maybe more for display purposes? the rule would handle the actual calculation, and you'd still be subject to details of the underlying data type on a device attribute), you could still eventually feed this value to one — just not sure if you do have a use for the device itself.
Mmm, why is humidity generally seen as an integer ?
The Aqara sensors report it as a decimal, so does the AirThings Cloud integration
Having it as a device is vastly more useful than having it as a hub variable. I stay away from hub variables as much as possible. Virtual switches, virtual illuminance, virtual humidity, … much easier to integrate in rules, export with maker api, integrate in dashboard…
Because most humans can't tell the difference between 65% and 66%, let alone 65.0% and 65.1%, so as a practical consideration, every built-in driver I'm aware of uses an integer value for this. (Compare to temperature, where decimal-level precision is more often found, especially in degrees Celsius--thermostat setpoints or reported temperatures, etc.) Again, I'm not saying this will break any app or that it's not necessarily to spec (not all of the numeric attributes are clearly defined...), just that it's possible some will only expect integers.
There are no built-in drivers for these devices, so you must be looking at a custom driver, which can do anything it wants to; I'd look for the behavior of built-in drivers to gauge what is normal.
It is true that Maker API can only work with devices (at least in its current form), but Hubitat Dashboard and Rule Machine can both work with variables. Rule Machine was actually the first built-in app where this concept originated on Hubitat, and hub variables expanded that possibility to all apps (theoretically).
If you prefer a device, you can create a variable "connector," which is a device (of various types, depending on the underlying variable type) that you can use in apps that expect a device. This is not normally needed anymore, but that functionality is still around. It appears humidity connectors are only available for number variables (integers) rather than decimal variables, likely for the above reason, but there is a generic "Variable" connector that could still work, along with other types -- or a variable directly without a connector if that really does fit your use case.
I’m not sure why « what humans feel » has any impact here.
Humans won’t see the difference between 100 and 100.1 lumens, and yet luminance is represented as a floating point number in the default virtual driver…
That is also unusual. Any driver for a real device that I'm aware of also uses integers for that value. My point is that the data types that Hubitat uses in drivers -- and that apps, in turn, expect -- is normally a reflection of whatever practical use there is for the value (and that's usually because a human would care about it).
Anyway, there is nothing stopping you from writing your own virtual humidity sensor driver with whatever attributes/types you want (assuming it still works in whatever apps you want to use it in).
I would think it’s because it impacts how sensors are designed for applications like this.
Even if they report humidity with a precision down to the 10th of a percent, are the aqara sensors really accurate enough to reliably distinguish “true” humidity values that differ so minimally?
Most humidity sensors I’m familiar with for monitoring humidity in a home have a stated accuracy of +/- 5% RH; the very accurate ones might be +/- 1%.
Any driver for a real device that I'm aware of also uses integers for that value. My point is that the data types that Hubitat uses in drivers -- and that apps, in turn, expect -- is normally a reflection of whatever practical use there is for the value (and that's usually because a human would care about it).
