SwingV other modes
nagyrobi opened this issue · 9 comments
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.
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 -%}
@nagyrobi It seems that I misunderstood that it was normalized by IRremoteESP8266. I'll figure out how to fix this.
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.
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
select
s 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.
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.
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.
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.
Didn't have the chance to do comprehensive tests. Gimme a few days.
OK you are right, thank you.