Ok, I'm aware of "after" operator, and in this case didn't want to use "between 13:00 and 13:05"

Consider the following example:

This is always true, which is not always evident (e.g. when used within Reactions or there are a lot of other conditions and you miss this one being "green").

Manual says there's no "at" operator, but I was thinking could this behaviour be changed so that when date/time is specified like in my example, it would behave like "at" instead of being always true?

latest-amd64

We already had a brief discussion about this via DM, but here goes again. I'm using build 25325 on Docker and noticed that a date/time condition is not working properly when a time interval crosses midnight (e.g. "from 23:00 until 01:00").

@toggledbits now this other case "triggered", so I'll send you rules as JSON and logs with some explanations

@toggledbits understood. The other case I still have is two rules having partly the same logic, but those identical bits are not behaving in the same way. Just started logging those rules and the next time they behave differently I’ll send you logs along with description what was expected to happen.

@toggledbits just sent that rule as a JSON, and updated to 25292 which did not address this issue of scrolling a long rule

@toggledbits I have a couple of "known" issues left with my rules. One is where I have a VERY long rule, a lot of conditions, but even more stuff in reactions, especially groups. It works, but when editing this rule, and trying to scroll down to reactions, I'm constantly taken back to the beginning. After a while (maybe as the whole content is loaded or something?) I'm able to scroll up or down without UI "resisting" (for the lack of better word or description). Not a bug, but more of a usability issue.

I guess I could or should divide the contents to one or two other rules, so that there wouldn't be one long rule as it seems to cause problems. But if you want to look at this, I could send you a JSON file of the rule so that you get a better idea?

Okay, can confirm that now this problematic rule updates correctly!

@toggledbits will report shortly (price_array updates at midnight), but wow, Set Rules widget is now lightning fast!

@toggledbits no, it has been around for a while. Has been renamed though

@toggledbits using your workaround (clone), but the problem remains with variables not updating correctly as price_array changes, e.g. sum variables do not update. If I (temporarily) modify one of the variables (e.g. change rounding & save), then all the rest changes correctly.

With this particular rule I cannot use Script Action workaround to force updates as I'm using those sum variables as triggers.

@toggledbits I was using a mobile hotspot when observing this behaviour, and now that I'm back on a high speed connection, delay is 1-2 seconds after browser hard refresh, so nothing to worry about.

@toggledbits thanks for fixing! Another more cosmetic issue is that there seems to be a quite long delay until "Set Rules" widget gets populated? Using Chrome v141

@toggledbits updated to this build, and can report one bug (although it might have been present earlier, but I only noticed this behaviour with this build).

I have a rule with following local variables:

If I click "play" (run) in edit mode on any of these local expressions, I get a runtime error "request failed" (with no other information). Also, if MSR is restarted and expressions get re-evaluated, some of these will be incorrect. E.g. "night_prices" should be first 24 entries of "price_array", but instead it contains first 24 entries of of "sorted_array". Likewise "evening_prices" contains last entries of "sorted_array" when it should have last entries of "price_array".

"highs_array" seems to be okay for some reason.

If you want to test this, I've attached "price_array" below:

[0.125,0.124,0.122,0.062,0.001,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0.001,0.099,0.123,0.125,0.15,0.309,0.29,0.269,0.271,0.428,0.5,1.166,2.073,3.399,4.84,5,6.481,7.292,7.789,8.893,8.915,9.567,9.948,9.027,7.044,8.687,8.001,7.315,6.658,7.902,6.843,6.36,6.098,6.595,6.061,5.838,5.639,6.194,6.036,5.814,5.842,5.378,5.804,6.632,7.254,5.613,6.531,7.357,8.272,6.046,7.089,8.029,10.411,7.843,9.741,13.613,15.002,13.305,16.292,16.651,17.314,15,15.686,15.592,14.559,13.656,13.081,10.844,9.922,11.692,9.631,9.201,8.912,10.17,9.889,9.28,8.79]

@toggledbits I also did a hard-refresh in addition to MSR restart. But as said, by deleting that condition and adding it again, now the rule is back to normal ...for now.

@toggledbits didn't see any errors or other interesting events in the logs. And yes, my intention is to use "NOT AND", in order to trigger the rule when variable is no longer updated and then send a notification about it.

There's a price value which is hourly updated from Home Assistant, and it's perfectly normal that the next value is the same as one before, so I cannot directly test for changes to that price value, but I'm checking metadata for last_modified to see if there has been an update.

Don't blame you for being confused, expression and condition do indeed have the same value and do update in synchronization, still the "changes from any to any" -condition won't work as expected in rule 2. Now that I deleted this condition, saved the rule, and added the same condition back, I was able to normalize the rule's state. Let's see how long it will function.

With previous builds these rules have worked fine.

@toggledbits I have tested the latest build (25278), and otherwise everything seems to work normally but having a strange variable issue with one rule.

I'm using practically the same structure in two rules, where one works but the other doesn't. Details below.

Rule 1: (ok)

Rule 2: (not ok)

(Timestamps for rules 1 & 2 are different as screenshots have been taken hours apart, so that can be ignored)

Tried resetting rule 2 and restarting MSR—neither made a difference. "lastModified" variable clearly changes, but for some reason MSR does not detect that. I can send you logs if needed.

@toggledbits okay, maybe my test case wasn't the best possible... what about that UI issue (a long array)?