@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

@toggledbits, since I don't have a separate testing environment, I've been hesitant to update to this build. Still trying to build up the nerve to take the plunge

@therealdb & @toggledbits, below you can find my simple test case for this case. At least in my setup I can consistently reproduce this behaviour. (Still) using build 25208.

1. First, make sure you have some device/entity which updates often (not strictly necessary, but it's faster to see the results & differences).
2. Then put "target" variable immediately after "source", and "expressionlessVariable" should be the last one
3. Now "target" should follow/change as "source" changes
4. Next, swap "target" & "expressionlessVariable" (as seen in the image). Save.
5. Now "target" ceases to update

@therealdb could you test this if you could get your original rules (variables) to work just by rearranging local expressions? My hypothesis being that expressionless variables should be last in the list

@toggledbits have you had time to look at this? I suspect there’s a bug in evaluating local variables when expressionless variables are not last items in the list

@toggledbits I’m not using script action currently, and those screenshots were from a rule that uses set variable action.

But could you test my finding? Even rule triggers are not relevant when reproducing this finding. Just put a variable referencing an entity which frequently changes as a first one. Then make expressionless variable second, and as a third one make some kind of expression which uses first variable and does some calculation with it. Observe what happens and then swap second and third line and again watch what happens.

@toggledbits that wasn’t what I was trying to convey here. Let’s forget script action for a moment as it has no relevance for my finding.

What I’m trying to say here is that by merely changing the order of variables (and to be clear, that setup has worked before), my rules are working again. Somehow new builds do not like if expressionless variables are in the middle of regular ones. If they are last in line, all is well. Sounds crazy, but please test.

Some strange results happened while I was experimenting with script action. I noticed that the order of local variables had an effect whether those variables did update or not.

If I had e.g. the following order:

"peak_power" did not update. But if I switched places of "ok_to_reset" and "peak_power", "peak_power" started to update in real-time:

@toggledbits ok, I'll have to try script action. Still, as @therealdb stated, I'm also sure the "old style" used to work with pre-252xx builds.

@toggledbits "success" variable cannot be other than true or false, that I know.

But is it so that every time a rule is triggered, its local variables are evaluated (or should be evaluated) at least once?

Also, you wrote earlier: "If there's already a pending request for re-evaluation queued, new requests are ignored. This is all to prevent infinite loops in rule evaluations where rules manipulate devices and rule-based variables in Reactions that are also part of the rule's dependencies"

I was wondering if this could happen in cases where re-evaluation is queued but somehow gets stuck, and because new requests are ignored, updates won't occur?

@toggledbits, some extra information that I hope will help solve this. I've noticed a few other instances where variables aren't updating. These happen to be Telegram notifications, although I don't think Telegram itself is the issue—it's just that I tend to notice notifications more easily than changes in the UI.

In all cases, a common denominator is that local variables (in my case, 'msg') that include other local or global variables also contain "if/else" and/or "case" statements.

Examples below:

msg = 
solar_last_day == "ERROR" ? "Error retrieving solar stats" : (solar_last_day > 1 ? "Daily solar stats are ready, total " + round(solar_last_day, 1) + " kWh, peak " + peak_array[0] + " W" + " @" + peak_array[1] : "NA")


msg =
case
  when success == true: "Export limit activated, sell price " + round(g_NordpoolCurrentPriceSellReal, 2) + " c/kWh (VAT 0%-mgin), grid balance " + round(g_FronPowerSum, 0) + " W" 
  when success == false: "Export limit could not be activated?"
  else "Setting export limit failed"
end

I'm not sure if it's related, but there was a recent bug involving global expressions not updating when certain functions were used (fixed in build 25082)

@toggledbits I did a very similar testing arrangement and got the same results as you, i.e. working fine. I guess I have to monitor this more closely and if this update problem happens again, find a way to reproduce it consistently.

One notable difference between my production expression and the test expression is that the production one is a lot more complicated:

@therealdb I noticed a similar behaviour with build 25208, although the issue might have been present also in the earlier (25201) build.

In essence I have a rule with a global variable correctly triggering when it has a certain value, but in reactions it has a Telegram notification using a local variable as message (like this: ${{ msg }}). And this local variable "msg" is using the same global variable that triggered the rule, but its value is something totally different, i.e. seems that it's not updating.

I'm also sure this rule was working fine before, with variables correctly updating.

As there are statements about compatibility for home assistant versions in MSR new version announcements (e.g. "HassController: Bless Hass to 2025.7.3"), I thought it would be good idea to track other controllers as well.

As an example, I can confirm that build "latest-25208-c53e8513" works with Hubitat Elevation C-8 platform version 2.4.2.134 using Maker API.

Updates: (the latest versions first in the list)

• OK: build "latest-25264-2fbe9217" with Hubitat C-8 platform v. 2.4.3.123