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

@toggledbits ok, good to know

@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

@Fanan having also the same issue with host time not being visible (build 25082 on Docker), using Chrome browser. With Safari both times are shown.

@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 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?

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!

I have the following yaml configuration in local_mqtt_devices file

      x_mqtt_device:
        set_speed:
          arguments:
            speed: 
              type: str
          topic: "command/%friendly_name%"
          payload:
            type: json
            expr: '{ "fan": parameters.speed }'

While this works fine, I'm wondering how this could be changed to "fixed" parameters, as in this case "fan" only accepts "A", "Q" or a numeric value of 1-5?

@toggledbits great! Will this fix make it to the next build?

Similarly as for local expressions, global expressions evaluate and update fine when getEntity(...) structure is used. However, at least when certain functions are in use, expressions do not update.

Consider the following test case:

Even though auto-evaluation is active, value does not change (it changes only if that expression is manually run). MSR restarts do not help.

Note: Tested using build 25067 on Docker. I have also a PR open (but couldn't now get details or PR number as my Mantis account was somehow expired?).

@toggledbits the main thing is that now I know that this behaviour is not a bug and there's a clear alternative (not using global variables when rule does not trigger often enough).

Anyway, MSR is a great software and thanks for your continued support!

This case is easy to reproduce, only the question is if this happens by design?

("TempOutside" is also a global variable, although its naming is a bit misleading)

@toggledbits well I guess the following test cases should either prove my point or prove me wrong

Rule 1: (no real triggers, only comments etc)

local expressions:
TempOutside = getEntity( "..." ).attributes.temperature_sensor.value

Rule 2: (no real triggers, only comments etc)

local expressions:
TempOutside = g_TempOutside

(where g_TempOutside = getEntity( "..." ).attributes.temperature_sensor.value)

So in my case "Rule 2" -type of local expressions won't be evaluated unless rule is triggered. I'm pretty sure it used to work differently with earlier builds, about a year ago.

Continuing this discussion, I've noticed that if I have local expressions that contain "getEntity(...)" type of variables, these expressions are evaluated every time entity changes. This happens regardless of triggers.

But if I have the same expressions where "getEntity(...)" is replaced by a global variable / expression (and this global variable contains getEntity-structure), these kind of local expressions are not evaluated even if global variable changes. For clarity, expressions would be evaluated if rule is triggered.

@toggledbits, is this behaviour by design? Using build 25060 on Docker.

@toggledbits using a very similar setup and works nicely!

Hubitat Elevation is one option (has both z-wave & zigbee)

@wmarcolin here's something I've used for a sensor that updates too frequently:

 id: virtual4b
          name: "Lay-Z-Spa temp"
          capabilities:
            temperature_sensor:
              attributes:
                value:
                  model: time series
                  entity: "mqtt>layzspa_states"
                  attribute: "temperature_sensor.value"
                  interval: 1  # minutes
                  retention: 1  # minutes
                  aggregate: sma
                  precision: 0
          primary_attribute: temperature_sensor.value
          type: ValueSensor

Now I can use this virtual entity instead of a real one in a rule without throttling or logging problems (log files rotating too often etc)

@wmarcolin search the manual for "time series"

@tbully that's easy, you have to use a variable in the notification and set that variable using case-statement, e.g.

case
  when sump_temp < 45: "House is too cold due to Sump Temperature below 45 degrees"
  when x_temp < 45: "similar message"
  when y_temp < 45: "similar message"
  else "some default message if needed"
end

If you use Unix epoch format, you can compare two values as they are numbers