Hi,
I've installed the latest version 26059 and can confirm that the parameter substitution works perfectly!
Thanks a lot for the quick fix and the feature update @toggledbits

Here's my setup

local_mqtt_capabilities.yaml

x_mqtt_annunciator_panel:
    actions:
      on:
        arguments:
          led:
            type: int
            min: 1
            max: 45
          color:
            type: string
          effect:
            type: string
            default: "static"
            values:
             - static
             - blink
             - breath
          speed:
            type: int
            default: 500
      off:
        arguments:
          led:
            type: int
            min: 1
            max: 45
      static:
        arguments:
          led:
            type: int
            min: 1
            max: 45
          color:
            type: string
      blink:
        arguments:
          led:
            type: int
            min: 1
            max: 45
          color:
            type: string
          speed:
            type: int
            default: 500
      breath:
        arguments:
          led:
            type: int
            min: 1
            max: 45
          color:
            type: string
          speed:
            type: int
            default: 500
      brightness:
        arguments:
          value:
            type: int
            min: 0
            max: 255

local_mqtt_devices.yaml

  annunciator-panel:
    capabilities:
     - x_mqtt_annunciator_panel
    requires: [panel]
    actions:
      x_mqtt_annunciator_panel:
        on:
          topic: "annunciator/panel/%panel%/led/%parameters.led%/set"
          retain: true
          payload:
            expr: >
              { "color": parameters.color, "effect": parameters.effect, "speed": parameters.speed }
            type: json
        off:
          topic: "annunciator/panel/%panel%/led/%parameters.led%/set"
          retain: true
          payload:
            expr: >
              { "color": "off", "effect": "static" }
            type: json
        static:
          topic: "annunciator/panel/%panel%/led/%parameters.led%/set"
          retain: true
          payload:
            expr: >
              { "color": parameters.color, "effect": "static" }
            type: json
        blink:
          topic: "annunciator/panel/%panel%/led/%parameters.led%/set"
          retain: true
          payload:
            expr: >
              { "color": parameters.color, "effect": "blink", "speed": parameters.speed }
            type: json
        breath:
          topic: "annunciator/panel/%panel%/led/%parameters.led%/set"
          retain: true
          payload:
            expr: >
              { "color": parameters.color, "effect": "breath", "speed": parameters.speed }
            type: json
        brightness:
          topic: "annunciator/panel/brightness"
          retain: true
          payload:
            expr: >
              { "value": parameters.value }
            type: json

reactor.yaml

      # Annunciator panels
        annunciator-panel-1:
          name: 'Annunciator panel 1'
          panel: 1
          include: annunciator-panel

        annunciator-panel-2:
          name: 'Annunciator panel 2'
          panel: 2
          include: annunciator-panel

Note that the brightness control is not panel-dependent, as it uses the rpi-ws281x-native library's global brightness attribute. This works well for my setup, as I want all panels to share the same brightness level anyway. Speaking of brightness, it will be controlled by the technical room's PIR and MSR rules that dim or turn off the panels when nobody is present.

Below is the setup for the ventilation unit (AHU) indicator light:

• Green: Running OK
• Yellow: Switched off
• Blinking Red: Error

And here are the panel operations:

br,
mgvra

@toggledbits said in Dynamic MQTT topics and parameters:

@mgvra said in Dynamic MQTT topics and parameters:

Is there a more efficient way to handle dynamic topics? I tried passing the panel and led IDs as parameters from the UI, but I soon realized that this syntax does not work:
topic: "annunciator/panel/%parameters.panelId%/led/%parameters.ledId%/set"

This makes a lot of sense, and I don't know why it hasn't come up before. I need to run out for an errand with mi esposa, but when I get back, I'll work on this and post an updated MQTTController for you to try.

That sounds great, thanks! I'm really looking forward to testing the updated MQTTController. It’s also a funny coincidence about the DSKY project - it’s such an iconic piece of hardware, so it's cool to hear you're getting back into it!

It's funny that you mention the DSKY project, because I kind of set it aside years ago, but recently got motivated to start building again, so I've spent a little time refamiliarizing myself with where I left it...

Your annunciator panel... chef's kiss!

I really appreciate the 'chef's kiss' - coming from someone with your eye for detail and history with hardware like the DSKY, that really means a lot!

br,
mgvra

@therealdb said in Dynamic MQTT topics and parameters:

