Hello
Doucement mais surement , je commence à migré de jeedom à HA
Mais j’ai des modules Enocean pour mes radiateurs ( fil pilotes )
Pour être précis sur les modèle que j’ai
Nodon Enocean
Mais d’après ce que je pu comprendre il ne sont pas compatible HA.
Vous me confirmez que je l’ao dans l’os !!
Merci
Je ne sais pas te dire.
Au pire du pire, tu peux faire comme moi et passer par un autre logiciel pour domotiser ton device (fhem) et passer par mqtt pour repasser par HA.
Mais si tu utilises fhem bon courage!
Hello
Merci @Christianb233
c’est si galere avec fhem ?
Le souci que j’ai avec MQTT, et que j’ai deja j’ai un broker MQTT zigbee que j’ai pu lier…
le second en Zwave mais que je n’arrive pas a joindre car je me sert déja de MQTT pour mon zigbee
Pour FHEM, c’est le logiciel le moins ergonomique que j’ai jamais vu. Facile à installer; documentation fournie et forum actif, mais ça reste compliqué à appréhender.
J’ai dû réinstaller 2 ou 3 fois le serveur fhem donc je connais maintenant un peu mieux mes propres manips et pourrai t’aider si besoin. Comme j’étais motivé et convaincu que je pourrai domotiser mes volets par ce moyen, j’ai mis l’énergie, poser les questions, ça a pris du temps (je qualifierais mon niveau domo d’intermédiaire).
Pour info, j’ai installé FHEM sur le même pi que HA donc pas de HA Os pour moi
Pour MQTT je suis surpris car j’ai aujourd’hui des flux différents (dont fhem) venant transiter par Mosquitto sans souci.
Hello,
Il s’agit de mon premier post sur le forum …
J’avais le même soucis que vous et effectivement l’intégration HA EnOcean n’est vraiment pas top et ne supporte pas nos modules (j’ai des modules Avidsen).
Pour résoudre le problème, je suis passé par enocean-mqtt, un module python qui permet de gérer le protocole EnOcean via MQTT. Il se base sur la librarie Python EnOcean pour traiter le protocole EnOcean.
Ce qui est top, c’est que cette association gère automatiquement le teach-in et y a pas mal d’EEP supportés.
De plus, on peut en rajouter assez facilement si celui qu’on veut n’est pas encore pris en compte.
C’est ce que j’ai fait pour nos modules D2-01-0C qui n’était pas supporté initialement.
Pour ma part, j’utilise une RPi avec ubuntu server et j’ai créé un service Linux qui lance le module python en tâche de fond à chaque démarrage. Il y a un fichier de configuration à remplir pour indiquer les modules EnOcean à gérer et c’est tout.
Une fois tout ça en place, plus qu’à démarrer le teach-in sur le module et hop, les messages MQTT arrivent dans HA et on peut piloter les radiateurs en envoyant des messages MQTT.
Je pourrai donner plus d’info si vous êtes intéressé par cette solution.
perso j’ai laissé jeedom géré le EnOcean… et je communique jeedom <> HA via MQTT. une plaie le EnOcean sur HA.
heureusement que j’utilise des VM et donc j’ai pas de soucis à avoir les 2 en même temps
Effectivement c’est le même principe, sauf que là c’est lite, ça évite d’avoir HA + un autre serveur à côté.
Hello
Désolé de pas avoir répondu plus tôt, mais je suis de retour …
@mak-dev
J’ai essayé ta solution y’a quelque temps sauf que l’installe plante , mais je réessayerais par la suite .
Bonjour,
Je débute avec Home assistant, et j’essaie d’y ajouter mes devices Enocean. J’ai réussi à intégrer les interrupteurs (F6-02-02) en mettant une entrée dans mon configuration.yaml.
binary_sensor:
- platform: enocean
id: [0x00,0x00,0x00,0xDD]
J’aimerais maintenant ajouter également mes lumières et volets roulants. En faisant quelques recherches, il me semble que j’ai les modules suivants : UBIDCL06100-QM, (EEP D2-01-12) pour les lumières et UBID1511B (EEP D2-05-00) pour mes volets roulants.
Je n’ai aucune idée de comment les intégrer dans HA.
J’ai essayé d’ajouter une entrée du même genre que les interrupteurs, mais avec ‹ light › et ‹ cover › à la place de ‹ binary_sensor › dans mon fichier de configuration, mais cela ne fonctionne pas. Avec ‹ light ›, ça me crée bien une entité, mais elle ne controle rien du tout, et avec cover, j’ai une erreur de configuration (cover does not exist).
A la lecture de votre post, je suis allée voir la page de enocean-mqtt. Malheureusement, je ne sais pas du tout par où commencer (à part installer la lib…), ni comment intégrer ça dans home assistant… Pourriez-vous donner un petit exemple type sur la façon d’ajouter un nouveau device (light et cover) grâce à cette librairie ?
Merci d’avance !
Bonjour,
Désolé je n’ai vu votre message que maintenant.
J’ai vu qu’entre temps vous aviez trouvé un autre moyen pour régler votre soucis mais je réponds toutefois à votre question.
Je précise que cette solution est actuellement assez technique et très proche du protocole EnOcean.
Il faut jongler avec les docs EEP de chaque module à gérer que vous trouverez sur le site de l’alliance EnOcean Enocean EEP Viewer.
Je songe à en faire une intégration HA pour cacher tout ce côté qui peut être complexe à première vue mais je n’en ai pas encore eu le temps.
J’ai essayé de schématiser un peu toute la chaîne et ça donne ça
EnOcean-MQTT va permettre de gérer tout le protocole EnOcean via la clé USB300 et la librairie Python EnOcean.
La librairie Python EnOcean s’appuie sur un fichier EEP.xml qui contient la définition des EEP EnOcean supportés. Il faudra rajouter le votre ici s’il n’est pas encore supporté (simple à faire et je pourrais vous le fournir).
EnOcean-MQTT quant à lui, a besoin d’un fichier de configuration dans lequel on indique entre autres le préfixe MQTT pour les topics MQTT ainsi que les périphériques EnOcean à gérer.
Par exemple, pour rajouter un module fil pilote nommé radiator, on indiquera
mqtt_prefix = enocean/
[radiator]
address = 0xDEADBEEF
rorg = 0xD2 # VLD
func = 0x01
type = 0x0C
log_learn = 1
command = CMD
L’adresse correspond à l’adresse de votre module EnOcean, rorg-func-type quant à eux parlent d’eux-mêmes (pour vous 0xD2 0x01 et 0x12). log_learn = 1 si vous voulez un log de vos messages EnOcean (edit: c’est plutôt si vous voulez remonter par MQTT les messages EnOcean lors des appairages), sinon 0. Et je passe sous silence la ligne command = CMD mais vous en aurez besoin pour vos modules D2-01-12.
Les messages MQTT seront alors envoyés et reçus depuis des topics du style <mqtt_prefix>/<module_name>/xx soit dans notre exemple enocean/radiator/xx
Une fois ce bout de texte dans le fichier de configuration et votre profil EEP supporté dans EEP.xml, EnOcean-MQTT pourra prendre en charge votre module.
Comme indiqué dans un autre post, le teach-in est parfaitement géré ce qui est assez pratique. Il suffit de mettre le module en mode teach-in et il sera reconnu et appairé.
Par la suite, tous les messages EnOcean seront transmis par MQTT et il vous faudra donc un broker MQTT au niveau de HA. Pour ma part j’ai installé l’intégration Mosquitto.
Chaque champ d’un message EnOcean corresponds à un topic MQTT du module.
Par exemple, en vous référant au document EEP D2-01-12, vous pouvez voir que la commande 0x1 permet d’allumer ou éteindre les canaux de votre module. Pour se faire, il faut:
CMD = 0x1
DV = 0x0
IO = 0x0 (pour le canal 0) - 0x1 (pour le canal 1) - 0x1E (pour tous les canaux)
OV = 0x0 (pour éteindre) - 0x64 (pour allumer)
Il faudra donc envoyer un message MQTT avec les paramètres de ces champs correctement positionnés suivant l’action que vous souhaitez réaliser.
Pour se faire, j’ai choisi de mon côté d’utiliser des scripts HA pour réaliser ces commandes « bas niveau ».
Par exemple:
d20112_set_output:
sequence:
- service: mqtt-publish
data:
topic: <mqtt_prefix>/<module_name>/req/CMD
payload: '1'
- service: mqtt-publish
data:
topic: <mqtt_prefix>/<module_name>/req/DV
payload: '0'
- service: mqtt-publish
data:
topic: <mqtt_prefix>/<module_name>/req/IO
payload: '0'
- service: mqtt-publish
data:
topic: <mqtt_prefix>/<module_name>/req/OV
payload: '0'
- service: mqtt-publish
data:
topic: <mqtt_prefix>/<module_name>/req/send
payload: 'clear'
qui permettra ici, vous l’aurez compris j’espère, d’éteindre le canal 0.
Pour généraliser, on peut imaginer un script plus générique qui prend en paramètres le nom du module à piloter (module), le canal (channel) ainsi que l’état à attribuer (state):
d20112_set_output:
sequence:
- service: mqtt-publish
data:
topic: <mqtt_prefix>/{{ module }}/req/CMD
payload: '1'
- service: mqtt-publish
data:
topic: <mqtt_prefix>/{{ module }}/req/DV
payload: '0'
- service: mqtt-publish
data:
topic: <mqtt_prefix>/{{ module }}/req/IO
payload: "{{ channel }}"
- service: mqtt-publish
data:
topic: <mqtt_prefix>/{{ module }}/req/OV
payload: "{{ state }}"
- service: mqtt-publish
data:
topic: <mqtt_prefix>/{{ module }}/req/send
payload: 'clear'
On pourra par la suite, imaginer un script de plus haut niveau qui permet de basculer la sortie d’un canal:
d20112_toggle:
sequence:
- service: script.d20112_set_output
data:
module: "{{ module }}"
channel: "{{ channel }}"
state: >
{% if is_state(entity, "on") %}
0
{% else %}
100
{% endif %}
Comment tout ça se présente maintenant au niveau interface utilisateur ? On peut imaginer un bouton qui permet de faire on/off sur un module:
type: button
tap_action:
action: call-service
service: script.d20112_toggle
service_data:
module: <module_name>
channel: <le_canal_à_piloter>
entity: <le_nom_de_votre_entity_pour_votre_module>
Avec <module_name> qui correspond au nom que vous avez indiqué dans la configuration enoceanmqtt.
Le champ entity permet enfin d’aborder le dernier maillon de la chaine, la représentation du module dans HA.
Ici, le module pourra être un binary_sensor MQTT qu’on définira dans configuration.yaml:
binary_sensor:
- platform: mqtt
name: <le_nom_de_votre_entity_pour_votre_module>
unique_id: <choisissez_un_id_unique>
state_topic: "<mqtt_prefix>/<module_name>/OV"
payload_on: "100"
payload_off: "0"
Ce bout de code indique qu’on crée un capteur à état binaire (on/off), dont l’état est récupéré en traquant le topic MQTT <mqtt_prefix>/<module_name>/OV, qui contiendra la valeur du champ OV du EEP EnOcean D2-01-12. Le capteur sera indiqué ON quand OV vaudra 100 et OFF quand OV vaudra 0.
Voilà en substance comment faire. Un peu technique c’est vrai. J’espère avoir le temps de simplifier tout ça via une intégration plus simple dans HA.
J’utilise celà depuis un moment et j’ai pu contrôler assez simplement tous les divers modules EnOcean que j’ai (fil pilote, interrupteur, capteur d’ouverture, smart plug, etc.).
C’est la voie que j’entends suivre en tout cas concernant le protocole EnOcean, car je maitrise tout ce qui se passe de bout en bout et j’ai l’impression que l’intégration HA officielle ne bougera pas de si tôt (j’espère me tromper).
Super merci !
Je débute tout juste. Il y a 2 semaines, les mots/concepts enocean/mqtt/EEP etc m’étaient totalement inconnus, donc ça fait beaucoup de choses d’un coup : Je vais donc regarder cela de + près, mais il est probable que je vous demande des infos complémentaires 
En tous cas, ça a l’air d’être + « générique » que l’intégration actuelle (et comme vous, j’ai l’impression qu’elle n’évolue pas trop…). Du coup, si vous trouvez le temps d’en faire une nouvelle intégration via mqtt ça serait top 
!
J’ai déjà installé mosquitto (pour Zigbee2mqtt), donc je ne vais pas aller chercher + loin concernant l’intégration mqtt de HA 
Bon, en fait je bloque avant la partie HA…
J’ai d’abord installé la librairie python enocean. Après avoir changé le port qui est rentré en dur dans le code, j’ai pu lancer enocean_example.py. Là, il se lance, envoie le paquet d’exemple, puis plusieurs situations :
Serial port exception! (device disconnected or multiple access on port?)
TypeError lorsqu’il veut formater le message de log.J’ai donc tenté directement enoceanmqtt, pour voir si j’avais les mêmes problèmes. Dans le fichier de conf, en dehors de la config de mon serveur mqtt (host, login/pwd…) j’ai juste mis un interrupteur et un volet (EEP qui sont tous les 2 dans le EEP.xml de la librairie python).
Le packet de test envoyé est bien reçu (réponse reçue ok).
Ensuite, j’ai des logs avec les modules que j’ai ajoutés, ainsi que des logs avec « unknown sensor ». Il détecte donc bien le flux de messages qui circulent. Mais encore une fois, au bout de qq secondes, il tombe sur une erreur Serial port exception! (device disconnected or multiple access on port?) et le SerialCommutator est stoppé.
Ce n’est donc pas la peine que j’essaie de réceptionner/envoyer des messages depuis HA, si déjà ils ne sont pas reconnus avant…
J’ai essayé d’augmenter le time out, mais même problème (et pas de corrélation entre valeur de time out et temps avant que ça crash). J’imagine que l’erreur est donc plutôt du côté multiple access on port. J’ai désactivé l’intégration enocean de HA pour ne pas qu’elle interfère en faisait des requêtes en même temps, comme c’est la même clé. Mais ça n’a pas résolu le problème.
Un idée d’où ça pourrait venir ?
Merci pour votre aide !
Déjà bien que vous voyiez des choses intéressantes dans les logs. 
Je n’ai jamais eu cette erreur mais j’étais persuadé que ça devait venir de l’intégration HA EnOcean et enoceanmqtt qui devait tout 2 tenter d’accéder à la clé.
Quel matériel utilisez-vous ? Quel est votre setup ?
Comment lancez-vous enoceanmqtt ?
Pourriez-vous partager votre fichier de configuration enoceanmqtt en masquant tout ce qui pourrait être sensible ?
Pour repartir d’une base clean, pourriez-vous désactiver totalement l’intégration HA EnOcean, faire un petit reboot et relancer enoceanmqtt ?
J’ai répondu à votre message ici : https://forum.hacf.fr/t/enocean-via-enoceanmqtt/11766?u=asetgem
Ce n’est plus trop dans le topic « Enocean Fil Pilote compatible? » donc autant créer un nouveau sujet, ce sera plus facile pour les futurs utilisateurs de trouver les infos !
Hello, petite question, pour le bouton pour allumer la lumière, on moyen pour afficher l’état ? l’icone changeant suivant le status?
Je n’ai pas encore intégré mes lumières donc ce qui suit n’est pas testé mais vous pouvez je pense :
type: button
tap_action:
action: call-service
service: <votre_script>
service_data:
<vos_parametres_de_script>
entity: <votre_entité_pour_votre_binary_sensor_lumière>
show_state: true
Vous parlez de voir l’état de l’interrupteur (physique) qui permet d’allumer votre lumière (recevoir button-pressed ou autre), ou bien de mettre un bouton dans HA permettant d’allumer vos lumières ?
Dans le second cas → voir réponse de @mak-dev
Les deux, j’ai des boutons enocean trio2sys qui controle mes lumières, donc j’aimerais récupérer l’état des lumières, quelques soit la source de l’allumage.
J’arrive a avoir un bouton quasi fonctionnel, mais je galère avec les modules 2 canaux.
Hello, j’ai trouvé un peu de temps pour continuer mon installation, mais comment tu gères les modules 2 canaux ?
Par exemple j’ai un module qui gère les 2 zones de mon salon, si je suis ta doc, les 2 modules ont le même state topic, donc je peux pas les différenciers
binary_sensor:
- name: inter_salon
unique_id: 61401
state_topic: "enocean/salon/OV"
payload_on: "100"
payload_off: "0"
- name: inter_canap
unique_id: 61400
state_topic: "enocean/salon/OV"
payload_on: "100"
payload_off: "0"
Hello,
Oui effectivement, je vois le soucis.
En fait le canal est indiqué via un autre topic, qui serait chez vous enocean/salon/IO.
Si ce topic vaut 0 alors c’est le canal 0 qui remonte son info et quand il vaut 1, alors c’est le canal 1.
L’idéal serait que enoceanmqtt gère mieux ce genre de cas, par exemple enocean/salon/0/OV pour le canal 0 et enocean/salon/1/OV pour le canal 1. Je vais essayer de modifier le code python en ce sens et faire un pull request sur github.
En attendant, vous pourrez peut être contourner cette limitation en indiquant ce topic en availability dans votre binary_sensor et en renseignant payload_available et payload_not_available suivant le canal. Plus d’infos ici.
Je ne suis pas en mesure de tester cette solution là maintenant et je pense qu’elle ne sera pas parfaite mais vous aidera peut être à contourner temporairement cette limitation.
Indiquez-moi s’il vous plaît ce que ça donne si vous la tester.