Bonjour,

Depuis la mise à jour de fin octobre de HA (j'ai oublié de noter l'indice de version), sur mon tableau de bord, les commandes du volet roulant sont inversées (↑ descend le volet et ↓ le monte).
Depuis l'intégration dans HA (il y a environ 8 mois) tout fonctionnait normalement et il n'y a eu aucun intervention logicielle ou matérielle sur l'installation.

Le module de commande du volet est un « Yueyang » qui a été connecté électriquement au volet avec une inversion des fils montée et descente. Il fonctionne en Wifi et a été intégré dans l'applications "Tuya Smart" avec un paramétrage qui inverse la logique de fonctionnement (afin d'annuler l'inversion électrique). Donc, sur la télécommande matérielle comme dans l'application Tuya, les commandes sont tout à fait normales (↑ monte le volet et ↓ le descend).

À l'origine l'intégration dans HA (via le pont "Tuya") reproduisait ce fonctionnement normal, jusqu'à récemment, où à l'occasion de la mise à jour de HA, tout s'est retrouvé inversé.
J'ai rectifié les automatisations en inversant les actions "montée" et "descente", mais dans le tableau de bord, j'ai toujours les symboles inversés.

Ma question : à défaut de pouvoir identifier et traiter l'origine du problème, y aurait il un moyen de le contourner en inversant juste les symboles "↑" et "↓" dans le tableau de bord ?

Salut @BièreNard,

Le problème semble assez courant avec l’intégration Tuya dans Home Assistant, surtout après des mises à jour qui peuvent introduire des changements dans la gestion des entités “cover” (volets roulants). D’après ce que j’ai pu vérifier, plusieurs utilisateurs ont rapporté des inversions similaires de positions ou de commandes pour les volets Tuya, souvent liées à des mises à jour du core HA ou de l’intégration

Inverser uniquement les symboles ↑ et ↓ sur le tableau de bord (sans toucher au comportement sous-jacent) est possible mais compliqué : cela nécessiterait du CSS personnalisé via des thèmes Lovelace ou des mods comme card-mod, ce qui n’est pas trivial et pourrait casser lors de mises à jour. Au lieu de cela, une meilleure approche de contournement est de créer une entité “cover” template qui inverse complètement le comportement du volet original (position, état, et commandes open/close).

Cela corrigera les icônes sur le dashboard (les flèches suivront la logique inversée), et tu pourra ajuster les automatisations en conséquence pour revenir à une logique normale si needed.

Voici comment procéder :

1. Ajoute la configuration dans ta configuration.yaml (ou dans un fichier inclus via !include).

Assure-toi que l’intégration template est activée (elle l’est par défaut si tu a default_config:).


Exemple YAML pour un volet Tuya inversé (remplace cover.votre_volet_tuya par l’ID réel de ton entité volet, visible dans les outils de développement HA) :

template:
  - cover:
      - name: "Volet Inversé"
        device_class: shutter  # Pour un volet roulant
        state: >-
          {{ 'open' if is_state('cover.votre_volet_tuya', 'closed') else 'closed' }}
        position: >-
          {{ 100 - state_attr('cover.votre_volet_tuya', 'current_position') | default(0) | int }}
        open_cover:
          - service: cover.close_cover
            target:
              entity_id: cover.votre_volet_tuya
        close_cover:
          - service: cover.open_cover
            target:
              entity_id: cover.votre_volet_tuya
        stop_cover:
          - service: cover.stop_cover
            target:
              entity_id: cover.votre_volet_tuya
        set_cover_position:
          - service: cover.set_cover_position
            target:
              entity_id: cover.votre_volet_tuya
            data:
              position: "{{ 100 - position }}"

•  Explications :

•  state : Inverse l’état (ouvert → fermé, et vice versa).

•  position : Inverse la position (ex. : 80% devient 20%).

•  open_cover : Appelle la commande “fermer” de l’original pour “ouvrir” le template (et inversement pour close_cover).

•  set_cover_position : Inverse la position demandée avant de l’envoyer.
Redémarre HA ou recharge les templates pour que l’entité apparaisse.

Modifié 18 novembre 202518 nov. par XAV59213

