This looks like a job for a finite state machine.

An alternate way to tackle this may be to have a state local variable that's just a number/counter that increments when the scene controller button is pushed... Set Variable state = ${{ ( ( state ?#0 } + 1 ) % 3 }}. This will make state cycle through the values 0, 1, 2, 0, 1, 2...

Then the reaction has these groups:

• When state == 0: turn both fans off
• When state == 1: turn 1 on, 2 off
• When state == 2: turn 1 off, 2 on

It's easy to add a fourth state if you want the option of having both fans on at the same time. I'll leave the changes as an exercise for readers. DM if you need a hint.

This is not something i'm going to entertain at the moment. It seems like a very specialized, one-off request, and the implementation has a lot of consequences throughout the system. I recommend starting and stopping using the currently available method (i.e. stopping the process itself). It's also relatively easy to enable and disable rules in the UI, so when working on isolated systems (like a heating/AC unit), you can temporarily disable just those rules. You can also force them to a set or reset state to keep them at bay, and put them back in auto later.

It works as I would predict.

@CatmanV2 said in Expose MSR entities:

@toggledbits this is precisely what it is, yes

Whew. OK. Then yes, this is the way to go.

@CatmanV2 said in Expose MSR entities:

Currently I am using the owntracks_sensor for tracking phones being in region in HA and it works great.

I'm reading this as "it's coming from HA."

Is it actually an MQTT entity created using the owntracks_in_region template of MQTTController? Because there's nothing natively called owntracks_sensor in Reactor.

I am still completely confused. Yes, Reactor will publish the sensor from HA. I use that myself. But since the Reactor sensor entity comes from HA, why would want to publish Reactor's entity back to HA then?

I'll say again, local variables are not processed/evaluated in the same way as global variables. Local variables are only evaluated when the Rule to which they belong is being evaluated (i.e. its triggers are being checked). They are not evaluated when a dependent local variable is changed. When the Rule is evaluated, its local variables, if any, are evaluated before the triggers, and yes, they are evaluated in the order in which they are defined. That is known.

Combine this with using a Set Variable action... if you don't check the "Force re-evaluation" checkbox, any other local variables that use the variable being set will not be updated until the Rule is next evaluated. If you check the box, it forces a Rule evaluation, and it is the second evaluation that will update the dependent variables.

The Script Action is absolutely relevant in your case, at least from what you've posted, because you apparently still had local variables that are dependent on the local variable that the script was changing, and that was not consistent with my recommendation. The script will not cause the dependent variables to be updated, because there is no "Force re-evaluation" option for the script, and local variables are not dependency-scanned/triggered, as I said above. That means your script action will change the local variable ok_to_reset, but that won't make peak_power change immediately after. That is why I recommended that you make all local variables expressionless when using the Script Action, and do all of the work in the script, none of the work in the local variables' expressions.

None of this is new. And again, no changes have been made to how variables (global or local) in any of these recent builds. The earlier changes you mentioned to make isRuleSet() and isRuleEnabled() trigger with the rules they reference (build 25082 -- a long time ago) was a change to the implementation of those functions themselves , but was not in any way a change to the mechanism that handles changes in global expressions.

@CatmanV2 said in Expose MSR entities:

Apologies if the ask is not clear/

Yeah, sorry. It's not at all clear to me what you're asking here. I'm reading "I have an owntracks_sensor in Home Assistant... is there any way to expose that sensor (which comes from Home Assistant) to Home Assistant trivially?" Uh... what?

Post your script. Based on the instructions given, your local variables should be expressionless, so that seems wrong and I want to see what your script is trying to do.

I can tell you right now, if ok_to_reset is expressionless and you are resetting it in the Script Action script, and expecting peak_power to see the updated value, it won't work.

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

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?

Well, they won't get stuck, but there is no guaranteed order to the re-evaluation. Other things waiting to execute can run before the re-evaluation happens, including things that could change the global variables or entity attributes on which the first Rule depends.

Here's something to try (it's the @therealdb solution he mentioned):

1. Make msg an expressionless local variable.
2. Before your notification, use a Set Variable or Script Action to compute the value of msg that you want to send in the notification.

Would look something like this:

...or this, using a Script Action...

I personally prefer the Script Action because you can set several variables at once in the script, if that's what you need, and the syntax looks cleaner (you don't have to use the ${{ }} substitution.

Basically it sounds like you just want Reactor to stop, so why not just stop it?

I'd need a full picture of this... every variable and rule involved. This is a very complex area to look at.

Again, the key rule to understand here, is that the local variables in a Rule do not update every time a global or other local they refer to changes -- they only update when the Rule has been marked for evaluation. The recomputation of the local variable values occurs before trigger conditions are evaluated, and only then. That is very different from the way global variables are handled.

Also in your second example, the use of "==" is a "loose" comparison. The use of "===" is tighter and matches type. In your example, if success is 0 (numeric), that will satisfy the test success == false -- that's true because numeric 0 will cast to boolean false, so they are logically equal, although not exactly equal. That alone would explain unexpected results, if the values of success can be other than true or false.

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

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

You know what to do (i.e. what I need to see). I can't do anything from just a post like this.

My simple test case:

1. I have a global expression/variable testVar (expressionless) with a numeric value assigned.
2. I have a rule that triggers on testVar changing, and sends me a notification in its SET Reaction (shown below).
3. I have a Reaction that I can run manually to increment testVar by 1 using a Set Variable action. This triggers the rule.

This works as expected: when the Reaction is run, testVar is incremented by 1. The change is detected by the rule, which updates its localtest variable and then uses that in a notification, which displays the correct value.

To be clear here, the Rule triggers on the global variable changing, not the local variable.

