Most controllers rebuild their entities when upgraded. Capabilities can change, and the new definition needs to be properly applied. Because you've chosen to add your own attributes to system-defined capabilities, those are not restored when the entity is rebuilt because Reactor knows nothing about them. In fact, to Reactor, they look like attributes from an old definition of the capability that have been removed from the most recent definition.

As I've said before, your attributes will eventually be created when the event that writes them (layzspa/message), with a correct payload (e.g. { AIR: 123.456 }), is received by MQTTController. You can wait it out, or force the device to send those events.

Or, you could do this the way Reactor expects, which is to define a local capability for yourself (e.g. x_mqtt_tunnus_layzspa) and define your own attributes for all of the things you need. Or, break up your single entity into multiple entities that use the system capabilities unmodified.

@tunnus said in Errors after updating to MQTTController build 25139:

I understood correctly, in the latest MQTTController build it won’t define these kind of attributes automatically which it used to do earlier?

No, that's incorrect. It never created those attributes automatically at startup before, and it still doesn't.

Your extra attributes will be created, just not automatically at startup. They will be created when the event that writes them is received by MQTTController and processed with a valid result value, but not before. That's as it always has been. I suspect you think otherwise because when you first created the entity, there were no rules to tell you those attributes didn't exist, and by the time you got around to creating those rules, the events had been received and the attributes were added.

You've added attribute values that aren't defined by the standard capabilities that you are using, so Reactor won't define them automatically to make sure they exist. Generally, this isn't a good idea, and one reason why custom capabilities (e.g. x_mqtt_etc_etc_etc are supported). You can do what you are doing for now, but these attributes won't be defined until events that set them are seen by MQTTController.

@wmarcolin said in Set Reaction > Script Action:

Thank you for your comment, but I need this to be executed by an action already within the routines I program in Reactor.

@crille is spot on. That's exactly what his suggestion does. Here's a trivial example of what he's saying:

In this case, I'm not using the contents of a dynamic group, I'm just building a list on the fly using matchEntities(), but the effect is the same. At midnight every night, this rule turns all things that have the power_switch capability off.

If your listed switches are in a group, either created using DynamicGroupController, or an expression of some grouping the underlying controller has (Vera and Hubitat have groups and Reactor expresses those as group entities you can use), then you can easily modify this example.

And in fact, you don't even need to do that, because Reactor understands how to do actions on groups, so you can just do one action on the group entity (in a regular Entity Action or by calling performOnEntity() in a Script Action) and Reactor will perform that action on all members of the group (so, you don't even need the each expression construction).

@tamorgen said in Advice reqeusted to migrate MSR from Bare Metal to Container:

Any advice?

I know nothing about Podman and can't provide much help there, but I can tell you how the Docker images are built, and you can probably use that info to help with building your own Podman images.

The biggest structural difference between bare-metal and the docker image is that all of the writable subdirectories are moved to /var/reactor within the image. They do not live under the Reactor install directory as they do in a bare-metal system. This is done by setting the REACTOR_DATA_PREFIX environment variable within the image to /var/reactor. Reactor will apply this prefix when it goes hunting for those data directories: config, storage, logs, ext, and locales. In the case of docker, it's then easy to bind this /var/reactor directory inside the image to a user directory on the real user file system outside the image (a thing docker does). The goal is that no writable directory lives inside the eventual container, and this is important, because the container is temporary — it is destroyed and recreated when the image is updated, and possibly even when the container is stopped, and if your writable data was in there, you'd lose your entire configuration and states every time. When a docker user installs Reactor, they create a directory (usually in their home directory) to house all this data. They configure the container to map /var/reactor inside the container to this data directory outside the container, so whenever Reactor writes to configuration or storage, it ends up writing to files inside that data directory. If the container is deleted and recreated, that data isn't lost because it's now living outside the container.

Reactor runs as root inside the Docker container. This is a legacy docker-ism. Containers exist so that things could be run as root but still be... well, contained... prevented from fully exercising root's (absolute) power over other things in the host system. Within the docker container, Reactor runs as root but it's only going to be able to manipulate things inside the container. It can't stop other system processes, take over system devices that haven't been configured for it, or go mad infecting or deleting files outside the container. Podman apparently likes to run tasks in user land (i.e. as a user other than root), and this is something you'll need to research how to handle. That may also determine where inside the image you choose to put the Reactor build itself.

Under docker specifically, Reactor is aware that it's running in a container, because I manipulate data inside the image so it will know that, but it's just informational. It doesn't modify its behavior in any meaningful way, so you won't need to change anything else about Reactor, I think.

I think the long pole here is that you're going to have to create your own image to use with Podman. I don't think it will use docker images directly. There is some suggestion that you can run a docker container inside a Podman container or something to that effect, but that sounds to me like it will complicate your configuration and therefore your troubleshooting when things aren't going well, and I don't recommend it. Your Podman image/container will need to have all of the same dependencies resolved as a bare-metal install, so the image needs to have a good version of nodejs (LTS, 20+) and all of the npm package dependencies installed. You will likely need to configure some kind of virtual network interface that the running container will use internally to access the network externally, etc. (this is simpler than it sounds, but necessary for LAN and WAN access).

