SwingV other modes

[nagyrobi]

I have GREE units, and these have auto, off, min, max, mid possible modes for SwingV, as reported by Tasmota's IrHvac.
Unfortunately here we have it restricted to only off, auto, highest, high, middle, low, lowest.

Would be nice if this list would be also configurable so the user could specify the list for SwingV, SwingH corresponding to her/his model. Or maybe it would just be enough to add the missing modes to the list above and the services selector.

[nagyrobi]

Here's how I try to use it with a template select:

template:
  select:
    - name: Hálózsoba klíma legyezés
      unique_id: haloszoba_klima_vswing_uuid
      availability: "{{ states('climate.haloszoba_klima') not in ['unavailable', 'unknown'] }}"
      icon: mdi:swap-vertical-bold
      options: "{{ ['Ki', 'Automatikus', 'Lassú', 'Közepes', 'Gyors'] }}"
      state: >
          {% if is_state_attr('climate.haloszoba_klima', 'fix_swingv', 'off') %}
          Ki
          {%-elif is_state_attr('climate.haloszoba_klima', 'fix_swingv', 'auto') %}
          Automatikus
          {%-elif is_state_attr('climate.haloszoba_klima', 'fix_swingv', 'min') %}
          Lassú
          {%-elif is_state_attr('climate.haloszoba_klima', 'fix_swingv', 'max') %}
          Gyors
          {%-elif is_state_attr('climate.haloszoba_klima', 'fix_swingv', 'mid') %}
          Közepes
          {% endif %}
      select_option:
        - service: tasmota_irhvac.set_swingv
          target:
            entity_id: climate.haloszoba_klima
          data:
            swingv: >
                {% if option == "Automatikus" -%}
                auto
                {% elif option == 'Ki' -%}
                off
                {% elif option == 'Lassú' -%}
                min
                {% elif option == 'Közepes' -%}
                mid
                {% elif option == 'Gyors' -%}
                max
                {% endif -%}

[nao-pon]

@nagyrobi It seems that I misunderstood that it was normalized by IRremoteESP8266. I'll figure out how to fix this.

[nagyrobi]

Also do I understand correctly that fix_swingv attribute shows the SwingV mode, while swingv attribute is just like an ON/OFF with values from swing_modes?

Why not just let us simply merge all the possible SwingV modes under swing_modes and use swingv to see the current one?
I know it can be SwingH and that can also have modes, but the vast majority of the devices have only one way to swing... Benefit would be that it would appear in HA's climate card.

[nagyrobi]

Moreover, I'd use a custom swing dict in the config for the users to manually map friendly swing names to both SwingV and SwingH modes of IRremoteESP8266, to populate the swing_modes of the entity.

Config example:

  supported_swing_modes:
    SwingV:
      - auto: "Automatik"
      - off: "Off"
      - min: "Vertical slow"
      - mid: "Vertical medium"
      - max: "Vertical fast"
    SwingH:
      - min: "Horizontal slow"
      - mid: "Horizontal medium"
      - max: "Horizontal fast"

would result in entity attribute:

  swing_modes:
    - Automatik
    - Off
    - Vertical slow
    - Vertical medium
    - Vertical fast
    - Horizontal slow
    - Horizontal medium
    - Horizontal fast

presenting the friendly names towards HA instead of the IrHvac keys. That would be beneficial in multiple aspects:

• various devices could be added with any type of swings (not strictly only the ones suggested by HA api or IRremoteESP8266)
• these would appear with names preferred by the user
• Vertical and Horrizontal swing options would be all combined in the same dropdown of the official HA user interface, no need to create selects etc. Can be the same keys of IrHvac, but the user can name them differently for HA.
• language issues could be easily handled

When a user selects an entry from under SwingV, the payload will contain SwingV. When a user selects an entry from under SwingH, the payload will contain SwingH. All transparently.
But in HA, the swing_mode will show the friendly name selected by the user. No need to handle swingv and swingh in HA separately.

[nao-pon]

After a quick look at the source, it seems that there is still some normalization going on. Test if you can control the device by sending "off", "auto", "highest", "high", "middle", "low" or "lowest" on the tasmota_irhvac.set_swingv service. can you please?

Also, creating a list in swing_modes is not currently considered. In reality, horizontal and vertical combinations exist, giving you a lot of options. It's not realistic unless HA Climate includes horizontal swing control.

[nao-pon]

I tried with my Panasonic air conditioner to see if SwingV is normalized. Here is the result of sending "max", "min", "mid" from the tasmota_irhvac.set_swingv service, which seems to be unsupported by Panasonic.

Service data |  MQTT stat payload
swingv: max  |  "SwingV":"Highest"
swingv: min  |  "SwingV":"Lowest"
swingv: mid  |  "SwingV":"Middle"

Based on this result, the normalization seems to work correctly.

[nao-pon]

If the normalization is working, I'd like to take action to remove the value limit.
If the normalization is not working then I also need to add service options.

[nagyrobi]

Didn't have the chance to do comprehensive tests. Gimme a few days.

[nagyrobi]

OK you are right, thank you.