Very cool. And I thought my wall panel was cool

Thanks! I'm not sure if I've seen yours, but I'm sure it's much more presentable. Mine is going straight into the technical room - it’s a bit too 'hardcore retro' for the hallway!

Actually, I'm a bit surprised myself how nicely and evenly those indicators light up. I guess it's all down to the sufficiently deep (white PLA) light wells and the LCD panel diffuser, which is really paying off here.

The project is still a work in progress (WIP), and I'm currently tinkering with the light colors to resemble actual incandescent bulbs as closely as possible. Unfortunately, the attached pictures don't really do justice to how it looks in real life.

if I were you, I'll just build a custom capability and have just one device doing the work per panel. 45 properties/actions per device are totally acceptable imho.

Good call. I'll check that out and see if it makes the maintenance any easier.

Unfortunately, AFAIK, at the moment the only dynamic part accepted in topics is substitutions from config. I think @toggledbits will need to specifically support this new option in order to work.

Fair point. Let’s wait and see if he decides to add support for it in the future.

Hi,
I'm building a retro annunciator panel for my home automation’s "mission-critical" (and not so critical) statuses. Each 3D-printed panel consists of 45 RGB WS2812D 5mm LEDs. The plan is to introduce at least two panels, maybe even four if I totally lose it.

Control is handled by a spare Raspberry Pi 3, which communicates with the MSR via MQTT. Each panel/LED follows this topic format:

annunciator/panel/<panel-number>/led/<led-number>/set

(e.g., annunciator/panel/1/led/1/set)

The payload is a simple JSON object:

{
  "color": "red", // or #FF0000
  "effect": "blink", // static, blink, breath
  "speed": 1000 // in ms
}

This setup is currently working fine in MSR. One might argue that the device name should be annunciator-panel-led instead, as that’s what it actually represents.

local_mqtt_capabilities.yaml

capabilities:
  x_mqtt_annunciator_panel:
    actions:
      on:
        arguments:
          color:
            type: string
          effect:
            type: string
            default: "static"
            values:
             - static
             - blink
             - breath
          speed:
            type: int
            default: 500
      off: {}
      blink:
         arguments:
           color:
             type: string
           speed:
             type: int
             default: 500
      breath:
        arguments:
          color:
            type: string
          speed:
            type: int
            default: 500

local_mqtt_devices.yaml

templates:
  annunciator-panel:
    capabilities:
     - x_mqtt_annunciator_panel
    actions:
      x_mqtt_annunciator_panel:
        on:
          topic: "annunciator/panel/%panel%/led/%led%/set"
          retain: true
          payload:
            expr: >
              { "color": parameters.color, "effect": parameters.effect, "speed": parameters.speed }
            type: json
        off:
          topic: "annunciator/panel/%panel%/led/%led%/set"
          retain: true
          payload:
            expr: >
              { "color": "off", "effect": "static" }
            type: json
        blink:
          topic: "annunciator/panel/%panel%/led/%led%/set"
          retain: true
          payload:
            expr: >
              { "color": parameters.color, "effect": "blink", "speed": parameters.speed }
            type: json
        breath:
          topic: "annunciator/panel/%panel%/led/%led%/set"
          retain: true
          payload:
            expr: >
              { "color": parameters.color, "effect": "breath", "speed": parameters.speed }
            type: json

reactor.yaml

      # Annunciator panel 1
        annunciator-panel-p01-l01:
          name: 'Annunciator P1 L01'
          panel: 1
          led: 1
          include: annunciator-panel
        annunciator-panel-p01-l02:
          name: 'Annunciator P1 L02'
          panel: 1
          led: 2
          include: annunciator-panel
        annunciator-panel-p01-l03:
          name: 'Annunciator P1 L03'
          panel: 1
          led: 3
          include: annunciator-panel
       
       and so on, totaling 45 for now

The Question:
Is there a more efficient way to handle dynamic topics? I tried passing the panel and led IDs as parameters from the UI, but I soon realized that this syntax does not work:
topic: "annunciator/panel/%parameters.panelId%/led/%parameters.ledId%/set"

While my current setup works, introducing four panels would generate 180 entities in total. The reason I pass the IDs in the topic (rather than the payload) is to take advantage of MQTT's retain functionality. Since retention works on a per-topic basis, putting IDs inside the payload would only retain the latest update for the entire panel, not for each individual LED.

