How to handle a mqtt topic with two different payloads, but returns one a at time

[penright (Paul Enright)]

How do you render a topic that could have different payloads?
For example, I have a Shelly 2 that is using Tasmota and MQTT. There are 2 switches called POWER1 and POWER2. They are returned in the topic “stat/Shelly2_2/ RESULT” You can see the two differences in a screenshot at the bottom.
I am using the mqtt grouped per domain. The domain is a “switch” with a series of entities being defined. The example shelly for my question is in my shop. I have the lights divided between what is over the workbench and what lights the bays. Power1 is for the workbench and Power2 is for the bays.
Here is the YAML snippet.

#************  Shelly2_2 192.168.3.178 *****************
    - name: "Shop Main/Bench"
      state_topic: "stat/Shelly2_2/RESULT"  
      value_template: "{{ value_json.POWER1 }}"
      command_topic: "cmnd/Shelly2_2/POWER1"
      payload_on: "ON"
      payload_off: "OFF"
      availability_topic: "tele/Shelly2_2/LWT"
      payload_available: "Online"
      payload_not_available: "Offline"
      qos: 1
      retain: false
      
    - name: "Shop Bays"
      state_topic: "stat/Shelly2_2/RESULT"  
      value_template: "{{ value_json.POWER2 }}"
      command_topic: "cmnd/Shelly2_2/POWER2"
      payload_on: "ON"
      payload_off: "OFF"
      availability_topic: "tele/Shelly2_2/LWT"
      payload_available: "Online"
      payload_not_available: "Offline"
      qos: 1
      retain: false

This all works except I get a warning because the device only publishes one payload with the same topic. This triggers both templates, but only one payload is present, so we get a warning that the other is not there. So I published a cmd so it would send a result. This screenshot is where I sent a POWER1 then a POWER2, hence the POWER2 warning, then a POWER1 warning.

Are there some conditions I can add to the template so as not to get the warnings?
I am not sure if my OCD is bad enough to redo a lot just to hide them.

BTW, while researching I did see this topic.

Two switches with one MQTT topic

I asked for some help on the forums with this, and it was suggested I post in the forums as it may be a little complex. Hoping someone can help get me started! In short, I currently have a device configured like this (topic, etc has been simplified for clarity): - platform: mqtt name: "My Device" state_topic: "things/my-device/mode/read" state_on: "3" state_off: "4" command_topic: "things/my-device/mode/write" payload_on: "{\"value\":\"3\"}" payload_off: "{\"value\":\"4\"}" val…

It is not exactly the same, the payload is the same, just different values for each switch.

[francisp (Francis)]

Easiest solution:

Shellies Discovery Script

This script adds MQTT discovery support for Shelly devices and without configuration it adds entities to Home Assistant. [Buy Me A Coffee] This is screenshots with Home Assistant Integrations page: [shellies-integration] Gen2 devices information Pro/Plus devies are supported by Shellies Discovery Gen2 script. Supported devices: Shelly 1 (with external sensors) Shelly 1L Shelly 1PM (with external sensors) Shelly 2 (relays and roller mode) Shelly 2.5 (relays and roller mode) Shelly 3EM Sh…

[penright (Paul Enright)]

@francisp

Easiest solution:

Sorry that I was not clear, I am using Tasmota.
If I understand the link correctly it is for Shelly running original software.
I have updated the original post.

[francisp (Francis)]

If Tasmota, why not use the Tasmota integration with discovery?

[penright (Paul Enright)]

@francisp

why not use the Tasmota integration with discovery?

Truth, ignorance. I am afraid of breaking all my automation. I guess, I can save the yaml and back up and see what smokes.
I wonder how the integration keeps from having the same issue. I am thinking I may have to change the Tasmota configuration. My resistance to that, is I have recompiled Tasmota with my configurations, so they will still work as a switch if for some reason they are factory reset. So I was trying to deal with it on the mqtt yaml side.

[penright (Paul Enright)]

I may have found the answer. I think credit goes to @schneich.
I found this post Test, if json object exists - #4 by schneich

I still have some more testing, but first clicks seem to work.
Here is my solution. It is @schneich trick of using regex to test for the payload.

#************  Shelly2_2 192.168.3.178 *****************
    - name: "Shop Main/Bench"
      state_topic: "stat/Shelly2_2/RESULT"  
      value_template: >
        {% if ( value_json | regex_search('POWER1') )  %}
          {{ value_json.POWER1 }}
        {% else %}
          {{ this.state }}
        {% endif %}
      #value_template: "{{ value_json.POWER1 }}"
      command_topic: "cmnd/Shelly2_2/POWER1"
      payload_on: "ON"
      payload_off: "OFF"
      availability_topic: "tele/Shelly2_2/LWT"
      payload_available: "Online"
      payload_not_available: "Offline"
      qos: 1
      retain: false
      
    - name: "Shop Bays"
      state_topic: "stat/Shelly2_2/RESULT"  
      #value_template: "{{ value_json.POWER2 }}"
      value_template: >
        {% if ( value_json | regex_search('POWER2') )  %}
          {{ value_json.POWER2 }}
        {% else %}
          {{ this.state }}
        {% endif %}
      command_topic: "cmnd/Shelly2_2/POWER2"
      payload_on: "ON"
      payload_off: "OFF"
      availability_topic: "tele/Shelly2_2/LWT"
      payload_available: "Online"
      payload_not_available: "Offline"
      qos: 1
      retain: false

[123 (Taras)]

You can simply check if value_json.POWER1 is defined.

    - name: "Shop Main/Bench"
      state_topic: "stat/Shelly2_2/RESULT" 
      value_template: >
        {{ value_json.POWER1 if value_json.POWER1 is defined else this.state }}
      command_topic: "cmnd/Shelly2_2/POWER1"
      availability_topic: "tele/Shelly2_2/LWT"
      ... etc ...

[penright (Paul Enright)]

@123

You can simply check if value_json.POWER1 is defined

That seemed to work for me, I have 8 shelly 2 switches and I will make all those changes and see what happens. No news is good news.
Reading the thread where I got this from, seems like there was an issue with that. The thread is over a year old so it could have been a typo or something was fixed. Anyway thanks again.