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?
Hello,
Je n’ai pas tout compris. Un peu plus d’info ?
Concernant CHANNEL, de quel module s’agit-il ? S’il s’agit des VR, Il semblerait qu’il y ait une erreur dans le code que j’ai indiqué dans ma réponse 36 de ce fil.
Ce n’est pas CHANNEL mais plutôt CHN.
En gros tout fonctionne bien pendant 3j, et ensuite l’état des lumières reste sur « unknown » sur Home Assistant :
Ok c’est plus clair.
Il faudrait que je vois le code pour comprendre ce qui se passe.
Chez moi les lumières fonctionnent sans aucun soucis depuis plusieurs semaines maintenant.
J’ai le même problème ! Tout fonctionne correctement pendant un certain temps, puis les entités passent à « unknown ». Pour les lumières, le toggle ne fonctionne donc plus, puisqu’il se base sur l’état actuel pour passer à l’autre.
Pour les VR, les actions sont encore possibles, mais il n’y a en revanche pas de retour (la position du VR est aussi unknown).
Il y a peut être une exception qui est levée pendant l’exécution d’enoceanmqtt et qui empêche le bon fonctionnement par la suite.
Il y a eu des modifications depuis pour corriger quelques bugs.
Je vous invite donc tous les deux à récupérer le dernier commit ici ou ici.
J’aimerais bien voir vos bouts de codes aussi pour bien cerner le problème.
Par ailleurs, vous trouverez ici, la nouvelle version dont je vous avais parlé et pour laquelle j’aimerais que vous soyez bêta-testeurs. Elle permet de gérer tous vos devices EnOcean sans une ligne de script. Plus d’info ici.
Il y a déjà quelques devices supportés. Si vous avez des devices non supportés, n’hésitez pas à me demander.
Toujours disponible également si vous avez des questions 
Hello, je viens de passer le dernier commit, on verra si ca corrigera le soucis ou non.
Sinon rien de particulier dans la conf :
mqtt:
light:
- schema: template
name: "inter_salon"
unique_id: "61401"
state_topic: "enocean/salon/IO0/OV"
state_template: '{% if value == "0" %}off{% else %}on{% endif %}'
command_topic: "enocean/salon/req"
command_on_template: "{\"CMD\":\"1\",\"IO\":\"0\",\"OV\":\"100\",\"send\":\"clear\"}"
command_off_template: "{\"CMD\":\"1\",\"IO\":\"0\",\"OV\":\"0\",\"send\":\"clear\"}"
cover:
- name: "Volet Baie Vitrée"
command_topic: "enocean/volet_baievitre/req"
position_topic: "enocean/volet_baievitre/POS"
set_position_topic: "enocean/volet_baievitre/req/POS"
qos: 0
retain: true
payload_open: "{\"CMD\":\"1\",\"POS\":\"0\",\"REPO\":\"0\",\"LOCK\":\"0\",\"CHANNEL\":\"0\",\"ANG\":\"0\",\"send\":\"clear\"}"
payload_close: "{\"CMD\":\"1\",\"POS\":\"100\",\"REPO\":\"0\",\"LOCK\":\"0\",\"CHANNEL\":\"0\",\"ANG\":\"0\",\"send\":\"clear\"}"
payload_stop: "{\"CMD\":\"2\",\"CHN\":\"0\"}"
position_open: 0
position_closed: 100
Et si j’ai bien compris le overlay, ca nous affranchi de la conf dans le yaml et les entity seront directement créées sous HA?
Pour mqtt.cover il faut remplacer CHANNEL par CHN comme indiqué plus haut.
Concernant l’overlay, c’est exactement ça. Tout est géré automatiquement. Plus rien à faire.
@Judzk et @asetGem
Pour tester, je conseillerais de ne pas supprimer tout ce que vous avez fait jusqu’à présent. Le mieux serait de conserver les 2 pendant quelques temps histoire de se familiariser avec.
Les entitités et appareils créés automatiquement sont préfixés par e2m_.
Merci beaucoup pour ton retour et ces nouvelles fonctionalités 
!!
Alors j’ai aussi fait un pull du dernier comit et relancé, pareil que @Judzk on verra dans les prochains jours ce que ça donne.
Concernant le « code » moi non plus, rien de spécial. Avant j’avais des scripts, mais avec ton astuce pour directement mettre le payload dans la déclaration du sensor ils ne sont plus utilisés !
Pour les cover, j’ai la même chose que @Judzk sauf que j’ai bien CHN et non CHANNEL. Et j’ai quelques infos en + :
- platform: mqtt
name: "VR salon"
unique_id: "VR salon"
device_class: "shutter"
command_topic: "enocean/VR salon/req"
position_topic: "enocean/VR salon/POS"
set_position_topic: "enocean/VR salon/req"
payload_open: "{\"CMD\":\"1\",\"POS\":\"0\",\"ANG\":\"0\",\"REPO\":\"0\",\"LOCK\":\"0\",\"CHN\":\"0\",\"send\":\"clear\"}"
payload_close: "{\"CMD\":\"1\",\"POS\":\"100\",\"ANG\":\"0\",\"REPO\":\"0\",\"LOCK\":\"0\",\"CHN\":\"0\",\"send\":\"clear\"}"
payload_stop: "{\"CMD\":\"2\",\"CHN\":\"0\",\"send\":\"clear\"}"
set_position_template: "{\"CMD\":\"1\",\"POS\":\"{{ int(0.007*position*position + 0.3* position) }}\",\"ANG\":\"0\",\"REPO\":\"0\",\"LOCK\":\"0\",\"CHN\":\"0\",\"send\":\"clear\"}"
#set_position_template: "{\"CMD\":\"1\",\"POS\":\"{{ 100 - position }}\",\"ANG\":\"0\",\"REPO\":\"0\",\"LOCK\":\"0\",\"CHN\":\"0\",\"send\":\"clear\"}"
position_open: 0
position_closed: 100
qos: 0
retain: false
@Judzk , tu n’as pas de soucis avec ton retain: true ? Pour ma part, si jamais je modifiais la position des volets manuellement, lorsque le serveur rebootait, il me les remettait à la dernière position envoyée via mqtt (donc via HA)… ça donne des volets qui se mettent à bouger « tous seuls » ^^
Pour les lumières, c’est globalement la même chose.
Je regarde pour l’overlay quand j’ai un moment !
Non aucun soucis pour mes volets, quand tu dis manuellement tu as un interrupteur classique bronché sur les entrées du module? Chez moi j’ai des interrupteur enocean trio2sys, du coup il reçoit l’info via le protocole enocean, ca explique peut être la différence de comportement
pareil, interrupteurs enocean (F6-02-02).
Donc effectivement ça reçoit bien un signal enocean, mais par contre ce message n’est pas envoyé via mqtt, c’est du enocean « direct ».
Donc le dernier message qui est « retained » dans enoceanmqtt est celui que j’ai envoyé lorsque j’ai modifié la position des volets via HA.
Ouais pareil ici c’est envoyé en direct au module sans passer par MQTT
Hello !
Je viens de jeter un coup d’oeil aux overlays. Je ne suis pas sure de comprendre ce qu’il faut mettre dans mqtt_discovery_topic. J’ai mis enocean, puisque c’est le topic sur lequel j’envoie les devices, mais ça n’a pas l’air d’être ça.
Dans le enoceanmqtt.log, j’ai l’erreur suivante :
File "/home/ha-route-pi/softwares/enocean-mqtt/enoceanmqtt/overlays/homeassistant/ha_communicator.py", line 169, in _publish_mqtt
self._mqtt_discovery(sensor)
File "/home/ha-route-pi/softwares/enocean-mqtt/enoceanmqtt/overlays/homeassistant/ha_communicator.py", line 112, in _mqtt_discovery
_device = "e2m_"+sensor['name'].replace(self.conf['mqtt_prefix'], "").replace("/", "_")
KeyError: 'mqtt_prefix'
Sinon, c’est un détail, mais dans la procédure d’installation, il me manquait aussi pyyaml.
En tous cas merci pour tout ce travail !
J’ai changé le code pour éviter l’exception. Le nom du device est e2m.<name> (name contenant le prefix donc).
J’ai bien des devices ajoutés :
2022-08-14 23:59:45,827 INFO: Device enocean/lumiere ch2 (@: 057BABEE / EEP: D2-01-12) added to device database
Par contre, ils n’apparaissent pas dans HA 
Hello,
Effectivement il faut aussi pyyaml. Je vais le rajouter. Merci.
Concernant mqtt.discovery, il faut choisir un topic (par exemple enocean/discovery et le rajouter à la fois dans la section [CONFIG] de enoceanmqtt.conf:
mqtt_discovery_prefix = enocean/discovery/
et dans la configuration YAML de mqtt dans HA:
mqtt:
broker: <broker>
username: <username>
password: <password>
discovery_prefix: enocean/discovery
C’est pour ça qu’ils n’apparaissent pas dans HA.
Plus d’info ici.
Je vais également le rajouter dans le README.
Pour l’exception, normalement le code est ok, pas besoin de le modifier.
L’exception indique que mqtt_prefix n’est pas défini dans enoceanmqtt.conf.
Dans enoceanmqtt.conf, il faut à la fois définir mqtt_prefix (utilisé pour la communication entre HA et les modules EnOcean) et mqtt_discovery_prefix (Utilisé pour la découverte automatique des modules EnOcean dans HA).
Puis-je avoir le contenu de la section [CONFIG] du fichier enoceanmqtt.conf ?
Vu que là tout ne c’est pas bien passé, il faudra par contre impérativement supprimer le fichier device_db.json qui a été créé dans le dossier overlays/homeassistant. En l’état, il contient des informations incorrectes.
Il sera recréé à la prochaine exécution de enoceanmqtt.
Voilà la partie config de mon enoceanmqtt.conf (sans les modifs que tu viens d’indiquer) :
[CONFIG]
enocean_port = /dev/enocean
overlay = HA
mqtt_discovery_topic = enocean
mqtt_prefix = enocean
log_packets = 1
mqtt_host = 192.x.x.x
mqtt_port = 1883
mqtt_user = user
mqtt_pwd = password
mqtt_client_id = enocean
mqtt_keepalive = 100
mqtt_debug = true
En fait, en regardant dans mqtt explorer, je vois que les devices créés sont déjà précédés de enocean/discovery, même si j’avais mis juste enocean dans le topic de discovery. Tu ajoutes peut-être automatiquement discovery ?
mqtt_discovery_topic = enocean/discovery dans la partie CONFIG du fichier de conf enoceanmqtt (au lieu de juste enocean)device_db.json
configuration.yaml:mqtt:
discovery_prefix: "enocean/discovery"
Cette fois-ci, les devices (lumières en l’occurrence) apparaissent bien dans HA
En regardant d’un peu plus près avec mqtt explorer, je vois que dans le device créé automatiquement, j’ai : {\"CMD\":\"1\",\"IO\":\"0\",\"OV\":\"0\",\"send\":\"clear\"}
alors que dans les devices light que j’avais créé manuellement, j’avais command_off_template: "{\"CMD\":\"1\",\"DV\":\"0\",\"IO\":\"0\",\"OV\":\"0\",\"send\":\"clear\"}" (DV en +).
Je suis allée modifier les lignes correspondantes dans overlays/homeassistant/mapping.yaml
→ c’est bon, je peux controler les lumières, et leur état se met bien à jour si je les controle via l’interrupteur physique.
Pour les VR, les commandes open/close étaient inversées. J’ai modifié également le mapping.yaml. Mais ça c’est peut-être spécifique à mes VR…
configuration.yaml ne controlent plus rien, et ne se mettent pas non plus à jour en cas de changement d’étatIl va donc falloir que j’investigue de ce côté là, mais côté overlay ça a l’air d’être ok pour ce qui est des VR et light 
(je n’ai pas encore testé le reste).
J’ai enlevé le discovery_topic. C’est bien ça qui bloquait tous les autres devices (zigbee2mqtt etc), car du coup ils n’étaient plus reconnus. Par contre, les device enoceanmqtt faits à la main ne fonctionnent toujours pas.
Ayant enlevé le custom discovery_topic, j’ai mis mqtt_discovery_topic = homeassistant dans enoceanmqtt.conf (homeassistant étant le topic de discovery par défaut d’après la doc). Mais ça ne fonctionne pas non plus. Les devices créés sont à nouveau dans les topics enocean/discovery/light/enocean_<device-ID>
Dans ha_communicator.py, il y a cette ligne (ligne 40) : self._mqtt_discovery_prefix = config.get('mqtt_discovery_prefix', 'enocean/discovery/') qui semble « imposer » le topic des nouveaux devices à être enocean/discovery. J’ai fait un test en mettant homeassistant à la place, et le device est bien trouvé dans HA, et fonctionne. Pourtant c’est un get, pas un set, donc il n’est pas censé modifier le topic…
Ah en fait je viens de me rendre compte qu’il y a une grosse coquille dans le README. C’est mqtt_discovery_prefix et non mqtt_discovery_topic
Donc quand mqtt_discovery_prefix n’est pas trouvé comme c’est le cas là, on choisit par défaut enocean/discovery.
Encore désolé , je vais mettre à jour le README avec toutes tes remarques. Merci.
Et je viens de me rendre compte que c’est normal que les entités à la main ne fonctionnent plus
Je force l’utilisation du format JSON pour les messages EnOcean vers MQTT car ça permet de faire plus de chose sympa au niveau de HA.
Deux solutions:
enoceanmqtt.conf pour revenir au fonctionnement normal de enoceanmqttIl vaut peut être mieux partir sur la solution 2 le temps que je comprenne pourquoi tes autres devices MQTT (zigbee2mqtt, etc.) ne fonctionnent plus lorsque tu définis discovery_prefix dans la configuration YAML de MQTT.
Encore désolé pour ces petites galères de bêta-testeur 
Deux solutions:
- Modifier les entités manuelles pour utiliser le format JSON. Il y a plein d’exemple dans mapping.yaml et je peux aider si besoin.
- Mettre overlay = none dans enoceanmqtt.conf pour revenir au fonctionnement normal de enoceanmqtt
En mettant mqtt_discovery_prefix = homeassistant/ et mqtt_prefix = homeassistant/ c’est bon, tout fonctionne ça fonctionne si on ne change pas le topic de discovery en fait.
Comme ça, j’ai les avantages de l’overlay, mais quand même les autres devices qui fonctionnent.
Par contre, les topics sont moins bien « classés » c’est sur.
Ah ok. Parfait !
Donc si j’ai bien compris, ça sous-entend que zigbee2mqtt utilise homeassistant/ comme prefix de discovery.
Je vais donc utiliser homeassistant/ comme préfixe par défaut pour `mqtt_discovery_prefix.
Pour les lumières c’est bizarre qu’il t’ait fallu rajouter DV parce que par défaut ça vaut 0 et donc pas besoin de le spécifier. Je vais quand même mettre à jour mapping.yaml avec tes trouvailles.
Pour les VR, si je comprends bien, 0 = open et 100 = closed avec nos modules D2-05-00 ? (→ edit:confirmer dans la doc EEP).
Je suis un peu perdu par rapport à la manière dont HA interprète le code vu que mqtt.cover utilise comme valeur par défaut 0 = closed et 100 = open.
il faut peut être également rajouter dans mapping.yaml:
position_open: "0"
position_closed: "100"
Je suis pas chez moi donc je peux pas tester mais oui par défaut zigbee2mqtt utilise homeassistant par défaut et classe dedans les sensor etc…
Par contre le
position_open: "0"
position_closed: "100"
N’est pas propre au module, mais au volet en lui même. C’est dépend du sens du moteur qui lui ai dépend de l’arrivée électrique souvent. Au pire faut changer le cablage du module pour tout uniformiser