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 :
Ç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 
Tu me chercher en ce moment 
non, l’aimant fait 25x11x10 
Dimensions : 41 × 22 × 11 mm, c’est la taille du module.
du tout
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 viens de mesurer, j’ai 14mm, donc ça passe large !
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.
Je aurait une préférence pour la fin de course fermé ( plus sur ) .
Forcer un état virtuel dans HA , c’est une idée mais vraiment pas fiable a 100% elle reste acceptable pour des tests pas pour le long terme.
Je commence à comprendre que mon installation n’est pas idéale du tout… 
J’envisage (si le coût est raisonnable), de rajouter un micro-module ZigBee (ou autre) ou même de remplacer chacun de mes 6 interrupteurs individuels, ainsi que pour ma centralisation.
Je comptais partir là-dessus :
Une contre-indication ou une alternative à me proposer ?
J’ai fini par ajouter des interrupteurs Meross MRS105 en Matter sur chaque volet…
Par contre, j’ai un soucis au niveau de la centralisation: je pensais pouvoir utiliser l’un de ces interrupteur pour centraliser le tout, et j’ai défini une automatisation en ce sens.
Ça fonctionne bien via l’appli. Par contre en physique, les volets ne se ferment qu’après la tempo de montée/descente (10s min)…
Une idée pour contourner ça ?
C’est bon, j’ai trouvé. On peut réduire à 1s avec l’intégration Meross dans HA. Ça me va parfaitement
courage