I can certainly change this, and I would have before now, if it had been raised as an issue.
Does the value for temperature events also need to be passed as an integer? Same for any/all other capabilities with a numeric value?
Sorry if that seems like a dumb question, but looking at the Hubitat Developer documentation, the Event Object Value is listed as String and for example, both the capabilities RelativeHumidityMeasurement and TemperatureMeasurement list their respective attributes as a "NUMBER".
This is an effect from RuleMachine getting better. For a very long time these Attributes weren't available in RM to compare to. RM3 and now RM4 has certainly encouraged their use. I am massively aware of the change because I chose to work on APIXU thinking that the "user side" of the existing program was well vetted. It's been in use for a year, how could the Attributes be incorrect? There certainly was a surprised look on my face when I found out STRINGS were throwing errors. @bravenel was very helpful that day in highlighting where one error was, and I then had to work on the remaining 61 Attributes.
Only to find out yesterday, I misread between the lines. Like Humidity, Illuminance is also an Integer, while Temperature is NOT. Documentation for both simply say "NUMBER" which is to say, not a string, but without narrowing down the casting needed. I treated them the same and since I know Temperature isn't an integer, I cast them both the same. I released updated versions of wx-ApiXU-Driver and Luxuriant-Driver this morning for that swing-and-a-miss.
Evidently that may not be the problem. Still investigating.
No, temperature is decimal. Not sure about pressure. Energy and Power are both decimal also. Your example was from temperature.
As I said above, we did find an error in the UI that caused the original error in this topic, where the UI allowed a decimal input for humidity when it should not have. Beyond that, it's not clear what, if anything, else is going on. And, also as reported above, others are using this driver with no error. So based on that, for now, I retract my statement that this is a driver problem.
I can't with the information you've showed. Believe it or not, it's actually necessary to see the error, and when you say "the error", are you sure its the exact same error. And when did it throw it? Evidently not when you were creating that rule? Whereas, the error from before happened when you were creating the rule, right?
I can't answer that, but I do see that the ZigBee spec for the Relative Humidity Measurement Cluster supports 0.01% precision. From the ZigBee Cluster Library User Guide:
The structure definition for the Relative Humidity Measurement cluster (server) is:
typedef struct {
zuint16 u16MeasuredValue;
etc.,
where: u16MeasuredValue is a mandatory attribute representing the measured relatively humidity as a percentage in steps of 0.01%, as follows: u16MeasuredValue = 100 x relative humidity percentage
So, for example, 0x197C represents a relative humidity measurement of 65.24%.
I tried a test with the full method for generating Relative Humidity events found in the GitHub/Hubitat example Environmental Sensor driver code:
private getHumidityResult(hex){
def valueRaw = hexStrToUnsignedInt(hex)
def value = valueRaw / 100
def name = "humidity"
def unit = "%"
def descriptionText = "${device.displayName} ${name} is ${value}${unit}"
if (txtEnable) log.info "${descriptionText}"
sendEvent(name: name,value: value,descriptionText: descriptionText,unit: unit)
}
With that above example hex value of 0197 (or any hex value in the valid range of 0x0000 to 0x2710), a decimal value is indeed passed on to the generated event:
Indeed, the error from before caused the first instance of the error.
However, it does appear that RM is storing some information about the error which cannot be rectified (edited). Apparently, the only means of rectification is to remove the entire rule, and start again from scratch.
That's not very user friendly.
Hey, it's a bug. Bugs are not user friendly. We do our best to fix them once they are identified. The bug you found that allowed 70.0 has already been fixed, and will be in the next release. Thanks for reporting it.
