Rule 5 issue with offset to DateTime

I'm trying to port over a 4.1 rule over to 5 where I had used a negative number in adding an offset to a time variable. That had worked in 4, but it now only accepts numbers, not the + or - sign. Am I missing something?

A rule in Rule 5.0 exactly like your second screenshot works for me with a local DateTime variable I created in that rule. It should be noted that I did have to set a date and time on this variable before the plus/minus operation worked; there was an error in the logs otherwise (guessing this is intentional, unless it's supposed to supply a default date like today--it isn't). You might try checking the logs regardless to see if you see anything unusual.

If you just mean the UI itself, it (as expected since I wrote this rule) let me put in a "-" sign:

If yours isn't, I'm not sure why; maybe see if a different browser works?

1 Like

This is a bug. Thanks.

What @bertabcd1234 said will work, but it should allow a negative value for offset the way you are doing it.

5 Likes

Another issue I ran across with Rule 5 and variables. 1st screen shows the rule and the variable's value which is a time and date. When I run the rule, the variable now becomes a "bad time" = the 2nd & 3rd screens. My guess is it has to do with sunrise/sunset (where it fails) while a time variable will work fine. One interesting note is if I go into to modify the variable manually, it shows the correct time so it was properly assigned; I just can't get the value.



Looks like another bug for me to dig into. DateTime is painful in software.

1 Like

I was doing it as an offset to a variable assignment rather than a time offset - and where I did it (below) will not allow a minus sign where it used to. Your method may indeed be the workaround I need for that issue - Thanks!

Beat it into submission

I tried to narrow it down - I think its just sunrise and sunset. All the new time variables work fine as long as they are populated with both a time and a date. Could that be the issue with sunrise/set - it never had a date before??

Sorry - perhaps another with local variables rather than global. I made a test rule using RM5 to assign a local variable to the value of a global - but it doesn't seem to work. The local changes but not to anything I did??
Here's before I ran the rule

then after and the log entry

This bug was found, and will be in the hotfix release.

There were some separate issues with local variables and DateTime, also fixed. So please revisit these after the hotfix comes out.

4 Likes

I'm now running 2.2.8.141 and I'm still having an issue with time variables in Rule 5.0 - it looks like a local timedate variable will not get assigned, it just takes and keeps the current hub time.

Rule before running:

Rule after running:

Log Entries:

Found and fixed... Thanks.

1 Like

It looks like sunrise and sunset in Rule Machine Legacy now come back as bad time values - started with 2.2.8.141. Please let me know if you need screenshots

Yes, there are too many contexts. Please show a screenshot to establish what the context is.

Again, this is under Rule Machine Legacy. Here are the global variables used (I use one in the rule) -

Here's the rule where I assign it to sunrise -

And here is the log file showing the errors -

A similar thing happens with sunset

OK, we made a change that evidently breaks this. I will revert that change for the next build. BTW, there is no %sunrise% unless you have a variable of that name.

1 Like

Download the Hubitat app