A condition of between two times doesn't work because RM seems to be using date times now. The default date (which is presumably ignored) is all 9's and RM is expecting a month between 1 and 12, not 99.
Integers and floats can't be compared. To get a dimmer level you have to use an integer and you can't later compare that with a temperature. Oddly if you create the variable first as an integer and later remove and re-add the variable as a decimal, it works.
I will look into the between two times bug.
Could you provide a screenshot of the "integers and floats" issue, I don't understand the context.
Please show a screenshot of this. I need to see what you're doing, as these conditions work for me.
I'm sorry to be dense, but I need you to explain where the failure is. And show me rather specifically.
Same for you, I'm dense. Please be specific and show me the specific problem you have. The only one I see is "null(null)" UI glitch.
The date issue is probably just me being retarded. I created a variable for a date time and left the date blank because I only needed the time. Between two times though looks at the variable's date.
It might take me a bit to get a screenshot because when I do the between two times with the date time variable and no date it completely borks the rule and I have to delete it and start over.
Can't you just show me the specific Between Two Times? Is it two variables? One, etc.
That's the error
This is probably the difference between DST (now) and no DST on that date in 1970.
This may be related:
Whenever I compare a decimal variable to a decimal device attribute , the comparison fails:
Expected behavior
The values of both the custom attribute and variable will show, and the comparison will pass or fail depending on the respective values.
Note
If you compare the variable above with the temperature using the sensor value, everything will work; if you get the temperature as a custom attribute, however, this is when it fails. I have the same rule in 4.1 which is working as expected.
Are you sure that attribute is actually a decimal value as opposed to a string? Most attributes come back as strings, so comparing an actual decimal value and a string that looks like a decimal value will fail.
I just tested a custom attribute that I know to return a decimal value with a decimal variable, and but for a UI glitch it works as expected. The UI glitch is that it didn't display the present value of the variable. But the test works correctly.
I think what you're showing is the UI glitch (now fixed for next release). By that I mean
= Feels()
Where it should be showing the current value of the Feels variable.
The bugs described above have been tracked down and fixed: Between Two Times and Comparing Number and Decimal variables. These fixes will be in the next hotfix release.
@bravenel the values were definitely decimal, but after reading your message I went back and did some more testing and it is definitely the UI glitch, as the comparison works -- only the UI did not show it. I could have sworn that the comparison failed in a similar situation with the same driver yesterday when I was porting an older rule, but maybe it was past my bed time and I wasn't fully there.
Thanks for the quick response.
Zuhair.
Download the Hubitat app