A key consideration before you venture forth may be this: I don't use or support Podman, and am not likely to. I have enough work handling the configurations I do support. You would be making yourself the subject matter expert in this community for Podman. That could be very good if you're the kind of person who loves to dig in themselves when things aren't working and figure it out, build up a knowledge base, and start using it to help others, track to my build releases and keep your images fresh. But otherwise, you could end up in the "I used a bunch of Google search/AI results full of commands I don't understand to build something complicated that I don't understand, and it has been working since _______ but doesn't work today; WAF is low" mode, and your only paths forward would be (a) more Google/AI spelunking, or (b) fall back to one of the supported configurations.

Reactor STABLE Update

The stable branch of Reactor is now updated to build 25139. Please scroll back and see the changes and advisories listed for builds here since the previous stable branch build (which was 24257, 13-Sep-2024), or whatever build you are currently running.

ALL USERS: It's always recommended to back up your Reactor system before upgrading.

IMPORTANT: Bare-metal users (only) need to do the following:

• Update dependent packages by executing npm run deps in the Reactor install directory.
• Reactor no longer supports nodejs versions before 20. If you are running on an earlier version, please upgrade nodejs before upgrading to this build, and make sure your current environment is working. Once you are sure Reactor is happy on the upgraded nodejs, then and only then should you upgrade Reactor to this new stable build. An even-numbered LTS (Long-Term Support) version of nodejs is recommended; the current LTS version is 22.
• If you are running extension controllers like ZWaveJSController or MQTTController in your configuration, you will need to upgrade those to their respective latest versions.

@Fanan Great!

A little more digging on my end, without a complete picture of your end, leads me to CORS. That is exactly the wording of an error I'd expect from CORS, and since HA Blue proxies for its add-ons, I'm betting that's where the issue lies. I don't know what that means for your (HA + Portainer) configuration, but I'd start with the Portainer add-on's support forums. This isn't really Reactor-related.

@Fanan

@Fanan said in Can´t restart or upgrade/deploy MSR:

I guess it have something to do with nodejs

Doubtful. The image provides its own nodejs, and doesn't use any version available outside the container.

Seems more like a Portainer problem to me. Was Portainer or HassOS upgraded recently?

@Tom_D said in Z-Wave Future....:

I think it is too soon to plan the Z-Wave funeral.

I don't think they're suggesting Z-Wave is headed for a dirt nap, just Z-Wave.me.

@wmarcolin By the way, if you really are concerned about performance/load, the other way to accomplish this is to tell HA that you don't need those entities by disabling them through their UI (Settings > Integrations).

HassController uses filter_entity not exclude_entities. Here are some examples:

  - id: hass
    implementation: HassController
    config:
      source: 'ws://192.xxx.xxx.xxx:8123'
      access_token: "xxxxxxxxxxxxxxxxxxxxxx"
      filter_entity:
        - sun_sun  # using Reactor entity ID, filter out the entire matching entity
        - "sun.sun"  # using HA domain.entity_id form, filter out entire entity

There are no wildcards.

