@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)?

Testing build 25272, and although the following findings may not be specific to this build, I'm reporting via this thread.

First, I noticed that if you have a long array in local expressions, UI is horizontally (over)stretched when viewing the rule (does not happen in edit mode). See below.

Secondly (and this can be user error), I was experimenting with failure handling and got the following:

The expression "isnull(blob?.data?.PriceWithTax) ? \"ERROR\" : blob.data.PriceWithTax" in variable "hourPriceBackup" of rule "Get prices" (rule-m0bb80xn) failed evaluation
ReferenceError: Invalid scope in reference to member PriceWithTax of (number)0.10595
Last 20:55:07; this alert has repeated 2 times.

(PriceWithTax was intentionally left out from the response to cause error)

And below the actual expression:

What would be correct way to guard against this?

@toggledbits also using similar variables as @therealdb, so nice that there will be a "fix"

prevHour = dateparts(time()).hour - 1
currentHour = dateparts(time()).hour

@toggledbits, now getting the following error which I haven't seen with earlier (official) builds. To be clear, build in use is 25264.

The global expression "VirtualTemp" isnull(getEntity( "weather>xxxxx" ).attributes.wx.temperature) ? VirtualTemp : round(getEntity( "weather>xxxxx" ).attributes.wx.temperature, 1)) could not be evaluated
Invalid scope in reference to member temperature of (object)null
Last 20:24:18; this alert has repeated 42 times.

(location redacted)

The above is actually an attempt to fix the situation (which did not help, as I'm getting these "invalid scope" errors), originally I had the following global expression:

VirtualTemp = round(getEntity( "weather>xxxx" ).attributes.wx.temperature, 1)

I'm wondering if this situation has been active already earlier, but maybe some change in this (experimental) build has made it visible?

Note that I'm not seeing these null values in the UI, e.g. as of now, in entities, wx.temperature has a value of "8.560000000000002" (rounded to 8.6 in global expressions)

@toggledbits configuration changed, no more errors. The bug I was experiencing (described in post #23) is also gone

Will continue testing...

@toggledbits, I bit the bullet and tried this build, but getting the following errors on UI:

Unable to configure time series "temperature_sensor.value" on "virtual7b": either 'depth' or 'retention' should be specified (but not both)
Controller: VirtualEntityController#virtual
Last 12:35:54


Unable to configure time series "value_sensor.value" on "virtual7": either 'depth' or 'retention' should be specified (but not both)
Controller: VirtualEntityController#virtual
Last 12:35:54


Unable to configure time series "temperature_sensor.value" on "virtual6": either 'depth' or 'retention' should be specified (but not both)
Controller: VirtualEntityController#virtual
Last 12:35:54


Unable to configure time series "temperature_sensor.value" on "virtual5": either 'depth' or 'retention' should be specified (but not both)
Controller: VirtualEntityController#virtual
Last 12:35:54

Didn't change my configuration as manual still had examples where both are used. So is this a bug or has time series functionality changed?

Below a snippet from my reactor.yaml:

 id: virtual5
          name: "Nibe out temp"
          capabilities:
            temperature_sensor:
              attributes:
                value:
                  model: time series
                  entity: "hass>sensor_bt1_outdoor_temperature_40004"
                  attribute: "temperature_sensor.value"
                  interval: 5  # minutes
                  retention: 20  # minutes
                  aggregate: wa
                  depth: 4
                  precision: 1
                  weight:
                    - 0.50  # most recent sample, 50% weight
                    - 0.35  # 35%
                    - 0.10  # 10%
                    - 0.05  # 5% oldest sample of the four considered
          primary_attribute: temperature_sensor.value
          type: ValueSensor