Ici c’est le numéro de série du capteur, j’imagine qu’il est donc bien unique ! 
tu as mis le même ID sur Porte fenêtre et porte entrée ?
La logique est de laisser faire MQTT pour cet unique ID et ensuite seulement le mettre dans le Payload
Surtout avec leur nouveau renommage !
Non chaque capteur à son propre numéro de serie
Tu me montres çà, alors je comprends pas !
Merde mauvais copy past !
Porte d’entrée:
{"device_class":"Door","name":"Porte entrée","unique_id":"00C0275A","state_topic":"homeassistant/binary_sensor/jeedom/porte-entree/state", "payload_on": "1", "payload_off": "0", "expire_after":"30", "value_template":#[Maison][Porte entrée][Ouverture]#,"icon":"mdi:window-closed-variant"}
Porte fenêtre:
{"device_class":"window","name":"Porte-Fenêtre SAM","unique_id":"00C04E71","state_topic":"homeassistant/binary_sensor/jeedom/portefenete-sam/state", "payload_on": "1", "payload_off": "0", "expire_after":"30", "value_template":#[Salle à manger][Porte fenêtre][Ouverture]#,"icon":"mdi:window-closed-variant"}
Ok.
regardes le nommage du senseur dans HA
Visiblement, binary_sensor.porte_entree et binary_sensor.porte_fenetre_sam
Tu n’as pas créé d’appareils ?
Attention au mélange alphabétique entre Majuscule et minuscule, même si MQTT le change ou HA
Ça m’a créé une entité, ce qui était suffisant pour mon besoin. La je constate juste une latence, jamais je ferme/reouvre ma porte 10 fois d’affilé… mais clairement au final je termine toujours par un état qui merdouille (J’ai checké, ce n’est pas le cas dans Jeedom.)
J’avais dans l’idée de balancer les action mode nuit, armé, désarmé et Panic mais je vais attendre d’avoir un truc plus stable 
Pour ça que je suis curieux des intégrations réussi des gars plus haut (Enfin peut être qu’ils ont lachés l’affaire aussi !)
C’est pas facile à vérifier ?
C’est surtout les messages de décodage sur MQTT de HA, qui ne se font pas toujours!, il faut vérifier dans les log et sur MQTT explorer tu as History !
Dernier example juste maintenant, ma porte fenêtre qui marchait parfairement à mon premier message ce soir ne change plus d’état maintenant Définitivement, y’a un truc qui va pas !
Tu sais faire la simule des cde depuis Jeedom ?
Le MQTT du state traduit comment sur Jeedom dans l’info ?
Je me servais plus du Payload si config Ok dans les entités !
Alors sur ces boutons action côté Jeedom, l’idée c’est d’appeler l’URL direct de l’action. J’imagine que je dois pouvoir faire ça d’une façon ou d’une autre depuis HA. Créer un bouton qui appel un URL. Il me reste l’état à récupérer ensuite, peut être via MQTT…
Enfin, déjà quand mes ouvrants seront ok, on verra cette dernière partie
Je voulais dire faire une cde qui simule tes ouvrants.
Tu les récupère comment sur Jeedom ?
Via un plugin officiel, jeedom à visiblement un accès API, ça passe donc par chez eux.
Au final pour moi, c’est comme un bête capteur zigbee, je cherche juste à l’avoir de façon stable via MQTT
Accessoirement et aux dernières nouvelles, une implémentation officielle HA semble compromise à moins que ce soit Nabu casa direct qui gère le truc (Comme l’a fait Jeedom).
Donc trouver un moyen de balancer toute ces infos via MQTT et de faire une petite card avec quelque bouton pour armer,désarmé, ce serait cool !
Ce qu’il faut surtout, c’est regarder au niveau de MQTT Explorer le message et son history, comme c’est horodaté tu dois voir si pas l’information !
Tu peut forcer l’envoie de l’état « state » ( si config OK) dans Jeedom dans la partie action de ce state, sur le bouton en fin de ligne 
Ensuite sur Ha regarder dans MQTT les messages avec l’historique( horodatage pas à la seconde !)
Bonsoir et Merci, c’est donc bien ce que j’ai fais. Dans mqtt explorer, c’est vraiment du temps réel. J’ai toujours le bon état au bon moment, sur jeedom aussi du coup, forcément.
Par contre sur HA, parfois oui, parfois non… Si par contre en effet, je pousse le bouton du state côté Jeedom, c’est ok instantanné.
Au passage, j’ai pu balancer vers HA mes boutons actions pour armer/désarmer en bouquinant Rest, ca marche super ça !
En attendant de comprendre le truc… j’ai créé un scénario sur Jeedom qui relance l’ensemble de mes state toutes les 1min. J’ai pas un temps réel mais au moins c’est pas complétement déconnant comme workaround.
Bon j’ai refait le test après plusieurs mois d’absence…
Ca a l’air de fonctionner. Bon les états des ouvertures sautent des fois. Mais ça me parait logique car ça passe par le cloud ajax/jeedom.
Par contre pour mettre l’état de toutes mes fenetres, tu me conseilles de tout mettre dans le même équipement jeedom jmqtt ou de créer un équipement par device ?
Bon finalement non
J’ai vérifié dans l’explorateur MQTT windows, le value template reflete dans 100% des cas celui du captuer JEEDOM Ajax.
En revanche dans HA l’entité n’est pas mise à jour dans 100% des cas. Et des fois c’est même super étranger car quand je ferme la fenetre, l’entité HA montre que la fenêtre vient de s’ouvrir…
Même quand on écoute le sujet MQTT dans HA, le value_template est bon. C’est mon entité qui ne se rafraichit pas dans 100% des cas. C’est rageant