I have a rule with a repeating action every 10 minutes. Each cycle, this rule sets a global variable with a message and calls another rule to send a push notification with that message.
In the notification rule, it has [%time%] %varmsg%. It works, but the time is only correct on the first call from the repeating rule. Each message after that has the time from the first call.
The built-in %time% variable represents the time of the last trigger event, not necessarily the current hub time. Since you have a repeat in your actions that are presumably set off by just one (already passed) trigger, this sounds like the expected behavior to me.
If you do want to print the current time, you can save that to your own variable and then use that instead. Here's an example with a local variable of time "Time" named currTime:
Thanks for the replies. I will try current time variables and using %now%, didn't know that was a thing. Won't be able to test until tomorrow, I will let you know if it works.
Wasn't sure if %now% gave a human-friendly date or Unix time like Hubitat's Groovy method with a similar name does, but turns out, it's human-friendly. So, I agree that this should work, too!
[EDIT: Actually, there are options for the display; see others' discussion below for more!]
You can choose how you want %now% displayed as well.
When you pick it in a notification for example, in one of the screens, not sure which one, you will see an option to configure in what format it is displayed.
Edit: Iām wrong. I suspect that overloading causes the conversions. I use %now% now() in rule arithmetic to measure elapsed time, and it appears to be Unix time (Seconds with millisecond resolution) when I look at the local variables (decimal) in the rule.