Si une ampoule est éteinte, le fait de changer sa luminosité allume l’ampoule. Existe-t-il un moyen que l’ampoule reste éteinte tout en mémorisant le réglage de luminosité ? (dans z2m peut -être ?)
Salut @Chris75,
Ce comportement ne vient pas de Gladys mais du Zigbee lui-même. Quand on change la luminosité, la commande envoyée est « Move to Level (with On/Off) », qui allume l’ampoule par conception. La plupart des ampoules ne savent pas modifier leur niveau en restant éteintes.
Deux pistes côté Zigbee2MQTT, si ton ampoule les expose. Va dans Z2M, sélectionne l’appareil, puis regarde s’il y a un bloc level_config dans les exposes :
on_level: c’est le niveau qui sera appliqué la prochaine fois que l’ampoule reçoit un ordre d’allumage. C’est exactement ce que tu cherches, tu mémorises la luminosité sans allumer.execute_if_off: autorise l’envoi d’un changement de luminosité sans allumer la lampe. Le support dépend beaucoup du firmware, certaines ampoules l’ignorent complètement.
Il existe aussi current_level_startup si ton besoin est plutôt de fixer le niveau après une coupure de courant.
Après, si l’objectif final est simplement que l’ampoule s’allume à la bonne luminosité dans un cas précis, le plus simple reste de mettre l’action « changer la luminosité » directement dans la scène qui allume. Pas besoin de pré-mémoriser quoi que ce soit, l’ampoule s’allumera au niveau demandé.
En fait j’ai trouvé la solution suivante : j’ai créé un mode nuit/jour (on/off) dans un widget avec un réglage général de la luminosité pour la nuit (variable virtuelle mqtt). Du coup je n’ai pas besoin de changer la luminosité dans chaque scène concernée, car l’ampoule s’allumera bien avec le niveau de luminosité défini dans le mode nuit
Mais effectivement il existe une autre possibilité avec les exposes suivants :
mais je suppose qu’ils ne sont pas repris dans gladys et je dois utiliser node-red ?
Salut @Chris75,
Ta solution mode nuit/jour est très bien, c’est même souvent plus lisible qu’un réglage caché dans l’ampoule : tu vois d’un coup d’œil dans quel état tu es, et ça marche pareil pour toutes tes ampoules quelle que soit la marque. Si ça te convient, garde-la 
Pour répondre à ta question : tu as raison, ces exposes ne sont pas repris dans Gladys. Le service Zigbee2MQTT convertit les exposes en fonctionnalités Gladys via une correspondance explicite (state, brightness, color_temp, température, humidité, etc.), et tout ce qui sort de cette liste est ignoré. level_config en fait partie : c’est un objet composite de paramètres, et aujourd’hui Gladys ne gère les composites que pour la couleur.
En revanche, pas besoin de Node-RED. Deux options :
1. Le plus simple : le régler une fois dans l’interface Zigbee2MQTT. Ces valeurs sont stockées dans l’ampoule elle-même, pas dans z2m. Tu vas dans l’onglet Exposes de ton ampoule dans l’UI Z2M, tu mets ton on_level (ou tu actives execute_if_off), et c’est terminé: Gladys n’a rien à savoir, le comportement change pour tout le monde, y compris tes scènes existantes.
2. Si tu veux le changer dynamiquement (typiquement : basculer on_level selon ton mode nuit/jour), il y a une action de scène dédiée dans Gladys : Zigbee2MQTT → Envoyer un message MQTT. Tu mets :
- Topic :
zigbee2mqtt/nom_de_ton_ampoule/set - Message :
{"level_config": {"on_level": 50}}
Et ça passe directement par la connexion MQTT de Gladys, sans dépendance supplémentaire. Le message accepte les variables Handlebars, donc tu peux même y injecter une valeur venant d’ailleurs dans la scène.
Deux mises en garde sur ces attributs : execute_if_off et on_level sont optionnels dans la spec Zigbee, toutes les ampoules ne les implémentent pas (et certaines les acceptent sans les appliquer). Le fait que z2m les affiche dans les exposes est bon signe mais pas une garantie: teste avant de construire toute ta logique dessus.
Après, si plusieurs personnes ont le besoin, on peut tout à fait ajouter la prise en charge de level_config dans le service Zigbee2MQTT. La vraie question est de savoir sous quelle forme l’exposer côté Gladys : c’est un paramètre de configuration du device plutôt qu’une valeur à piloter au quotidien, et ça n’entre pas naturellement dans les catégories de fonctionnalités actuelles.