@mike.maxwell
So, its either a bug report, or a feature request, depending upon how you look at it.
The built-in Virtual Humidity Sensor only supports number values instead of decimal values. This means that when I create a rule to apply an actual sensor value to the virtual device, I get an error in logs because the sensor outputs a decimal value which the virtual device won't accept.
I would really appreciate it if we could change the virtual humidity sensor device to accept a decimal instead of the current whole number only approach. This would allow me to use the actual output from my actual device, and would maintain consistency with the virtual temperature driver which does support decimal values.
Thanks!
1 Like
I could write this driver is a few minutes, but AI is really good with this type of simple driver. I just asked Deep Seek,
"Write a virtual humidity device driver for Hubitat, that uses a decimal value for the humidity attribute that can be set"
I saved it, and I put it on my github if you want to add it to your drivers code.
Though you should try it yourself and see how easy it is for AI to write simple drivers.
2 Likes
Awesome, thanks! I will give this a shot!
It is fun to see what it spits out, with instructions for installing and using it even.
1 Like
Just curious, what is the use case for this precision on a relative humidity sensor?
2 Likes
Terrarium and humidor monitoring.
I took your AI generated output and made some changes. I modified the decimal rounding part because for whatever reason, some numbers came out in a weird format (ie 80 became 8E+1)
But it works great! Thanks! I am going to try generating tons of devices now cause I have lots of ideas all the sudden!
1 Like
This was my first thought as well.
Are you using humidity sensors that have an accuracy rated/calibrated to <1% RH? Precision to that level doesn’t mean much if the sensor itself may or may not be accurate to a tenth of a percentage point.
2 Likes
It should also be pointed out that the Relative Humidity device Capability specifies the value is a number and not a decimal.
This means by making a driver where it is a decimal make the driver incompatible with the standard and as such any other such device/app that follows the standard. Keep that in mind as you try to use it with other things.
So just because it should be easy to do, it may not make sense if you want to use this as a actual humidity device. I would suggest you don't use the capability or use it as a humidity device and instead just a generic value to analyse. At that point you could just create a hub variable to store the value and trigger off of.
1 Like
To be honest, it's not about the accuracy. It's more about keeping the data the same as it's always been. My humidity sensors (well, most of them) output data in decimal format.
Every once in awhile, they spit out absurd values (both temperature and humidity) and then spit out a real value immediately after. So I created a rule to filter the bad data and a virtual device to store the good data.
It's just sharing the data with Home Assistant and HA doesnt care at all about decimals at all, so..
Do you just need the driver to not barf on decimals (and, say, round or truncate)? That would be an easy enough change.
Then they are not following the Device Capability properly. Where did the drivers come from. Are they Hubitat written drivers or created by community members.
It would be better to talk to the driver developer to filter out the bad reports. In theory the driver should be able to help prevent obviously bad date.
That is fine, but you have to cognizant of what happens when not following standars properly. I am not saying you shouldn't be able to do something like what you are asking, but it probably should be something clearly not a hubitat humidity device and be a cuatom drivers with custom attributes.
So essentially, every once in awhile (sometimes a few times a week, sometimes just once in 6 months) the actual device will spit out nonsense values (like temp of 876 degrees and a humidity over or 250%) and then a couple milliseconds later it spits out a proper value. It seems to be a device problem, as various different drivers from different community sources (or Hubitat's built-in driver) all exhibit this periodic problem.
To solve the problem, I just created rules that monitor the device and filter out the erroneous data, and apply the good data to a virtual device.
Everything is working great now. @chrisbvt basically solved my problem, and I've since modified that device to make a few other virtual devices for similar purposes.
to be honest, I specifically try to avoid using Hubitat built-in drivers whenever possible. I find that they often only support the bare minimum functionality and really put limits on how useful your devices can be.
I think that is out of the question unfortunately as the driver developer is no longer around. But as I mentioned earlier, even the built-in Hubitat driver has attempted (and failed) to solve the erroneous data problem (aqara weather sensor driver) and, as you mentioned, Hubitat has decided that they will not support decimals in humidity devices. That is totally their prerogative. Luckily I have found a way not to be confined by their limitation in this regard.
Respectfully, it’s not a limitation if the humidity sensors that are typically used for home automation purposes are incapable of resolving a RH value to greater than +/-5% accuracy.
The limitation you’re working around seems to be related to a device that is reporting bad data.
1 Like
It is more of a standard that device makers stick to so that is how most humidity devices report humidity, or at least, how most drivers report it. So I think the decision is really more based on the devices reporting humidity as an integer, and not an arbitrary decision by Hubitat to limit it that way.
Still, the capability for RelativeHumidityMeasurement defines humidity as a number type, so the capability as defined can store a decimal as the number type, but apps that are using Humidity values will try to convert the number to an integer, even though it could be used as a decimal value if is converted that way.
As was mentioned, if no standard apps are going to use your virtual humidity sensor value assuming it should be converted to integer, you will have no issues.
It is definitely both. Fixing the erroneous data was the easy part of this endeavor. However, this is now the 5th post asking for decimal support in various places where only integers are supported. It is however, the first time anybody even bothered to describe why decimals aren't supported. I prefer all readings from sensors to support at least one decimal place of resolution. Whether than is practical or not, doesn't really matter. It's just a personal preference. And now, i have it.
But I do appreciate the more in depth explanation of the situation, thanks for that.
2 Likes
I still think the best thing to do would be to simply update the driver to review the raw data first and then filter bad returned results out. If you are using a community driver it should be fairly easy to do since you have the logic already figured out in your additional process.
I would also really consider precision is something that should make sense based on usage. The difference between 45.3 and 45.8 wont really mean much in 99.999% of cases.
Now the compressed color range used for bulb color selection on Hubitat can make a big difference depending on the devices involved. That is a place were the inproved precision could be useful.
1 Like
It means nothing if the “true” RH in the room is actually, let’s say, 44.5% (or 41.0%) as measured by a much more highly calibrated sensor than the relatively inexpensive ones used for home automation.
ETA: But it’s clear enough the OP has a workaround in mind that works for them, so whatever works 
.
2 Likes