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”.
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
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 ?
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
@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 :
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.
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.
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.
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 ?
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!
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 Donc c’est la grosse partie à laquelle je m’attaque cette semaine
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
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
Aïe 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
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
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 »
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.
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.
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.
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 featurescurrent, 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.
@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)
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à
Merci pour le schéma @cicoub13, c’est vraiment clean d’avoir ce genre schéma pour des nouveaux arrivants ensuite
Limite on pourrait garder ces schémas et les mettre quelque parts dans la doc côté “développeur” une fois le service publié ? Garde les sous le coude, ça peut-être utile !
Pour information, le 02 mars avec @cicoub13 on a fait le point sur tous les bugs et détails que j’avais pu trouvé.
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 ) et génère une des dernières images de test je l’espère
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 !
La pression Mais oui, ce call a permis de bien comprendre les derniers bugs et je vais pouvoir travailler dessus ce week-end
La prochaine image sera assez stable et ce serait bien si d’autres personnes pouvaient tester avec plein d’appareils différents
Donc c’est la grosse partie à laquelle je m’attaque cette semaine 
Forcément, sans tests c’est dur d’avoir une bonne stabilité…
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.
) et génère une des dernières images de test je l’espère 
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 !