Zigbee device qui flood à mort... comment faire?

Bonjour,

Voilà plusieurs jours que je cherche, mais ne trouvant pas, je me résous à vous demander de l’aide !
J’ai une installation de panneaux solaires et je mesure les puissances à l’aide de deux PJ-1203A qui ont comme « Modèle zigbee » dans zigbee2mqtt « TS0601 ».

« Tout » fonctionne bien sauf une chose, ils flood avec une date de « last_seen ». Voilà une vidéo du point de vue de zigbee2mqtt pour mieux expliquer : Vidéo

Côté MQTTExplorer, je retrouve le même flood :

Savez-vous si il y a des choses à faire pour éviter ça ou bien si je suis obligé de changer ces périphériques chinois pas cher ?

Merci par avance de vos conseils !

Salut,

j’en ai 2 comme ça. Ca fait effectivement comme chez toi, en fait il envoie 1 publication par valeur… a chaque fois qu’il a une nouvelle mesure. C’est pour ça que tu as un spam toutes les 10 sec.

Le contrôle de la fréquence n’est pas implémenté… j’ai cru comprendre qu’en passant par la passerelle Tuya et leur app tu as la possibilité de changer la fréquence.

Sinon pas trop de conséquences pour HA, si tu dans la config de Z2M > Paramètre>Intégration HA> tu as bien l’option « Home Assistant legacy entity attributes » décochée… sinon RIP la taille de ta DB.

1 « J'aime »

Le fait de poser un message des fois aide à réfléchir.
J’ai réussi à désactiver la mise à jour du « last_seen » dans zigbee2mqtt. Je pensais que c’était lui qui faisait le problème, mais en fait il n’est que le reflet du fait que le device semble renvoyer (car il flood toujours) les mêmes données.
J’ai alors pensé au debounce car les données envoyées étaient toujours les même. En ajoutant un debounce à 5 dans mon cas, cela fonctionne désormais bien.
Je vais remettre le last_seen car je pense que cela va fonctionner.

[EDIT]
Il semble que les problèmes reviennent en activant le last_seen… je vous recommande de le désactiver pour le device en question si vous êtes dans ce même cas…

Si cela peut aider quelqu’un !

Bonne journée à tous

Salut @AlexHass,
Lorsque tu écris cela, c’est de manière générale ou c’est propre aux capteurs mentionnés par @AGW
Perso, dans ma config, la case est cochée. Mais je travail, dans mon recorder, avec include uniquement. Et il y a peu d’entrés dans cet include.

1 « J'aime »

Salut !

Je comprends pas trop ce que tu veux dire par :

Quand à décocher l’option @AlexHass , tu veux dire pour éviter de doubler les données ?

Vous avez un routeur zigbee pour tuya en plus de ce qui est utilisé par home assistant pour faire ce genre de réglages ? Moi j’ai pas ça !

A+

Recorder :wink:
C’est là que tu décides ce que tu veux concerver comme données pour tes entités.
Limiter les enregistrements de données dans la DB empèche celle-ci de devenir obèse…

Ah oui, pardon !
Pour le coup, je suis plutôt avec des exclude :wink:
Merci pour la précision.
Pour le coup, la situation que j’ai trouvée semble fonctionner pas trop mal après ces quelques heures de tests !
A+

Salut,

en fait l’impact majeur de cette condition chez moi c’est les attributs de chaque entité remontée par Z2M.
Quand elle est active, et que tu regardes dans les outils de dev, tu vois que chaque entité à toutes valeurs des toutes les autre entités dans ses attributs.
Du coup avec un appareil bavard, et des messages toutes les 10 secondes, HA enregistre une quantité de données énorme dans la table des attributs et qui conduit à une base de données qui explose pour rien car il y a une plusieurs nouvelles entrées par chaque fois qu’une des entité change .

Quand tu la décoches, chaque entité reçoit seulement les attributs nécessaires.

Merci pour cette précision.
J’ai décoché l’option, je verrai si je perçois une différence.

Celle ci est bien décochée, mais « Home Assistant legacy triggers » est coché, c’est bon ?

Ce matin, mon réseau zigbee a encore planté c’est un enfer ce truc ! Je sais pas si c’est dû à leur présence ou pas… j’ai cette erreur dans mes logs zigbee2mqtt (c’est ce soir, mais la même que ce matin)

