Erreurs d'agrégations dans l'onglet "Tâches en arrière

Salut @spenceur
Est-ce que tu pourrais me donner le modèle de ta clé Zigbee ?

J’ai retourné mon problème dans tous les sens, réduit mon install au strict minimum et j’ai encore des erreurs d’agrégation. Beaucoup moins, mais j’en ai encore.
J’ai arrêté la VM qui faisait tourner Gladys et l’ait installée directement sur le NAS, branché la clé directement sur le NAS également, sans passer par un concentrateur, uniquement intégré une sirène et 7 capteurs d’ouverture, un compte Caldav, Enedis, et Gladys Plus.

J’aurai bien testé avec un autre dongle du coup

Merci

Cest un sonoff -p

1 « J'aime »

@Philou changer le dongle ne va rien changer à mon avis :slight_smile:

Une option que tu peux faire, serait d’aller récupérer le fichier SQLite, et de faire tourner une petite query SQL pour déterminer quel appareil envoie le plus de valeurs!

La DB est situé dans :

/var/lib/gladysassistant/gladys-production.db

Pense à stopper Gladys avant de récupérer le fichier pour éviter toute corruption.

Ensuite, tu récupère le fichier sur ton ordi en local (hors Gladys), et avec un outil genre TablePlus tu exécute la query suivante:

SELECT COUNT(t_device_feature_state.id), device_feature_id,
t_device_feature.name as feature_name, t_device.name as device_name
FROM t_device_feature_state
JOIN t_device_feature ON t_device_feature.id = device_feature_id
JOIN t_device ON t_device.id = t_device_feature.device_id
GROUP BY device_feature_id
ORDER BY COUNT(t_device_feature_state.id) DESC;

Ce qui te donnera les appareils les plus verbose :slight_smile:

Merci @spenceur et @pierre-gilles

La messe semble dite. Il s’agit de celui-ci Neo NAS-AB02B2 control via MQTT | Zigbee2MQTT

Y a-t-il quoi que ce soit que je puisse faire pour limiter le nombre d’infos remontées ?

Ton instance date de quand ? 453 valeurs c’est rien :smiley:

L’idée ici c’est de calculer combien de valeurs/seconde reçoit Gladys pour voir si un capteur est vraiment extrêmement agressif, mais là 453 valeurs si c’est sur quelques jours, c’est vraiment rien.

Tu peux aller voir la table t_device_feature_state et filtrer par ce capteur pour voir à quelle fréquence il envoie, mais ça me parait tout à fait correct là…

La denière fresh install date d’il y a 20h.
A part le fait qu’il beggaie de temps en temps je ne vois rien d’anormal non plus

Le dernier échec date de 2h du matin environ.

Ok, ça doit être l’heure à laquelle ton système se backup via Gladys Plus, rien d’anormal !

Tu as juste un seul échec par jour à ces heures là ?

Hier matin et depuis plusieurs jours je n’avais que des échecs.
Fresh install en direct sur le NAS (sans VM), avec dongle en direct sur le NAS (sans concentrateur USB), j’ai ré-appairé tous mes devices et me suis retrouvé avec que des échecs à nouveau.
J’ai donc pris le parti d’une install minimum.
Depuis j’ai eu deux échecs, celui de cette nuit donc et un autre hier, 4h après l’install

Je remarque également ces messages dans les logs qui indiquent que certaines features de la sirène ne sont pas prises en charge mais je doute que ce soit bloquant.

Ok effectivement pas normal.

C’est des logs tout à fait normales, rien de bloquant :slight_smile:

Tu as déjà fais un petit test de performance de ton NAS ? La partie disque en particulier ?

Je te conseille cet article:

Regarde la partie test de disque en écriture/lecture

Je serais curieux de savoir la performance de ce NAS !

Hop, voici
image

DiskStation® DS1621+ | Synology Inc.

Ok, ça parait normal. Pas exceptionnel mais pas mauvais du tout :slight_smile:

C’est un SSD? SSD NVMe? HDD?

Et sur ton NAS il y a des choses qui tournent en même temps j’imagine? Rien qui pourrait occuper le disque « à fond » et qui pourrait bloquer Gladys?

