Hi,
This post is a kind of feature request and a question at the same time.
I've just recently started to play with the MSR, thanks to friend of mine @tunnus
who recommended to try it out. So bear with me if I'm asking trivial or stupid questions.

Some background information of my setup

I have a KNX bus as a hardware backbone which I'm accessing through my own KNXNet/IP protocol stack implementation. On top of that I have NodeJS based dockerized microservices which are communicating using the MQTT. Since I'm still lacking a good rule engine, I've decided to try the MSR, and so far everything is looking pretty promising.

MSR version: latest-22274-24dfd72c (tested on Ubuntu but will eventually run on RPi 4)
MQTTController version: 22260

So what is the problem then?

Having well over 100 entities (62 relays alone) definitely means that I have to go with the entity template configuration. I've already succesfully POCed some simple binary and value sensors, e.g. entities that provide only state changes and are so to speak read-only. These are working just fine, but the problem lies within the switches and generally speaking
entities that have actions.

But let me first explain how I do the MQTT topic mapping for the KNX group addresses, which are basically unique identifiers for the attributes and functions of the KNX devices.

For example a motion sensor has a single group address, let's say 0/6/0,
for which we the following MQTT topics:

For status updates: /knx/0-6-0/status
And for the read operation: /knx/0-6-0/read

The group address 0/6/0 is formatted as 0-6-0 since it would clash with the MQTT topic.

The problem arises with swiches and gets even worse with dimmable lights.

In the KNX world we have separate group addresses for the statuses and for the write operations.

For example a simple switch would have a setup like this:

0/0/55 write (toggle on/off)
0/0/56 status (current status, can be also used to read the status)

And for the dimmable light we may have:

0/0/3 write (toggle on/off)
0/0/4 write (absolute dimming value)
0/0/5 write (relative dimming value)
0/0/6 status (current status, can be also used to read the status)

Now these would map to MQTT topics like this:

knx/0-0-55/write
knx/0-0-56/read
knx/0-0-56/status

knx/0-0-3/write
knx/0-0-4/write
knx/0-0-5/write
knx/0-0-6/status
knx/0-0-6/read

And there lies the problem. Since the MQTTController configration is only interpolating the %topic% variable, it's not possible to pass those additional 'write' topics into the template.

I've tried to get my head around this and didn't find any easy solution. One that crossed mind was the possibility to interpolate all the entity's config keys into the template.

I'm open to all suggestions since I would love get on writing the rules and logic with the MSR. Anyway, keep up the good work @toggledbits !

br,
mgvra

Some background
I have two simple rules that will toggle my carport's down lights depending on outdoor brightness when I open the motorized sliding gate. I.e. if the brightness is 1500 lux or less and the gate is opened, the down lights will be switched on, and when the gate is closed, the lights will switch off after 3 minutes. Pretty simple 'coming home' functionality so to speak.

Here's the switch off rule showing the 'hard coded' thresholds

The problem
I would like to parameterize the lux and switch off delay using entities. I bet the lux threshold can be done with local expressions the same way I do my WC background music scheduling:

weekdays_enabled = (time() >= time(getEntity( "mqtt>wc-music-weekdays-enable" ).attributes.string_sensor.value )) && (time() <= time(getEntity( "mqtt>wc-music-weekdays-disable" ).attributes.string_sensor.value ))

But the since I'm using the Condition must be sustained for functionality for the switch off rule, I have no idea how to parameterize that with some entity value.

So my question is that is it even possible to do this using entities or could there some other way to accomplish the same functionality? In this example it's the sustain -value but I might need same kind of parameterization for the delay reset also.

I have to go with entities, since my own HA system will provide the threshold values for the MSR through the MQTTController.

Help would be appreciated @toggledbits
br,
mgvra

MSR latest-23302-b7def56a and MQTTController [0.1.23254]

Thanks for your quick reply!

You can use expressions in condition operands by using the substitution syntax: ${{ your-expression }}

