Tasmota has this inconsistency where if there's only one relay configured, it does not include the relay number; if more than one, then it adds it. There's no way for the template to know how many relays are configured, so you found the correct fix.

@cw_kid in your post here the configuration you posted is incorrect -- the indenting is invalid, and that will prevent anything from working for that entity.

Honestly, I can't at this stage really get a read on where you are. Between you jumping in with random AI changes and others commenting, your config is a moving target and I can't follow it. If you want my help, I will send you a link so you can upload your config and I can look at it and potentially fix it. Otherwise, I'll let you continue to learn on your own and seek help from others.

Sorry, my bad, change the include section to look like this (I'll fix the example above as well):

        include: 
          - tasmota_generic_relay
          - tasmota_sensor_temperature_humidity

Also, you can use yamllint.com to sanity-check your entire config file.

@cw-kid By the numbers:

1. tasmota_discovery is not a thing in Reactor, so that won't work.
2. The AI-recommended use of 0.0.0.0 for the host IP address of your MQTT broker (mosquitto) is correct and recommended.
3. implementation: MQTTController is the correct usage (class is deprecated).
4. You should use the 127.0.0.1 (aka loopback) address for the MQTTController's source configuration in reactor.yaml whenever the MQTT broker (i.e. mosquitto) is running on the same host as Reactor; otherwise, use the LAN interface address (192.168.0.4 in your case).
5. system: and extension_path are also not a thing in Reactor configuration (another AI fantasy fact).
6. All ESP32s and other MQTT clients should use the LAN address for the MQTT host (192.168.0.4 as shown in your image; that's correct).

You need to use one of the available templates for Tasmota described in the MQTTController documentation or create a configuration of your own. The latter may be necessary for your configuration, but we need more info. Please show more of the Tasmota device configuration (screen shots), so we can help you with that.

Until then, just choose the simple included switch/relay configuration template to get things working (i.e. so you can see that Reactor sees the device and may be able to control it).

  # In the controllers section of reactor.yaml:
  - id: mqtt
    enabled: true
    implementation: MQTTController
    name: Mosquitto
    config:
      source: mqtt://127.0.0.1:1883/
      log_topics: ['tele','stat','tasmota']  # only for testing, disable when not in use (makes big log file)
      entities:
        tasmota_fan_controller:
          name: "Tasmota Fan Controller"
          topic: fan_controller  # matches topic configured in Tasmota
          unit: 0  # relay number on the device
          include:
            - tasmota_generic_relay
            - tasmota_sensor_temperature_humidity

This may be all you need. Try it and see what happens. Don't forget to look at the logs when things aren't working as expected. And look at the mqtt-topics.log file to see what data you are getting (post a nice snippet of it here, along with everything else requested, if the device isn't working in Reactor).

Here's another one that is very likely to not have significant downtime: https://checkip.amazonaws.com/

If you still get errors with this one, I suspect your local network or something off with the configuration of your host.

Best add some error detection, then.

In your x_vera_device.set_variable action, where you have the substitution ${{ myIP }}, change it to ${{ trim(myIP) }}

Ref: String Functions

The endpoint has 15 seconds to answer by default (i.e. default timeout)... that's a long time for such a simple request. https://icanhazip.com is a popular choice for this purpose, apparently, and may be more reliable. Its response is plain text rather than JSON, but based on your use, that's more direct.

In any case, network errors are a fact of life, and requests will fail. If that's important to your process, error handling should be added (e.g. detect failed requests and skip changing the Vera variables).

@cw-kid The capture variable having a null value is a pretty indication that there was an error. You have the "Suppress alerts on HTTP errors" box checked, so you're silencing your first option for notification of an error on the request. But then, there could be another location...

Article here that may be of interest to some:

Jean-Luc Aufranc (CNXSoft)  /  Feb 5  /  Hardware

Raspberry Pi 4 dual RAM variant introduced to mitigate RAM price increases and supply challenges - CNX Software

Desperate times call for desperate measures. Raspberry Pi has decided to introduce a dual RAM variant of the Raspberry Pi 4 to allow DRAM supply chain

VirtualEntityController can sample another entity's data and do time-series aggregation (moving average, rate of change, etc.).

Refer to the documentation for VirtualEntityController

The name is incorrect at ZWave-JS (on the node itself) if that's the case, so to keep your sanity later, make sure you go all the way back to the source and work your way forward from there.

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