Intégration Enocean dans Home Assistant

Top d’avoir créé un add-on ! Je teste ça dès que j’ai un peu de temps !

@edoss concernant le switch de la carte SD au SSD, il y a 2 étapes principales :

Un conseil : fais un backup complet de ton instance HA (dans Paramètres/Systeme/Sauvegardes), on ne sait jamais !

Qu’appelles-tu les « soft remote » ?

Merci, je regarderait ça à l’occasion =)

C’est la que intervien (selon moi) le réel intêret du système enocean.
Ce sont des télécommandes qui n’ont pas besoin de pile. Elle récupère l’énergie quand tu appuie sur un bouton pour transmettre la trame.

Voila quelques liens pour te faire une idée =)
(comme d’hab, je ne suis pas affilié à ces liens)

https://www.leroymerlin.fr/produits/electricite-domotique/domotique-et-objets-connectes/domotique/solutions-de-commande/interrupteur-connecte-blanc-2-boutons-sans-pile-sans-fil-enocean-avidsen-74771774.html

J’avais réussi à les intégrer, mais pour faire fonctionner les stores, j’ai remplacé un fichier, faut que je me souvienne duquel :sweat_smile:

Ah ok, je ne connaissais pas le nom. J’ai mes interrupteurs qui sont sur le même principe, juste pas le même design. Ils sont directement intégrés avec l’add-on de @mak-dev. Il suffit de mettre ces infos dans le enoceanmqtt.conf:

[inter-sup-salon]
address         = 0xXXXXXXX # (l'ID de l'interrupteur)
rorg            = 0xF6   
func            = 0x02
type            = 0x01 # (ou 0x02 selon celui que tu as)
log_learn       = 1
publish_rssi    = 0

Tu auras alors un appareil avec les entités pour récupérer les infos de chaque bouton (=4 sur ton exemple), avec pour chacun l’info de quand il est appuyé et quand il est relâché. Pratique pour certaines automations !
Pas besoin d’appairage pour ces interrupteurs.

Chez moi, ce sont eux qui contrôlent tous les stores et lumières. Et en parallèle, je peux aussi contrôler ces devices (et récupérer l’info des inter) via HA.

@mak-dev, je viens d’installer l’Add-on à la place de mon clone git + enoceanmqtt en arrière plan. J’ai bien récupéré toutes les entités, mais par contre, ce qui est étrange, c’est que je n’ai pas de retour sur les VR. Je peux les contrôler (ouvrir/fermer/mettre à x%), mais je n’ai pas leur position actuelle dans HA (même lorsque je contrôle via HA, la position ne se met pas à jour).
Pour les lumières, aucun soucis. Je peux les contrôler via HA ou via mes interrupteurs ‹ physiques ›, et leur statut se met bien à jour dans HA.
J’ai gardé le même fichier de conf (en enlevant la section config bien sûr).
Une idée d’où ça pourrait venir ?

Le problème est résolu.

1 « J'aime »

J’ai 2 groupes de cover, 4 et 6 volets
Quand je les sollicite, il y a un ou plusieurs volets qui ne réagissent pas, ce ne sont pas toujours les mêmes, juste après si je clique sur un volet seul en dehors d’un groupe qui n’avait pas bougé, alors ça fonctionne

Est-ce la clé usb à qui HA demande d’envoyer « tout d’un coup » et ça fait foirer certaines trame ?
Si c’est le cas, j’imagine que ce serait solutionable en créant une « automation » à la main qui appellerait les 4 ou 6 volets les un après les autres avec une micro tempo

Auriez vous des conseils avant que je me lance dans un probable galère?
Merci

Bonjour,
Qu’appelles-tu groupe de cover ? Ce sont des groupes créés dans HA ou indépendamment ?

C’est intégré dans HA, ça marche pour cover et plein d’autres items

cover:
  - platform: group
    name: volets_rdc
    entities:
      - cover.volet_bureau
      - cover.volet_salon
      - cover.volet_chambre
      - cover.volet_sdb

