Zigbee2mqtt : Image docker de test basée Gladys v4

Merci c’est top, je te tiens au courant.

Pour info sur le contexte, j’utilise beaucoup Gladys depuis mon téléphone. L’onglet reste ouvert sur mon téléphone mais se recharge lorsque j’y accède.

Une idée de pourquoi l’interrupteur n’est pas actionnable ?
Il est pourtant bien vu comme tel dans les périphériques.

Édit : pour je ne sais quelle raison il n’est pas reconnu comme interrupteur et n’est pas actionnable. La partie « éteindre les lumières » dans une scène est vide, malgré la présence de cet interrupteur. C’est un bug d’après toi @pierre-gilles ?

2021-02-22T08:50:12+0100 <warn> handleMqttMessage.js:97 () Zigbee2mqtt device InterrupteurCuisine, feature state not configured in Gladys.

Édit 2 : @cicoub13 la prise connectée n’est toujours pas acceptée par Gladys. Des que j’ai du temps je regarde les logs.

Edit 3 : Pour que le scan fonctionne, je dois forcément rafraichir la page totalement. Si je suis dans l’onglet « Mes appareils » par exemple, il faut quand meme rafraichir et ça refonctionne.

[feature request]

Sur la page « Appareils », on peut chercher par noms lorsqu’il y a beaucoup d’équipements.
Mais ça serait aussi bien pratique de pouvoir afficher par pièces, comme sur le dashboard.

Tu en penses quoi @cicoub13 ?
Niveau faisabilité ça doit être plutôt facile, puisqu’il y a déjà un tri avec le nom.

Bug sur l’ajout d’équipements

Détails du bug : Lorsque j’ajoute un nouvel équipement, régulièrement j’ai l’erreur « Une erreur s’est produite lors de la sauvegarde ».

Étapes pour reproduire le bug :

  1. Ajouter un nouvel équipement avec son nom par défaut
  2. Le supprimer
  3. L’ajouter à nouveau avec son nom par défaut
  4. BOUM ! Erreur.

Corrections :

  1. Lors du 2e ajout, renommer le nom avec « TEST » à la fin (par exemple)
  2. Ajouter l’équipement
  3. Renommer l’équipement avec son nom par défaut (ça fonctionne)

Recommandations :

  • Lors de la suppression d’un équipement, s’assurer de retirer toutes les entrées dans la BdD, pour permettre de l’ajouter à nouveau avec le même nom
  • Si un équipement avec le même nom existe, afficher une erreur plus explicite « Un équipement avec le même nom existe déjà » par exemple.

L’action "allumer/éteindre les lumières des scènes prend tous les appareils de catégorie « light ».

Cet appareil ne doit pas être de catégorie « light » tout simplement :slight_smile:

Juste une petite remarque générale sur ce développement ^^

Le développement du service Zigbee2mqtt a commencé en Octobre 2019, ça fait donc 1 an et 4 mois qu’il est en développement.

J’ai l’impression que ce service est un peu bloqué dans sa propre branche… Le projet est en mode effet tunnel depuis un bout de temps, et du coup personne ne peut s’en servir, c’est dommage !

Est-ce qu’on aurait pas plutôt intérêt à concentrer les développements sur la partie « qualité » plutôt que sur la partie « quantitée » de feature, pouvoir merger ça dans master et que ça profite à tout le monde ? :slight_smile:

Honnêtement, je préfère les petites PR qui itèrent rapidement sur un sujet, quitte à faire 5 PR les une à la suite des autres pour ajouter des nouvelles fonctionnalités, plutôt qu’une PR monolithe qui met 2 mois à être review tellement c’est dense !

Les PRs d’ @AlexTrovato sont des bons exemples de PR efficaces :slight_smile:

@cicoub13 @lmilcent Pour vous, est-ce que le service est prêt pour la production, et si non qu’est-ce qu’il manquerait ?

Pour moi voici ce qui reste à terminer avant de pousser une v1 fonctionnelle :

  1. Problème n°1, il faut que la partie « recherche » soit fonctionnelle en tout temps. Il m’arrive régulièrement d’avoir un scan qui ne fonctionne pas côté Gladys mais correctement côté Zigbee2Mqtt.
    @cicoub13 semblait évoquer un problème de socket. Une fois ce problème résolu, c’est fonctionnel pour une v1 en production.

  2. Problème n°2 avant une mise en production : la gestion des suppressions / ajouts d’équipements avec les même noms. C’est ce que j’expliquais, il faut pouvoir supprimer puis rajouter le même équipement avec le même nom sans que ça pose problème.
    Dans mes tests, ce n’est pas encore le cas.

  3. Le reste ce sont des améliorations qui pourraient être ajoutées, mais qui ne touchent pas à la partie serveur, c’est purement du front. Typiquement, mieux gérer les erreurs pour ne pas perdre l’utilisateur (ce que j’évoquais plus haut et relatif au point 2) et pouvoir filtrer l’affichage des équipements intégrés à Gladys car il peut vite y en avoir beaucoup.

  4. Cette partie se fera au fil de l’eau une fois en production : vérifier que chaque capteur soit bien supporté totalement par Gladys. Je me suis rendu compte que mes détecteurs d’ouverture et capteurs de température sont gérés, mais il manque par exemple les valeurs battery et temperature.
    Je vais pousser une PR sur le repo de cicoub13 pour les capteurs que j’ai chez moi.

