Mon problème
Bonjour à tous !
Un problème m’a foi fort étrange…
Ma config est assez simple pour l’instant :
- HA installé sur RPI5 équipé d’un module usb sonoff 3 pour le Zigbee
- Un module contact sec zigbee (marque Girier)
J’ai une automatisation qui allume le module sur une plage horaire et l’éteint en dehors.
Mais là n’est pas le problème…
Ce matin, mon automatisation a bien éteint mon module, mais il s’est auto-rallumé.
Et quand j’essaie de l’éteindre manuellement, il s’auto-rallume…
Est-ce qu’il y aurait des logs quelque part pour me permettre de creuser ce problème ? Ou un fonction fail-safe qui met le module par défaut en position allumé ?
EDIT : Le système avait déjà fait un cycle complet via l’automatisation et aucun soucis jusqu’à présent…
En vous remerciant o/
Ma configuration
[center]## System Information
| version |
core-2024.4.3 |
| installation_type |
Home Assistant OS |
| dev |
false |
| hassio |
true |
| docker |
true |
| user |
root |
| virtualenv |
false |
| python_version |
3.12.2 |
| os_name |
Linux |
| os_version |
6.1.73-haos-raspi |
| arch |
aarch64 |
| timezone |
Europe/Paris |
| config_dir |
/config |
Home Assistant Community Store
| GitHub API |
ok |
| GitHub Content |
ok |
| GitHub Web |
ok |
| GitHub API Calls Remaining |
5000 |
| Installed Version |
1.34.0 |
| Stage |
running |
| Available Repositories |
1400 |
| Downloaded Repositories |
2 |
| HACS Data |
ok |
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 12.1 |
| update_channel |
stable |
| supervisor_version |
supervisor-2024.04.0 |
| agent_version |
1.6.0 |
| docker_version |
24.0.7 |
| disk_total |
28.5 GB |
| disk_used |
7.4 GB |
| healthy |
true |
| supported |
true |
| board |
rpi5-64 |
| supervisor_api |
ok |
| version_api |
ok |
| installed_addons |
ESPHome (2024.3.2), Terminal & SSH (9.10.0), Duck DNS (1.16.0), File editor (5.8.0), Tailscale (0.17.0) |
Dashboards
| dashboards |
3 |
| resources |
0 |
| views |
2 |
| mode |
storage |
Recorder
| oldest_recorder_run |
10 avril 2024 à 11:51 |
| current_recorder_run |
14 avril 2024 à 18:25 |
| estimated_db_size |
1.73 MiB |
| database_engine |
sqlite |
| database_version |
3.44.2 |
[/center]
___
Tu as pas un paramètre de ton module qui règle le retour à l’état précédent. C’est souvent le cas pour les modules contact sec.
Bonne remarque !
Je suis allé fouiner dans les paramètre de l’appareil, et l’attribut qui y ressemble le plus est celui là.
Je l’ai passé à bool.false, mais cela n’a rien changé
Et après redémarrage de HA, il est retourné à bool.on
Sur le principe, c’est quand même fou. Le module s’auto rallume tout seul ^^".
Si c’était des lumières connectées, la situation serait très rigolote…
Tu es sûr qu’il n’y a pas des micro coupures ?
Effectivement, ca sent les micro coupures… Est-ce qu’il y a une manière d’évaluer la qualité de la connexion avec HA ?
Mon RPI est dans la maison et le module zigbee dans la cave, séparé par 1.5m d’épaisseur de mur en pierre. J’avais déjà rapproché mon RPI au maximum, mais ce n’est peut être pas suffisant.
J’ai tenté de :
- Appuyer sur le reset du module => Rien ne change
- Utiliser le mode interrupteur physique => Rien ne change du point de vue de HA
- Ramener dans la maison à proximité du RPI => Fonctionnement revenu à la normal
Il faut peut être que je densifie un peu plus mon reseau zigbee pour améliorer la qualité du signal et la perte de données.
Je pensais ajouter quelques prises Zigbee et module sur le chemin
Les coupures réseau zigbee n’influence pas les actions des modules. Je pensais plus a des coupures électriques.
C’est vrai que j’ai pas mal de micro coupure electrique sur le reseau (merci Enedis d’avoir sous dimensionné les câbles électrique au poteau).
J’ai commandé un paquet de module Zigbee à disposer le long du trajet entre le RPI et celui dans la cave.
Et une rallonge usb pour séparer le controlleur zigbee du RPI.
Affaire à suivre…
Salut,
Après quelques tests, voici ma conclusion :
-
L’intégration ZHA de HA n’est pas assez complète et ne gère pas les pertes de signaux correctement. En passant sur ZigBee2MQTT, on a accès à certaines options (type de switch, position par défaut au démarrage, …)
Et surtout, on peut demander à afficher la carte du réseau, avec la qualité de la connexion !
-
Les modules que j’ai utilisé sont « sans neutre », le problème est que pour qu’il soit correctement alimenté, il faut une fuite résiduelle de courant, ce que n’offre pas de manière stable mon ballon thermodynamique.
En résumé, je passe sur un switch zigbee neutre+phase et je recommende ZigBee2MQTT