Using: Reactor (Multi-hub) latest-25323-d340b7d9 / MQTTController [0.2.25304] (latest-arm64 Docker image running on RPI5)

Off-topic:
One might ask: "Who on earth needs dozens of indicator lights in a modern HA system?" Well, probably nobody, unless you get carried away with 1960s NASA ground control panels. I stumbled upon @toggledbits DSKY project and thought that since you’re clearly a fan of similar hardware, you might be interested in this "crazy" project of mine.

This project was dormant for years but escalated quickly after I picked up a Creality K1C 3D printer. After the obligatory "calibration benchies," I remembered the annunciator panel, fired up Blender, and things got serious. Unlike the DSKY project, I’m not trying to replicate a specific device but rather capturing the era's aesthetic. The design is heavily inspired by the Master Specialties Company’s Roto-Tellite Series 1000 - those classic multicolor indicators found in the Titan II ICBM and NASA consoles.

The Design:
The construction is straightforward. Each light module consists of a 20mm light well that snap-fits into the front panel. At the bottom, there’s a snug fit for the 5mm LED. The front face is a "sandwich" of a diffuser plate (reclaimed from an old LCD monitor), a label printed on transparent overhead film, and a 1mm acrylic plate. These are held together by a black frame/cap that snap-fits into the light well for toolless removal.

The enclosure is roughly 200x200x26 mm - near the maximum size for the K1C build plate. The LEDs are daisy-chained and connected to the RPi via a 74AHCT125N level shifter.

P.S. You probably won't make sense of the labels since they are all in Finnish, but I hope the photos clarify the mechanical structure and how the "light wells" are built.
BTW: Did you ever finish the DSKY?

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

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

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,
It seems that the widget deletion does not work. I tried to drag the widget to the left (as explained in here https://smarthome.community/topic/1071/deleting-widgets?_=1744037333660)
but it does not delete it. Anyone else experiencing the same problem?

Also the landing page after login is empty and seems be have some JS issues on the dev console:

Using dockerized version of Reactor (Multi-hub) latest-25082-3c348de6 on Chromium 135.0.7049.52 (Official Build) snap (64-bit)

br,
mgvra

@toggledbits

@toggledbits said in Custom capabilities in MQTT templates:

Showing off all your cool toys, eh?

Well I wouldn't boast with employer provided montitor, and definitely wouldn't call it cool, just damn wide.

But speaking of showing off cool toys, this is something I bet you've never seen before, one of my weird projects:
A custom made flow through heater for my summer cottage's outdoor shower. Based on old used Webasto ThermoTop EVO 5kW car engine diesel
heater and controlled by ESP32 which provides WiFi AP and web UI. Fully modular, so that the heating unit can be removed before the winter.
Wouldn't call this cool either (no pun intented) but unique. Works pretty well, at least @tunnus agrees.

Old WIP photo

Thanks for letting me know. I'll see what I can do to make it look more presentable.

np

br,
mgvra

@toggledbits

Thank you for your reply! Well this is what I mean, the answer is right in your face (local_mqtt_capabilities.yaml) and you just can't see it.
Now it works like charm and I can even refactor my existing KNX templates using the custom capabilities.

For anyone else who might be struggling with the same problem, here's my config:

local_mqtt_capabilities.yaml

capabilities:
  x_mqtt_sonos_announcement:
    actions:
      speak:         
        arguments:
          text:
            type: string
          volume:
            type: int
            default: 50
          delay:
            type: int
            default: 500

local_mqtt_devices.yaml

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

UI looks like this:

FYI there's a subtle layout issue with the login screen background image when using ultra wide monitors, just to let you know.

@therealdb

Well thanks for your reply, but didn't get it working.
This is my config now:

capabilities:
  x_sonos_announcement:
    actions:
      speak:         
        arguments:
          text:
            type: string
          volume:
            type: int
          delay:
            type: int
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

I just fail to see what is the problem here.

br,
mgvra

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]

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.

Well I stumbled across exactly the same bug and was able to resolve the problem only because @tunnus knew what was the issue.

This would be nice a improvement.

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

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 yet another quick reply! I'll start playing with the expressions and JSON payloads now that I know the proper syntax.

          expr: >
            { "brightness": parameters.level * 255 }

So it is this implicit parameters object that contains the value (level) to be set.
In the case of step dimming, is this the notation?

          expr: >
            { "brightness": parameters.step * 255 }