I'll use that for the brightness threshold.

The workaround is to group conditions and use additional conditions as gating criteria. For example, if you would change the "sustained for" delay based on time of day, say 120 for day and 600 for night, then you would have conditions structured like this:

Group A - Daytime -- AND group
    Rule Condition: Rule "Is Day" is TRUE
    Entity Condition: some entity test that tests a value
        condition option: Sustained for 120 seconds
Group B - Night -- AND group
    Rule Condition: Rule "Is Day" is FALSE
    Entity Condition: the same test as used in group A
        condition option: Sustained for 600 seconds

Well unfortunately this doesn't help much if I need to set an arbitrary delay value from my custom UI.

You cannot use expression substitution in the values of condition options. These are required to be constants (literal values).

Could this be a new feature request to support expression substitution in timeout values (sustain / delay reset etc) if it's feasible to implement?

br,
mgvra

A case with only a single when (and possibly an else) is an if statement, so why not use that? This is the workaround/recommendation. Using case in this way just seems unnecessarily complex

Well that's true and I don't think anyone uses the case-when structure with a single when. But for example in my case, I was testing the expressions, had written only one section and was getting this mysterious syntax error. As a software engineer myself, coming from C / Java / JS background, I naturally associated the case-when structure to switch-case where it's perfectly fine to have a single case, although as you mentioned, does not make much sense.

This is not a bug that needs to be necessarily fixed ASAP, but it would be nice if you could add a clarification to the manual, stating that the case-when structure must have at least two when sections.

Hi,
I'm trying to integrate the sonos-mqtt (https://sonos2mqtt.svrooij.io/) with the MSR and it's coming along nicely so far.
But cannot wrap my head around how to define custom capabilities in MQTT templates. I need this for the TTS announcements and similarly for the notification sounds where I would pass the sound file as parameter.

So this is what I have in the local_mqtt_devices.yaml

capabilities:
  x_sonos_announcement:
    attributes:
    actions:
      speak:
        arguments:
          text:
            type: string
          volume:
            type: int
          delay:
            type: int

And this is the template:

templates:
  sonos-announcement: 
    capabilities: 
      - x_sonos_announcement
    actions:
      x_sonos_announcement:
        speak:
          topic: "sonos/cmd/speak"
          payload:
            expr: >
              { "text": parameters.text, "volume": parameters.volume, "delayMs": parameters.delay, "onlyWhenPlaying": false, "engine": "neural" }
            type: json

So the speak action should send something like this to topic sonos/cmd/speak

{
  "text": "message goes here",
  "volume": 50,
  "delayMs": 100,
  "onlyWhenPlaying": false,
  "engine": "neural"
}

At startup the MSR seems to be quite unhappy with my configuration:

reactor  | [latest-25016]2025-02-09T08:19:59.029Z <MQTTController:WARN> MQTTController#mqtt entity Entity#mqtt>sonos-announcement unable to configure capabilities [Array][ "x_sonos_announcement" ]
reactor  | i18n: missing fi-FI language string: Configuration for {0:q} is incomplete because the following requested capabilities are undefined: {1}
reactor  | i18n: missing fi-FI language string: Configuration for {0:q} has unrecognized capability {1:q} in actions
reactor  | Trace: Configuration for {0:q} is incomplete because the following requested capabilities are undefined: {1}
reactor  |     at _T (/opt/reactor/server/lib/i18n.js:611:28)
reactor  |     at AlertManager.addAlert (/opt/reactor/server/lib/AlertManager.js:125:25)
reactor  |     at MQTTController.sendWarning (/opt/reactor/server/lib/Controller.js:627:30)
reactor  |     at MQTTController.start (/var/reactor/ext/MQTTController/MQTTController.js:268:26)
reactor  |     at async Promise.allSettled (index 0)

Configuration for "sonos-announcement" has unrecognized capability "x_sonos_announcement" in actions
Controller: MQTTController#mqtt
Last 10:21:37 AM

