Bonjour à tous,
je dispose de d’une télécommande Müller Licht 404049D prise en charge par Zigbee2mqtt. Dans Gladys, seul les actions « On » et « Off » sont prisent en charge. Serait-il possible de prendre en charge les autres actions ( brightness_step_up, brightness_step_down, brightness_move_up, brightness_move_down, brightness_stop, color_temperature_move, color_move, scene_1, scene_2, scene_3, scene_4, scene_5, scene_6) ?
Pour le coup, là je te conseille de suivre la PR que je t’ai mise plus haut et de faire exactement pareil.
Pour ton environnement de DEV, je te conseille de connecter l’environnement à ton Zigbee2mqtt distant pour récupérer la télécommande dans ton Gladys de DEV.
Si tu veux de l’aide, n’hésite pas je suis toujours là pour aider !
j’avais commencé le dev, puis bloqué sur un point et ensuite parti en vacances. Effectivement de l’aide serait le bienvenu. Je n’ai pas beaucoup de temps pour développer actuellement. Mais je suis en train de m’y remettre depuis une semaine en m’inspirant de ton livecoding sur Sonos (belle performance par ailleurs)
Je viens de comprendre sur quoi je bloque. Une grande partie des actions de cette télécommande nécessitent de les déclarer pour leur prises en compte. Le point de blocage se trouve sur les actions color_temperature_move et color_move qui nécessitent de récupérer une information qui n’est pas « Exposes » mais dans « State » ce qui a mon sens demande de gérer du spécifique alors que l’intégration Zigbee2mqtt est orientée générique. J’espère avoir été clair. Du coup, je perds l’intérêt de la gestion des couleurs par la télécommande
Pour exploiter l’action color_temperature_move, il faut récupérer la valeur de action_color_temperature qui n’est pas dans Expose puisque l’action ne détermine pas si on augmente ou si l’on diminue.
Même problématique pour l’action color_move puisque action_color n’est pas dans Expose non plus. Hormis ajouter du code pour ce traitement spécifique, cela changerait le principe de l’intégration zigbbe2mqtt que ce veux générique.
Voici les exemples récupérés avec un client MQTT (MQTT.fx).
Sur color_move, je récupère ceci : {"action":"color_move","action_color":{"x":0.7,"y":0.3},"action_group":16387,"action_transition_time":0,"last_seen":"2025-02-10T18:30:10.634Z","linkquality":185}
Sur color_temperature_move, voici le retour : {"action":"color_temperature_move","action_color_temperature":153,"action_group":16387,"action_transition_time":10,"last_seen":"2025-02-10T18:32:33.806Z","linkquality":167}
Bonsoir, j’ai l’impression de ne pas mettre bien expliqué ou d’être passé à côté de quelque chose. J’ai bien acté la prise en compte de cas particulier pour les éléments qui sont expose.
Dans le cas présent, la création du device ne génère que les features mappés depuis Zigbee2mqtt et géré par Gladys qui sont expose dans Zigbee2mqtt.
Par conséquent, la télécommande ne dispose pas de features pour la couleur ni la température, features pour stocker les états et pouvoir les utiliser dans les scènes.
L’astuce pourrait être de forcer l’intégration Zigbee2mqtt à ajouter les features « utiles » mais ça me parait beaucoup juste pour cela.
Je ne voudrais pas m’embarquer dans une usine à gaz pour ces 2 points.
Juste pour comprendre le besoin, comment utilises tu cette télécommande et qu’est-ce que tu aimerais faire avec une fois qu’elle serait intégré dans Gladys ?
L’objectif est de pouvoir utiliser la gestion des couleurs, de la température de l’éclairage, la luminosité d’une ampoule RGB ainsi que des ambiances lumineuses associables aux six boutons de scènes. Pour la gestion des boutons scènes, ça fonctionne. Même chose pour la luminosité. Le problème reste la gestion de la température de l’éclairage ainsi que la couleur comme expliqué précédemment.
La gestion de groupe de lumière ( action_group) pourrait être un plus mais ce n’est pas ma priorité.