Wow. That error has been around a while, and I'm surprised nobody noticed and reported it. It's actually a bug in lexpjs, the parser/executor for expressions... it's sorting the array in place rather than sorting a copy that it then returns. That's not consistent with its spec, and I can easily fix that and get it into the next build. That bug causes other expression values to be modified when they should not be (the effect is pretty obvious in the image, for example, the first price is not 0, so the first night_price should not be 0 either).

If you need to work around it, clone your array before sorting it:

sorted_array = sort( clone( price_array ), $2 - $1 )

I also added a little shortcut there for the sorting function. You don't specifically need to return +/-1 or 0, the sort will look at anything positive, negative, or zero, so simple subtraction can take the place of the more complex conditional expression.

The clone() should not be necessary in future builds.

Here's what it looks like for me now with the lexpjs fix in place (no clone() needed):

Thank you for including a copy of the source array in text form. That was super-helpful and a big time-saver.

Build 25285 now up for docker 64-bit only once again, and intended only for users on this thread. This will be the last development/test build before a general release.

I know you said you restarted Reactor, but humor me... do it again, AND hard-refresh your browser. Then see how the rule behaves.

Can you confirm that you intend your condition group to be "NOT AND". This is a bit confusing, because you are just showing your logic without explanation as to what you intend to do (not how you think it works, how you want it to work).

Also confusing is that the expression and the condition are showing the same value (so the condition seems to be up to date), modulo the reset delay, but I have no reference for time passed there.

Edit:

Also, always look at the logs when something doesn't work as expected. There may be a logged error there that will tell the story without hours of back-and-forth and research.

At the moment, I'm not able to reproduce this.

OK. He just posted 11.4.1 and things are looking better on docker.

About 20 hours ago, the author of zwave-js-ui posted build 11.4.0 of that product, and it contains an error and won't start (at all) under docker. The author is aware and working on a fix. In the meanwhile, stick with 11.3.1 or earlier.

Ref: Issue 4401

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

Looking forward to the bare metal release to try this out.

Shouldn't be too long, unless the group here finds something more, but I'm pretty satisfied with how it's working now. As long as a few others are as well, I'll feel better unleashing it on everyone.

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

If I replace interval with alarm(60) would that also start a new timer everytime meter updates or would I achieve the same behavior as now?

No, if you replace interval/getEntity()..reactor_uptime with alarm(60), you won't get a new timer. Next build, you will be able to call alarm(0) before alarm(60) (i.e. alarm(0), alarm(60), ...) and that will cancel any existing timer first, then start a new timer for 60 seconds. In 25278, there's no way to stop the existing timer.

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

A global variable named christmas_time, that will be updated every hour/day with dateparts()?

Yes. alarm() will do that.

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

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.

Clever! One side effect, though... getEntity() creates an entity dependency for the expression, so that when the entity changes, the expression is re-evaluated. When the expression is re-evaluated, the alarm() timer is not restarted if it is already running, the prior still-running timer is allowed to finish at its originally scheduled time. I'm guessing this may interfere with your intent — if you are using it to detect timeout, you probably want to push the clock out — but I can address that in the next build.

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.

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

Reactor's ZWaveJSController will take the first name it is given and that sticks until you rename it. If you rename it in Reactor, no amount of changing it in ZWave JS will change it in Reactor.

This is by design. It is possible, for example, to use entity names in getEntity() expressions. If Reactor just changed them on its own like HA, that would break those expressions.

By the way, HassController behaves the same way. If the name of a HA entity changes, the corresponding Reactor entity doesn't follow the change. You can see it in the extended attributes of the Reactor entity, but the Reactor entity itself retains the unmodified name.

Deleted entities are marked "dead" in Reactor and will be removed at a later time if they don't reappear. Reactor doesn't immediately remove entities just because the remote hub omits them. Some hubs may not fully enumerate all devices during startup, so removing an entity only to recreate it a few seconds/minutes/hours later would be troublesome. If you're impatient, you can purge dead entities by using the purge_dead_entities action on the Controller's system entity (give it small age limit, like one second; it only acts on entities that are already marked dead).

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).

@therealdb said in Strange behavior for MQTT templates using payload and attributes:

Never code in a hurry while doing 100 other things

Ummm... is there any other way?

Looking more deeply at your logic, I don't think it's going to work. Here's where I think you are:

The current value of button.since is {"event":"", "event_cnt":0}. I assume it got set this way from prior effort leading up to this point. Now, based on what you currently have configured...

When the topic shellies/shelly-gatebutton/input_event/0 arrives with event_cnt:2 in the payload, the first thing MQTTController is doing is setting value_sensor.value to 2. You can see that in the log snippet.

The next thing is it attempts to set button.since, but since your expression is set up so that button.since is only changed if if the value of value_sensor.value is different from payload.event_cnt, which it won't be, because it just set them to the same value. So the expression simply returns the current value of button.since and thus changes nothing.

See the problem now?

You have control over the order in which the attributes are processed for the topic/event.

Debug level 5 for MQTTController and log files are your friend.

That said, I'm suspicious of the operator precedence effect on your expression. Wrap a set of parens around the conditional of the ternary operator and try it again.

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...

@CatmanV2 said in The reaction stopped working (Google Nest max playing a video):

Tangentially did I miss 2025.9.4 getting blessed in MSR? I've been holding off

Generally, if 2025.9.0 or .1 is blessed, the remaining releases are going to contain only small tweaks and bug fixes, and will likely be OK to install (just ignore the warning alert). The biggest risk there is the first release (e.g. 202x.y.0) changing behavior that required me to adapt to in HassController, and a later minor release (e.g. 202x.y.2) addresses some error they made in that first cut and changes/fixes that behavior in a way that's now incompatible with the new HassController changes. Historically, that's pretty rare. The biggest risks are always the first of their monthly releases, where there are long lists of big behavior changes and usually many potentially breaking changes.

And yes, please keep the threads on-topic.

Logs will definitely be your friend right now. If HA is returning an error on a request, the detail of that error is logged, along with the request that was sent to HA and the full response from HA. There are rules for fields that HA doesn't publish in its service data APIs, and that can vary by device and even firmware, so sometimes, you just have to "go low" to figure out how to talk to them.

Odds are there's something logged. This is why I always say, go look at the log files when something isn't working. When you find it, post with context, don't just post the one or two line error message.

@gwp1 in your case I would also like to see posted the attributes of the new device (using the Copy Attributes button, not a screen shot).

I'll be away all weekend, unfortunately, so this won't get more attention until Monday.