Configuration for "sonos-announcement" is incomplete because the following requested capabilities are undefined: x_sonos_announcement
Controller: MQTTController#mqtt
Last 10:21:37 AM

This is probably a pretty stupid question and the approach may not even work at all, but maybe someone or @toggledbits for sure, could point me to the right direction.
Basically the idea is to be able to send TTS messages from reactions using entity actions. I've previously used HTTP requests to Sonos HTTP API (https://hub.docker.com/r/chrisns/docker-node-sonos-http-api/) for the same functionality, but since moving to sonos-mqtt, I need a way to send the TTS notifications using MQTTController. Along with the actual message, volume and delay must also be parameterizable.

br,
mgvra

MSR latest-25016-d47fea38 / MQTTController [0.2.24293]

Hi,
Well my bad and classic RTFM case. Actually I also tried to drag it to the top but it seems that you have to hit the top bar on the spot in order to trigger the deletion, which is fine when you know it. And well right after the post, new release came out which fixed the landing page problem - nice work!

br,
mgvra

Hi,

I'm in the process of migrating from a Raspberry Pi 4 (ARMv7) to a Raspberry Pi 5 (ARMv8/aarch64), but I’ve run into an issue: there is no proper ARMv8/aarch64 image available.

None of the existing images run on the Pi 5 - they all exit immediately with code 139 (segmentation fault), which typically indicates that the binaries inside the image are not compatible with the ARM64/aarch64 architecture used by the Pi 5.

Would it be possible to publish a correct ARMv8/aarch64 (linux/arm64) image?
Building one should be relatively straightforward using docker buildx with multi-arch support. For example, my own Node.js images are built this way:

docker buildx build --push \
    -t <localrepo>/<project>:<tag> \
    --platform=linux/arm64,linux/amd64 \
    --file ./apps/<project>/Dockerfile .

This produces both the AMD64 and ARM64/v8 variants automatically.

Also, as a side note, it may be best to avoid using Alpine as the base image for the ARM64 build, since musl-based builds often cause compatibility issues and unnecessary headaches. A glibc-based base image (e.g., Debian or Ubuntu) tends to work far more reliably on ARM64, especially for Node.js applications.

@toggledbits - tagging you in case you missed this.

Thanks,
mgvra

The latest-arm64 works perfectly now on my RPi5 - huge thanks for pushing the arm64 Bookworm build!
This was the last showstopper for my RPi4 → RPi5 migration, so I can finally continue the move.

Here’s the container coming up cleanly:

mgvra@desktop:/development/knx-hal-mono$ docker --context production-rpi5 compose --env-file .env-prod up msr
[+] Running 1/1
 ✔ Container mosquitto  Running 0.0s 
Attaching to msr
msr  | Reactor latest-25315-bc301993 app 25315 configuration from /var/reactor/config
msr  | NODE_PATH /opt/reactor:/opt/reactor/node_modules
msr  | [latest-25315]2025-11-15T03:42:09.308Z <app:null> Reactor build latest-25315-bc301993 starting on v24.11.1 /usr/local/bin/node
msr  | [latest-25315]2025-11-15T03:42:09.309Z <app:null> Process ID 1 user/group 0/0; docker; platform linux/arm64 #1 SMP PREEMPT Debian 1:6.12.47-1+rpt1 (2025-09-16); locale (undefined)
msr  | [latest-25315]2025-11-15T03:42:09.309Z <app:null> Basedir /opt/reactor; data in /var/reactor/storage
msr  | [latest-25315]2025-11-15T03:42:09.309Z <app:null> NODE_PATH=/opt/reactor:/opt/reactor/node_modules
msr  | [latest-25315]2025-11-15T03:42:09.332Z <app:null> Resolved timezone=Europe/Helsinki, environment TZ=Europe/Helsinki; offset minutes from UTC=120
.
.
.

Thanks again — I dropped a few drams for such a fast support.
br,
mgvra