Need advice: what's the best way to handle multiple conditions and actions

[bartplessers]

Hi,

I configured an OpenMQTTGateway to handle RF2 codes of my remote
My remote ( flamingo sf-501) has 4 rows of 2 buttons (and one “master” row with 2 buttons):

When I press a button, following information in coming in

{"unit":2,"groupBit":0,"period":267,"address":52166656,"switchType":1}

• address: the ID of my remote (I have multiple remotes, they all have different ID’s)
• unit: number from 1-4, depending on the button I pressed
• switchType: 1 = on, 0 = off

I managed to create a simple automation:

  - id: omg_rf2tomqtt_52166656_1_1
    alias: omg_rf2tomqtt_52166656_1_1
    trigger:
      - platform: mqtt
        topic: "home/OpenMQTTGateway_ESP8266_RF2/RF2toMQTT"
        payload: "52166656"
        value_template: "{{ value_json.address }}"

    condition:
        condition: template
        value_template: "{{ trigger.payload_json['unit'] == 2 }}"

    action:
    - data:
        entity_id: light.my_n00_p01_light_l23_marokko
        transition: 0
      service_template:
        homeassistant.turn_on

Now my question is: what’s the best way to handle multiple conditions and actions:

I need an automation that does something like

case address == 52166656 AND unit == 1 AND switchType == 1
  turn on light A
case address == 52166656 AND unit == 1 AND switchType == 0
  turn off light A
case address == 52166656 AND unit == 2 AND switchType == 1
  turn on light B
case address == 52166656 AND unit == 2 AND switchType == 0
  turn off light B

etc…

What’s the best way to implement this?
Do I need multiple automations? Multiple conditions?
Can anybody point me to a simple example for this case?

kind regards,
Bart

[finity]

use “choose:”

[bartplessers]

top!

Right now, I created 10 automations
The only benefit of doing this is debugging: you can see exactly which button was pressed, because for each button there as an automation. But it’s a little bit overwhelming…

Are there some other benefits/drawbacks of using “choose”?

grtz
B

[finity]

The only drawback I can think of is the one you already mentioned - less readability.

But it isn’t too bad once you get used to it.

Or if you already have working automation and they are easy to read and maintain then just keep them like that.

[Markus99 (Mark)]

This is for my weather card, but you could convert for your needs. This builds a lookup array essentially. You could concatenate the values and then match this unique pair to the event you want to trigger…

      m99_weather_date_1d:
        value_template: "{{ (as_timestamp(strptime(states('sensor.date'),'%Y-%m-%d')) + (1*86400)) | timestamp_custom('%a') }}"
        icon_template: >
          {% set farray = { 'clear-day':'mdi:weather-sunny',
                            'clear-night':'mdi:weather-night',
                            'partly-cloudy-day':'mdi:weather-partly-cloudy',
                            'partly-cloudy-night':'mdi:weather-night-partly-cloudy',
                            'cloudy':'mdi:weather-cloudy',
                            'wind':'mdi:weather-windy',
                            'fog':'mdi:weather-fog',
                            'rain':'mdi:weather-rainy',
                            'snow':'mdi:weather-snowy',
                            'sleet':'mdi:weather-snowy-rainy'} %}
          {{ farray[states('sensor.darksky_weather_icon_1d')] }}

[tom_l]

This may be of some use to you:

Sonoff RF Bridge. Strategies for receiving data

Here are two strategies for receiving payloads published by a Sonoff RF Bridge (flashed with Tasmota firmware). Strategy 1: value_template In this strategy, all sensors are subscribed to the same topic published by the RF Bridge. The topic's structure depends on how you defined it when you configured *your* RF Bridge. This example will use `tele/RF_Bridge/RESULT`. Change that to whatever you have set for your Bridge. Because all sensors are subscribed to the same topic, a sensor will receive pa…

Different device, same requirements (I think).

[oscarb (Oscar 🇸🇪)]

I just did the same thing, let me share how I did it

My MQTT payload looked almost like yours, albeit a bit different:

{
    "model": "Nexa-Security",
    "id": 123456789,
    "channel": 3,
    "state": "ON",
    "unit": 3,
    "group": 0,
    "protocol": "Nexa",
    "rssi": -47,
    "duration": 448996
}

Of interest here is:

• id: the ID of the remote
• state: “ON” for turning something on and “OFF” when turning something off
• unit: from 1 to 3 depending on which button from top to bottom I pressed (my remote had 3 buttons)
• group: my remote has one “turn off all” button, when pressed this is 1, otherwise 0
• duration: how long the button was pressed, perhaps could be fun to use in an automation

So what I did was to split this up in two:

configuration.yaml

In my configuration.yaml I set up an MQTT Event so that all button presses make use of the newly introduced Event Entity. This way my automation doesn’t really know if the remote is using MQTT or something else which makes it easier to update the configuration in the future if I ever switch to some other remote.

mqtt:
  event:
    - name: Office Remote
      event_types: 
        - 'on' 
        - 'off'
      state_topic: "home/OMG_lilygo_rtl_433_ESP/RTL_433toMQTT/Nexa-Security/1/123456789"
      device_class: "button"
      value_template: |
        { 
          "button": "{{ value_json['id'] }}",
          "unit": "{{ value_json['unit']}}",
          "event_type": "{{ value_json['state'] | lower }}",
          "group": {{ iif(value_json['group']) | to_json }}
        }

This makes it so that whenever a button is pressed, the event entity event.office_remote is updated and includes attributes like button, unit, event_type and group (this will simply be true or false.

automations.yaml

So to make automations for this, check whenever the state of the event entity has changed.

- id: '000000001'
  alias: Turn light on/off when pressing remote
  mode: parallel
  trigger:
    - platform: state
      entity_id: event.office_remote
      variables:
        button1: light.office_desk
        button2: light.office_spotlights
        button3: light.office_corner
  action:
    - service: >
        {% if trigger.to_state.attributes.event_type == 'on' %}
          homeassistant.turn_on
        {% else %}
          homeassistant.turn_off
        {% endif %}
      target: 
        entity_id: >
          {% if trigger.to_state.attributes.group %}
            {{ [button1, button2, button3] }}
          {% else %}
            {% set i = trigger.to_state.attributes.unit | int - 1 %}
            {{ [button1, button2, button3][i] }}
          {% endif %}

In my automations, I’ve set up which (light) entity should correspond to each button row in the trigger section, then in the actions I simply check if it’s the “turn off all” press and return all the entities otherwise just the entity that corresponds to the button row pressed (“unit”).

Should scale well if you add more remotes but might need some tweaking if you want to do completely different things for the ON and OFF actions respectively.

Enjoy!