Merci pour toutes tes explications XAV59213 !
En effet, ce que tu proposes et une bien meilleure solution que mon idée de bricolage du tableau de bord. J'ai donc essayé de la mettre en œuvre, mais mes compétences en HA sont plutôt limitées. Voici ce que j'ai fait :
- Ajout de ton code YAML dans la partie "default_config" de "configuration.yaml" (voir fichier joint) après avoir remplacé tous les "cover.votre_volet_tuya" par l'ID de mon volet "cover.volet_rue"
- Redémarrage HA - Une nouvelle entrée de nom "volet inversé" du type "template" avec l'ID "cover.volet_inverse" apparait dans l'onglet "Entrées" du menu "Paramètres"

==> Cette nouvelle entrée fonctionne parfaitement (montée/arrêt/descente dans le bon sens)
Mais :
Si j'essaye le menu "paramètres" , j'obtiens le message suivant :
Cette entité (« cover.volet_inverse ») n'a pas d'identifiant unique, par conséquent ses paramètres ne peuvent pas être gérés depuis l'interface utilisateur.
Consultez la documentation pour plus de détails.
Si je veux l'attribuer à une catégorie, j'obtiens le message suivant :
Vous ne pouvez pas attribuer une catégorie à cette automatisation
Pour attribuer une catégorie à une automatisation, celle-ci doit avoir un identifiant unique.

Donc, je ne comprends pas comment je peux l'utiliser dans mon tableau de bord et/ou dans les automatisations puisque je ne peux faire des actions que sur des appareils, pas sur des templates ou des entrées.

Où j'ai raté quelque chose ?
D'avance merci.
BièreNard

configuration.yaml

Salut @BièreNard,

Teste ce code, il manquait l’ID, ça devrait fonctionner.

# Loads default set of integrations. Do not remove.
default_config:

template:
  - cover:
      - unique_id: volet_rue_inverse_template  # Ajouté pour l'ID unique
        name: "Volet Inversé"
        device_class: shutter # Pour un volet roulant
        state: >-
          {{ 'open' if is_state('cover.volet_rue', 'closed') else 'closed' }}
        position: >-
          {{ 100 - state_attr('cover.volet_rue', 'current_position') | default(0) | int }}
        open_cover:
          - service: cover.close_cover
            target:
              entity_id: cover.volet_rue
        close_cover:
          - service: cover.open_cover
            target:
              entity_id: cover.volet_rue
        stop_cover:
          - service: cover.stop_cover
            target:
              entity_id: cover.volet_rue
        set_cover_position:
          - service: cover.set_cover_position
            target:
              entity_id: cover.volet_rue
            data:
              position: "{{ 100 - position }}"

# Load frontend themes from the themes folder
frontend:
  themes: !include_dir_merge_named themes

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

Modifié 18 novembre 202518 nov. par XAV59213

Génial ! ça fonctionne 👏
- Les flèches dans le tableau de bord sont synchro avec la position réelle du volet
- J'ai refait mes automatismes avec "actions" : ouverture (ouvrir/fermer) et "cible" "volet inversé", qui sont maintenant aussi conformes à l'état du volet

Merci encore, pour le travail, les explications détaillées et le temps passé 👍
Bièrenard59650

C’est toujours un plaisir d’aider😎

ATTENTION : le mot clé "service:" vient d'être remplacé par "action:" dans les versions récentes.

Cependant, depuis la version 2025.12, ce changement de sens des volets (Tuya) ne fonctionne plus. Il n'y a pour l'instant pas de correction du code de l'intégration Tuya.

Merci Burdi33 pour l'info : Je viens de faire la mise à jour HA "2025.12.2" et je confirme qu'avec l'intégration "Tuya" les volets ne fonctionnent plus (avec "service:" ou "action:" dans le script "yaml").

Du coup, dans l'urgence, j'ai basculé mes automatismes volets sur "Google Home" dont l'intégration 'Tuya" fonction toujours bien et ... dans le bon sens ;-)

Bon, si on résume avec HA :
. MAJ d'octobre : tout va bien !
. MAJ de novembre : les volets fonctionnent toujours, mais en sens inverse
. MAJ de décembre : les volets ne fonctionnent plus du tout
Vivement la MAJ de Janvier :-D