En fait il te faudrait un tool genre Netdata ( https://www.netdata.cloud/ / c’est gratuit et open-source), pour voir si il y a de l’activité sur ton NAS qui fait coincer tout

Je vais creuser, merci pour l’idée je n’y avais pas du tout pensé :+1:
J’avais un serveur Minecraft qui tournait j’ai commencé par le couper.

C’est RAID SHR (propriétaire Synology) sur 4 disques WD RED 5400 T/m de 2T, un disque de hot spare.
Oui j’ai un peu d’activité dessus, serveur mail, backups nocturnes, réplications croisées, serveur multimédia, un petit site web, bref de quoi faire bosser les disques mais rien de fou non plus.
Par contre quand je regarde l’occupation des disques pendant les aggrégations… surprise !

Tu as moyen de brancher un disque supplémentaire ? Sinon met un SSD (pas en RAID) en plus et met le volume Docker Gladys dessus, au moins tu seras isolé + en SSD :wink:

Si il y a de l’activité disque au moment des agrégations c’est normal :slight_smile:

1 « J'aime »

Quitte à ajouter un SSD j’ai commandé un NVMe au format M2 dont je vais me servir comme cache pour l’ensemble de la grappe RAID, merci du conseil ! J’ai la chance d’voir un modèle qui le permet.

Pas d’autre échec depuis, je vais ajouter un de mes capteurs Xiaomi pour voir si ça met tout en l’air.

Après ajout j’ai attendu 10 mins et relancé Gladys pour forcer l’aggrégation :

J’ai supprimé le device, nettoyé la base, relancé gladys et les aggrégations passent crême. Il semble donc que ce device pose problème.
Xiaomi WSDCGQ11LM control via MQTT | Zigbee2MQTT

ça m’étonne… Tu as le rythme de publication de ce device dans Gladys ?

Pas encore, désormais quand je fais une modif aussi petite soit elle je laisse tourner quelques heures pour confirmer que c’est stable. Je viens d’en remettre un, je vais monitorer.

1 « J'aime »

Petite update : tests toujours en cours.
J’ai pu ajouter 2 devices Xiaomi à mon rez de chaussée sans trop de problème, plutôt stable mais quand j’ajoute un périphérique de l’étage les aggregations commencent à planter.

Chez moi j’ai

  • dans mon garage (-1) NAS+Cle Zigbee, quelques capteurs de porte, capteur Xiaomi de Température
  • au RDC (0) plusieurs capteurs de portes, une prise sonof, une sirène Neo, un capteur Xiaomi, une bande LED Tuya.
  • au 1er, une prise Sonof, 4 capteurs Xiaomi déconnectés
  • au 2e, une seconde sirene Neo

En l’état ça fonctionne.

Je me suis aperçu que les associations Zigbee fonctionnent beaucoup mieux quand le « routeur » Zigbee (le clé USB) est proche. J’avais pas mal d’échec d’associations et les faire proche du routeur principal puis déplacer le device fonctionne mieux que de vouloir associer directement à l’emplacement final.

Et donc dès que j’ajoute un device de mon 1er étagé les aggregations commencent à planter.
Pas mal de tests en tête à faire pour trouver la root cause, la première étant l’ajout d’un cache NVMe sur mon NAS. J’ai bien commandé un premier NVMe au format M2 mais je viens d’apprendre qu’il en faut 2 pour que le cache soit en read/write et pas read only, Jen ai donc commandé un second.

To be continued… :sweat_smile:

1 « J'aime »

Merci pour ton retour @Philou ! :slight_smile:

N’hésite pas si tu trouve quelque chose de bizarre dans Gladys à un moment et que ça demande un correctif.

Mainenant le Cache NVMe en place, les 3 aggrégations prennent 10 secondes là où elles prenaient 1 min 50,soit divisée par plus de 10. Jusque la j’avais le temps de voir les % augmenter, même reculer, pour augmenter à nouveau etc. Désormais c’est en ligne droite. La réactivité de l’interface est pour le moment juste excellente, au dessus de ce qu’elle était, et c’est tout mon NAS qui en profite. J’ai rajouté tous mes capteurs, la première aggrégation est passée crème, à suivre.
Que ça règle mon problème ou non, j’ai clairement sous estimé l’importance du stockage. Merci @pierre-gilles de m’avoir orienté dans cette direction :beers:

4 « J'aime »