Reactor only changes the entity name when the entity is first created. From there on, it sticks, no matter what the underlying hub does. To change the name, hit the "Rename" button on the entity in the detail pane (see your latest screen shots).

Also future note. When posting log snippets, please don't use grep or other filtering. Find the lines of interest, and post 20-25 of context before and as much context after as is relevant. Not all relevant log messages may contain the string you are searching for.

@tamorgen said in Set reaction triggering wrong z-wave device:

Here are some logs of me turning the entities on and off from HAAS.

You've shown here all stuff from ZWaveController, not HassController...? I don't think that would be helpful here anyway, because it would only show the HA entity IDs, and HA doesn't embed ZWave node numbers in their entity names. You would have to go look at the device in HA to confirm the node numbers. In HA's UI, go to Settings > Integrations > ZWave > Devices. Find the device you think is your Front Porch Lights switch, and click it. In the Device Info area, there's a Z-Wave Info heading with an arrow — click the arrow to expose the node number.

You said you updated ZWaveJSController, but it's still not showing me the expected log data. Can you confirm that in the startup messages for Reactor, ZWaveJSController reports it is version as 25304. If not, your update was not successful.

You can also go back to the ZWave-jS UI and command node 137 on from there, and see which device ZWave-JS switches. If it's the same device that Reactor switches, your Z-Wave nodes or HA devices are incorrectly identified.

What is clear in the Reactor logs so far is that ZWave node 137 is being told to do something, and ZWave node 137 responds back that it received the command its values changed. Nowhere along the way do the logs mention 136. If there was something wrong with what ZWaveJSController was commanding ZWaveJS to do, I would expect it log that it was performing an action on 137, but then gets update reports from 136, and that's not what is happening. I can also see in your Z-Wave data that node 137 is named "Front Porch Lights" at the node itself, which is consistent with the Reactor entity name, so Reactor/ZWaveJSController thinks it is doing the right thing.

I would start looking at the root, which is the ZWaveJS-UI, and make sure that node 137 is really your porch lights and you can command them on and off from there. If that's not the case, change the device name in Z-WaveJS UI, and then make sure the names in both HA and Reactor for nodes 136 and 137 match that data. Right now, it appears they do not.

OK. Everything checks out there. I would upgrade to the latest ZWaveJSController -- it looks like you are a release behind. That version added logging for what is actually sent to ZWaveJS, which may be instructive. But restarting for that update and rebuilding the state data may resolve the issue (you've probably done the former, I assume, but the latter is less obvious), so we're changing the conditions of the test. But let's see what happens when you upgrade, and then see what the log entries look like if the behavior is the same, because it sure looks like ZWaveJSController has it correct.

Please go to the Entities list, find entity zwavejs>137-0, open its detail panel, and copy-paste the output from the Copy Attributes button here (as text, no screen shots).

Have you looked at the logs to confirm your theory? Every device action is logged. I wrote this post a couple of months ago about how to find which Rule is manipulating a device.

@Pabla said in Can you run MSR on Home Assistant OS ?:

Had to edit entity config file recently to batch update entity names

You mean in the storage directory?

@Pabla said in Can you run MSR on Home Assistant OS ?:

occasionally you have to go into the container's directory to make changes and HA OS basically makes that impossible.

If you have to go into the container to make changes, something is wrong in the configuration. Nothing inside the container should ever need to be changed. Everything that is "mutable" and configurable by the user should be in the data directory external to the container. So... this comment has me puzzled...

And Docker can be made even easier with Portainer on top!

Not a fan, but I can see the utility. And there's a Portainer add-on for HA OS.

UPDATE (Jan 2026)

Orange Pi now offers a model 4A in 2GB or 4GB RAM configurations. The new model features an eight-core processor at 1.8Ghz, USB C power only (the DC barrel jack has been removed), an M.2 NVMe SSD (M-key 2280) slot, and eMMC interface (so no more onboard eMMC configurations, apparently, you have to buy an eMMC module separately). The 2GB model can be found for around US$55. eMMC modules are available in 32, 64, and 256GB (64GB is around US$32).

UPDATE (Jan 2026)

The Orange PI Zero 2 1GB is still available from that large, well-known online retailer; current pricing is $39.

I have one of these boards in service as my pool interface. Trouble-free, faithful service. The big plus for my particular use is that is has its WiFi on a UFL connector rather than traces-on-board, so I can use an external antenna for better range to the nearest AP in my home.

Again, don't confuse this board with the Orange Pi Zero or the Orange Pi Zero 2W, which are different boards.

UPDATE — JANUARY 2026

Since this Libre Le Potato board is still a good lower-cost alternative to RPis (especially for running Reactor), I pulled it out and did an update on the OS (Ubuntu 22.04.1). It had been in storage since I wrote the first post in November 2022, so it was... ahem... a little behind.

My first attempt at apt update semi-failed because a signature for one repository had changed, so that had to be fixed (easy):

wget https://deb.libre.computer/repo/pool/main/libr/libretech-keyring/libretech-keyring_2024.05.19_all.deb
dpkg -i libretech-keyring_2024.05.19_all.deb

From there, I was able to update the OS as usual. After the update, Ubuntu offered an upgrade to the current 24.04.3 LTS release. In the interest of science, I went for it (do-release-upgrade). That went less well. The system came up, but without networking and ssh access. I had to fix that with a locally-connected HDMI monitor and keyboard by adding (as root) a /etc/netplan/01-netcfg.yaml file as follows:

network:
  version: 2
  renderer: networkd
  ethernets:
    end0:
      dhcp4: true

Then run (still in a shell as root) netplan apply to bring the network up (you should be able to ping something at that point), and then systemctl enable ssh to re-enable sshd at startup. I then rebooted the unit, and all was well and it was ssh accessible.

I then upgraded nodejs to the current v24 LTS, and ran Reactor, no problem.

As of this writing, the price of this board at that large, well-known online retailer is around US$45. A heatsink for the CPU may be needed.

An upgraded/newer Sweet Potato model AML-S905X-CC-V2 runs about US$60 (with 2GB RAM). Same CPU; changes include heatsink now included/installed, DDR4 RAM, UEFI BIOS, USB C power input (5V/3A), support for a PoE hat, and an eMMC 5.x SM interface. A 16GB eMMC (flash disk) 5.x module is available (same source) for around US$10. Direct OS support includes Debian 13 and Ubuntu 24.04 LTS).