Don't forget you can set MQTTController's log level to 5 while doing this work to troubleshoot what you are doing and see more clearly what is ultimately being sent.

Good point!

I do have functions for converting between HS(L), RGB, and XY. Currently they are only available to HubitatController, but I can easily extend them to MQTTController as well. The trick there, however, is that your device's implementation is the same (e.g. for HSL 0° is red, 120° is green, 240° is blue, etc.). There's a de facto standard, but some devices have their own way.

Well that would be really nice if it doesn't require too much effort. A new release of the MSR or just the MQTTController?

The trick there, however, is that your device's implementation is the same (e.g. for HSL 0° is red, 120° is green, 240° is blue, etc.). There's a de facto standard, but some devices have their own way.

Well I think those functions should exist even if they don't work with all possible devices. It's sure better than nothing and chances are that they work just fine.

br,
mgvra

Some background
I'm trying to integrate a Zigbee device into the MSR using zigbee2mqtt bridge and MQTTController. The device in question is a cheap mood light that has following properties that I'd like to control:

• switch (on/off)
• brightness
• color

I'v already managed to get the switch part working and can toggle the light on/off. Also the brightness value is mapped back to MSR. In zigbee2mqtt it has a value range from 0 to 254, so this the reason for the expression:

expr: 'payload.brightness / 254'

Here's the entity definition (don't know whether the type should be something else than the Switch)

zigbee-lidl-mood-light:
  name: 'Lidl Mood Light'
  friendly_name: 'Mood Light'
  type: Switch
  uses_template: lidl-moodlight      

And the corresponding template (NOTE: rgb_color has not been defined in this example):

lidl-moodlight:
  init: "zigbee2mqtt/%friendly_name%/get/state"
  query: "zigbee2mqtt/%friendly_name%/get/state"
  capabilities:
    - power_switch
    - toggle
    - dimming
  primary_attribute: power_switch.state
  events:
    "zigbee2mqtt/%friendly_name%":
      "power_switch.state":
        json_payload: true
        expr: 'upper(payload.state) == "ON"'
      "dimming.level":
        json_payload: true
        expr: 'payload.brightness / 254'          
  actions:
    power_switch:
      "on":
        topic: "zigbee2mqtt/%friendly_name%/set/state"
        payload: 'ON'
      "off":
        topic: "zigbee2mqtt/%friendly_name%/set/state"
        payload: 'OFF'
      set:
        topic: "zigbee2mqtt/%friendly_name%/set/state"
        payload: 
          expr: "parameters.state ? 'ON' : 'OFF'"
          type: raw
      toggle:
        topic: "zigbee2mqtt/%friendly_name%/set/state"
        payload: 'TOGGLE'

The problem
In order to control the brightness or the RGB color values, I would have send a JSON payload in corresponding actions. But I have no idea how to define it in the template. The reason why the switch part is working is that the zigbee2mqtt accepts also plain ON / OFF / TOGGLE string payloads in that case.

But the brightness should be controlled with the following payload:

{"brightness": 196}

And the RGB color like:

{"color":{"rgb":"46,102,150"}}

Here's the link for the documentation (the Exposes part defines the messages).

So how should I define the JSON payload for example for the dimming action? It definitely should be some sort of expressions since I have to map the MSR real value (0...1) to (0...254) for the zigbee2mqtt.

actions:
    dimming:
      set:
        topic: "zigbee2mqtt/%friendly_name%/set"
        payload: 
          expr: ?????
          type: json

Another problem is the RGB value. I could use the rgb_color capability for the setting but the problem is that the zigbee2mqtt only reports the current color in hue/saturation or xy coordinates.

Here's an example of published message after setting the color:

Topic: zigbee2mqtt/Mood Light QoS: 0
{
   "brightness":254,
   "color":{
      "hue":240,
      "saturation":100,
      "x":0.1355,
      "y":0.0399
   },
   "color_mode":"xy",
   "color_temp":574,
   "linkquality":96,
   "state":"ON"
}

I would have to map those values back to RGB, but is it even possible with existing constructs in MQTTController's templates?

Help would be appreciated @toggledbits
br,
mgvra

Thanks for your quick reply!
With added NUL group and interval it seems to be working just fine.

Well don't know about great post, just asking 'stupid' questions and hoping to learn something along the way.
But it's nice if it can be used as an example of how tackle that kind of problem.

br,
mgvra