Merci @mak-dev pour cet addon qui me parait puissant et en mesure de remplacer ma laborieuse intégration via FHEM (puis comme toi le protocole MQTT).
Je cherchais en effet une alternative pour contrôler mes commutateurs de volets roulants Eltako FSB61NP.
Sous HA supervised, j’ai donc installé et configuré GitHub - mak-gitdev/HA_enoceanmqtt-addon: Home Assistant addon for HA_enoceanmqtt (https://github.com/mak-gitdev/HA_enoceanmqtt) , mais comme sous FHEM l’EEP défini est A5-3F-7F, logiquement mon config_file débouche en
2023-01-11 23:21:45,325 INFO: Waiting for device base ID

[shutter/EnO_switch7_FSB61]
address         = 0x05158030
rorg            = 0xA5
func            = 0x3F
type            = 0x7F

Il me semble avoir lu que A5-3F-7F est trop générique, mais du coup je n’arrive pas à trouver le bon EEP à déclarer pour mon FSB61NP :frowning: = saurais-tu me venir en aide ? :pray: l’idée étant bien-sûr d’obtenir l’entité cover.e2m…

Je vois dans certaines pages web que FSB61NP « répond au profil EEP F6-02-01 défini par l’Alliance EnOcean » mais si je mets F6-02-01 en config_file, il me génère les entités ci-dessous plutôt assimilable à mes Nodon remote 4 boutons qu’à un cover :frowning:

Bonsoir,

As-tu déclaré l’EEP A5-3F-7F dans le mapping.yaml ?

Si ça ne marche pas malgré ça, essaye peut-être avec D2-05-00 ?

Edit : je suis allée voir l’EEP A53F7F, mais effectivement il a l’air de ne plus être utilisé en fait.

Merci @asetGem pour ton retour, du coup j’ai tenté avec D2-05-00 mais il me dit aussi qu’il est en Waiting for device base ID.
Pour le mapping.yaml (que je n’arrive pas à trouver dans mon /config), je ne sais pas comment le configurer mais tu sembles dire que c’est peine perdue car plus utilisé ?
Je serais donc dans une impasse ?

Salut,

La solution a été initialement pensée pour ne fonctionner qu’avec les EEP standards.

Comment ça marche en détails

Typiquement, quand un télégramme EnOcean est reçu, il est décodé par enoceanmqtt grâce à la librairie Python EnOcean qui se base sur un fichier EEP.xml et l’EEP renseigné lors de la définition du device pour connaitre la définition de ce télégramme.
Ensuite ha_enoceanmqtt vient associer des entités HA (binary sensor, sensor, cover, etc.) suivant l’EEP du device à l’aide du fichier mapping.yaml.

L’EEP A5-3F-7F est un cas particulier. La définition peut varier d’un constructeur à un autre.

De façon plus générale, les devices Eltako utilisent des EEPs quelques fois non standards. Ils ont pris des EEPs standards et ont fait des exceptions, typiquement des champs inutilisés ou pire qui n’ont pas la même signification que l’EEP standard équivalent.
Il y a même des fois des devices qui, pour une même adresse, génèrent plusieurs EEPs.
Ça doit être le cas de ton cover Eltako. Il est piloté par un EEP A5-3F-7F et il doit certainement renvoyer son statut par un F6-02-01 :confused:. (EDIT: Quand le volet va au bout de sa course, il génère un message de statut avec RORG = 0xF6. Par contre lorsque le volet est stoppé avant la fin de sa course, il génère un message de statut avec RORG = 0xA5 tout en utilisant la même adresse !).
Certainement que ces devices sont sortis avant l’arrivée des EEP VLD (0xD2) et MSC (0xD1) qui simplifient grandement tout ça.

De ce fait, pour supporter les devices Eltako, il va falloir que je développe un support particulier dans le soft, qui n’utilisera pas le même chemin de traitement que les EEPs standards.

Typiquement ce que j’ai en tête pour l’instant, c’est qu’il faudra par exemple définir un device de la sorte quand il sera non standard:

[myFSB61NP]
address = 0x01234567
model = eltako-FSB61NP

Ainsi, dans le soft, quand on détectera un device comme ça, il ne va pas suivre la même chaine de traitement que les devices avec EEP standard.

Il va falloir un peu de patience avant que ce ne soit disponible :slight_smile:

Donc pour l’instant, je ne peux que te conseiller de garder encore un peu ton FHEM :sweat:

Concernant le message Waiting for base ID, il défile en boucle ou pas dans le log ?

Hello @mak-dev merci pour ton retour.

Oui le message Waiting for base ID défile en boucle.

Peut-être en lien avec ton analyse du FSB61NP, j’ai vu dans les recherches web, une rubrique « contenu des télégrammes radio » :
image

Pas de souci pour patienter, j’attendais une implémentation aussi bien structurée depuis 2 ans :wink:

Hello @Christianb233,

C’est exactement à cet encadré que je faisais référence dans l’EDIT de mon message précédent.
RORG = 0x05 et 0x07 c’était dans la version 2 du protocole radio EnOcean. On est maintenant à la version 3 et ça correspond maintenant à respectivement 0xF6 et 0xA5.

Le contenu des trames radio est disponible. Il faut juste intégrer ça proprement :slight_smile:.

Pour le message Waiting for base ID, il semblerait que ça apparaisse quand il y a plusieurs instances lancées en même temps.
Je n’en ai pas encore la certitude mais ça semble arriver quand on redémarre l’addon plutôt que arrêt+démarrage.
C’est une erreur à mon niveau ou au niveau du superviseur HA.
Il faut stopper l’addon, ensuite vu que tu es en supervised, dans un terminal, tape ps aux | grep enoceanmqtt pour avoir le process id de l’instance en trop et ensuite kill -TERM <pid> pour l’arrêter. Plus qu’à redémarrer l’addon ensuite.

1 « J'aime »

Hello @mak-dev
Je ne pense pas du tout que ce soit lié mais en arrêtant du coup le module, HA n’a pas voulu redémarrer, perte d’addons comme terminal… :sweat_smile: Bref réinstallation de HA, puis en recheckant, le waiting for device base Id demeure en boucle toutes les secondes :grin:. Je le redémarrerai quand tu auras eu le temps d’intégrer le FSB61NP :wink:

Haha :sweat_smile: ! Je ne pense pas aussi. Mais bizarre quand même.

Concernant le message Waiting for base id, ça aurait dû être réglé avec la dernière version dev (0.1.23).
Si c’est celle là que tu avais installée, il faudrait que j’investigue encore donc.

Et je te tiendrai informé lorsque ça sera prêt pour ton FSB61NP. J’aurais peut être besoin de ton aide pour faire des tests si tu veux bien :sweat_smile:

Hello, bah je suis en version 0.1.21 (installé il y a quelques jours (4-5) depuis le début de nos échanges) et suis en mise à jour automatique et je ne trouve pas de version ultérieure à charger.
Par contre je n’ai pas installé la version dev, c’est peut-être pour ça.


PS pas de souci pour tester tes codes

Salut
j’aurai besoin d’un éclaircissement svp

J’ai installé l’addon enoceanmqtt de @mak-dev
image

ma configuration :

device_file: /config/enoceanmqtt.devices.sample
mapping_file: ""
log_file: /config/enoceanmqtt.log
enocean_port: /dev/serial/by-id/usb-EnOcean_GmbH_EnOcean_USB_300_DC_FT5NSA7J-if00-port0
debug: false
log_packets: false
mqtt_broker: {}
mqtt_discovery_prefix: homeassistant/
mqtt_prefix: enoceanmqtt/
mqtt_client_id: enocean_gateway
mqtt_keepalive: 60

Log :

Dans mes appareils j’ai bien le MQTT ENOCEAN que je peux activer « LEARN »
image

j’appuie sur l’un des boutons de ma télecommande F6-02-02
mais il se passe rien

Je dois louper une étape, auriez vous une idée ?
F6-02-02 est intégré par défaut dans l’intégration si je dit pas de bétise, mais j’ai pas la subtilité si il faut modifier le enoceanmqtt.devices.sample

merci