Global Moderators group | Smart Home

toggledbits

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

toggledbits

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

toggledbits

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

toggledbits

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.

toggledbits

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.

therealdb

so:

alarm(10), true

should fire every 10 secs? It's not working for me, maybe I have something wrong in the expression.

EDIT: ok, setting it as pulsing every X secs indefinitely did the trick. amazing!

toggledbits

Yes, that's correct!

therealdb

Sorry to write here without trying, but I’m flying today.

Am I correct if i say that script action with alarm() makes it possible to execute a reaction in a given interval, lets say 15 seconds or 3.5 minutes?

That sounds amazing, since I’ve used weird tricks, including a custom controller, just to do this.

CatmanV2

I shall have a play!

C

toggledbits

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

Global Moderators

Posts

Reactor build 25321

Member List