Timeouts within proximity to a restart are not a concern. And when I say "proximity", I mean 30 seconds because that's the default timeout period.

Host-side logs won't reveal anything here. If you want to look at logs, it's browser-side developer console that will have info. No screen shots, please, copy-paste text is far preferable. Also need to know browser version/details. And need to know if you are using login authentication or straight-in access.

Also, please remember the posting guidelines. Posting the one line with an error message isn't within those guidelines. There should be 20-25 lines of context preceding, always. Looking at one line with no context has about zero chance of leading me to any conclusions.

Try build 25323 just posted.

Reactor build 25323

• Rule-based Variables: correct an error handling dependency evaluation of subscoped variables.
• SystemController: prevent spurious exception that could be thrown while shutting down Reactor. It had no effect, but it's preventable and I like my logs error-free.

First question is, does the behavior change if you restart Reactor?

If not, then put the rule into level 5 logging as shown in the numbered steps in this post, restart Reactor, get the rule to run its challenge, and then send me the entire log file and your reactor.log file. I will PM you a link for the uploads.

Try build 25321 that I just pushed. I think I already had a fix for that.

Reactor build 25321

• alarm() function: has been redefined to return a boolean; true will be returned when the configured interval has completed; false in all other cases. The function previously returned the number of milliseconds remaining in the interval (less useful).
• Fix an issue where modifying a global expression that contains an alarm() call may not reset the timer.
• HassController: Bless HA to 2025.11.2

This post does not apply to users of Intel/AMD-based systems. If you are using a Reactor image tagged latest-amd64 or stable-amd64, then this post does not apply to you. It also does not apply to bare-metal installs; it's for users of docker images on ARM-based systems only (principally Raspberry Pi hosts, but could be others).

After January 15, 2026, I will no longer produce the aarch64-tagged docker image for Reactor. The ARM images will be arm64 for 64-bit operating systems, and armv7l for 32-bit operating systems.

For those of you running a container from the aarch64 image today, this will be a relatively simple change: you just need to switch the image used for your docker container to a differently-tagged image. If you are using docker-compose, then this is a relatively simple matter of changing the image line in your docker-compose.yaml file and then stopping (docker-compose down) and restarting (docker-compose up -d) your Reactor daemon.

But there's a catch... not all of you can safely just switch from the aarch64 image to the arm64 image. And, you can't just trust the output of uname -m, for example, because this exposes the CPU architecture, but not the word size of the OS running on that CPU.

For Raspberry Pi systems, the transition to 64-bit operating systems was long (starting in 2016) and not always obvious — although there was a first "official" 64-bit OS for RPis in 2020, it did not become a default recommendation in the Raspberry Pi Imager until 2021, and then that was only the default for Pi 3/4 systems with >4GB RAM; it was 2022 before it was universally recommended for all 64-bit CPUs regardless of RAM size. Depending on when you first imaged your RPi system and what default you may have been offered/chosen, you could today easily have a 64-bit CPU Raspberry Pi running a 32-bit version of the operating system. Upgrades along the way would not change this; changing it to fully 64-bit requires a full reimage of the system.

To establish if your OS is 64- or 32-bit, log in to your Pi and run: sudo dpkg-architecture -q DEB_HOST_ARCH. If the response is arm64 or aarch64, then you are running a 64-bit OS and you should use the arm64-tagged image. If it's anything else, you are running a 32-bit OS, and you should use the armv7l-tagged image.

    pi@rpi4-1:~ $ sudo dpkg-architecture -q DEB_HOST_ARCH
    armhf
    pi@rpi4-1:~ $ uname -m
    aarch64
    pi@rpi4-1:~ $

In the example above, the uname command reports that the CPU is 64-bit architecture (aarch64), which is true for the host on which I ran these commands, but the DEB_HOST_ARCH value is armhf, indicating a 32-bit operating system. This system has to use the armv7l-tagged image.

Other systems will have their own ways of determining the word size of the running OS. Since the majority of Reactor users running ARM systems are on Raspberry Pis, I am able to supply the above instructions, but if you happen to have a different ARM system, you'll need to do some web searching to figure out how to expose that information. Or, you can just try the arm64 image, and if it doesn't start up, try the armv7l image.

