Hmm, il semblerait que je n’ai rien de nouveau à pull sous ce tag, je retest un peu plus tard (certainement demain, pas dispo ce soir).
Bon ok, j’ai parlé trop vite, il semblerait qu’il reste ~45 minutes avant que l’image soit prête 
Nouveau test avec la nouvelle image, mais il semblerait que le bouton “Sauvegarder” ne change pas, même après réajout du device 
Le device disparait à l’ajout… Puis réapparait au rechargement de la page.
Bonne nouvelle !
Contrairement à ce que je pensais, j’avais pris avec moi l’un des interrupteurs dont j’avais demandé l’ajout il y a quelques temps (Zigbee2mqtt: Add device ZM-L03E-Z · Issue #1244 · GladysAssistant/Gladys · GitHub) et il fonctionne aussi 
1 « J'aime »
ça me rend triste. Je peux espérer que tu aies mal testé ?? 
Le device disparait ? Le bouton n’est pas modifié en « Deja dans Gladys » ? Et au rechargement, c’est toujours « Sauvegarder » ? Pas « Mettre à jour » ?
Bon ok, j’ai reproduis le problème, et en effet, erreur toute bête sur la détection d’un ID…
Nouvelle image avec correctif en cours de build, il faut compter 1h30 avant qu’elle soit disponible.
Bon, maintenant j’ai bien “Déjà créé” sur les devices qui sont enregistrés dans Gladys.
En supprimant un device (depuis Gladys, puis Z2M), je peux le réintégrer directement dans Gladys sans aucun soucis ; le bouton “Sauvegarder” revient bien en lieu et place du bouton “Déjà créé”.
Je pense que l’on est plutôt bon du coup 
P.S. : Tant que j’y suis, j’ai fais quelques tests et j’ai remarqué une incohérence au niveau des scènes lors de la suppression et du ré-ajout d’un device. Dans les blocs de type “Allumer/Éteindre la lumière”, le device est bien retiré lors de sa suppression de Gladys. Une fois retiré, il doit être remis manuellement dans la scène. Par contre, dans les blocs de type “Contrôler un appareil”, le comportement diffère légèrement. L’édition d’une scène après la suppression du device conserve le bloc de contrôle du device en question (mais non rempli). Par contre, en cas de ré-ajout du device avant toute nouvelle sauvegarde de la scène (comprendre entre la suppression et le nouvel ajout), la scène conserve les propriétés pré-suppression du device en question.
Ok, cest un peu alors.
En revanche, pour un bug de scene, je pense qu’il ne faut pas en parler dans un topic zigbee2mqtt, sinon on va perdre les gens.
Merci d’avoir testé @Shiftmaj, c’est cool d’avoir des retours ça permet de merger plus sereinement (je n’ai pas ce matos)
Je viens de merger la PR de @AlexTrovato !
@AlexTrovato Tu confirme que là c’est “production ready” ce qu’on a sur master ? Plus de bug connus ?
Sur cette partie, je ne suis pas au courant d’autres bugs liés aux évolutions.
Je suis plutôt serein.
(J’ai l’impression que quelqu’un veut clôturer une 10aine de ticket Github sur le sujet )
Sinon je saurais me rendre disponible.
1 « J'aime »
Top! Aha c’est pas pour moi, c’est pour les gens qui demandent ces compatibilités
ça va vraiment être cool une fois qu’on aura cette auto-détection en prod.
Alors je suis entrain de tester mes nouveaux joujoux, pour l’instant pas trop de problèmes bravo pour votre boulot sur ce service 
J’ai juste une question sur ce genre d’appareil Philips 929002398602 control via MQTT | Zigbee2MQTT c’est une sorte de télécommande/interrupteur. Si je comprend bien la bonne manière de faire pour allumer/éteindre une ampoule à partir de ce type d’appareil, c’est de passer par les scènes. Mais il semble que ce ne soit pas possible. Dans les déclencheurs, j’ai mis Changement d'état de l'appareil, j’ai choisi ma télécommande puis égale et là je mets la valeur on_press (la doc zigbee2mqtt indique la liste des valeurs possible) malheureusement lors de l’enregistrement erreur avec "[0].value" must be a number comme message dans l’onglet développeur Network. N’est ce juste pas encore implémenté ou bien ma solution n’est pas la bonne ?
Désolé, mais en effet, ce genre d’appareil (télécommande / cubes…) ne sont pas entièrement gérés.
Les valeurs sont des actions non numériques, et nous n’avons pas encore étudié (à ma connaissance) la manière adaptée de gérer ce genre de valeur dans le core de Gladys.
Et sur zigbee2mqtt, les valeurs sous forme de chaîne de caractère sont presque uniques à chaque device.
Il faut faire du cas par cas et faire un composant spécifique dans l’UI pour gérer les valeurs 
Plusieurs possibilités:
- Soit on fait un mapping avec des valeurs numériques (ce qui permet d’avoir l’historique). Genre « click » = 1, « double-click » = 2, etc… et ensuite il faut dans l’UI afficher un composant spécifique qui affiche une valeur traduite.
- Soit on ne fait pas de mapping et on utilise les états « string » de Gladys 4 (oui ça existe ), par contre du coup on perd l’historique des valeurs. Et pareil il faut faire un composant spécifique dans l’UI pour traduire les valeurs
Pour info, la nouvelle version de Gladys intègre le Zigbee2mqtt avec détection automatique 
Merci à @AlexTrovato !
2 « J'aime »
Il semble que la lib qu’utilise zigbee2mqtt fournisse une liste de status pour chaque action zigbee-herdsman-converters/devices/philips.js at 05f0795cbf3742a17d59152bbe2186ec6bc8a48e · Koenkk/zigbee-herdsman-converters · GitHub
Surement que cette deuxième solution est plus simple non ? Il me semble que le seul endroit où on a besoins de ces états c’est dans les scènes donc garder les string peut être une bonne solution et sachant qu’on peut avoir la liste automatiquement (donc un select pour les conditions des déclencheurs scènes).
Pour info on voit que les états sont bien détectés par Gladys, voilà ce que ça donne sur le dashboard.
1 « J'aime »
Pour revenir sur l’histoire des devices avec valeur en “string”,
- Il faut pouvoir intégrer ça dans les scènes, car un double clique pourrait permettre de déclencher une scène (je pense que ce serait top)
- en effet, les états “string” existent, mais la gestion de ceux-ci assez pour le moment très limitée (selon pour les caméras), donc non exploitable en l’état
Maintenant, cela risque d’être “compliqué” (pas impossible) de réussir à faire un mapping exhaustif et cohérent entre tous les états possibles des devices et intégrations et Gladys.
Pour moi le plus simple serait vraiment de faire un mapping en valeur numérique, mais niveau UI, l’affichage risque de s’avérer complexe vu la nombre d’états et leur variantes.
@Tolkyen
Je te ping ici, en rapport à la multi-prise Zigbee2Mqtt.
Si tu es motivé par une phase de test, j’ai créé une nouvelle image docker qui doit géré ton device : atrovato/gladys:zigbee2mqtt
Si tu n’es pas “habitué” à installer des images de test, je ne te recommande pas d’essayer.
PS : pour tous, cette image contient une mise à jour sur le contrôle des devices, une correction sur le changement d’état des actionneurs
@AlexTrovato Par rapport aux multi-prises, tu pense il y aura moyen de faire le fonctionnement dont on avait parlé à un moment avec le split des multi prises en plusieurs device (nativement) ?
L’idée c’est de permettre à l’utilisateur de répartir les différentes prises dans différentes pièces, de permettre le contrôle de chaque prise individuels dans les scènes, et que ces prises fonctionnent avec les assistants vocaux
Yes 100%, c’est pas codé, après ce que je voulais dire c’est que c’était pas quelque chose d’impossible, et que niveau modèle de donnée/DB on avait déjà le fonctionnement avec les caméras.
Après du coup oui il faut adapter les scènes / et un peu le core pour propager ces états proprement.
C’est un peu le problème du double mapping effectivement, ça peut vite être n’importe quoi ^^