Maybe so, but that is a bastardized colloquialism. And I don't know for sure if decimal is a wrapper for double, or float, but I digress.
In groovy the NUMBER type is a wrapper class for all/any of: byte, short, integer, long, float, and double.
If they meant integer, they should have just used integer - that is a base data type. They chose to make it easy from a coding perspective and just use NUMBER, which I can understand, but then they did not document anywhere what data type individual attributes are - even though they assume/require them to be specific base types elsewhere.
Anyway, it is what it is. This is just something we will have to live with as developers at this point.
Regardless, I did setup a virtual omni sensor, and I am not seeing this same issue if setting it with a decimal from the device detail page. I do see the error over Maker API regardless wehat I send though.
Don't send humidity as a decimal, convert it to an integer
and/or
Convert the string to a double/float before sending it to the node if you really want to keep the decimal.
You do not get an error if you send:
Decimal value as a decimal (not inside a string)
Integer value
String that contains an integer value
As the Virtual Omni Sensor will accept a decimal as an argument to setRelativeHumidity if done locally, this seems like a driver bug @bravenel . Just my opinion, yours may differ - and that's OK. No big deal in the end, as it is easily worked around.
Oh yeah, I remember that now. I forgot about that completely, but that's why I was specifically converting the payload to a number. Also wanted to round it down to 2 decimal places.
Would be cleaner, particularly since decimal is not appropriate for use with attributes (ENUM, STRING, DYNAMIC_ENUM, JSON_OBJECT, NUMBER, DATE, VECTOR3), but for preferences and input values decimal can be used ( along with: bool, date, decimal, email, enum, number, password, time, text )
You aren't passing it a number. You're passing it a string, as it clearly states in the error message. AFAIK, Virtual Omni Sensor does not care about integer vs decimal number value, although as discussed ad nauseam, some apps do.
The driver does force the value to integer if a decimal is given (see below). But string? The attribute is NUMBER.
There have been no changes to Virtual Omni Sensor.
Fair enough. Just because it seems that the driver will cast a string with an integer in it without throwing an error doesn't mean that sending it a string in the first place was ok.
Evidently, the driver throws an error if you pass it a string for a number, per OP above. I think all drivers do this. Where do you get the idea that anything will "cast a string" to a number? As far as I know this has never been the case.
I don't know what is going on with the OP situation reported above. Maker API does look up that command parameter attribute, and does convert a string to a number, either integer or double. So that's where the conversion is taking place, not the platform.
Dunno. I see the same error as him when passing a decimal in a string through maker api though.
I had to fabricate an example to do it, though, I hadn't seen that in "real use" as I don't typically pass numbers as strings. It may always have worked this way - never tried it before.
I think this code has worked for everyone for as long as Maker API has been available, pretty sure it's never changed. So I honestly don't know what would cause the error he has with the device. Curious...
Both it.isInteger() and it.isDouble() would have to fail for it to send a string.
Mystery solved: The Virtual Omni Sensor driver is doing this, that is forcing an integer value, which in turn would make it barf on decimal value. And this is a recent change. Will change it back...
As far as I am aware, I was sending the correct data type - number or decimal. I wasnt sending a string. Although are you referring to integer, (which I was not sending)?.
Yes. Although it isn't documented (so how would any driver author know??) The system expects integers for some variables - humidity included.
I'm not faulting you, or any other driver author. But as a generic/blanket statement I always think it is better to send the expected type rather than relying on it being cast to the correct type by the system.
@JasonJoel Hoping you might be able to assist me. Here is the story. I have a new install of Node Red on my qnap and everything works perfect, no issues at all. A friend of my advised that it would be much better to use Node red thru Home Assistant. So I got HA up and running. I have Node Red, Influxdb and Grafana all up and running and everything seemed to be working. However, the only time I get info from Hubitat using this app is when I do a deploy. Any other time it just sits there. Any ideas on what I did wrong or what I am missing? I have my original setup identical and that works, but the new does not.