TTS announcements with Home Assistant Voice are about as easy as they can be (once you have your HAV unit configured).

Via the Home Assistant Developer Tools UI:

Choose the announce action, and then the HAV "satellite" unit on which to play the announcement. Enter the text, and go!

Via Reactor:

Pretty much the same... select the HAV satellite's entity, and the x_hass_assist_satellite.announce action. Supply the message text and go:

In a Reaction, the entity, action, and parameters are the same.

Starting with the basics...

Via the Home Assistant Developer Tools UI:

Select the HAV device on which to play the media. Specify the URL to the media as the media_id. For most media played on HAV units, you'll want to select music as the media_type.

Via Reactor:

There will be an entity specifically for the HAV unit's media player. On that entity, run the x_hass_media_player.play_media action. Parameters are the same as those described above. The image below shows a direct run of the action from the Entities list; in a Reaction the action and parameters would be the same.

I got my HAV a couple of days ago. Out of the box, setup was actually pretty easy. I agree with others that watching videos isn't my favorite way to do that kind of thing, but there are written instructions behind the QR code they provide in the box.

It deemed my HA host system (NUC) insufficient to do speech-to-text/conversation locally, so I signed up for Home Assistant Cloud and set it up that way. I'll circle around to that again later and see if I can free myself from the cloud, but the small monthly or annual fee is within my sensibilities for ensuring high Wife Acceptability on functionality.

Lights on an off is easy. This is the most basic thing to get right, I guess, and it works great. With a few small tweaks to HassController (future build/release) I was able to get TTS output working very easily. Also playing media is pretty straightforward. It's also easy to control the brightness and color of the LED ring (maybe some future purpose for this will arise).

Most challenging so far was getting it to recognize a custom sentence. Actually, configuring the custom sentence was not really hard, but getting HA to do something other than speak "Intent does not exist" took some trial and error -- a classic HA trial of getting the right configuration magic into the right places, restarting untold numbers of times, while combing through inconsistent examples in the pages of their online documentation. Finally got it, although I swear my last attempt was the same as a half-dozen prior that didn't work. But I can finally say "Hey Jarvis, bark like a dog" and have it cause Reactor to reliably launch the play of an MP3 file on my living room Sonos SL1. Woof!

I also was able, from Reactor, to get it to speak a question, recognize a response from a list of expected responses, and store the response data in a Reactor variable. Seems useful, although I'm not yet sure how. That also took a little HassController modification (again, future release) to fully realize, and some tribal knowledge of how the HA API wants data structured for certain fields of that call. This isn't the kind of knowledge we normally encounter when calling HA services, so I'll write that up separately somewhere.

These minor successes are actually very encouraging. I think this thing is going to create a lot of opportunities.

Clearly there's a lot of context you haven't posted, so I really don't have enough to go on.

I can tell you that if a rule is in mid-evaluation, the re-evaluation of variables and triggers in the same rule won't happen instantly or more than once -- infinite loops have to be prevented. What will happen is that a request for re-evaluation will be queued for later, but it's not deterministic when that runs (except that it won't run before the current evaluation completes). 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.

And to be specific, the "Force re-evaluation" only queues a request to re-evaluate the rule's triggers and local variables at some point in the future. It does not instantly and immediately re-evaluate every dependent variable of the variable being set.

@tbully said in Gradually turn on lights.:

I'm having this same issue with a bare metal install. I assume this fix will be included in a future release? (No hurry. This is just a nice-to-have thing...)

The 25208 build released yesterday includes the fixes in the temporary containers built for @vezinpi and others on this thread.

Reactor build 25208

• Status page: fix an issue placing the widget adder tool the first time (i.e. on a new browser or after flushing cache/cookies).
• HTTP Request action now offers storage of the query response in "advanced form." This is a structure (object) that includes the response body as well as the response status, messages, and response headers. The simple form (store body or null) is the default and all existing HTTP Request actions will use the simple form response unless/until modified.
• Telegram notifications now support photo and video messages. To send a photo or video message, select the appropriate Message Format and place the URL or filename in the Message field. Telegram's limits for file type and size must be observed (refer to Telegram's documentation).
• HassController: Configuration for filter_entity now accepts regular expressions to match to entity IDs (i.e. it can now do pattern matching, not just match exact strings). Specify regular expressions in /regexp/flags form (e.g. /^update./i to match IDs that begin with update., case insensitive; flags are optional, and the only flag supported right now is i for case-insensitive matching).
• HassController will requery for service data if the lookup of service data from the startup query does not have the needed info. This can occur when an integration is not fully up and running when HA restarts -- HA will only report on services for fully running integrations at the time. The requery updates the service data for integrations that start later.
• HassController remove old entity mapping configuration that was preventing a mutable attribute (dimming.step) from being changed by the user permanently.
• Expressions: new geodist() extension function to compute Great Circle Distance between two points (presumably on Earth). See docs for details. Example: kilometers = geodist( lat1, lon1, lat2, lon2 )
• HassController: Bless Hass to 2025.7.3

No changes have been made to variable evaluation for some time. Definitely no changes for 25201.

In your raintripped variable, you make reference to badweather_trigger and badweather_lastevent, but the source for those isn't shown. If their values don't change (even if they are evaluated by some other mechanism), raintripped will not be updated. The use of time() does not generate any continuous evaluation, so this (raintripped) variable is entirely dependent on those other two variables changing value (not just being evaluated). Same applies to windtripped.

If you have been editing these, particularly the deep dependencies like debugmessage, you probably will need a restart to get a full deep dependency scan. Current versions of Reactor can't do a full-depth scan when you edit a variable and add dependencies in mid-run. So I recommend a restart after making changes when the dependencies may run deeper than one level.