Salut @BièreNard

Peux tu tester cette version

template:
  - cover:
      - name: "Volet Inversé"
        unique_id: cover_volet_inversed  # optionnel mais recommandé
        device_class: shutter
        icon: mdi:roller-shade

        # État inversé
        state: >
          {% if is_state('cover.votre_volet_tuya', 'closed') %}
            open
          {% elif is_state('cover.votre_volet_tuya', 'open') %}
            closed
          {% else %}
            {{ states('cover.votre_volet_tuya') }}
          {% endif %}

        # Position inversée (0 → 100, 100 → 0)
        position: >
          {% set pos = state_attr('cover.votre_volet_tuya', 'current_position') | default(0) | int %}
          {{ 100 - pos }}

        # Tilt (facultatif, si ton volet gère l'inclinaison des lamelles)
        tilt: >
          {{ state_attr('cover.votre_volet_tuya', 'current_tilt_position') | default(50) | int }}

        # === ACTIONS CORRIGÉES avec "action:" au lieu de "service:" ===
        open_cover:
          - action: cover.close_cover
            target:
              entity_id: cover.votre_volet_tuya

        close_cover:
          - action: cover.open_cover
            target:
              entity_id: cover.votre_volet_tuya

        stop_cover:
          - action: cover.stop_cover
            target:
              entity_id: cover.votre_volet_tuya

        set_cover_position:
          - action: cover.set_cover_position
            target:
              entity_id: cover.votre_volet_tuya
            data:
              position: >-
                {{ 100 - position }}

        # Si ton volet gère les lamelles (tilt)
        set_cover_tilt_position:
          - action: cover.set_cover_tilt_position
            target:
              entity_id: cover.votre_volet_tuya
            data:
              tilt_position: "{{ tilt_position }}"

Modifié 12 décembre 202512 déc. par XAV59213

Salut XAV59213,

Merci pour ta nouvelle version !
Après pas mal de manips, je suis arrivé à rétablir le fonctionnement du volet et de ses 2 automatismes associés sous HA :
- remplacement du mode « backward » par « forward » pour la sélection du sens du moteur dans l’appli « Tuya » de gestion du module (malgré l'inversion des fils de commande du moteur qui reste inchangée).
- inversion des automatismes :
. ouverture automatique du matin : pour la montée du volet : choix de l'action « Tuya » de fermeture du volet
. fermeture automatique du soir  : pour la descente du volet : choix de l'action « Tuya » d’ouverture du volet

Par cohérence, il a été aussi nécessaire de reprogrammer l'affectation des boutons de la télécommande matérielle du volet, en associant le bouton "montée" à la fermeture et le bouton "descente" à l'ouverture du volet.

Ce soir c'est ma box HA qui devrait fermer mon volet et pas Monsieur Google depuis je ne sais où, et je préfère quand même çà ;-)

_______________________________________________________________________

Ah, au fait, j'ai oublié de te demander une petite précision :
Ton "template" ajouté dans "configuration.yaml" fait apparaître les "commandes inversées" du volet dans une carte "Ouverture" dans l'aperçu de mon réseau et je ne sais pas :
- où est paramétré cet intitulé "Ouverture"
- si je peux déplacer ces "commandes inversées" dans la carte de la pièce dans laquelle est située le volet ?

Modifié 13 décembre 202513 déc. par BièreNard
Ajout d'un complément

Bonjour BièreNard,

Chez-moi, c'est étrange !
Après de nombreux essais, j'ai réussi à tout faire fonctionner avec la dernière version du script de XAV59213, mais en inversant seulement le retour d'état et la position, mais sans inverser open_cover et close_cover !!!

Le code HA a du être à nouveau modifié, et les commandes ne sont plus inversées.
Par contre, il faut bien inverser les informations state: et position:
En effet, si je reprends les identités des entités sans inversion, les commande d'ouverture et de fermeture sont inversées, c'est à dire que lorsque mon volet est complètement fermé, la commande d'ouverture est grisée. Inversement, si le volet est complètement ouvert, la commande de fermeture est grisée.
J'ai du griller plusieurs neurones et plusieurs dolipranes dans cette histoire ! 😉