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 !
Bonjour,
Concernant le calibrage des VR (message de @mak-dev https://forum.hacf.fr/t/enocean-fil-pilote-compatible/9087/44?u=asetgem) J’ai vérifié, et ça confirme bien nos observations :
- Fermé : ANG=0, POS= 100.
- ouvert : ANG=0, POS=0
Par contre, entre les 2, ce n’est pas linéaire. Par exemple, si je mets le volet :
- à la moitié, POS = 35.
- à 1/4, POS = 15
- à 3/4, POS = 62
Donc POS varie bien entre 0 et 100, pas de soucis de ce côté-là, mais par contre pas régulièrement.
Autre comportement étrange (complètement indépendant du calibrage). J’ai donc réussi à intégrer mes VR (je peux les monter/descendre/stop/aller à un % donné) et mes lumières (on/off) dans HA. Par contre, lorsque je reboot le système (et donc relance enoceanmqtt), mes volets se ferment (ou s’ouvrent) tous seuls jusqu’à être à 80% fermés environ ! Un peu embetant si le RPi redémarre en pleine nuit pour une raison ou une autre…
Une idée d’où ça pourrait venir ?
Merci !
Hello @asetGem,
Merci pour les infos sur la calibration. Ça ressemble donc à un genre de « défaut » au niveau du module.
Je n’ai malheureusement pas de neutre au niveau de mes interrupteurs de volets donc j’ai remis à un peu plus tard l’intégration de mes VR, le temps de voir si je peux tirer quelques fils.
Pour votre soucis au reboot, là comme ça j’imagine deux possibilités:
1- Faire une automatisation dans HA pour, à chaque démarrage, remettre les VR à leurs positions … (:~)
2- Utiliser retain=true dans vos messages MQTT vers VR pour que le broker garde le dernier message concernant la position des VR. Ensuite, lorsque enoceanmqtt sera relancé et qu’il souscrira au topic concernant la position des VR, le broker lui enverra directement le dernier message connu et donc normalement la dernière position. Le VR devrait donc rester à sa position.
La solution 2 semble la plus séduisante, mais à confirmer que ça corrige bien votre soucis.
Merci pour les infos sur la calibration. Ça ressemble donc à un genre de « défaut » au niveau du module.
Oui. Mais un défaut « générique », dans le sens où le « biais » est le même sur tous les modules de ce type (du moins sur ceux que j’ai).
Je n’ai malheureusement pas de neutre au niveau de mes interrupteurs de volets donc j’ai remis à un peu plus tard l’intégration de mes VR, le temps de voir si je peux tirer quelques fils.
Moi non plus, mais en réappuyant dans la même direction (appuyer sur fermer lorsque c’est en train de se fermer), c’est l’équivalent du stop/neutre.
La solution 2 semble la plus séduisante, mais à confirmer que ça corrige bien votre soucis.
Au départ j’avais bien retain=true. Puis je me suis dit que, si je changeais la position manuellement (ie depuis un interrupteur physique), il allait peut-être revenir à la dernière position demandée dans HA justement. Donc j’avais enlevé le retain, mais le problème est toujours là. Je vais essayer de le remettre, j’ai peut-être changé autre chose entre temps.
Je parlais plutôt du fil de neutre électrique . Sans ça, je ne peux pas alimenter mon module et il faut donc que je vois si je peux tirer le neutre depuis mes volets vers les interrupteurs.
Effectivement j’avais oublié cette partie commande manuelle.
Et je pense qu’avec ce dernier bout de message, je viens de comprendre pourquoi vos volets se comportent comme vous l’avez décrit.
Je pense que le broker MQTT renvoie à chaque reboot la consigne correspondant à votre dernier message MQTT avec le retain = true. Ce qui fait que ça se comporte exactement comme je l’ai décrit précédemment dans la solution 2, mais avec une (très) ancienne valeur de position.
Si j’ai vu juste, alors ce qu’il faut faire, c’est supprimer cet ancien message du broker en envoyant un message vide sur le topic en question.
Par la suite, il faudra supprimer le retain = true de vos messages MQTT vers VR.
Note: Pendant que j’y pense, après chaque reboot, il se pourrait que HA ne sache pas quel est l’état de vos VR et affiche une icône indiquant « position inconnue » dans votre dashboard. Si vous avez ce « soucis », il faudra mettre persistent = true dans la configuration de vos VR dans enoceanmqtt.conf.
En faisant ça, le dernier message concernant la position de vos VR, qu’il soit le résultat d’une commande HA ou manuelle, sera conservé au niveau du broker MQTT, et HA l’aura dès qu’il souscrira aux topics MQTT de vos VR après chaque reboot. Il affichera donc la bonne position dans votre dashboard.
Note: Pendant que j’y pense, après chaque reboot, il se pourrait que HA ne sache pas quel est l’état de vos VR et affiche une icône indiquant « position inconnue » dans votre dashboard. Si vous avez ce « soucis », il faudra mettre
persistent = truedans la configuration de vos VR dans enoceanmqtt.conf.
En effet, j’ai ce problème pour toutes les entités (lumières et VR) qui sont ‹ indisponible › au reboot. Mais dès que l’état du device est modifié (que ce soit via HA ou manuellement), il devient disponible. Je n’y avais donc pas prêté + attention que ça. Je viens d’essayer le persistent: true mais ce n’est pas implémenté (Invalid config for [mqtt]: [persistent] is an invalid option for [mqtt]). Dommage !
Je parlais plutôt du fil de neutre électrique
Oups. Comme j’ai des interrupteurs enocean (donc sans fil) je n’avais pas pensé à ça ^^.
D’ailleurs, je n’arrive pas à les intégrer. ça doit être possible, puisqu’avec l’intégration enocean de HA c’était une des seules choses que j’arrivais à faire ^^. Ce sont des F6-02-02, qui est bien dans EEP.xml de la librairie enocean. Mais même en le mettant dans mon enoceanmqtt.conf, le sensor n’apparait pas dans le mqtt explorer. Je ne vois pas comment récupérer les événements tels que « button_pressed ».
Hello,
Persistent = true est à mettre dans enoceanmqtt.conf, pas au niveau de HA.
Bizarre pour vos interrupteurs F6-02-02. Si ça se trouve dans EEP.xml, normalement ça devrait être supporté. Je vais jeter un coup d’oeil tout à l’heure.
Le soucis que vous avez au reboot avec vos VR est résolu alors ?
J’ai fini par ouvrir MQTT_explorer, où j’ai vu que, en effet, il y avait de vieux messages en ‹ retained ›. Je les ai effacés (toujours via mqtt-explorer). Dans mes sensors HA, j’ai bien retain=false, et maintenant les VR ne bougent plus au reboot
Concernant le persistent, j’ai fini par trouver où le mettre : il faut mettre persistent = 1 dans la définition de chaque capteur. Par exemple :
[VR salon]
address = 0x00000000
rorg = 0xD2
func = 0x05
type = 0x00
log_learn = 1
command = CMD
persistent = 1
Pour les VR, tout semble OK maintenant.
Pour les lumières, je voudrais tester avec mqtt-light au lieu d’un mqtt-binary_sensor, pour ne pas avoir à mettre tap_action et ses différents paramètres à chaque fois que je veux contrôler une lumière dans lovelace.
Je ferai un retour sur mes tests.
Restera ensuite les interrupteurs, et le E-wattch à intégrer.
1 « J'aime »
Parfait ! 
Oui c’est exactement ça. C’est ce que je disais un peu plus haut. Ce n’était peut être pas très clair.
J’ai également intégré mes lumières en utilisant mqtt.light. Ça marche très bien. J’ai quelque chose de fonctionnel donc je pourrai vous aider si besoin.
J’avance bien sur les modifs que je voulais intégrer pour que tout soit fait automatiquement. Je devrais mettre à disposition quelque chose sous peu 
Je crois que je vais avoir besoin de vos lumières ( 
) pour intégrer mes lumières avec mqtt.light
J’arrive à les commander, mais pas à récupérer le statut. Du coup, le « toggle lights » ne fonctionne pas car, n’ayant pas l’état, il ne sait pas s’il doit éteindre ou allumer… Voilà ma config :
light:
- name: "light_lumiere pt"
unique_id: "light_lumiere pt"
state_topic: "enocean/lumiere cuisine/IO1/OV"
payload_on: "{\"CMD\":\"1\",\"DV\":\"0\",\"IO\":\"1\",\"OV\":\"64\",\"send\":\"clear\"}"
payload_off: "{\"CMD\":\"1\",\"DV\":\"0\",\"IO\":\"1\",\"OV\":\"0\",\"send\":\"clear\"}"
command_topic: "enocean/lumiere cuisine/req"
J’imagine que c’est dans state_value_template qu’il faut compléter. Mais je n’arrive pas à trouver la bonne variable. Il faudrait quelque chose du genre # state_value_template: 'iif{{ OV }} == "0", "off", "on" }}' avec OV la valeur lue dans state_topic, mais je n’ai pas la bonne variable à priori.
Est-ce que vous pouvez m’éclairer ?
Merci !
Hello
Excellent !
Essayez avec ça:
light:
- schema: template
name: "light_lumiere pt"
unique_id: "light_lumiere pt"
state_topic: "enocean/lumiere cuisine/IO1/OV"
state_template: {% if value == "0" %}off{% else %}on{% endif %}
command_topic: "enocean/lumiere cuisine/req"
command_on_template: "{\"CMD\":\"1\",\"IO\":\"1\",\"OV\":\"100\",\"send\":\"clear\"}"
command_off_template: "{\"CMD\":\"1\",\"IO\":\"1\",\"OV\":\"0\",\"send\":\"clear\"}"
Vous aviez quasiment bon, excepté qu’il fallait plutôt utiliser schema = template.
Juste pour info 0x64 = 100 d’où le OV = 100 dans les commandes. En fait même avec 64 ça aurait fonctionné je pense parce que le module interprète toute valeur OV différente de 0 comme une commande d’allumage.
Et aussi, si le message est un message « simple », HA utilise la variable value pour stocker la payload du message.
Si c’était un message au format JSON, ce serait value_json et donc value_json.OV par exemple.
1 « J'aime »
Hello, petit retour d’utilisation de l’été, j’ai parfois, tout les 2/3 les états qui ne fonctionnent plus sous HA, tout est ok sur le raspberry, le service tourne toujours et son status est ok.
Le seul truc que j’ai trouvé en regardant les logs c’est ca :
2022-08-10 11:58:57,855 INFO: Sending packet
2022-08-10 11:58:57,871 WARNING: Cannot find data description for shortcut CHANNEL
Mais il suffit que je redémarre le service et tout roule à nouveau, des idées?