You don't need an "at" because an "after" will trigger at the set time. It also has the advantage that if the system is down when the set time arrives, it will trigger as soon as the system comes up (when used in a Rule's trigger conditions; any time until midnight), so the event is less likely missed. If you want to make sure something only happens at the set time or within a smaller error, set a between <time> and <time+minutes> (there are other clever things you can do as well, exercise for the reader).

Between 1300 and 1300 means between 1300 today and 1300 tomorrow. That won't change.

BTW, this behavior (and explanation) goes back to the Reactor plugin for Vera.

When I'm working on my laptop, this section on the right takes up about 25% of my screen width, and I never look at it or touch anything in it. Is there a way to turn it off? I've been tinkering in the settings but not finding anything effective so far.

You list Hubitat and HASS as hubs, and the default logging for both of these hubs should tell you what you need to know. I've tried to keep these messages fairly consistent across the controllers, generally in this form:

[...]2025-11-25T12:45:08.121Z <xxx:INFO> xxx#house perform power_switch.set on Switch#house>device_396 with { "state": false }

Search using the canonical entity ID. There are several capabilities that can turn a light on, so searching by capability is harder. The idea is to find a perform ??? on ??? with ??? at the right time with the right entity ID.

From there, start looking backwards for a message like either one of these:

[...]2025-11-25T12:45:00.100Z <Engine:NOTICE> Starting reaction Parking Area Light Off (re-lk5lrx5a)

    or 

[...]2025-11-25T12:45:08.121Z <Engine:INFO> Resuming reaction Parking Area Light Off (re-lk5lrx5a) from step 3

If this line is within just a couple of lines, maybe even directly before, the perform log entry you found above, then that's the name of the Reaction that manipulated the device. If that has :S or :R at the end of its ID and the tag <SET> or <RESET> appended to the Reaction name, the Reaction is part of a Rule with that ID and name, and that is the rule that is manipulating the entity — you're done!

If the Reaction ID doesn't have the :S or :R suffix, then the Reaction is not rule-based (e.g. it's a global reaction), and you need to find what launched it.

If the line you've found is of the form Resuming "<reaction name>" (reaction id)" from step n, then keep looking backwards. You may find more Resuming lines for other steps of the same reaction, but your goal now is to find the line that looks like Starting "<reaction name>" (reaction id).

Once you are on the Starting "<reaction name>" (reaction id) line, you should not have to look very far to find an Enqueuing "<reaction name>" (reaction id) line.

Once you are on the Enqueueing line, you should not have to look very far to find another Resuming or Starting reaction line. This line may have the :S and :R on the reaction ID that you are looking for to indicate the rule that launched the reaction. If it doesn't, then the reaction was launched by another reaction, and you just repeat the above process looking for what started this reaction. This path will eventually lead to the responsible rule.

Live example from my host this morning. The perform action we found above is for an outdoor flood light that lights a parking pad at my house. It got turned off. By what, though? Well, we already established that is was by a reaction called Parking Area Light Off because we found a Resuming line for that reaction right before the perform line for the entity. Let's keep digging to find the responsible rule. Here's are some more relevant lines from my log:

[...]2025-11-25T12:45:00.067Z <Engine:INFO> Enqueueing "Morning Lighting Off<SET>" (rule-knjifbn1:S)
[...]2025-11-25T12:45:00.078Z <Engine:NOTICE> Starting reaction Morning Lighting Off<SET> (rule-knjifbn1:S)
[...]2025-11-25T12:45:00.078Z <Engine:INFO> Enqueueing "Outdoor All Off" (re-kl73syb6)
.
.
[...]2025-11-25T12:45:00.088Z <Engine:NOTICE> Starting reaction Outdoor All Off (re-kl73syb6)
[...]2025-11-25T12:45:00.089Z <Engine:INFO> Enqueueing "Parking Area Light Off" (re-lk5lrx5a)
.
.
[...]2025-11-25T12:45:00.100Z <Engine:NOTICE> Starting reaction Parking Area Light Off (re-lk5lrx5a)
.
.
[...]2025-11-25T12:45:00.118Z <Engine:INFO> Resuming reaction Parking Area Light Off (re-lk5lrx5a) from step 2
[...]2025-11-25T12:45:00.119Z <Engine:NOTICE> Parking Area Light Off delaying until 1764074708119<11/25/2025, 7:45:08 AM>
.
.
[...]2025-11-25T12:45:08.121Z <Engine:INFO> Resuming reaction Parking Area Light Off (re-lk5lrx5a) from step 3

Working backwards from the last line, which is the Resuming line that we found earlier (reaction step 3), we find a Resuming line for the previous step (2) of that same reaction at 12:45:00.118. Notice also that reaction had a delay at that step that was logged immediately after, which accounts for the time gap between reaction steps 2 and 3.

Keep working backwards to 12:45:00.100 and we find the Starting line for that Parking Area Light Off reaction. And continuing to look backwards for that same reaction ID, we eventually find the Enqueueing line for it (12:45:00.089). Usually these two lines are pretty close together, but it's not usual to have other things logged between.

Now just looking backward line by line (not searching for any ID here), we soon find a Starting reaction Outdoor All Off line (12:45:00.088) very close to our Enqueueing line, indicating that Outdoor All Off launched the Parking Area Light Off reaction.

Now we just repeat this process with Outdoor All Off — find it enqueued at 12:45:00.078 by Morning Light Off<SET> also at 12:45:00.078. The <SET> on the name and :S on the ID means it's a rule reaction, so Morning Light Off is the rule that triggered and started the sequence of two other reactions that eventually turned off the light.

So to recap:

1. Find the perform line (search using entity ID) that occurs at about the right time.
2. Look backwards a short distance and you will find either a Starting <reaction> or Resuming <reaction> line. If that's a rule's SET or RESET reaction, you've found the responsible rule. Otherwise, a global reaction manipulated the entity/device, so proceed to the next step.
3. Find what launched the current reaction. Keep looking backward until you find the Enqueueing line for it. Then very shortly preceding it, you should find a Starting <reaction> or Resuming <reaction> line for a different reaction. That's what started the current reaction. If this new reaction is a rule's SET or RESET reaction, you've found the responsible rule. Otherwise, find what launched this new (global) reaction by repeating this step.

NOTE: Almost all actions in Reactor are asynchronous, meaning the Engine launches them in a separate process and the Engine can move on to working on a different reaction if multiple are running concurrently. Some in particular can take a lot of time (like HTTP Request). Depending on how busy your system is in that moment, all of these lines can be separated by other lines for other things going on, and you have to be careful and patient sifting through them.

Tested. It's working and not. It looks like if the condition is evaluated (e.g. Reactor restart or rule edited) in the period between midnight and its end time, it's getting the wrong result (should be true but reporting false). That's a regression in 25315. I've already got a fix for that based on your DM.

What docker image are you using specifically?

You might also try 25325 now and see if it goes away (or at least becomes less frequent -- there may be more than one similar case to one fixed in that release).

Reactor build 25325

• Rules/Expressions: fix an additional evaluation case from @Crille
• UI: silence an error that could occur during restarts (the shutdown process could stimulate the Set Rules status widget to fire queries at the inoperative host that eventually time out).
• HassController: Bless HA to 2025.11.3

Got it. OK, next time it pops up, open the Developer Tools windows on your browser, and in the Console tab, you should see a similar message with the pre-roll context -- copy-paste a bunch of that here and let's see what it can be.

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