Home Assistant 2025.11.2 and latest-25315

[tunnus]

@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

[CatmanV2]

Fabulous effort here by @toggledbits We owe a great deal!

C

[toggledbits]

@tunnus I don't blame you for hesitating at all. It's a potential upheaval. I think it will mostly affect people that have unwittingly taken advantage of specific quirks of the old behavior that now are gone, and hopefully those are few. I have a test environment, but my home is always the final boss of QA.

@CatmanV2 said in [Reactor] Variables not updating correctly in latest-25201-2aa18550:

Fabulous effort here by @toggledbits We owe a great deal!

I can't take any bows for this. This is fixing past mistakes, decisions I've made (or side-effects that I just accepted) that I wish I hadn't, and now fixing it means potentially putting many in the community through some pain. Nothing about that feels good, but if I don't fix this now, it will continue to be thorn in everyone's side and I find that even less acceptable. This, too, shall pass.

[CatmanV2]

I'd not agree. You were not obliged to build it in the first place!

C

[toggledbits]

Build 25264 now out, again, docker 64-bit only, for the limited audience of this topic right now. A bunch of edge cases figured out and a lot of code cleanup.

[tunnus]

@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]

This is a coming functionality change. I recommend commenting retention out. I am considering allowing both as long as they make sense together (i.e. retention is equal to or greater than that required by the configured interval and depth), and that may be done before the final release.

[tunnus]

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

Will continue testing...

[tunnus]

@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]

If your intention is to guard against request/response failures from the weather API, that would be better written something more like this:

isnull(getEntity( "weather>xxxxx" )?.attributes?.wx?.temperature) ?
    VirtualTemp : 
    round(getEntity( "weather>xxxxx" ).attributes.wx.temperature, 1)) 

The ?. operator guards against its left side operand resolving to null.

Shorter version:

local d=getEntity( "weather>xxxxx" )?.attributes?.wx?.temperature,
isnull(d) ? VirtualTemp : round(d, 1)

And yes, the change in the variable approach exposes something that OWMWeatherController should be doing that it's not (and I've spotted and fixed that for a future build). If you're using another weather source, likely same/similar.

[therealdb]

@toggledbits I have a couple of routines (previously working OK) that are checking for various things based on the hour we're in.

The variable code is like this one:

d = dateparts(),
(d.hour >= 20 && d.hour <= 23)

I remember we've been told that this would not work in previous builds (but it did), but it's not really working now. It was false at 20 (the rule is triggered every 30 minutes when dark), and after I pressed play it went to true. I changed it with a script action and it's working now. But I'm reporting as an edge case, because I'm not sure it is supposed to work with the new behavior. Nothing else to report ATM. Thanks for the effort!

[toggledbits]

Build 25272 now up for docker 64-bit only once again. A good bit of cleanup again.

@therealdb wrote:

But I'm reporting as an edge case, because I'm not sure it is supposed to work with the new behavior.

I'm keeping it this way (not working) for the moment, because it keeps it completely consistent with how Global variables work. But I see why you'd want to do what you did, and I think I can make it work... give me a day or two...

[tunnus]

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

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

[tunnus]

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]

The error here is that data isn't an object, so you can't dereference through it. If you look at your blob, you've set data to a number (0.10595), and the error is telling you that you can't dereference through a number like an object. The coalesce operator isn't going to apply here, because data is just the wrong type. I assert that your test case is broken and testing something you are never actually going to encounter in real life. Well-written APIs, for example, don't do things like this, at least, not without other clues (e.g. a type value in the response to tell you what kind of data is in data, so that you can easily know how to handle it).

[tunnus]

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

[toggledbits]

@tunnus already fixed for next build. Thanks for reporting!

[toggledbits]

Build 25278 now available, again docker 64-bit only, and only for the folks testing variables/expressions in this thread. Please read this for summary of behavior for global and rule-based variables in this build.

[therealdb]

@toggledbits is alarm() a new thing? What's the best example to understand its use? IE: A global variable named christmas_time, that will be updated every hour/day with dateparts()? Thanks.

[Crille]

I think it's brilliant. My best example is to check if a getEntity() is not updated in X minutes by comparing time() with value.last_modified but if the entity isn't updated the expression will not evaluate because nothing changed.
I'm now using other entities like reactor_system.reactor_uptime for 1 minute interval checking but with the new alarm() I believe I can skip that and set any interval suitable for each expression.