[Reactor] Variables not updating correctly in latest-25201-2aa18550

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

[toggledbits]

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

[Crille]

My current simple use case does not have to be exactly X minutes.

do
interval = getEntity( "reactor_system>system" ).attributes.reactor_system.reactor_uptime,
meter = getEntity( "mosquitto-mqtt>smartmeter" ),
(time() - meter.attribute_meta.x_uptime.value.last_modified) > 300000 ? bool(true) : bool(false)
done

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?

[toggledbits]

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

[Crille]

Great, thank you! Looking forward to the bare metal release to try this out.

[toggledbits]

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

[tunnus]

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

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.

[tunnus]

@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 know you said you restarted Reactor, but humor me... do it again, AND hard-refresh your browser. Then see how the rule behaves.

[tunnus]

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

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.

[tunnus]

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

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.

[tunnus]

@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