Certaines prises NOUS AZ1 trop bavardes - migration ZHA vers Z2M

Bonjour,

Mon problème

j'ai migré récemment de ZHA vers Z2M, et je constate que 2 prises NOUS AZ1 (sur 4) polluent les logs avec des messages incessants.
sur les 2 qui fonctionnent, j'ai pu paramétrer le "child lock" et défini un throttle à 30s, et elles publient des topics périodiquement , au bon rythme
les 2 autres ont également un throttle défini, mais ne prennent pas en compte le réglage du "child lock" (il reste à "unknown") et le LQI oscille entre 196 et 201 chaque seconde
J'ai l'impression que leur configuration ne s'est pas bien faite lors de leur inclusion

pour ne pas risque de bloquer la VM à cause du traffic, j'ai supprimé ces deux prises dans Z2M : elle avaient environ 5 msg/s

je ferai une nouvelle tentative demain, quitte à les rapprocher de la clé si besoin, mais l'un de vous a déjà rencontré ce type de cas ??

Ma configuration


[## System Information

version core-2026.9.2
installation_type Home Assistant OS
dev false
hassio true
docker true
container_arch amd64
user root
virtualenv false
python_version 3.14.6
os_name Linux
os_version 6.18.39-haos
arch x86_64
timezone Europe/Paris
config_dir /config
Home Assistant Cloud
logged_in false
can_reach_cert_server ok
can_reach_cloud_auth ok
can_reach_cloud ok
HACS
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 4126
Downloaded Repositories 18
Home Assistant Supervisor
host_os Home Assistant OS 18.2
update_channel stable
supervisor_version supervisor-2026.09.2
agent_version 1.10.0
docker_version 29.6.2
disk_total 30.8 GB
disk_used 8.6 GB
nameservers 2a01:cb00:12b:5e00:2237:f0ff:fe37:9f30, 192.168.1.1, fe80::2237:f0ff:fe37:9f30
healthy true
supported true
host_connectivity true
supervisor_connectivity true
ntp_synchronized true
virtualization kvm
board ova
supervisor_api ok
version_api ok
installed_addons File editor (6.1.0), Matter Server (9.2.0), Mosquitto broker (7.1.1), Z-Wave JS (1.8.1), Zigbee2MQTT (2.14.1-1)
Dashboards
dashboards 7
resources 13
views 4
mode storage
Network Configuration
adapters lo (disabled), enp0s3 (enabled, default, auto), docker0 (disabled), hassio (disabled), vethd1e13ab (disabled), vethb0f025d (disabled), veth1c7fe18 (disabled), veth4552ac9 (disabled), veth1db4720 (disabled), vetha7fa584 (disabled), veth40951fc (disabled), veth929a140 (disabled), vethcc52624 (disabled), vethb0e713b (disabled), vetha931c89 (disabled)
ipv4_addresses lo (127.0.0.1/8), enp0s3 (192.168.1.9/24), docker0 (172.30.232.1/23), hassio (172.30.32.1/23), vethd1e13ab (), vethb0f025d (), veth1c7fe18 (), veth4552ac9 (), veth1db4720 (), vetha7fa584 (), veth40951fc (), veth929a140 (), vethcc52624 (), vethb0e713b (), vetha931c89 ()
ipv6_addresses lo (::1/128), enp0s3 (2a01:cb00:12b:5e00:a6c1:86c0:9f01:29b4/64, fe80::b844:60c2:59d1:b4e/64), docker0 (fd81:9443:439c::1/64, fe80::408a:41ff:fe6a:726/64), hassio (fd0c:ac1e:2100::1/48, fe80::84a0:4dff:fe52:da1f/64), vethd1e13ab (fe80::906f:cdff:fe2e:d314/64), vethb0f025d (fe80::6c0c:53ff:fe31:8462/64), veth1c7fe18 (fe80::4869:c4ff:fe77:e7ff/64), veth4552ac9 (fe80::8ce6:8ff:fef6:715b/64), veth1db4720 (fe80::8815:f1ff:fee7:8ed3/64), vetha7fa584 (fe80::3c50:a4ff:feb9:5e0c/64), veth40951fc (fe80::1cc0:f9ff:fea1:f9de/64), veth929a140 (fe80::87d:b0ff:fe8b:7208/64), vethcc52624 (fe80::74e1:acff:fe6c:dade/64), vethb0e713b (fe80::e40b:3fff:fec5:2ea1/64), vetha931c89 (fe80::d00a:dcff:fe9c:80bd/64)
announce_addresses 192.168.1.9, 2a01:cb00:12b:5e00:a6c1:86c0:9f01:29b4, fe80::b844:60c2:59d1:b4e
Recorder
oldest_recorder_run 6 septembre 2026 à 20:16
current_recorder_run 13 septembre 2026 à 16:53
estimated_db_size 74.28 MiB
database_engine sqlite
database_version 3.53.2
___

j'ai comparé les informations d'état d'une prise qui fonctionne noirmalement

{
    "child_lock": "UNLOCK",
    "countdown": 0,
    "current": 0,
    "energy": 69.46,
    "indicator_mode": "on",
    "last_seen": "2026-09-17T21:22:45.877Z",
    "linkquality": 255,
    "power": 0,
    "power_outage_memory": "restore",
    "state": "OFF",
    "switch_type_button": "press",
    "update": {
        "installed_version": 80,
        "latest_release_notes": null,
        "latest_source": null,
        "latest_version": 80,
        "state": "idle"
    },
    "voltage": 236,
    "identify": null
}

avec celles qui débloquent :

{
    "countdown": 0,
    "current": 0,
    "energy": 00.00,
    "indicator_mode": "on",
    "last_seen": "2026-09-17T21:22:45.877Z",
    "linkquality": 201,
    "power": 0,
    "power_outage_memory": "restore",
    "state": "OFF",
    "switch_type_button": "press",
    "update": {
        "installed_version": 80,
        "latest_release_notes": null,
        "latest_source": null,
        "latest_version": 80,
        "state": "idle"
    },
    **"child_lock": null,**
    "voltage": 236,
    "identify": null
}

Pas fait gaffe sur les miennes. Elles ont la même version de FW ?

bien vu : j'ai réintégré l'une des deux qui posait problème, et son firmware est "-1" dans le "a propos", et la page OTA indique non évalué (not assessed), alors que les autres indiquent "build 80"
la colonne "id du firmware" est dans tous les cas "non pris en charge"

je pensais qu'elles étaient toutes d'un même lot, mais j'ai un doute...

j'ai l'impression que le comportement est encore un peu différent, peut être parce que je n'ai intégré qu'une prise à la fois (le "child lock" est bien affiché, même s'il ne semble pas bien géré)

J'ai tenté une mise à jour du FW , cela a fait passer au même niveau "80" que les autres

cela se confirme dans l'état :

{
    **"child_lock": "UNLOCK"**,
    "countdown": 0,
    "current": 0,
    "energy": 0.14,
    "indicator_mode": "off/on",
    "last_seen": "2026-09-18T20:38:41.902Z",
    "linkquality": 229,
    "power": 0,
    "power_outage_memory": "restore",
    "state": "OFF",
    "switch_type_button": "press",
    "voltage": 236,
    "identify": null,
    "update": {
        **"installed_version": 80,**
        "latest_release_notes": null,
        "latest_source": null,
        "latest_version": 80,
        "state": "idle"
    }
}

elle semble aussi calme que les autres, mais impossible de retrouver le tableau donnant l'état de santé des appareils, qui indiquait le nb de messages par seconde pour chacun, :thinking:

edit : retrouvé , dans Z2M/Paramètres/Santé
et effectivement, la prise est "calme", moins de 0,02 msg/s, comme les autres

je ferai le test ce weekend de rajouter la 4ème, pour essayer de vérifier sic'est d'avoir forcé un mise à jour qui remet le débit en ordre

test effectué, en lançant l'inclusion avec la prise proche de la clé (1m au lieu de 3m)

le flux de message au début a finalement diminué pour se caler vers 0,05msg/sec, contre environ 0,015 pour les autres prises, et ce sans que je force de mise à jour
cf l'état affiché

{
    "child_lock": "UNLOCK",
    "countdown": 0,
    "current": 0,
    "energy": 7.12,
    "indicator_mode": "off/on",
    "last_seen": "2026-09-19T11:17:30.043Z",
    "linkquality": 201,
    "power": 0,
    "power_outage_memory": "restore",
    "state": "OFF",
    "switch_type_button": "press",
    "voltage": 237,
    "identify": null,
    "update": {
        "installed_version": -1,
        "latest_version": -1,
        "state": null
    }
}

donc le flux ne s'est pas calmé pour cela, et j'ai pu régler le "child lock" sans problème
j'ai l'impression que la distance reste le facteur décisif, pe,dant l'inclusion
'les deux prises sont retrounées à leur emplacement plus éloigné, sans changement notable de flux)

je vais quand même faire la vérification de maj du firmware, je complèterai si cela agit un peu

depuis la maj (?) de firmware, le flux est descendu au même niveau que les 3 autres prises, donc possible effet aussi de ce côté

le plus bavard maintenant est aussi un capteur Tuya, qui génère à lui seul 8 x plus que le zlinky, essentiellement des messages vides sauf "timestamp" avec la date et l'heure

edit : pas de changement, les prises sont bien calmées, donc je pase en résolu
les deux points qui ont réglé le problème:

  • intégration "au plus près" du coordinateur Zigbee , quitte à remettre la prise à son emplacement final ensuite
  • mise à jour du firmware