Centralisation de volets CPL et état

Bonjour à tous,

Mon problème

J’ai un petit souci avec l’automatisation de mes volets roulets. Malheureusement, j’ai une installation centralisée équipée de volets Legrand In-One (sic).
La centralisation est réalisée à partir d’un interrupteur qui pilote les volets en CPL (Legrand 770 24) :

Et les volets reçoivent le signal CPL :

Avec une idée derrière la tête, j’ai acheté un module Fibaro FGR224, Z-Wave pour piloter cet centralisation :

Plutôt que de câbler comme cela est recommandé, j’ai essayé ceci :

Vu que je n’ai pas de sorties sur mon interrupteur centralisé (E1 et E2 sont des entrées), je n’ai pas câblé S1 et S2 du module Fibaro.
En effet, ça reste l’interrupteur qui pilote les volets, et pas le module Fibaro.

Tout à l’air de fonctionner : j’arrive à piloter les volets depuis l’interrupteur mural et depuis HA.
Mais j’ai tout de même un problème : Dans HA, la position des volets est mémorisée en fonction de la dernière commande qui est passée : si c’est une commande de montée, alors seule la commande de descente est disponible :

05 - HA

Ça me pose un problème, parce que HA ne connait pas la position réelle de mes volets lorsque je les commande à l’interrupteur.
Y-a-t’il un moyen d’avoir les 2 commandes disponibles ?
Sinon, j’ai vu qu’on pouvait forcer l’état d’une entité dans Outils de développement > Etats. Je pensais utiliser cette fonction pour définir un état avant de lancer la commande. (Exemple : définir un état fermé avant de demander une montée.)

Malheureusement, je débute et je ne sais absolument pas comment faire.
Quelqu’un pour m’aider ?

Merci à vous.


System Information

version core-2025.7.0
installation_type Home Assistant OS
dev false
hassio true
docker true
container_arch aarch64
user root
virtualenv false
python_version 3.13.3
os_name Linux
os_version 6.6.74-haos-raspi
arch aarch64
timezone Europe/Paris
config_dir /config
Home Assistant Community Store
GitHub API ok
GitHub Content ok
GitHub Web ok
HACS Data ok
GitHub API Calls Remaining 5000
Installed Version 2.0.5
Stage running
Available Repositories 2080
Downloaded Repositories 4
Home Assistant Cloud
logged_in false
can_reach_cert_server ok
can_reach_cloud_auth ok
can_reach_cloud ok
Home Assistant Supervisor
host_os Home Assistant OS 15.2
update_channel stable
supervisor_version supervisor-2025.06.2
agent_version 1.7.2
docker_version 28.0.4
disk_total 57.8 GB
disk_used 4.5 GB
healthy true
supported true
host_connectivity true
supervisor_connectivity true
ntp_synchronized true
virtualization
board rpi3-64
supervisor_api ok
version_api ok
installed_addons Plex Media Server (3.6.4), File editor (5.8.0), Terminal & SSH (9.18.0), Z-Wave JS (0.17.0)
Dashboards
dashboards 2
resources 2
views 1
mode storage
Network Configuration
adapters lo (disabled), enu1u1 (enabled, default, auto), hassio (disabled), docker0 (disabled), veth86aafb5 (disabled), vethcd7e843 (disabled), vetha358845 (disabled), veth3e7f476 (disabled), veth1f64272 (disabled), veth49b3b3a (disabled), veth8025cd8 (disabled), veth7e8989e (disabled), veth1158abf (disabled)
ipv4_addresses lo (127.0.0.1/8), enu1u1 (192.168.1.75/24), hassio (172.30.32.1/23), docker0 (172.30.232.1/23), veth86aafb5 (), vethcd7e843 (), vetha358845 (), veth3e7f476 (), veth1f64272 (), veth49b3b3a (), veth8025cd8 (), veth7e8989e (), veth1158abf ()
ipv6_addresses lo (::1/128), enu1u1 (2a01:cb10:971:9a00:7748:ae92:14e:eb8d/64, fe80::c4ae:58b2:9141:daf7/64), hassio (fe80::a820:9cff:fe22:d7c9/64), docker0 (fe80::9811:8aff:fe96:b5b5/64), veth86aafb5 (fe80::9492:54ff:fea7:a3e3/64), vethcd7e843 (fe80::40af:8ff:fe27:4c82/64), vetha358845 (fe80::f0a5:a2ff:feed:e095/64), veth3e7f476 (fe80::b0de:6aff:fe1c:847c/64), veth1f64272 (fe80::4ce0:f4ff:fe0d:a2c1/64), veth49b3b3a (fe80::3877:3ff:fe66:6bea/64), veth8025cd8 (fe80::bc2e:4ff:fe74:2504/64), veth7e8989e (fe80::a811:a0ff:fe89:f1f8/64), veth1158abf (fe80::a8a0:58ff:fe3f:cbfd/64)
announce_addresses 192.168.1.75, 2a01:cb10:971:9a00:7748:ae92:14e:eb8d, fe80::c4ae:58b2:9141:daf7
Recorder
oldest_recorder_run 3 juillet 2025 à 15:39
current_recorder_run 5 juillet 2025 à 00:08
estimated_db_size 3.37 MiB
database_engine sqlite
database_version 3.48.0

