Bonjour suite a l installation de 2 modules QS-Zigbee-C03 pour volet roulant , je suis confronter a un probleme pour mon deuxieme module .
pour faire simple « physiquement » le volet souvre et se ferme correctement mais dans HA quand le volet est fermé l etat sur le dashboard reste ouvert car il manque 1% de fermeture .
j ai essayer de calibrer descente puis monté , monté puis descente , seulement monté ou seulement descente . toujour se probleme de 1% manquant a la descente , si quelqu un a une idée .
!
[center]## System Information
| version |
core-2025.3.2 |
| installation_type |
Home Assistant OS |
| dev |
false |
| hassio |
true |
| docker |
true |
| user |
root |
| virtualenv |
false |
| python_version |
3.13.2 |
| os_name |
Linux |
| os_version |
6.6.62-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 |
1588 |
| Downloaded Repositories |
3 |
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 14.2 |
| update_channel |
stable |
| supervisor_version |
supervisor-2025.03.2 |
| agent_version |
1.6.0 |
| docker_version |
27.2.0 |
| disk_total |
116.7 GB |
| disk_used |
5.3 GB |
| healthy |
true |
| supported |
true |
| host_connectivity |
true |
| supervisor_connectivity |
true |
| ntp_synchronized |
true |
| virtualization |
|
| board |
rpi4-64 |
| supervisor_api |
ok |
| version_api |
ok |
| installed_addons |
Mosquitto broker (6.5.0), File editor (5.8.0), Zigbee2MQTT (2.1.3-1), Terminal & SSH (9.16.0), Let’s Encrypt (5.4.3), NGINX Home Assistant SSL proxy (3.11.1), Duck DNS (1.18.0), tiko / Mon Pilotage Elec (2.0.0), ZigStar TI CC2652P/P7 FW Flasher (0.4.1) |
Dashboards
| dashboards |
1 |
| resources |
1 |
| views |
4 |
| mode |
storage |
Network Configuration
| adapters |
lo (disabled), end0 (enabled, default, auto), hassio (disabled), docker0 (disabled), veth33aedb4 (disabled), veth0bdb9a8 (disabled), veth5812918 (disabled), vethcf2a9b9 (disabled), vetha17a43c (disabled), veth90b9a4e (disabled), veth46946f6 (disabled), vethdac9be9 (disabled), veth75cab6d (disabled), veth13e8e0b (disabled), veth99e1b79 (disabled), veth7e3e851 (disabled) |
| ipv4_addresses |
lo (127.0.0.1/8), end0 (192.168.1.184/24), hassio (172.30.32.1/23), docker0 (172.30.232.1/23), veth33aedb4 (), veth0bdb9a8 (), veth5812918 (), vethcf2a9b9 (), vetha17a43c (), veth90b9a4e (), veth46946f6 (), vethdac9be9 (), veth75cab6d (), veth13e8e0b (), veth99e1b79 (), veth7e3e851 () |
| ipv6_addresses |
lo (::1/128), end0 (2a02:8429:8c32:2c01:2daf:6d04:ca7c:93ed/64, fe80::f8d6:f876:bf30:c2ad/64), hassio (fe80::42:ceff:fe78:8032/64), docker0 (fe80::42:71ff:fe18:8551/64), veth33aedb4 (fe80::20db:86ff:fe62:ee96/64), veth0bdb9a8 (fe80::6c52:77ff:fe68:f14f/64), veth5812918 (fe80::cc18:b3ff:fe26:4bd/64), vethcf2a9b9 (fe80::64b1:68ff:febc:a3dc/64), vetha17a43c (fe80::f824:c6ff:fe7b:accd/64), veth90b9a4e (fe80::d430:74ff:fe28:260d/64), veth46946f6 (fe80::ec77:e3ff:fee6:af9d/64), vethdac9be9 (fe80::6c3a:ddff:fe66:916e/64), veth75cab6d (fe80::f4ae:e2ff:fe89:7e90/64), veth13e8e0b (fe80::bc60:94ff:fe92:db05/64), veth99e1b79 (fe80::34b8:acff:fe7e:a08a/64), veth7e3e851 (fe80::2808:caff:fe53:f422/64) |
| announce_addresses |
192.168.1.184, 2a02:8429:8c32:2c01:2daf:6d04:ca7c:93ed, fe80::f8d6:f876:bf30:c2ad |
Recorder
| oldest_recorder_run |
2 mars 2025 à 18:22 |
| current_recorder_run |
11 mars 2025 à 19:04 |
| estimated_db_size |
143.41 MiB |
| database_engine |
sqlite |
| database_version |
3.48.0 |
Sonoff
| version |
3.8.2 (c4b6fda) |
| cloud_online |
5 / 10 |
| local_online |
5 / 5 |
[/center]
___
Salut,
tu a bien lu la doc Zigbee2MQTT qui explique la procedure de comment effectuer l’étalonnage du module ?
oui parfaitement si je me trompe pas c est toi qui m avais donner le lien , mais leur manip n est pas bonne car le temp de monté et le temp de descente ne sont pas les memes et la calibration n enregistre qu un seul temp .
mais j ai trouver sur le forum comment faire en trichant sur le temp de monté et cela fonctionne tres bien .
c est seulement sur un volet que cela ne fonctionne pas , il bloque a 1% malgré la fermeture total du volet et bien 4 sec de delai entre fermeture volet et claquement du relai .
je vais peut etre tenter ce soir une reinnitialisation du module on ne c est jamais .
Bonjour,
J’ai le même problème avec un module moes volant roulant (Zigbee + RF curtain switch module (MS-108ZR)
Pour compenser ce bug, j’ai fait une automation comme ceci :
alias: Bug - Statut - Volet garage - Close
description: ""
triggers:
- trigger: numeric_state
entity_id:
- cover.volet_garage
attribute: current_position
below: 1
conditions: []
actions:
- action: cover.stop_cover
metadata: {}
data: {}
target:
entity_id: cover.volet_garage
mode: single
@Jeffodilo je te remercie de ton retour , etant novice j avoue que je n aurais pas penser a faire une automatisation pour « leurer » le bug .
j ai reproduit la meme que toi et effectivement cela fonctionne tres bien j ai bien le retour d etat fermé maintenant .
je trouve ca quand meme bizarre que sur les deux modules un c est appairer sans probleme et le deuxieme a bugger .
merci pour la combine
1 « J'aime »
