Personne ne se trompe , l’expérience et le métier de chacun veut que nos avis divergent, pour la RC tu penses core et api , je penses surtout features ( au sens large ).
Pour le zigbee2mqtt je comprends parfaitement, c’est pour ça que je disais " on fait tous au mieux " .
Donc je penses que tu aura compris que pour moi un RC c’est un software ( je ne parle pas de Gladys en particulier ) proche de la release d’un point de vue features. Mais mon point vue n’est pas forcément adapté à l’Open Source je te l’accorde et il est vrai aussi que tu es un peu seul sur le dev en ce moment !
Quelques news au sujet du module Zigbee2mqtt suite aux différentes questions récentes.
Tout d’abord sur l’historique, pour rendre à César…
En fait, c’est @AlexTrovato qui a lancé le dev de ce module et j’ai proposé de prendre la relève alors qu’il manquait de temps pour continuer. Il m’a quand même bcp aidé pour me lancer.
A mon tour, j’ai manqué de dispo ces derniers temps avec des jalons de projets très importants côté boulot, jusqu’à la semaine dernière. Je suis actuellement en vacances en famille et devrai me remettre à Gladys la semaine prochaine.
Comme je l’ai déjà indiqué, les derniers dev du module ont notamment porté sur l’utilisation d’un container MQTT et j’avais interrompu cette partie là en voyant les dev d’@AlexTrovato et @VonOx sur le sujet.
Leur PR étant intégrée, je vais réutiliser leur travail pour la partie MQTT pour assurer une certaine homogénéité. Ces devs ne semblent pas trop compliqués a intégrer.
Par contre, comme je l’ai aussi déjà indiqué, il va manquer la partie tests pour que @pierre-gilles puisse intégrer la PR dans Gladys pour la RC.
Je ne suis pas spécialiste dans ce domaine et si il y a qq volontaires (@VonOx ?), ça me serait d’une grande aide.
Voilà, à très vite pour vous donner des news sur la suite des devs du module.
Je suis actuellement en train de faire un tour sur la demo et il y a un truc qui me perturbe sur la page intégration.
Quand je vois la liste de toutes les intégrations, je me rend compte que c’est pas hyper parlant pour un mec lambda.
Ce que je veux dire c’est qu’un mec qui veut rendre compatible son volet beh la il est perdu.
Ne serait il pas plus intéressant d’avoir des catégories, c’est a dire, ampoule et au click les modules pouvant les pilotés, fenêtre et pareil au clique etc …
Merci, c’est cool de donner des nouvelles .
Je ne suis qu’utilisateur final, mais ce module est la base de ma modeste installation .
J’ose une petite demande : peux-tu refaire une image Docker qui contienne Z2MQTT à partir de la dernière image de Gladys (bêta 11) en attendant l’intégration définitive ?
Ça me (nous ?) permettrait de bénéficier des améliorations qui ont été intégrées depuis la v4.0.0 bêta 4.
Langue française, openweather, caldav…
Je n’ai aucune idée du temps que cela représente, alors si c’est trop chaud, aucun souci :).
Merci pour ton message @Reno et merci pour le travail effectué jusque là !
Wow génial ! Hâte de te voir de retour dans la communauté.
Pour la partie test, c’est vraiment pas compliqué, je suis disponible pour s’appeler si tu veux de l’aide pour apprendre à les mettre en place. C’est vrai que ça peut faire peur quand on en a jamais fais, mais tu verras qu’une fois que tu sauras les écrire tu vas gagner du temps de développement et surtout en qualité de code.
Les tests c’est une vrai philosophie de développement produit, j’essaie au maximum d’être en mode « TDD » (Test Driven Developement), c’est à dire que tu écris tes tests avant d’écrire ton code pour ensuite voir tes tests se valider progressivement. Ca fait gagner un temps fou de dev les tests!
Ma vision dans Gladys 4, c’était justement de faire le raisonnement inverse:
Si un utilisateur achète une ampoule Philips Hue, et qu’il veut la contrôler dans Gladys, il s’attend à chercher “Philips Hue” puis “Ampoule” puis “ajouter”. Surtout si il achète un kit Philips Hue, il veut ajouter tous ses périphériques Philips Hue d’un coup, donc il va dans l’intégration “Philips Hue”, et il clique sur “ajouter” sur chaque périphérique.
Je trouve que le raisonnement inverse, partir de l’objet pour remonter vers la marque (“Ampoule” => “Philips Hue”) fait moins sens.
Après, ça c’est côté produit.
Côté documentation, je suis d’accord avec toi, pour trouver les périphériques compatible Gladys, c’est l’option inverse qui fait sens:
Tu te demande quelle ampoule tu peux acheter pour utiliser avec Gladys? Tu vas sur le site, tu filtre par “ampoule” puis tu vois toutes les marques disponibles.
C’est ce qu’on faisait sur le site de la v3, et ce qu’on va faire sur le site de la v4. Pour l’instant il y a peu de produits listés sur le site (sur la page Intégrations) donc je n’ai pas encore codé les filtres (par techno/par type de produit/etc…), mais c’est l’objectif
J’ai demandé des corrections en Mai, et la PR n’ayant pas changé depuis et mes commentaires n’ont pas été répondu, du coup pour Github de mon côté c’est marqué comme “en attente de correction”. Je pensais que @link39 n’avait pas le temps de faire les fixes mais au vu de son message on a du mal se comprendre ^^ @link39 je peux aider si il faut mais il faut que je sache l’état de la PR
Tu fais bien fais de demander, c’est vraiment dommage ces problèmes de communication…
Petit messages pour ceux qui développent sur Gladys, il y a beaucoup beaucoup d’issue/de PR sur GitHub. La seule manière que je sache qu’une PR est “prête” à être review, c’est que vous le disiez ^^ Je ne peux pas deviner ou en est le travail, et il y a trop de PR/issue en cours pour que je me rappelle individuellement de chaque cas.
Par exemple @atrovato fait ça super bien, quand il a finit une PR, il “demande une review” sur Github, ce qui me fait une notification:
Je sais que la PR est prête à être review, je mets ça dans mes todos et dès que ça arrive en haut de ma pile je fais ma review, ce qui est conclu par 2 possibilités:
La PR est bonne, je l’accepte et elle est mergée sur master
J’ai des feedbacks, la PR passe donc de status “Ready for review” => “Changes requested”.
Dans le cas 2., tant que la PR est en “Changes requested”, elle est complètement sortie de mon radar, je ne la revois sur mon Github que si les changements sont fait et que les remarques que j’avais écrites ont été “marquée comme fixée” par l’auteur de la PR.
Je comprend ton raisonnement sur la documentation des intégrations enfaite j’en arrivais là parce que je ne savais pas ce que le module tasmota pilotait bref …
Deux petites questions,
Concernant la partie notification des scenes, on ne peut pas récupérer les événements d’un calendrier ?
C’est a dire que pour une scene réveil, il aurait été bien de pouvoir check si des rdv son prévu et si oui notifier l’utilisateur.
Effectivement ça serait sympa ! C’est une feature intéressante, après elle n’est pas encore chiffrée ni programmée à court terme, pour l’instant toutes mes ressources vont sur la stabilité du core pour la sortie de la RC
Si mes souvenirs sont bons, si Gladys est sur Docker :
Aucun broker n’est pas détecté par son nom, on propose de le télécharger
Un broker est présent, on propose de l’utiliser
On n’utilise pas de broker embarqué par Gladys (configuration manuelle)
Maintenant si la page n’est pas assez claire, il est possible de modifier les aides, mais nous avons besoin de savoir quoi modifier, car @Serge tes explications ne nous sont pas claires non plus.
Une nouvelle semaine qui commence pour moi, j’ai review ce matin toutes les PRs en attente sur GitHub et mergé 3 supers PR de @AlexTrovato + une PR sur la documentation de Gladys 4
J’ai bien avancé sur la gestion des timezones dans Gladys, mais c’est un chantier plus gros que prévu et je vais mettre plus de temps qu’estimé.
J’ai mis à jour le milestone avec la nouvelle estimation, on est pour info à:
2 tâche low * 2 = 4 hours = 0.5 jours
5 tâches medium * 1 jours = 5 jours
1 tâche high * 4 jours = 4 jours
= 9.5 jours/homme de développements restants
@VonOx, en remontant le channel, je me suis rendu compte que tu avais un problème d’affichage des devices hue il y a 12 jours, c’est toujours le cas?
Si oui, est-ce que tu peux me créer une issue GitHub avec un descriptif exact du problème ainsi que les informations nécessaire pour résoudre le bug (le JSON des devices) ?
GitHub est ma seule source de vérité, si un bug n’est pas sur GitHub, il passe hors de mon filet et je l’oubli la seconde où je quitte le forum ^^
Oui, j’ai utilisé l’image prise dans la partie installation du site : gladys-4.0.0-beta-raspbian-buster.img.zip
La MAJ vers la beta 6 s’était faite sans pb.
Il est connecté à Internet puisqu’il ne renvoie mon calendrier et la météo.
Taille mémoire :
Je crois que je vais investir dans une carte µSD plus grande.
Je ne sais s’il est possible de faire booter Gladys sur une µSD, puis de travailler sur une clé USB. Ceci pour ne pas trop faire travailler la µSD.
J’avais trouvé un tuto pour faire ça quand j’utilisais Domoticz
Comment je peux arrêter Gladys ?
L’interface ne le propose pas.
en SSH pm2 stop gladys (avec ou sans sudo) me renvoie [PM2][ERROR] Process or Namespace gladys not found
Salut @gaetanb76,
pour info depuis la v4 de gladys, pm2 n’est plus utilisé.
la V4 a été conteneurisé via docker.
Tu dois pouvoir trouvé la commande en recherchant dans google : stopper un container docker.
.
bref …