je ne suis pas électricien mais je vois sur ton schéma de câblage le retour d’état du volet n’est pas cabler et Le CPL n’est pas bidirectionnel dans ce cas (pas de retour d’état)
solution a mon avis c’est d’ajouter un capteur d’ouverture pour une détection de fin de cours

Merci pour ta réponse. En effet, l’interrupteur fin de course peut être une idée à creuser.
Je débute, as-tu des références à me proposer ?
Je pense considérer que si le volet monitoré n’est pas en position fermée (ouvert ou en position intermédiaire), c’est qu’ils sont tous ouverts.
=> Comment faire pour forcer la position de l’entité centralisée en fonction du retour d’état de ce capteur ?

Par contre, ça m’embête surtout pour l’automatisation: j’ai programmé l’ouverture des volets roulants à une heure donnée, mais si la veille, j’ai fermé manuellement, ils ne s’ouvriront pas.
=> Une autre solution serait d’envoyer une commande de fermeture une minute avant l’heure désirée d’ouverture, mais ça me semble un peu bête de faire comme ça: Je préférerais jouer sur l’état de l’entité une minute avant.

deux capteurs de fin de course mécanique (si tu bricoles bien ) avec un esphome tu peut faire des merveille tu pourras avoir la position exacte en % .si non un simple capteur de contact magnétique, plug&play Ex : Aqara, Sonoff SNZB-04 (Zigbee), Shelly Door/Window (WiFi)

il faudra peut être penser a changer ton interrupteur par un bouton poussoir

Merci hackdiy,

Je vais regarder ce qu’il se fait au niveau des contacts magnétiques. Je choisirais en fonction de l’épaisseur du capteur je pense.
Etant donné que l’interrupteur ne me permet pas d’avoir des positions intermédiaires (bouton STOP non géré), c’est pas nécessaire que je mette en place 2 capteurs, mais ça aurait été un plus non négligeable.

En ce qui concerne l’interrupteur, le contact est impulsionnel pour la gestion de la commande via CPL, c’est donc déjà un poussoir (Céliane)

Tu n’as pas de position STOP intermédiaire (ni via le Fibaro, ni manuellement),
un seul capteur (en bas de course, par exemple) te donne une info suffisante pour estimer le groupe entier. Le Sonoff SNZB-04 Zigbee ~7 mm je pense que c’est le moins épais.
A placer en haut pour l’état / ouvert ou en bas / fermer il faudra utiliser template cover pour les adapter au bon retour d’état.

Faut penser aussi qu’un capteur sur pile a tendance a prendre un coup , selon les contraintes météo , les capteurs sur pile elle sont généralement destiner pour un usage intérieur .
Exemple:

  • Sonoff SNZB-04
  • -10°C à +40°C
  • Non IP
  • Usage intérieur
  • Dimensions du module : 50,5mm x 32mm x 21.9mm (LxlxH)
  • Aimant : 27mm x 12mm x 12.4mm (LxlxH)

AQARA - Détecteur d’ouverture porte/fenêtre Zigbee 3.0 Door and Window Sensor T1 MCCGQ12LM

  • Dimensions : 41 × 22 × 11 mm
  • Distance de détection maximale : 22 mm
  • Température de fonctionnement : -10 °C ~ 45 °C

Le Aqara est plus petit.

C’est la taille de l’aiment ça :crazy_face:
Tu me chercher en ce moment :rofl:

non, l’aimant fait 25x11x10 :wink:
Dimensions : 41 × 22 × 11 mm, c’est la taille du module.

du tout :wink:

L’ancien modèle MCCGQ11LM

  • Dimensions : 4 x 2,1 x 1,5cm (Partie principale) 2,5 x 1 x 1cm (Aimant)
1 « J'aime »

Je te taquine , :kissing_heart: courage

1 « J'aime »

Je viens de mesurer, j’ai 14mm, donc ça passe large :rofl: !
Par contre, je n’avais pas pensé à la contrainte de température…
C’est peut-être un peu moins extrême dans le caisson du VR, mais c’est tricky à mettre en place, et bien moins fiable…

Par contre, le mettre en haut du VR ça va créer des problèmes à l’enroulement, non ? C’est pas plus simple de le mettre en bas ?

Au final, je me demande si ce n’est pas plus simple de jouer sur l’état, et de forcer l’état inverse à celui désiré juste avant la programmation de montée/descente.