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

@gwp1 said in Can't customize home page:

So I... wasn't... crazy?

Absolutely not. That's my role.

Great. Update to the latest container image and try again.

Is your VM Intel/AMD?

Yeah, that won't do it. Do you see a line that reads "Placing widget at" or "Moving widget-adder to" anywhere?

Hit F12 for the developer window, then click the Console tab. Any errors?

First, try just a hard refresh of the browser and go back to the Status page.

If that doesn't do it, there's a somewhat hidden "Clear Local Storage" link on the Tools page... hit that and then hard refresh and go back to Status.

I'm in. Let's see what we can get done with this, shall we?

I'm also looking at some other open source solutions that aren't HA-specific.

Have you done a hard refresh on the browser? If that's not it, check file permissions on your storage directory, and also check the logs to see if any errors are emitted when you change the attribute value and within the window of about two minutes after (allowing for the delayed-write strategy caching). The other likely issue is that your storage directory has issues and isn't properly saving the state data for the entity.

Edit: Well, I said:

There is no code that changes dimming.step other than the button you use on the UI.

And that's technically true, there's no code, but... seems there is a stray directive in the entity mapping data table hass_devices.yaml, which is specific to HassController, left over from wayyyyy long ago that should not be there today, and will do what you are observing. Simple fix. I'll roll a new docker image shortly.

Edit 2: Updated container is up and ready.

Yup, a lot going on here. ZWave and ZWave-JS produce values for brightness in the range 0-99. HA maps that into its 0-255 scale, so precision oddities are introduced there. HassController then attempts to scale HA's 0-255 into Reactor's 0-1, which introduces more precision oddities.

I've made an interim build with a handful of adjustments. It is published only for docker aarch64/arm64 (RPi 64-bit and similar) right now, because I don't have time to repackage the whole thing for all platforms right now (I'll be unavailable from 11th through 20th), and it's too risky. For others reading, I don't recommend going to this build unless you need this specific fix immediately.

OK. There are some rounding issues with JavaScript, and I think I can tune things up to work around them a little better. Stay tuned.

Also, tip: use the Copy Attributes button instead of screen-grabbing the attributes. Gives more data.

Sounds like you might have dimming.minimum on the entity set to 0.1? And what of dimming.maximum? Failing that, does the device itself have min/max set in its Z-Wave configuration?

This is a Reaction; it can be a Rule's Set or Reset Reaction, or a Global or Rule Set-based Reaction:

Note some instructions are in the comment row.

Also note that some entities, like those from Hubitat and ZWave-JS, may only show 0.99 as full brightness, so plan your upper-limit accordingly (I've done that here since it will generally work "well enough" for all dimmable entities from any controller). Ramping down would be similar.