Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Unsolved
Collapse
Discussion Forum to share and further the development of home control and automation, independent of platforms.
  1. Home
  2. Software
  3. Multi-System Reactor
  4. MQTT configuration question
Gradually turn on lights.
Tom_DT
I have several lights that I would like to turn on very gradually over 15 or 20 seconds. from 0 to .25 in .01 increments. I have tried a few things that came nowhere near working, so here I am.
Multi-System Reactor
Stop the MSR by an external switch on Hubitat.
wmarcolinW
Use case: When performing home maintenance, such as air conditioning, I want all rules involving air conditioning to be disabled. To do this, to day, I have a virtual switch that I placed within all rules involving air conditioning, meaning that if I turn it off, none of them work. Then another situation: the water pump system and garden irrigation, another switch. In short, I had to create several virtual switches in Hubitat to disable rules in MSR. Unfortunately, however, I was unable to cover all scenarios, so I wondered if it would be possible for MSR to support a virtual MSR switch, which, when configured in the reactor settings, would function as a general on/off switch for MSR. If it is configured and turned off, the entire rules and actions in MSR stops working, except for the status change reading process, specifically for this switch, which, when turned on, would restart the MSR. Would it be possible to do something like this? Any recommendations from the experts?
Multi-System Reactor
Error After Upgrade
T
Topic thumbnail image
Multi-System Reactor
Reset attribute value of entity in event handler
R
Topic thumbnail image
Multi-System Reactor
Need help figuring out how to delay a reset on reaction
T
Topic thumbnail image
Multi-System Reactor
Way to search for rules (rule state) in other rules
T
@toggledbits, not sure if this is a feature request or I'm using the search tool wrong. You have a "Search for rule" in the Rules Set tab in MSR. It works nicely to find a rule and bring up said rule, but can it/could it be used for as a "where used?" global search? For instance, I have a fairly large set of rules, divided up into 10 different rulesets. There's easily a hundred individual rules, and many of the rules have Rule State triggers, which of course refer to other rules. Amongst my troubleshooting today, I came across what may have been a duplicate or troubleshooting attempt, but I can't tell if it's actually used as a Rule State in another rule without opening each rule that I suspect it may be a part of. Thanks.
Multi-System Reactor
Links to MSR from HA
Tom_DT
I am using Home Assistant a lot recently. On a dashboard showing the devices, I would like to show a link to the MSR rule that controls the devices. Is there a way to link directly into MSR?
Multi-System Reactor
Set Reaction > Script Action
wmarcolinW
Topic thumbnail image
Multi-System Reactor
Errors after updating to MQTTController build 25139
tunnusT
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.
Multi-System Reactor
🎉 My very first MSR controller: OpenSprinkler
therealdbT
Since today is my birthday - and I still pretend to be unconventional - I'm giving away a present to this wonderful community and I'm releasing my first OpenSprinkler controller for MSR. It was real fun to code it - and while it's still WIP, it seems to work OK for me. It's polling-based at the moment, but I'll add support for updates via MQTT very soon (it's already partially coded). Get it at (install is similar to MQTTController and such): https://github.com/dbochicchio/reactor-opensprinkler Feel free to try it. It's beta software, but it's stable. I'll update it weekly until all the tasks from my todo list are empty. Since I've learnt a lot from this controller, I'll explore new controllers soon.
Multi-System Reactor
Advice reqeusted to migrate MSR from Bare Metal to Container
T
Good day all, I'm in the process of trying to shut down my 10 year old Linux home server that served many purposes, but primarily it's what I used for my NAS/Plex Media server. I migrated the NAS aspect of the server in November of last year to a true NAS solution (Ubiquti UNAS Pro), which is rack mount and much more efficient than my old tower, which it's only side benefit was heating my home office during the winter. Unfortunately it also means heating my home office during the summer, which were about to be in full swing. I have two things running on this 10 year old server at this point. MSR and pi-hole. I'm running Plex Media Server on Fedora Workstation in Podman on mini PC, which is much more energy efficient than my old tower. My next step is to migrate MSR. I know there are images of MSR out there, and creating it is well documented. I'm going to be using Podman instead of Docker for various reasons, but they work very similar. What I don't know, is what I need to do to migrate my existing Bare Metal installation over to a container. Has anyone done this? Any advice?
Multi-System Reactor
Reactor (Multi-System/Multi-Hub) Announcements
toggledbitsT
Build 21228 has been released. Docker images available from DockerHub as usual, and bare-metal packages here. Home Assistant up to version 2021.8.6 supported; the online version of the manual will now state the current supported versions; Fix an error in OWMWeatherController that could cause it to stop updating; Unify the approach to entity filtering on all hub interface classes (controllers); this works for device entities only; it may be extended to other entities later; Improve error detail in messages for EzloController during auth phase; Add isRuleSet() and isRuleEnabled() functions to expressions extensions; Implement set action for lock and passage capabilities (makes them more easily scriptable in some cases); Fix a place in the UI where 24-hour time was not being displayed.
Multi-System Reactor
Can´t restart or upgrade/deploy MSR
F
Topic thumbnail image
Multi-System Reactor
[Solved] Limit HA Entity in MSR
wmarcolinW
Topic thumbnail image
Multi-System Reactor
Organizing/ structuring rule sets and rules
R
Hi guys, Just wondering how you guys organize your rule sets and rules. I wish I had an extra layer to have some more granularity, but my feature request was not popular. Maybe there are better ways to organize my rule sets. I use the rule sets now primarily for rooms. So a rule set per room. But maybe grouping by functionality works better. Any examples/ suggestions would be appreciated.
Multi-System Reactor
Moving MSR from a QNAP container to RP 5 - some issues
Tom_DT
Topic thumbnail image
Multi-System Reactor
Widget deletion does not work and landing page (status) is empy
M
Topic thumbnail image
Multi-System Reactor
Need help reducing false positive notifications
T
Topic thumbnail image
Multi-System Reactor
Deleting widgets
tunnusT
Hopefully a trivial question, but how do you delete widgets in a status page? Using build 22266
Multi-System Reactor
MQTT configuration question
tunnusT
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?
Multi-System Reactor

