RM 5.0 Bugs - Between Two Times, Comparing Numbers & Decimals

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.

While porting the following two RM4.x rule to RM5:

I got several DateTime related errors like month initialized to 99 and null variables:

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.

I have two TimeDate local variables defined (TIME_OFF and TIME_ON).
If I try to create a trigger based on a specific time -> variable time I get the null(null) "glitch".

Here's the rule I'm trying to migrate

I have two TimeDate local variables defined (TIME_OFF and TIME_ON).
If I try to create an action based on a specific time -> between two times I always get the 99 "glitch":

That's the error

I found another issue while testing. If I add a date...


RM sets it incorrectly
2021-07-17_3

This is probably the difference between DST (now) and no DST on that date in 1970.

@bravenel

This may be related:
Whenever I compare a decimal variable to a decimal device attribute , the comparison fails:

  1. Create a rule and call it anything you like
  2. Define a decimal variable -- let's call it feelsLikeTemperature
  3. Define a condition comparing the "temperature" custom attribute of the openweather driver with the variable created above

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.


Observed behavior
The value of the variable is always read as null (see screenshot).

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.

1 Like

@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.

This is still present in 2.2.8.138

Still not possible to define a trigger based on a "Certain Time" local variable:

Download the Hubitat app