Je suis totalement d’accord avec toi, il est temps que cette fonctionnalité très attendue par beaucoup d’entre-nous sorte ! Et on est vraiment très proche désormais, une fois que les points 1 et 2 sont résolus c’est prêt.
Tu en penses quoi @cicoub13 ?

Ok @lmilcent merci pour le retour :slight_smile:

A mon avis le point 3. est très important aussi. Les erreurs frontend c’est tout sauf optionnel, il faut que les messages d’erreurs soient clair, sinon quand ça part dans la nature c’est impossible à débugger en cas de soucis sur une instance!

Bonjour,

Je pense que le cœur est là mais ça manque de finition. Je n’ai pas trop de soucis avec mes 4 capteurs mais @lmilcent rencontre pas mal de blocages qui font qu’on ne peut pas sortir l’intégration comme ça.
Je me concentre sur les bugs et l’expérience utilisateur.

L’ajout de périphériques est vraiment bien pensé par Renaud donc j’en ajoute quelques-uns en passant.

Ce week-end, j’ai regardé la couverture des tests et il n’y en a pas :frowning: Donc c’est la grosse partie à laquelle je m’attaque cette semaine :rocket:

Je suis d’accord avec @pierre-gilles sur le fait de ne pas ajouter de fonctionnalités pour le moment mais de se concentrer sur la qualité.

Si d’autres personnes pouvaient tester, ce serait aussi top :+1:

1 Like

Ok merci pour le retour ! Bien entendu la stabilité du service est hyper importante. Je ne veux pas rusher cette partie, tant que l’intégration n’est pas béton niveau stabilité on ne la sortira pas :slight_smile:

Aïe :confused: Forcément, sans tests c’est dur d’avoir une bonne stabilité…

C’est dommage que les tests n’aient pas été développé en même temps que l’intégration, maintenant pour les rajouter à posteriori, essaie vraiment de tester le fonctionnement attendu, et pas de partir du code pour faire des tests sans réel intérêt.

En tout cas n’hésite pas si tu as des blocages/questions en route :slight_smile:

Bon courage pour l’écriture des tests, c’est un sacré boulot (mais nécessaire…).

Côté bugs, j’ai essayé d’avoir plus d’infos sur mon bugs lors de l’ajout d’équipements, mais je n’ai rien de plus malgré les logs en mode verbose :frowning:
Quand je recrée le bug, rien n’est affiché côté Gladys. J’ai seulement l’API dans le navigateur qui répond :
« External ID must be unique » « zigbee2mqtt:CapteurMouvementSalleAManger:battery »
image

Sauf que j’avais renommé ce périphérique avant de l’ajouter, en « CapteurMouvementSalleAMangerunique ». Donc dans le front, le renommage ne semble pas correct à tous les niveaux.

Salut @cicoub13 c’est encore moi :laughing:

Ce soir j’ai essayé de trouver ce qui pouvait générer l’erreur lors de l’ajout de ma prise Lonsonho (ou TuYa).

Côté backend c’est ici :

La variable feature est vide quand j’essaye d’ajouter ma prise, ce qui cause l’erreur.
Je n’ai pas encore regardé comment est récupérée cette variable, mais c’est déjà une piste à explorer.

[edit]

Côté modèle :
Ma prise connecté TuYa ne voulais pas être ajoutée dans Gladys. En modifiant le fichier de modèle, j’ai retiré plusieurs features et la prise a pu être intégrée. Je n’ai pas vraiment d’explication car toutes les features sont sensé être supportées par Gladys.

  • Configuration « problématique » : TS0121_plug: [features.switch, features.power, features.current, features.voltage],

  • Configuration fonctionnelle : TS0121_plug: [features.switch, features.power],

Si tu as d’autres pistes à explorer pour trouver la source du bug, n’hésite pas à me pointer les fichiers intéressants et j’y jetterais un oeil dès que j’ai quelques minutes !

[edit 2]

J’ai compris ce qui pose problème pour ma prise (et donc pour d’autres modèles aussi je pense).

