Allez, j’attaque les volets maintenant !
Bon mon volet est reconnu, c’est déjà bien par contre je sais pas tellement quelles infos lui envoyer pour modifier la position.
Et je sais pas si je dois passer encore par script comme pour les lumières, ou directement via MQTT.cover ( MQTT Cover - Home Assistant ).
Merci 
Avant que mon enoceanmqtt arrete de fonctionner, j’avais fait le script suivant pour régler la position des volets, dans le même esprit que le script de @mak-dev pour les lumières :
vr_set_position:
alias: VR_set_position
sequence:
- service: mqtt.publish
data:
topic: enocean/{{ module }}/req/POS
payload: '{{ pos }}'
- service: mqtt.publish
data:
topic: enocean/{{ module }}/req/ANG
payload: '0'
- service: mqtt.publish
data:
topic: enocean/{{ module }}/req/REPO
payload: '0'
- service: mqtt.publish
data:
topic: enocean/{{ module }}/req/LOCK
payload: '0'
- service: mqtt.publish
data:
topic: enocean/{{ module }}/req/CHN
payload: '0'
- service: mqtt.publish
data:
topic: enocean/{{ module }}/req/CMD
payload: '1'
- service: mqtt.publish
data:
topic: enocean/{{ module }}/req/send
payload: clear
mode: single
Avec pos une valeur entre 0 (fermé) et 100 (ouvert).
Avec ça, je pouvais régler la position des VR. Par contre, je ne savais pas trop comment récupérer un changement qui serait engendré par ailleurs (en actionnant l’ouverture via un interrupteur par exemple). Pour la lumière, on créait un binary_sensor. Ici, j’ai tenté d’utiliser, comme toi, mqtt cover :
mqtt:
cover:
- name: "MQTT Cover"
command_topic: "enocean/module_name/CMD"
state_topic: "enocean/module_name/POS"
payload_open: 1 # CMD to open or close is 1
payload_close: 1
state_open: 100
state_closed: 0
Mais c’est là que je bloquais. Il me semble que ça m’affichait bien la position. Par contre, lorsque j’essaie de mettre une lovelace card pour ce sensor de type « cover », l’ouverture/fermeture ne fait rien.
Je ne sais pas du tout comment gérer ici (et je n’ai plus de quoi tester…). Il faudrait presque pouvoir mettre « script.vr_set_position » dans command_topic, mais je ne sais pas si c’est possible.
Hello, merci de ta réponse, j’étais parti sur presque le même script que toi, mais je tentais un POS à 50 pour l’ouverture, et ca ne faisait rien du tout … Par contre j’envoyer CMD 4 à la place du 1.
C’est peut être ca, je testerais ce soir avec du 1.
Je regarde de mon coté pour récupérer l’état. Je vois bien dans MQTT explorer quand ca bouge en tout cas, ca doit donc être facilement récupérable sous HA
CMD 4 c’est justement le module qui renvoie sa position de ce que j’ai compris. CMD1 c’est pour aller à telle position. J’avais tenté aussi avec POS 50 et ça marchait.
Avec le code que j’ai mis au-dessus de mqttcover, je récupère bien la position. Mais je n’arrive pas à voir comment piloter le VR depuis l’interface. Par exemple, si je fais une entity card avec ce sensor de type « cover », j’ai ça :
Sauf que les flèches ne descendent/montent pas les volets, et elles ne se mettent pas non plus à jour (par exemple, si le store est ouvert comme ici, la flèche pour descendre n’est quand-même pas dispo…). Faut-il le faire « à la main » en appelant le script ?
Ok j’avance 
cover:
- name: "Volet Baie Vitrée"
command_topic: "enocean/volet_baievitre/CMD"
position_topic: "enocean/volet_baievitre/POS"
set_position_topic: "enocean/volet_baievitre/req/POS"
qos: 0
retain: true
payload_open: "1"
payload_close: "1"
Avec ca, et surtout la ligne « position_topic » j’arrive à avoir l’état dans une card disponible sous HACS :
Par contre je m’apercois que le volet à 50%, ca donne le volet ouvert de 20% a peine et que le 0% et le 100% sont inversés, mais ca c’est juste de la conf du mqtt.cover je pense.
J’arrive pas encore à piloter depuis cette card, mais surement avec la meme conf que sur le widget des lumières et appeler le script depuis la card
Hello,
J’ai encore fait des modifs hier dans enoceanmqtt que je n’ai pas encore « pushées » vers mon github.
Ces modifs apportent un support complet du format JSON.
J’ai fait des tests sur mes lumières et grâce à ces modifs et mqtt.light, j’ai pû intégrer une lumière sans écrire une ligne de script.
En fait @asetGem a tout à fait raison en disant qu’il faudrait presque mettre le script dans la commande et c’est exactement ce que permet de faire le format JSON.
Le script qu’on faisait jusqu’à présent décomposait la commande en plusieurs messages MQTT. Avec le format JSON, on peut envoyer la commande en un seul message.
En fait, à mon avis, c’est normal que ça ne fonctionne pas très bien parce que là vous indiquez uniquement comment remplir le champ CMD de la commande, mais la commande en elle-même est constituée de plusieurs champs (CMD, POS, etc.).
Avec les modifs que je « pusherai » ce soir, votre mqtt cover devrait ressembler à peu près à ça:
cover:
- name: "Volet Baie Vitrée"
command_topic: "enocean/volet_baievitre/req"
position_topic: "enocean/volet_baievitre/POS"
qos: 0
retain: true
payload_open: "{\"CMD\":\"1\",\"POS\":\"100\",\"REPO\":\"0\",\"LOCK\":\"0\",\"CHANNEL\":\"0\",\"ANG\":\"?\",\"send\":\"clear\"}"
payload_close: "{\"CMD\":\"1\",\"POS\":\"0\",\"REPO\":\"0\",\"LOCK\":\"0\",\"CHANNEL\":\"0\",\"ANG\":\"?\",\"send\":\"clear\"}"
Pas dit que ce soit tout bon en l’état mais c’est l’idée en tout cas. Je n’ai pas encore intégré mes VR donc je ne sais pas comment le champ ANG évolue mais il faudra lui attribuer une valeur correcte.
Je vous tiens au courant dès que les modifs sont disponibles.
En fait, à mon avis, c’est normal que ça ne fonctionne pas très bien parce que là vous indiquez uniquement comment remplir le champ CMD de la commande, mais la commande en elle-même est constituée de plusieurs champs (CMD, POS, etc.)
C’était exactement mon problème. On ne peut donner dans « command-topic » qu’un seul topic, alors que pour la commande complète il en faut plusieurs. D’où mon « « mettre « script.vr_set_position » dans command_topic » » pour justement lui donner l’ensemble des commandes. Du coup ça sera top avec la modif que tu proposes. Malheureusement, je ne peux pas tester pour l’instant.
Je n’ai pas encore intégré mes VR donc je ne sais pas comment le champ
ANGévolue mais il faudra lui attribuer une valeur correcte.
Perso mes VR sont « verticaux » en un seul bloc (pas des lames orientables), donc il n’y a pas de valeur ANG à régler. Je la laisse donc sur 0, la valeur par défaut.
Par rapport à la séquence d’instructions mqtt, il ne faut pas respecter l’ordre [pos, ang, repo, lock, chn, cmd, send] (je n’y connais rien, c’est peut-être une question bête…) ?
Et une autre question : que signifie retain ? Je le vois à plein d’endroit, mais je n’arrive pas à comprendre ce qu’il fait.
Par contre je m’apercois que le volet à 50%, ca donne le volet ouvert de 20% a peine et que le 0% et le 100% sont inversés, mais ca c’est juste de la conf du mqtt.cover je pense.
J’ai remarqué aussi que les pourcentages donnés ne correspondent pas trop à la réalité. Chez moi, 0 est fermé, 100 est ouvert, et 50 est 2/3 fermé. Mais ça ne vient pas de enoceanmqtt. Dans l’appli officielle j’avais déjà ce problème. Je pense que c’est une histoire de calibration des volets. Mais par contre, on peut surement trouver un hac pour le corriger dans HA.
Non pas besoin, il faut juste configurer tous les champs qu’on veut (peut importe l’ordre) avant d’envoyer send lorsqu’on n’utilise pas le format JSON.
Et c’est encore moins nécessaire avec le format JSON. Lorsque le message est reçu dans enoceanmqtt, on regarde juste si le message comporte un champ send, si oui, on crée un paquet EnOcean avec les valeurs définies dans le message. Sinon on stocke les valeurs définies dans le message en attendant de recevoir plus tard le champ send.
Dans le cas où retain = true le broker garde ce message et l’enverra directement à tous ceux qui souscriront au topic par la suite. Plus d’info ici.
Il y a normalement une calibration à faire afin que le module apprenne à quel moment le VR est fermé ou ouvert.
Je pense le soucis décrit vient peut être d’une calibration défaillante.
Un exemple de calibration dans la video ici.
Merci j’y vois un peu plus clair. Ça sera encore plus clair lorsque j’intégrerai mes volets.
Il y a normalement une calibration à faire afin que le module apprenne à quel moment le VR est fermé ou ouvert.
Je pense le soucis décrit vient peut être d’une calibration défaillante.
Oui, j’ai bien fait la calibration, mais j’ai quand même le problème. Et ça me le fait sur tous les VR, donc c’est un soucis du module le pense. Et a priori pareil pour @Judzk
Mais bon, ça n’empeche pas de les intégrer dans HA, et voir par la suite comment corriger.
ma calibration est fait, mais je pense que c’est un soucis propre a mqtt.
MQTT veut forcement de 0 à 100.
Par contre quand tu calibres ton module enocean, imagine que la plage est de 0 à 180. Quand tu lances ta calibration il va mettre des butées dès qu’il sent que le moteur bloque. Donc il peut te mettre des butées à 40 fermé et 120 ouvert.
MQTT sera en 0-100
le module sera en 40-120
mais j’ai vu qu’on pouvait gérer ce soucis dans mqtt cover
Ici on le voit utilisé avec un tilt, on devrait pouvoir faire pareil avec ‹ position_min › et ‹ position_max ›
Reste juste a déterminer les valeurs
Le module que j’ai (D2-05-00) reporte sa position entre 0 et 100. Je ne savais pas que ça pouvait être différent pour d’autres modules. Quel est l’EEP de votre module juste par curiosité ?
Le mien c’est aussi D2-05-00, et je pense qu’il est bien entre 0 et 100. Il n’est juste pas également réparti entre 0 et 100, mais je ne sais pas pourquoi.
J’ai aussi un d2-05-00, et le sav m’avait expliqué comme ça a l’époque. J’avais aussi bien le soucis avec jeedom ou la box Leroy Merlin
Ok. Donc ce qu’on peut faire:
- Mettre le VR en position « fermé »
- Utiliser mqtt_explorer pour récupérer la position retournée par le module en envoyant la commande 3 et en regardant ce qui est retourné dans POS et ANG.
- Mettre le VR en position « ouvert »
- Utiliser mqtt_explorer pour récupérer la position retournée par le module en envoyant la commande 3 et en regardant ce qui est retourné dans POS et ANG.
- Utiliser les valeurs récupérées dans les commandes d’ouverture et fermeture des VR.
Je vais essayer de mettre à profit ce long week-end à venir pour tester mes VR. J’y verrai plus clair à ce moment là.
J’ai récup ton commit, les boutons a coté de la card cover fonctionne très bien ( sauf le stop mais normal je pense ).
Par contre faut que je regarde pourquoi les boutons sont inversés mais ca c’est du tuning propre à mon install.
C’est top ! Merci pour le test. Ne surtout pas hésiter à remonter les bugs potentiels sur github.
Je pense que je vais laisser tourner chez moi une bonne semaine au moins pour vérifier qu’il n’y a pas de bug avant de demander à fusionner le commit dans enoceanmqtt.
La prochaine étape sera de mettre quelque chose en place autour de MQTT discovery pour rajouter automatiquement les devices EnOcean dans HA.
Quand j’aurai quelque chose de potable, j’aurai besoin encore une fois de bêta-testeur, donc si vous avez un module (peu importe lequel) qui peut attendre un peu avant d’être intégré … 
J’ai un D2-0F-01 qui peut attendre et un autre module volet dans un tiroir si jamais, donc pas de soucis pour refaire des tests
1 « J'aime »
J’ai récup ton commit, les boutons a coté de la card cover fonctionne très bien ( sauf le stop mais normal je pense ).
Si tu veux que le stop fonctionne, il faut rajouter cette ligne dans la définition du cover dans configuration.yaml :
payload_stop: "{\"CMD\":\"2\",\"CHN\":\"0\",\"send\":\"clear\"}"
Et pour pouvoir régler directement la position :
set_position_topic: "enocean/VR salon/req"
set_position_template: "{\"CMD\":\"1\",\"POS\":\"{{ position }}\",\"ANG\":\"0\",\"REPO\":\"0\",\"LOCK\":\"0\",\"CHN\":\"0\",\"send\":\"clear\"}"
Moi j’ai un E-wattch ( A5 12 01 ou A5 12 00) qui n’est actuellement pas pris en charge. Donc pareil, je peux bêta tester si besoin !