@therealdb could you test this if you could get your original rules (variables) to work just by rearranging local expressions? My hypothesis being that expressionless variables should be last in the list

@toggledbits have you had time to look at this? I suspect there’s a bug in evaluating local variables when expressionless variables are not last items in the list

@toggledbits I’m not using script action currently, and those screenshots were from a rule that uses set variable action.

But could you test my finding? Even rule triggers are not relevant when reproducing this finding. Just put a variable referencing an entity which frequently changes as a first one. Then make expressionless variable second, and as a third one make some kind of expression which uses first variable and does some calculation with it. Observe what happens and then swap second and third line and again watch what happens.

@toggledbits that wasn’t what I was trying to convey here. Let’s forget script action for a moment as it has no relevance for my finding.

What I’m trying to say here is that by merely changing the order of variables (and to be clear, that setup has worked before), my rules are working again. Somehow new builds do not like if expressionless variables are in the middle of regular ones. If they are last in line, all is well. Sounds crazy, but please test.

Some strange results happened while I was experimenting with script action. I noticed that the order of local variables had an effect whether those variables did update or not.

If I had e.g. the following order:

"peak_power" did not update. But if I switched places of "ok_to_reset" and "peak_power", "peak_power" started to update in real-time:

@toggledbits ok, I'll have to try script action. Still, as @therealdb stated, I'm also sure the "old style" used to work with pre-252xx builds.

@toggledbits "success" variable cannot be other than true or false, that I know.

But is it so that every time a rule is triggered, its local variables are evaluated (or should be evaluated) at least once?

Also, you wrote earlier: "If there's already a pending request for re-evaluation queued, new requests are ignored. This is all to prevent infinite loops in rule evaluations where rules manipulate devices and rule-based variables in Reactions that are also part of the rule's dependencies"

I was wondering if this could happen in cases where re-evaluation is queued but somehow gets stuck, and because new requests are ignored, updates won't occur?

@toggledbits, some extra information that I hope will help solve this. I've noticed a few other instances where variables aren't updating. These happen to be Telegram notifications, although I don't think Telegram itself is the issue—it's just that I tend to notice notifications more easily than changes in the UI.

In all cases, a common denominator is that local variables (in my case, 'msg') that include other local or global variables also contain "if/else" and/or "case" statements.

Examples below:

msg = 
solar_last_day == "ERROR" ? "Error retrieving solar stats" : (solar_last_day > 1 ? "Daily solar stats are ready, total " + round(solar_last_day, 1) + " kWh, peak " + peak_array[0] + " W" + " @" + peak_array[1] : "NA")


msg =
case
  when success == true: "Export limit activated, sell price " + round(g_NordpoolCurrentPriceSellReal, 2) + " c/kWh (VAT 0%-mgin), grid balance " + round(g_FronPowerSum, 0) + " W" 
  when success == false: "Export limit could not be activated?"
  else "Setting export limit failed"
end

I'm not sure if it's related, but there was a recent bug involving global expressions not updating when certain functions were used (fixed in build 25082)

@toggledbits I did a very similar testing arrangement and got the same results as you, i.e. working fine. I guess I have to monitor this more closely and if this update problem happens again, find a way to reproduce it consistently.

One notable difference between my production expression and the test expression is that the production one is a lot more complicated:

@therealdb I noticed a similar behaviour with build 25208, although the issue might have been present also in the earlier (25201) build.

In essence I have a rule with a global variable correctly triggering when it has a certain value, but in reactions it has a Telegram notification using a local variable as message (like this: ${{ msg }}). And this local variable "msg" is using the same global variable that triggered the rule, but its value is something totally different, i.e. seems that it's not updating.

I'm also sure this rule was working fine before, with variables correctly updating.

As there are statements about compatibility for home assistant versions in MSR new version announcements (e.g. "HassController: Bless Hass to 2025.7.3"), I thought it would be good idea to track other controllers as well.

