Enocean Fil Pilote compatible?

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).

EDIT: Un addon ainsi qu’une image docker sont maintenant disponibles. Tout a été simplifié au maximum. Plus d’infos ici

1 « J'aime »

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 :pensive:
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 :slight_smile: !
J’ai déjà installé mosquitto (pour Zigbee2mqtt), donc je ne vais pas aller chercher + loin concernant l’intégration mqtt de HA :wink:

1 « J'aime »

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 :

  • erreur Serial port exception! (device disconnected or multiple access on port?)
  • erreur du fait qu’il détecte un signal inconnu, ce qui déclenche une TypeError lorsqu’il veut formater le message de log.
  • plus rien ne se passe, que j’actionne ou non des modules

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. :+1:

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 :

  • Ajouter un bouton dans lovelace avec le code suivant (à modifier selon votre configuration)
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.

Hello, merci de ta réponse, donc si je comprend bien le code :

binary_sensor:
    - name: inter_salon
      unique_id: 61401
      state_topic: "enocean/salon/OV"
      payload_on: "100"
      payload_off: "0"
      availability:
        - topic: "enocean/salon/IO"
          payload_available: "1"
          payload_not_available: "0"
    - name: inter_canap
      unique_id: 61400
      state_topic: "enocean/salon/OV"
      payload_on: "100"
      payload_off: "0"
      availability:
        - topic: "enocean/salon/IO"
          payload_available: "0"
          payload_not_available: "1"

Je suis pas dispo cet aprem, mais si ca te semble bon j’essaye de mettre rapidement ca en place

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 :sweat_smile:
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:

binary_sensor:
    - name: inter_salon
      unique_id: 61401
      state_topic: "enocean/salon/IO1/OV"
      payload_on: "100"
      payload_off: "0"
    - name: inter_canap
      unique_id: 61400
      state_topic: "enocean/salon/IO0/OV"
      payload_on: "100"
      payload_off: "0"

Je ferai un pull request sur github en fonction de votre retour.

Hello désolé de retard de réponse, j’essaie de rester ça d’ici mardi, période super chargée
Merci encore pour la modif en tout cas

Ok je valide tes modifs :

## 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

type: custom:button-card
show_entity_picture: true
state:
  - value: 'off'
    icon: mdi:ceiling-light
  - value: 'on'
    icon: mdi:ceiling-light
    color: yellow
tap_action:
  action: call-service
  service: script.1655230838787
  data:
    module: salon
    channel: 1
    entity: binary_sensor.inter_canap
  target: {}
entity: binary_sensor.inter_canap
name: Canapé
show_state: false
show_label: true
size: 20%
label: |
  [[[
    if (states['binary_sensor.inter_canap'].state === "on")
      return "Allumé";
    else if (states['binary_sensor.inter_canap'].state === "off")
      return "Eteint";
  ]]]