Organizing/ structuring rule sets and rules

[tunnus]

Then another case, where I'm trying to pass a variable "cmd":

requires: [cmd]
...      
    actions:
      power_switch:
        "on":
          topic: "command/%friendly_name%"
          payload:
            type: json
            expr: '{ "cmd": true }'
...

Expression here seems to be tricky, as "cmd" does not translate to its value (e.g. "econo"). What I'm after here is the following JSON:

{
  "econo": true
}

I have tried multiple variations, e.g.:

 expr: "{ cmd: true }"
 expr: "{ 'cmd': true }"
 expr: '{ cmd: true }'

But no luck. The closest I have gotten is with:

expr: '"{" + cmd + ": true }"'

So any help is appreciated!

[toggledbits]

Your post doesn't have enough context. Under what section have you placed the x_mqtt_device structure, for example. You're giving us a bunch of bits and pieces that don't line up to anything, so it's impossible to tell if you even have the right structure, let alone if it's going to do anything like what you want to do. If that's a template, show the entire template, because it just looks like a fragment of one.

You also haven't given us any real context for the device itself. What is it? What topics does it send or receive?

From what is discernible, defining an action (set_speed) that isn't defined as part of the native definition of x_mqtt_device isn't really a good idea. What you need to do is use an existing system capability that is close to your device, or perhaps define your own extended capability, but redefining an existing extended capability will only create problems.