error 2024-01-26 19:42:38: Error while starting zigbee-herdsman
error 2024-01-26 19:42:38: Failed to start zigbee
error 2024-01-26 19:42:38: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start.html for possible solutions
error 2024-01-26 19:42:38: Exiting...
error 2024-01-26 19:42:41: Error: Failure to connect
    at Ezsp.connect (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/ezsp.ts:277:19)
    at Driver.startup (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/driver/driver.ts:139:9)
    at EZSPAdapter.start (/app/node_modules/zigbee-herdsman/src/adapter/ezsp/adapter/ezspAdapter.ts:172:16)
    at Controller.start (/app/node_modules/zigbee-herdsman/src/controller/controller.ts:132:29)
    at Zigbee.start (/app/lib/zigbee.ts:60:27)
    at Controller.start (/app/lib/controller.ts:98:27)
    at start (/app/index.js:107:5)
    at Timeout.restart [as _onTimeout] (/app/index.js:17:5)

Je me demande si ce n’est pas ma clé SONOFF ou bien la raspberry et son port USB qui sont capricieux. Vous avez un réseau stable de votre côté ?

Bonne soirée

Ces options d’intégration HA, n’ont pas d’impact sur la stabilité, mais celle dont je parle peut avoir un impact sur la taille de la base de donnée.
Et ce n’est pas non plus le « spam » cause des soucis de plantages… 10 messages MQTT toutes les 10 secondes c’est peanuts.

Perso très stable.
Jamais eu de plantage de Z2M depuis un peu plus de 2 ans sur une clé Sonoff P, non flashée.
Mais là les erreurs c’est clairement la clé qui n’a pas répondu… problème d’alimentation peut-être…

1 « J'aime »

Bonjour,
bien faire attention de mettre la clé sur un port USB2 ( port noir ) et d’utiliser une rallonge USB de 1m pour éviter toute interférence.

Quel modèle de clé Sonoff tu as, la P ou la E ?

Salut,

Ses messages d’erreurs indiquent EZSP, donc je suppose que c’est un E.

1 « J'aime »

Merci pour tous vos commentaires ! Oui, j’ai une E. Je viens de la flasher ce matin. On va voir si ça aide un peu.
Tous mes ports sont noirs (Raspberry Pi 3 B+). J’ai une rallonge de 30cm environ, faudrait que j’essaye avec une un peu plus longue…

Je me demande aussi si le fait d’avoir plusieurs contacteurs zigbee dans mon tableau électrique n’est pas un truc un peu embêtant… en même temps, ils ne discutent pas non plus en permanence…

J’ai un SSD branché aussi en USB, avec pas de chance, il tire un peu trop sur l’alimentation et la clé « perd » quelques instants l’alimentation…

Encore merci la communauté ! :+1:

oui c’est limite 30cm, mets une d’un mètre au moins.
Ok un RPI3 donc que du USB2 :wink:

Mets une alimentation de 5V 3A, ca devrais aller mieux.

Ok, je vais regarder tout ça et je vous donnerai des nouvelles ! :crossed_fingers:

Mon alim actuelle fait 2,5 A, je la change quand même tu penses ?

Oui,
sur mon RPI3B , j’avais un SSD , une clé zigbee, une clé bluetooth et une allimentation de 5V 3A. Celle que ta en 5V 2.5A c’est celle d’origine.
Maintenant je suis sur un RPI4 avec le même materiel et alim 5V 3A.
Suivant les SSD, il demande plus ou moins de voltage.

A mon début sur HA j’avais un RPi3 sans Zigbee mais avec Carte SD, ZWave et RF
La stabilité c’était la cata.
Ca s’est grandement amélioré avec Rpi4 et encore mieux avec MiniPC…

Qui à varier les sujets de cette discussion :wink: Vous avez quoi comme mini PC, je crains la conso électrique. J’ai un vieux mac mini sur lequel je me tâte de basculer, mais c’est 12W au lieu de 5…

La carte SD, je ne l’ai pas laissé longtemps, trop peur qu’elle crâme à vitesse grand V !

Je suis passé sur une alim 3A, on va voir si ça change la donne…