Since eMMC 5.x modules are available for the Sweet Potato, I highly recommend it (I wasn't able to find a seller of eMMC 4.x modules compatible with the older Le Potato at this point). MicroSD cards are notoriously failure prone (they're not up to the sustained, frequent writes of general purpose OSs). The NAND flash will do much better and likely be faster. Alternately, you could use an overlay filesystem. Maybe I'll write a post about that separately, if anyone wants to know.

@therealdb said in Can you run MSR on Home Assistant OS ?:

It’s just the first phase that’s complicate.

Spot on! For most Linux systems, docker is just a package with a one-line install process. From there, life is simple if you install and use docker-compose, for which I include sample configurations in both the documentation and the distribution.

Don't forget to hard refresh your browser as well.

OK. That's easy to address.

1. Stop Reactor
2. Delete the entire storage/entities subdirectory (no others, just that one)
3. Restart Reactor

This will force all Controller-based entities to be rebuilt, like the motion sensor was, just in bulk.

@cw-kid said in This trigger no longer working - complaining about the operator needing changing:

OK let me see if I can do that. You mean pressing the X here ? And then adding it back in to the trigger right?

No... Entities page... where you got the Copy Attributes output. There's a delete button there.

Delete the entity, then restart Reactor. It will come back, hopefully with binary_sensor capability.

I would delete the entity (using the delete button in the entity detail display), and the restart Reactor and see if it re-creates the Reactor-defined capabilities and attributes.

If not, look at the reactor.log file and see if it logged any errors related to VeraController.

Don't scorch the earth yet. Let's figure it out.

Post the attribute list for the device for starters. There's a Copy Attributes button in the entity detail. Use that, and paste the output here.

"Changing the operator on this condition will remove the non-default condition options currently set."

It's just telling you that the conditions options (under the dot-dot-dot button/icon) are going to be cleared because the operator is changing. That's because not every condition option is available for every operator. If you choose a Reactor-defined capability and attribute, it will recognize the operator's required type (so things like is TRUE and is FALSE will be allowed for attributes known to be boolean). When you use any extended attribute, like x_vera_anything.anything (the x_vera part being the clue that's an extended capability and attribute), that system's native type governs, and for Vera, that's a string, so is TRUE and is FALSE don't apply.

General recommendation is don't use the extended attributes when a Reactor-defined attribute is available.

To look beyond this, you'd need to post the attribute list for the device for starters. There's a Copy Attributes button in the entity detail. Use that, and paste the output here.

@cw-kid said in How to upgrade from an old version of MSR?:

Well that old Vera plugin still seems to work, it took a long time to trigger my new MSR rule however, even with the Site Sensor plugin set to a 60 secs interval. But it did eventually trigger the rule and send a TTS to my Google Home speak saying Emby sever was down.

Since you are hitting an endpoint in your local network, you can shorten the HTTP timeout by setting the Timeout variable on the SiteSensor device.

sys_system.state for the Controller instance.

It should be fine. Take a backup of your storage directory in its entirety before the upgrade, along with config and any other directories where you may have customizations (perhaps also ext if you have add-in Controllers). Then go. Make sure you do a npm run deps in the install directory before starting the new version of Reactor, to upgrade package dependencies, or Reactor will likely not start. Post if you have any problems.

Edit: Oh! And very important... make sure you are running nodejs version 18 or higher. If you have to upgrade, install a current LTS (Long-Term Support) version (either 22 or 24). Stick to even-numbered releases.