Dans le fichier modèle associé, la configuration appliquée était features.switch, features.power, features.current, features.voltage.
Ces features spécifiques au service zigbee2mqtt sont ensuite traduites en features compréhensibles par Gladys.

La traduction se passe ici : Gladys/features.js at d0ba2e13b3e69a3615172c7a7cf91abd68b805e4 · cicoub13/Gladys · GitHub

Par exemple, features.switch sera traduite avec la catégorie associée dans Gladys.
Service Zigbee2mqtt :

Traduction pour correspondre aux features Gladys qui sont là :

Et ce dont je me suis aperçu, c’est qu’il n’est pas nécessaire d’indiquer dans le modèle Zigbee2mqtt toutes les features, car certaines sont implicites (contenues dans l’objet SWITCH en tout cas).
Pour Switch, les features current, voltage, power et energy sont implicites (cf le bout de code au dessus).

Donc dans le modèle Zigbee2mqtt, il faudrait simplement indiquer : features.switch.
Mais là où je ne comprends pas encore, c’est qu’en faisant ça, l’interface web n’affiche plus que la fonction On / Off. Les données de consommation, voltage ou courant ne s’affichent pas.


@cicoub13 toi qui a un peu plus travaillé dessus, aurais-tu des éclaircissement à apporter sur le fonctionnement ?
Mon raisonnement est-il correct au moins partiellement ? Je n’ai pas encore compris comment Gladys ajoutait les features en fonction de ce qui est renvoyé par le service zigbee2mqtt.

Les tests unitaires avancent :sweat_smile:

Capture d’écran 2021-02-27 à 11.41.52

@lmilcent Je suis en train de me pencher sur les périphériques et le mapping features zigbee / features Gladys. Dès que je comprends mieux, je pense qu’on pourra fixer facilement tes appareils.

Ce serait bien qu’on fasse une session ensemble sur Google Meet pour qu’on regarde tous les comportements bizarres et les logs backend dans ce cas-là. Dès que j’ai une nouvelle image, je t’envoie un message pour planifier un soir (selon nos dispos)

2 Likes

Génial, tu avances bien !

Avec plaisir :slightly_smiling_face:

Si tu voudra bien prendre un peu de temps le jour du meet, pour m’expliquer le mapping justement, ça m’intéresse :sweat_smile:

Voici le principe :

  • pendant la partie Discover, toutes les catégories de features sont détectées avec une conversion dans convertCategory (pour celles qui n’ont pas le même nom entre Gladys et Zigbee). S’il y a des soucis de devices non compatibles ou avec des features manquantes, c’est là

  • lorsque des messages avec valeurs sont reçues, ça se passe comme ça

  • lorsqu’on modifie des valeurs, seul le state ON/OFF est géré

Je te laisse regarde un peu plus en détails les fichiers mentionnés si tu veux faire tout le parcours.
Mais on revoit ça ensemble :slight_smile:

3 Likes

Merci c’est super clair !
J’aime bien les schémas pour ça :slight_smile:

Par contre de quels « fichiers mentionnés » parles tu ?
Je peux en trouver quelques uns via les appels API, mais pour les autres (les loop par exemple)?

Merci pour le schéma @cicoub13, c’est vraiment clean d’avoir ce genre schéma pour des nouveaux arrivants ensuite :slight_smile:

Limite on pourrait garder ces schémas et les mettre quelque parts dans la doc côté « développeur » une fois le service publié ? :slight_smile: Garde les sous le coude, ça peut-être utile !

1 Like

Point de situation

Pour information, le 02 mars avec @cicoub13 on a fait le point sur tous les bugs et détails que j’avais pu trouvé.

:bug: On a identifié les bugs bloquant empêchant « une mise en production » et les retouches ou nouvelles fonctionnalités qui peuvent être apportées dans d’autres versions.

Tout est dans les mains de @cicoub13 désormais, il termine l’écriture des tests (sacré boulot, bravo à toi :clap:) et génère une des dernières images de test je l’espère :grinning:

:hourglass_flowing_sand: Ce n’est plus qu’une question de jours pour une PR et de semaines avant qu’elle soit revue, modifiée, approuvée et intégrée dans Gladys !

6 Likes

La pression :sweat_smile: Mais oui, ce call a permis de bien comprendre les derniers bugs et je vais pouvoir travailler dessus ce week-end :slight_smile:
La prochaine image sera assez stable et ce serait bien si d’autres personnes pouvaient tester avec plein d’appareils différents

6 Likes

Tu as prévu le fait de pouvoir spécifier un Server mqtt personnalisé ou c’est pour une autre fois ?

Bon courage btw

J’ai peu d’appareil Zigbee pour le moment mais je pourrais tester avec ce que j’ai sans problème !