J’ai installé tydomtoMQTT et cela fonctionne très bien. Sauf que, pour chaque lampe cela m’a créé 2 appareils différents l’un avec les capteurs (Entités liées: level_tydom__Plafond_Bureau, thermicDefect_tydom__Plafond_Bureau, id_tydom__Plafond_Bureau, device_id_tydom__Plafond_Bureau, endpoint_id_tydom__Plafond_Bureau) , l’autre avec le controles (light.lum_salle_de_sport_plafond).
Mon problème c’est que quand je contrôle ma lampe depuis home assistant, Il remonte bien l’info dans « level_tydom__Plafond_Bureau » passant de 0 quand éteint à 100 quand allumé. L’icône du contrôleur passe bien au jaune donc allumé.
Par contre si j’appuie sur le bouton physique le capteur « level_tydom__Plafond_Bureau » réagit correctement mais l’icône du contrôleur ne réagit pas car les deux appareils sont séparés. Par conséquent si j’allume par home assistant ma lumière et que je l’étain physiquement l’icône du contrôleur ne bouge pas.
Du coup comment faire pour réunir dans un seul appareil les commande et les sensor. Je le même problème pour les volets
Je connais pas spécialement tydom mais j’ai pas mal joué avec MQTT discovery qui est utilisé par tydom2mqtt pour créer les appareils/entités.
Il semblerait que le soucis vienne de tydom2mqtt qui crée 2 appareils dans HA pour un même appareil physique (votre lampe).
En regardant rapidement le code de tydom2mqtt, il semblerait que ce soit effectivement le cas.
Light.py fait appel à sensor.py pour créer les sensors, sauf que les structures device sont différentes.
MQTT Discovery comprend donc qu’il s’agit de 2 appareils différents.
A confirmer avec le dev de tydom2mqtt.
Une solution temporaire serait de passer par MQTT Explorer et modifier une des 2 structures device pour qu’elle soit équivalente à l’autre.
Sinon il faut remonter une issue sur github en indiquant le problème que j’ai expliqué.
Je pense que c’est plus safe de remonter une issue sur github.
A mon avis c’est volontaire d’avoir séparé les élements.
D’un coté ça crée des sensors, et de l’autre un cover. L’avantage de ce dernier c’est de pouvoir être utilisé de la même façon partout (volet RTS, zigbee etc) et avec les compléments (timecover etc). En regroupant, on perdrai directement cette fonction.
Par ailleurs, au quotidien, vu les sensors, je pense qu’il ne sont même pas utiles : la position est connue dans le volet, l’id ne sert à rien dans HA et le reste est vide…
PS: Editer la structure coté MQTT ne sera qu’une solution temporaire, à la prochaine publication des messages, l’ancien format reviendrai
Pas sûr d’avoir compris l’avantage de séparer sensors et cover dans deux appareils différents.
Rien n’empêche en soit d’avoir un seul appareil avec tout là dedans comme c’est le cas dans la réalité d’ailleurs.
Si tu peux donner plus de détails, je suis preneur
Désolé si c’est pas clair. Pourtant quand tu lis les noms des sensors tu te rends bien compte que c’est plus en lien avec la box tydom qu’avec un volet proprement dit… Ça représente quoi ‹ thermicdefect › pour un volet par exemple ?
Dans la réalité tu n’as pas 1 mais 2 appareils : volet et box(ou son écosystème)
Sinon posons la question dans l’autre sens dans ce cas:
Quel avantage de tout regrouper sachant que ce n’est pas cet affichage que tu vas utiliser (l’affichage se fait via les cartes) ? A quoi te servirai ces sensors si considérés comme appartenant au volet dans un usage quotidien ? Avec un deuxième volet raccordé à la même box, on met tout dans 1 seul regroupement ? Ce fameux 'thermicdefect serai rattaché au volet 1 ou 2 ? Même cas avec 1 volet et 1 lampe qui est lié à quoi ?
en fait la difficulté c’est que finalement le retour d’état se fait par le sensor mais comme il n’est pas inclus avec le cover, tant que l’on se sert que de ha cela fonctionne mais si je change l’état pa run bouton physique ou même par l’application tydom, le retours d’état ne se fait pas au niveau des commandes. On a donc une lampe qui soit reste allumé hors elle apparait éteinte dans le faux retours d’état des commandes et vis versa. y a t il possibilité de créer moi meme mes lampe dans le config.jaml en lui disant de se référer au retours d’état du sensor.
Ça n’en avait pas l’air tel qu’exposé par @mimilamy2000 et de ce que j’ai vu dans le code.
Comme je disais, je ne connais pas Tydom donc si c’est comme ça en vrai, je comprendrais, donc ok.
level est soit 0 soit 100
du coup
est-ce que je dois écrire
{℅ if state_attr(‹ light.lampe_atelier_agnes ›, ‹ level ›) = 100 = valeur_equivalent_on ℅}
ou
{℅ if state_attr(‹ light.lampe_atelier_agnes ›, ‹ level ›,100) == valeur_equivalent_on ℅}