As an example, I can confirm that build "latest-25208-c53e8513" works with Hubitat Elevation C-8 platform version 2.4.2.134 using Maker API.

@toggledbits okay, but the issue now is that, if I upgrade to MQTTController build 25139, I'll get errors which I haven't gotten before

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

I'm running MSR build 25139 on Docker, using MQTT controller 24293, and everything working as expected. But if I try to upgrade to MQTTController build 25139, I'm getting the following errors on MSR UI:

An Entity Attribute condition in "Lay-Z-Spa auto heating off" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute value_sensor.god
Last 11:20:37

An Entity Attribute condition in "Lay-Z-Spa auto heating off" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute temperature_sensor.green
Last 11:20:37

An Entity Attribute condition in "Lay-Z-Spa filter pump auto off" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute temperature_sensor.red
Last 11:20:37

An Entity Attribute condition in "Lay-Z-Spa filter pump auto run" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute value_sensor.pump
Last 11:20:37

An Entity Attribute condition in "Lay-Z-Spa watchdog" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute value_sensor.status
Last 11:20:37

My MQTT configuration (local_mqtt_devices.yaml) for the related entity is:

layzspa_message:
    type: ValueSensor
    capabilities: ["temperature_sensor", "value_sensor", "power_sensor"]
    primary_attribute: power_sensor.value
    events:
      "layzspa/message":
        "power_sensor.value":
          json_payload: true
          if_expr: '! isnull( payload?.PWR )'
          expr: "float(payload.PWR)"
          
        "value_sensor.air":
          json_payload: true
          if_expr: '! isnull( payload?.AIR )'
          expr: "float(payload.AIR)"
          
        "value_sensor.pump":
          json_payload: true
          if_expr: '! isnull( payload?.FLT )'
          expr: "float(payload.FLT)"
          
        "value_sensor.god":
          json_payload: true
          if_expr: '! isnull( payload?.GOD )'
          expr: "float(payload.GOD)"
          
        "value_sensor.lock":
          json_payload: true
          if_expr: '! isnull( payload?.LCK )'
          expr: "float(payload.LCK)"
         
        "value_sensor.unit":
          json_payload: true
          if_expr: '! isnull( payload?.UNT )'
          expr: "float(payload.UNT)"
          
        "value_sensor.error":
          json_payload: true
          if_expr: '! isnull( payload?.ERR )'
          expr: "float(payload.ERR)"
          
        "temperature_sensor.green":
          json_payload: true
          if_expr: '! isnull( payload?.GRN )'
          expr: "float(payload.GRN)"
          
        "temperature_sensor.red":
          json_payload: true
          if_expr: '! isnull( payload?.RED )'
          expr: "float(payload.RED)"
          
        "temperature_sensor.target":
          json_payload: true
          if_expr: '! isnull( payload?.TGT )'
          expr: "float(payload.TGT)"
          
        "temperature_sensor.value":
          json_payload: true
          if_expr: '! isnull( payload?.TMP )'
          expr: "float(payload.TMP)"
          
        "temperature_sensor.virtual":
          json_payload: true
          if_expr: '! isnull( payload?.VTM )'
          expr: "round(float(payload.VTM), 1)"
          
        "temperature_sensor.ambient":
          json_payload: true
          if_expr: '! isnull( payload?.AMB )'
          expr: "float(payload.AMB)"
          
      "layzspa/Status":
        "value_sensor.status":
          if_expr: '! isnull( payload )'
          expr: "payload"
          
      "layzspa/button":
        "value_sensor.button":
          if_expr: '! isnull( payload )'
          expr: "payload"

and in reactor.yaml I have:

"layzspa_states":
          name: "Lay-Z-Spa States"
          friendly_name: 'Lay-Z-Spa States'
          include: layzspa_message

I realize my MQTT configuration might be a bit unorthodox, but could there still be something unintentional in the latest MQTTController build? If needed, I can provide detailed logs.

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?