Bonjour,
C’est effectivement ce à quoi je pensais.
Vous n’en aurez peut être pas besoin. J’ai eu un peu de temps aujourd’hui pour modifier le code de enoceanmqtt pour rajouter la feature évoquée plus haut. J’aimerais que vous soyez beta testeur là dessus
Vous pourrez trouver les modifs ici (récupérer les modifs du dernier commit).
J’ai testé cela rapidement sur un module sans lumière cablée dessus et ça a l’air de fonctionner.
Il vous faudra rajouter dans votre configuration de vos lumières la ligne channel = IO.
On indique ainsi qu’on souhaite que tous les messages EnOcean reçus qui concernent le module et qui contiennent le champ IO soient groupés sous <sensor_name>/IOx/ avec x qui indique le canal.
Dans votre cas, donc plus besoin de passer par availability, ce serait:
## ma déclaration de module sous enoceanmqtt.conf
[salon]
address = 0xFFFFFFF
rorg = 0xD2 # BS1
func = 0x01
type = 0x12
log_learn = 1
publish_rssi = 0
command = CMD
channel = IO
# ma déclaration de binary sous HS :
binary_sensor:
- name: inter_salon
unique_id: 61401
state_topic: "enocean/salon/IO0/OV"
payload_on: "100"
payload_off: "0"
- name: inter_canap
unique_id: 61400
state_topic: "enocean/salon/IO1/OV"
payload_on: "100"
payload_off: "0"
Maintenant j’ai plus qu’a faire mon bouton qui récup l’état sous le dashboard HA, pour l’instant j’ai ca pour récup l’état et qui est fonctionnel, mais j’ai une erreur quand je clique dessus : Echec d’appel du service « script/1655230838787 ». Error rendering data template: UndefinedError: ‹ entity › is undefined
Effectivement ça marche nickel, je pensais l’avoir récup sur ton tuto, mais non j’ai du merder à un moment donné.
Bon j’ai plus qu’à faire tout mes modules, merci beaucoup
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 :
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 ?
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
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:
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
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é ?