Remember to always back up your system before making any changes.

For everyone, please make this change as soon as possible, and if you have any trouble finding a working image, please (1) go back to the current aarch64 image; and (2) let me know in this thread along with as much detail about your host system as you can offer (including the output of the dpkg-architecture command mentioned above).

Depends on what you mean by "fire". If you look at the logs (not in pulse output mode, but in the default "follow"), you will probably see it being re-evaluated every 10 seconds, but because your result is a constant true, the rule SETs and never RESETs. Changing it to pulse output, of course, changes that.

The thing to notice, though, is that the expression IS being evaluated every 10 seconds, regardless of the output mode of the condition.

Ahhh... the subtlies of Pi. I have on my Pi4 build system:

root@rpi4-1:~# uname -m
aarch64
root@rpi4-1:~# dpkg-architecture -q DEB_HOST_ARCH
armhf
root@rpi4-1:~#

And never noticed. I guess I'll be rebuilding that host.

Image is up for arm64 using Bookworm (slim). I've always done builds directly on target hosts; this one was built on x86_64 cross-platform, so I'm eager to hear if it works for you. I can't run it on that Pi4 in its current condition.

Yes, that's correct!

You should be able to go back to something similar to what you were doing originally, just in Script conditions. Give it a try!

Reactor build 25315

NOTE FOR HOME ASSISTANT USERS: Versions of Home Assistant prior to 2025.01 are no longer supported as of this build. They may continue to work, but no effort will be expended to maintain compatibility going forward.

• Rules: New Script condition -- write an expression (simple or complex/compound) that returns a boolean (true/false) or null, just like any other condition. The alarm() function works in it, too! And it holds more secrets... see docs WARNING: This is a "bleeding edge" new feature; it may be subject to breaking changes as it evolves into final form.
• Expressions: Add new print() function to assist troubleshooting of complex expressions.
• HassController: Support for new HA selector/data type in input_datetime entities and other similar.
• HassController: Versions of Home Assistant older than 2025.01 are no longer supported, as support for a number of (their) deprecated features and functions is about to end.
• HassController: Bless HA to 2025.11.1

Got it. Multiple layers of this. It actually is related to the other PR, but again, that's also not the only issue. They also introduced a new selector type specifically for time and HassController is not handling it properly.

I'll have a new full build out later today. No more respins on 25310.

OK. So this is not the whole mystery, but it addresses one part... the service call looks like it depends on the configuration of the entity. The integration has two properties for its entities has_date and has_time, and if one is false and you attempt to set that field, you get an error. I just created another input_datetime with has_date: false and has_time: true and the service call works fine.

HassController is still not happy, though... still looking...

Different. I'm looking into this. Using HA's own developer tools UI, this service fails as well when trying to set only the time component...

I'm working for you. You also gave me an idea that I think could create a very useful alternative way to get to where you want to go. More to come...

@CatmanV2 said in Help resolve change in behaviour post update:

My assumption is it will go false at, or immediately after midnight?

No. If your GlobalAlarmTime will always show time only (no date components), then you can safely add an alarm() call to GlobalHeatTime as well.

@CatmanV2 said in Help resolve change in behaviour post update:

Will I see it updating in the logs?

Yes, and on the Expressions page.

@CatmanV2 said in Help resolve change in behaviour post update:

I'm further guessing that I'd set up a new global variable to replace HeatTime and have something like
GlobalHeatTime = alarm ( 900) , time(GlobalAlarmTime) - 3600000

You're on the right track. If I understand your description, something like this should work (all globals):

gAlarmTime = getEntity( ... )

gHeatTime = time(gAlarmTime) - 3600000

gHeatOn = alarm(900), time() >= gHeatTime

gAlarmTime will be updated any time the dependent entity changes. gHeatTime will change any time gAlarmTime changes (reference to another variable creates a dependency on that variable). gHeatOn will be updated by the periodic alarm() tripping.

@gwp1 yes!