MQTT configuration question

Scheduled Pinned Locked Moved Solved Multi-System Reactor
11 Posts 2 Posters 884 Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • tunnusT tunnus

    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?

    tunnusT Offline
    tunnusT Offline
    tunnus
    wrote on last edited by
    #2

    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!

    Using MSR on Docker (Synology NAS), having InfluxDB, Grafana & Home Assistant, Hubitat C-8, Zigbee2MQTT

    1 Reply Last reply
    0
    • toggledbitsT Offline
      toggledbitsT Offline
      toggledbits
      wrote on last edited by
      #3

      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.

      Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

      tunnusT 1 Reply Last reply
      0
      • toggledbitsT 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.

        tunnusT Offline
        tunnusT Offline
        tunnus
        wrote on last edited by
        #4

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

        Using MSR on Docker (Synology NAS), having InfluxDB, Grafana & Home Assistant, Hubitat C-8, Zigbee2MQTT

        1 Reply Last reply
        0
        • toggledbitsT Offline
          toggledbitsT Offline
          toggledbits
          wrote on last edited by toggledbits
          #5

          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!

          Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

          tunnusT 1 Reply Last reply
          0
          • toggledbitsT 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!

            tunnusT Offline
            tunnusT Offline
            tunnus
            wrote on last edited by tunnus
            #6

            @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
            

            Using MSR on Docker (Synology NAS), having InfluxDB, Grafana & Home Assistant, Hubitat C-8, Zigbee2MQTT

            toggledbitsT 1 Reply Last reply
            0
            • tunnusT 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
              
              toggledbitsT Offline
              toggledbitsT Offline
              toggledbits
              wrote on last edited by toggledbits
              #7

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

              Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

              tunnusT 2 Replies Last reply
              👍
              0
              • toggledbitsT 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.

                tunnusT Offline
                tunnusT Offline
                tunnus
                wrote on last edited by tunnus
                #8

                @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
                

                Using MSR on Docker (Synology NAS), having InfluxDB, Grafana & Home Assistant, Hubitat C-8, Zigbee2MQTT

                toggledbitsT 1 Reply Last reply
                0
                • tunnusT 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
                  
                  toggledbitsT Offline
                  toggledbitsT Offline
                  toggledbits
                  wrote on last edited by
                  #9

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

                  Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

                  tunnusT 1 Reply Last reply
                  0
                  • toggledbitsT 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.

                    tunnusT Offline
                    tunnusT Offline
                    tunnus
                    wrote on last edited by
                    #10

                    @toggledbits ok, good to know

                    Using MSR on Docker (Synology NAS), having InfluxDB, Grafana & Home Assistant, Hubitat C-8, Zigbee2MQTT

                    1 Reply Last reply
                    0
                    • toggledbitsT 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.

                      tunnusT Offline
                      tunnusT Offline
                      tunnus
                      wrote on last edited by
                      #11

                      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

                      Using MSR on Docker (Synology NAS), having InfluxDB, Grafana & Home Assistant, Hubitat C-8, Zigbee2MQTT

                      1 Reply Last reply
                      1
                      • tunnusT tunnus marked this topic as a question on
                      • tunnusT tunnus has marked this topic as solved on
                      Reply
                      • Reply as topic
                      Log in to reply
                      • Oldest to Newest
                      • Newest to Oldest
                      • Most Votes


                      Recent Topics

                      • Gradually turn on lights.
                        G
                        gwp1
                        0
                        4
                        108

                      • Stop the MSR by an external switch on Hubitat.
                        wmarcolinW
                        wmarcolin
                        0
                        1
                        23

                      • Error After Upgrade
                        G
                        gwp1
                        0
                        4
                        96

                      • Reset attribute value of entity in event handler
                        R
                        RHCPNG
                        0
                        5
                        185

                      • Need help figuring out how to delay a reset on reaction
                        G
                        gwp1
                        0
                        22
                        906

                      • Way to search for rules (rule state) in other rules
                        T
                        tamorgen
                        0
                        3
                        97

                      • Links to MSR from HA
                        Tom_DT
                        Tom_D
                        0
                        1
                        81

                      • Set Reaction > Script Action
                        wmarcolinW
                        wmarcolin
                        0
                        11
                        431

                      • Wiring Samotech SM308-S into light fitting
                        akbooerA
                        akbooer
                        0
                        2
                        139

                      • Errors after updating to MQTTController build 25139
                        toggledbitsT
                        toggledbits
                        0
                        6
                        235

                      • 🎉 My very first MSR controller: OpenSprinkler
                        therealdbT
                        therealdb
                        5
                        13
                        909

                      • Advice reqeusted to migrate MSR from Bare Metal to Container
                        T
                        tamorgen
                        0
                        5
                        252
                      Powered by NodeBB | Contributors
                      Hosted freely by 10RUPTiV - Solutions Technologiques | Contact us
                      • Login

                      • Don't have an account? Register

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Unsolved