As for the cmd part, you're getting close. What you are missing is the context object for cmd, which is config. So you should be using config.cmd to get to the value of the cmd configuration element. But that's not the whole story... you then need to use that value as a key in creating the object. We'd like the expression language to support { [config.cmd]: true } which is similar to JavaScript, but it doesn't (yet -- I'll look into that). But what you can do is this:

  payload:
    type: json
    expr: 'result={}, result[config.cmd]=true, result'

What this expression does is define an empty object in result, then set the key stored in config.cmd to true, and then returns that amended object as the expression result.

[tunnus]

@toggledbits thanks, cmd part works fine! Other part in the same case is:

...
requires: [cmd]
    events:
      "state/%friendly_name%":
        "power_switch.state":
          json_payload: true
          if_expr: '! isnull( payload?.cmd )'
          expr: "bool(payload.cmd) ? 'on' : 'off'"

Again, here "cmd" should translate to "econo", but for this to work I guess something similar you showed could do, but not sure how to formulate that?

[toggledbits]

I'm in teaching mode here. I've given you the tools you need. I'll give you a little bit more... where you have payload.cmd, it is literally looking for the key named cmd in the payload. You need it to look for the word that is in cmd as given by your device configuration. This is exactly the same as one small part of the modification I gave you.

Go forth and experiment!

[tunnus]

@toggledbits ok, got it (took a couple of iterations...)

Then to my original question, now with a little bit more context:

daikin_command:
    capabilities: [ "hvac_heating_unit", "value_sensor" ]
    primary_attribute: hvac_heating_unit.setpoint    
    events:
        "hvac_heating_unit.setpoint":
          json_payload: true
          if_expr: '! isnull( payload?.target )'
          expr: "float(payload.target)"
        "hvac_heating_unit.units": "°C"
        
        "hvac_heating_unit.state":
          json_payload: true
          if_expr: '! isnull( payload?.mode )'
          expr: "lower(payload.mode) == 'heat'"
          
        "value_sensor.fan":
          json_payload: true
          if_expr: '! isnull( payload?.fan )'
          expr: "str(payload.fan)"
          
    actions:        
      hvac_heating_unit:
        set_setpoint:
          topic: "command/%friendly_name%"
          payload:
            type: json
            expr: '{ "temp": min(28, max(16, float(parameters.setpoint))) }'
            
      x_mqtt_device:
        set_speed:
          arguments:
            speed: 
              type: str
          topic: "command/%friendly_name%"
          payload:
            type: json
            expr: '{ "fan": parameters.speed }'

So I want to control fan speed and I noticed there is "hvac_blower_unit" in standard capabilities:

hvac_blower_unit:
    ...
    actions:
      set_mode:
        arguments:
          mode:
            type: string
            values:
              - 'off'
              - auto
              - continuous
              - periodic
              - low
              - medium
              - high

But as this wasn't 1:1 capability mapping as compared to my AC unit, I didn't know how to extend/change that to suit my needs. MQTT topics relevant to this case are documented here. Kinda thought using x_mqtt_device was a good idea. Seems to work though.

How can I define my own (extended) MQTT capability? Also, I'd like to utilize those fixed arguments, so something like:

set_speed:
          arguments:
            speed:
              type: str
              values:
                - A
                - Q
                - 1
                - 2
                - 3
                - 4
                - 5

[toggledbits]

@tunnus Kudos! I'm guessing you discovered that something like payload[config.cmd] got you where you were going with that (I'm repeating it here for future readers, since you didn't show your final result).

To your next question, first thing: I believe you said you are using local_mqtt_devices.yaml. You'll "modernize" a bit by moving your template to its own file (e.g. daikin.yaml) in config/mqtt_templates/. Within template files in that subdirectory, you can define both custom capabilities and the templates that use them. They are structured more like a package, so you can more easily share them as others here have done.

In this case, though, you probably don't need to define your own capability. While the system-defined capabilities have values for attributes and action parameters, they are not set in stone. The defined values are a reasonable subset that a lot of devices may have in common, but there would be no way for me to know the entire range of values for every device that ever was or will be, so Reactor doesn't enforce them. They are mostly hints to the UI for reasonable values it can display for the user as a starting point. You can use your own values for hvac_blower_unit.set_mode without defining your own capability; it won't be a problem as long as your implementation (template) expects those values and handles them.

You're on the right track replacing the value_sensor capability with hvac_blower_unit. Using your posted config as a guide, it may look something like below. Let's look at the attributes of the capability first:

daikin_command:
  # some config here, redacted in OP's post
    capabilities: [ "hvac_heating_unit", "hvac_blower_unit" ]
    primary_attribute: hvac_heating_unit.setpoint
    events:
      "some-topic-for-status-I-assume":  # topic was redacted in OP's post
        # hvac_heating_unit stuff redacted for clarity/focus on hvac_blower_unit
        "hvac_blower_unit.state":
          json_payload: true
          if_expr: '! isnull( payload?.fan )'
          expr: 'payload?.fan !== "X"'  # whatever expression you need here.
        "hvac_blower_unit.mode":
          json_payload: true
          if_expr: '! isnull( payload?.fan )'
          expr: payload.fan
          map:
            A: auto
            Q: quiet
            1: low
            2: low-medium
            3: medium
            4: medium-high
            5: high

What I can't tell from your posts is if there's a value for payload.fan that represents fan off. That would be used to drive the state boolean attribute. You may use an expression like expr: payload?.fan !== "X" Assuming X means off, state will be false when the fan is off, and true when it's running at any speed, which is the intent of the attribute. If the fan is always running or you just don't know (i.e. the device doesn't actually report it), you can forego the if_expr and expr and just supply value: true (or perhaps value: null, meaning "I don't know"), which supplies a fixed value for that attribute that never changes.

For hvac_blower_unit.mode, you can see I've mapped the single-character values to strings. This isn't strictly necessary, but it's in keeping with the spirit of Reactor's design goals. Some of the values map to pre-defined values in the capability, and some don't, and that's just fine. It won't bother Reactor at all.

Now on the action side, we need to add:

    actions:
      hvac_blower_unit:
        set_mode:
          topic: "command/%friendly_name%"
          payload:
            type: json
            expr: |
              value = {},
              value.fan =
                ({
                  "auto": "A",
                  "quiet": "Q",
                  "low": 1,
                  "low-medium": 2,
                  "medium": 3,
                  "medium-high": 4,
                  "high": 5
                })[parameters.mode] ?? parameters.mode, value

This defines the set_mode action for the capability, preparing it to send a JSON payload. It first sets up an empty object in the value local variable. It then sets the fan key in the object by mapping any words given in the mode parameter to the action back to their letter equivalent for the device. If the value of the mode parameter doesn't map, it's just passed through as given (so you can still use the one-letter values directly if you don't want to use the words). Finally, the object in value is returned as the expression result (that's the , value bit at the end).

Digging in to that mapping a little more, we're creating a key-value pair object on the fly to use to look the value in parameters.mode. If it matches a key (i.e. left side of a colon), it changes it to the value (the right of the colon). If it matches nothing, the lookup results in null, which is handled by the ?? operator — when given null on its left, it returns the value of the expression on its right (i.e. if the map isn't matched, parameters.mode as given is the result). This is how you can use either the fancy strings or the one-letter values equally.

Hint: for debugging, when you run an action, MQTTController logs the exact topic and full payload being published at INFO level by default.

Finally, if you truly wanted to define your own capability, you could make your own Daikin+MQTT custom version of hvac_blower_unit by putting it in a capabilities section of your template file (this does not work in local_mqtt_devices.yaml, only in files in config/mqtt_templates/:

capabilities:
  x_mqtt_daikin_moredetail:  # moredetail may include device type, model number, interface type, etc.
    attributes:
      speed:
        type: string
        values:
          - A
          - Q
          - 1
          - 2
          - 3
          - 4
          - 5
    actions:
      set_speed:
        arguments:
          speed:
            type: string
            values:
              - A
              - Q
              - 1
              - 2
              - 3
              - 4
              - 5

This section can just precede the templates: section in your file. You would then adjust the capability name, attribute name, and action and parameters names accordingly in the above example to match your custom definition.

When you post snippets, please don't redact in a way that disrupts the structure. For example, you removed the topics from under events, and other data in your template. For future readers, that makes your post confusing and misleading, so other people that may find your post because they're having the same problem won't be able to follow it as easily. It would also be a courtesy to those other readers if you posted the final solution, for example the expression you finally came up with for the first problem solved.

Link to: MQTTController Documentation

Edit: fix missing expr in example for hvac_blower_unit.mode.

[tunnus]

@toggledbits thanks again! I did left some stuff out, as I thought they were not relevant for the questions at hand, as I was not trying to present how to configure a particular device, but trying to learn how to do something a bit more "advanced" (and that stuff would be visible to others as well).

Actually only thing I left out from my "daikin_command" template was power_switch:

 daikin_command:
    # also nothing here before capabilities
    capabilities: [ "hvac_heating_unit", "power_switch", "value_sensor" ]
    primary_attribute: hvac_heating_unit.setpoint    
    events:
      "state/%friendly_name%":
        "power_switch.state":
          json_payload: true
          if_expr: '! isnull( payload?.power )'
          expr: "payload.power ? 'on' : 'off'"
...

For clarity, here's that "payload.cmd" final solution (with some extra logic):

requires: [cmd]
    events:
      "state/%friendly_name%":
        "power_switch.state":
          json_payload: true
          expr: 'config.cmd == "swingv" || config.cmd == "swingh" ? payload.swing : payload[config.cmd]'

About "hvac_blower_unit.mode", I think you had forgotten "expr", so I added that, and also "map_default" in case something changes in the other end, and this would continue to work. Also those mapping values were the other way around (something that you could not know).

      "hvac_blower_unit.mode":
          json_payload: true
          if_expr: '! isnull( payload?.fan )'
          expr: "payload.fan"
          map:
            auto: "Auto"
            night: "Indoor quiet"
            low: 1
            lowMedium: 2 
            medium: 3
            mediumHigh: 4
            high: 5 
          map_default: payload.fan

[toggledbits]

@tunnus said in MQTT configuration question:

About "hvac_blower_unit.mode", I think you had forgotten "expr", so I added that, and also "map_default" in case something changes in the other end, and this would continue to work.

Yes, you are correct on expr -- I missed it. I will amend my prior post.

map_unmatched is not necessary. The default for map is to leave the value unchanged. And actually, the map_default you provided will result in the default being the string "payload.fan", not the value of the expression payload.fan.

[tunnus]

@toggledbits ok, good to know

[tunnus]

Hint: for debugging, when you run an action, MQTTController logs the exact topic and full payload being published at INFO level by default.

I've used MQTTX, which I can highly recommend