You can also filter down to the HA attribute level. In this form, you use the HA domain.entity_id form combined with HA attribute names (you need to know/discover these from reading HA's integration documentation or examining your hass_states.json log file).

      filter_entity:
        # This is the abbreviated syntax for a single HA attribute
        "sun.sun": "last_updated"  # ignores only this *one* HA attribute
        #
        # This is the full syntax for one or more HA attributes
        "sun.sun":
          - last_reported
          - last_updated

Filtering at the attribute level is intended for when an attribute on the entity changes frequently but isn't of use to your configuration -- by filtering the attribute out, Reactor won't post changes for its interpretation of that attribute, and thus Rules that depend on the entity won't be notified that it may have changed.

Reactor build 25139

BARE-METAL USERS: You must execute the shell command npm run deps in your Reactor install directory after upgrading, to update package dependencies. The UI may not start if you fail to do this. This advisory does not apply to docker containers.

BARE-METAL USERS: nodejs version 18 is End of Life (EOL) as of April 30, 2025, and is no longer supported. For best results and longevity, upgrade to an even-numbered version of nodejs. The current LTS (Long Term Support) version (recommended) is 22 and will go EOL in April 2027.

BREAKING CHANGE FOR DEVELOPERS: If you use Entity.registerAction() and specify a function, the target function now takes the canonical action name as its second argument, and the action parameters will be the third argument (the target entity remains the first argument). That is, the signature of the function has changed from targetFunc( entity, params) to targetFunc( entity, actionName, params).

• Engine: Improve the approach of Rule State conditions to changes in the subject rule's state that don't end up changing the top-level rule state. This should considerably reduce potential throttling that can occur when inter-related/co-dependent rules change.
• Reactor UI: On the Entities list, fixed a minor display error in the display of atttribute values when an attribute other than the entity's primary is selected.
• Reactor UI: Reworked the URL routing so that linking to tabs and objects is possible. For this build, this will be most visible in many (but not all) of the Status tab widgets. More linking will be done in future. There's a lot more to do; please don't bother reporting areas where objects are not linked at this time.
• Reactor UI: The Rule Sets offcanvas navigation now has a search field that allows you to search for a rule by name.
• Upgraded some packages used by Reactor to maintainer's latest versions.
• HassController: Bless Hass to 2025.5.2

ZWaveJSController build 25139

• Minor bug fixes for initialization of devices with scene controller capability.

MQTTController build 25139

NOTE: Uses latest mqtt package, which is version 5.11 as of this writing. You must run npm run deps in the MQTTController install directory to update the package.

• New template support for Shelly Plus 1PM (use include: shellyplus1pm) and Shelly 1 Mini Gen3 (use include: shelly1minig3).
• The query directive in a device configuration now supports payload construction using the same semantics as that for action payload constructions. Principally, this gives you access to expr for query payloads, which facilitates more dynamic construction of payload fields where devices or templates need.
• New inbound topic reactor/:ident/Reaction/:reaction_id/:command; the command may be run, stop, or query to run (enqueue), stop (if running), or query the status of the specified global or Ruleset-based Reaction. You cannot run, stop, or query the state of the SET or RESET Reactions in a Rule. The query command requires Reactor build 25111 or higher for accurate response.

@wmarcolin said in Limit HA Entity in MSR:

in my opinion, this generates unnecessary integration overload

What's your basis for that opinion? On the HA side, all entities and events are published for everything on HAs websocket API, without filtering, so the data is coming to Reactor regardless. On the Reactor side, even with thousands of entities in my home environment, the load overall is low to Reactor and its host (load average <0.1 at 1, 5, and 15 minute measurement periods on an RPi 4), and HassController is only a fraction of that total load.

You can filter out entities, but it won't stop HA from sending data about them, and it won't stop Reactor from receiving that data and having to process it enough to know it should ignore it. What you want to know is in the docs, if you're committed to it.

I do a mix. I have rule sets for each room. Generally, these manage lighting, and maybe a small number of specific devices in that area. I have functional rule sets for other things like determining house mode (which is really a blend of season, day of week, time of day, and other switches I can throw for when we're having a party or overnight guests). Functional rule sets also cover room- or level-spanning rules. For example, I bring management of all leak detectors to a single utility rule set.

There's no harm in moving things around. Rules in rule sets have unique IDs that are not affected by their parent location, so moving them changes nothing operationally, it's just an organizational tool for the user. Make a structure and evolve it as you find need. You'll settle into something that works for you.

I know I sound like a broken record, but look at the logs. At startup, much is logged, and if there are problems with file permissions (which I suspect), you'll see it mentioned there in some form.

Reactor build 25097

• Expression syntax enhancement: it is now possible to use a variable's value as a key when creating an object on the fly. For example, if the variable cmd contains the word "econo" (presumably derived from configuration or some other dynamic source), it is now possible to create an object { econo: true } by enclosing the key source in square brackets: obj = { [cmd]: true }. For reference, this syntax mimicks JavaScript.
• Fixed a UI crash when bringing up Reactor initially after using the About page bypass.
• OWMWeatherController: implement sys_system.restart, which will cause all locations to be refreshed immediately.
• OWMWeatherController: new config option (boolean) ignore_certs can be set to ignore certificate errors. These seem to pop up occasionally, perhaps because of a misconfiguration in the load balancing at OWM.

As of build 24343, widget deletion is accomplished by dragging the widget to the top navigation bar (only). Dragging to the left margin no longer deletes the widget.

This change was also mentioned in the release notes for build 24343.

@tamorgen Frankly, it looks like you've made an overly simplistic sensor that you're trying to improve on in the rule... you're taking a low-res image of the device and trying to make it back into something higher-res.

I'd just look at the power directly in Reactor:

@tamorgen said in Need help reducing false positive notifications:

Any thoughts? I know I can set up a a condition to monitor the power sensor value, and make sure it is above 3.5 for 5 minutes, but the condition I need is for the power value to go to the standby value of under 2.9 after that condition is met. That's what I'm unclear how to do.

Look at the condition options (for any condition). You'll see the ability to sequence conditions there -- set a condition so it can only go true after another condition has gone true.

Your problem seems simpler to me, though. Maybe I just don't get the full scope from what you wrote, but what you asked for can be done without sequencing.

If you just want to know if the machine is running, make a rule for power >5W (your 3.7W plus some headroom) sustained for at least 5 minutes (see condition options again). If you want to know if the machine is not running, make a rule for (guessing) power < 15W sustained for 5 minutes. I think you'll find these pretty effectively ignore the transitions between cycles and bumps at the controls or door left open (light on) if you get the power values right for your machine's behavior.

Now you have two rules, one to tell you that it appears to be idle, and the other that it appears to be running. We could use one rule, but by using two rules with a gap between the power values, we create additional hysteresis to prevent those false positives. For you rules that need to react to the machine going idle, use a Rule State condition to check your idle rule; for rules that need to react to the machine running, check the running rule.