Enocean Fil Pilote compatible?

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 »