Enocean via enoceanmqtt

Mon problème

J’essaie d’intégrer mes modules EnOcean dans HA, via enoceanmqtt (basé sur la librairie python enocean). Ceci est la suite d’une discussion commencée ici : https://forum.hacf.fr/t/enocean-fil-pilote-compatible/9087
Déviant du sujet original, je crée un nouveau sujet.
J’ai suivi ce tuto : https://forum.hacf.fr/t/enocean-fil-pilote-compatible/9087/10?u=asetgem
mais enoceanmqtt n’arrive pas à tourner (voir https://forum.hacf.fr/t/enocean-fil-pilote-compatible/9087/12?u=asetgem).

Ma configuration

Concernant le matériel, j’ai installé HA sur un Raspberry pi 4 avec une carte SD (directement depuis le dépot raspberry Pi Imager). Il est connecté en ethernet.
Ensuite, j’ai une clé zigbee Sonoff (utilisée avec Zigbee2mqtt) et une clé Enocean USB300 DC.

J’ai pour l’instant installé enoceanmqtt via pypi, et je le lance directement depuis le terminal (via le script enoceanmqtt avec le fichier de conf qui va bien). J’ai laissé le fichier EEP.xml par défaut concernant la librairie python-enocean. A priori, le profil D2-01-12 n’y est pas, mais pour l’instant ce n’est pas trop grave, je teste sur les F6-02-02 et D2-05-00 qui, eux, y sont (si je ne me trompe pas).

J’avais aussi essayé de l’installer en mode developpement (cloné le repo, puis setup.py develop) au cas où ce soit un fix récent. Mais même comportement.

Voilà mon fichier de conf enoceanmqtt:

[CONFIG]
enocean_port    = /dev/ttyUSB0
log_packets     = 1
mqtt_host       = *****
mqtt_port       = 1883
mqtt_client_id  = enocean   
mqtt_keepalive  = 50
mqtt_prefix     = enocean/
mqtt_user       = ******
mqtt_pwd        = ******

[inter-sup-salon]
address         = 0xFFFFFFFF (l'ID de l'interrupteur)
rorg            = 0xF6   # BS1
func            = 0x02
type            = 0x02
log_learn       = 1
publish_rssi    = 1

[shutter]
address         = 0xFFFFFFFF (l'ID du module qui contrôle mon VR)
rorg            = 0xD2
func            = 0x05
type            = 0x00

J’avais déjà supprimé l’intégration enocean. J’ai également supprimé les devices que j’avais mis dans le fichier configuration.yaml. Normalement, HA ne communique plus via enocean.
Après un redémarrage complet (reboot du raspberry Pi également), j’ai encore le même problème :

2022-06-11 12:58:54,364 INFO: Logging to file: /usr/lib/python3.10/site-packages/enoceanmqtt.log         
2022-06-11 12:58:54,366 INFO: Loading config file enoceanmqtt.conf                                                      
2022-06-11 12:58:54,371 INFO: Authenticating: *****
2022-06-11 12:58:54,380 INFO: SerialCommunicator started                                                                
2022-06-11 12:58:54,381 WARNING: Replacing Packet.optional with default value.                                          2022-06-11 12:58:54,391 INFO: Succesfully connected to MQTT broker.                                                     2022-06-11 12:58:54,481 INFO: Sending packet  
2022-06-11 13:03:14,415 INFO: got response packet: OK                                                                            
2022-06-11 12:58:58,803 INFO: received: 05:98:3A:BD->FF:FF:FF:FF (-61 dBm): 0x01 ['0xa5', '0x0', '0xb', '0x1c', '0xa', '0x5', '0x98', '0x3a', '0xbd', '0x82'] ['0x0', '0xff', '0xff', '0xff', '0xff', '0x3d', '0x0'] OrderedDict()              
2022-06-11 12:58:58,805 INFO: unknown sensor: 05:98:3A:BD                                                               
2022-06-11 12:58:58,806 WARNING: Replacing Packet.optional with default value.                                          2022-06-11 12:58:58,904 INFO: Sending packet                                                                            
2022-06-11 12:58:58,910 ERROR: Serial port exception! (device disconnected or multiple access on port?)                 2022-06-11 12:58:58,911 INFO: SerialCommunicator stopped      

EDIT:

Je ne sais pas si ça peut aider, mais voici un autre test que j’ai fait :
Si je branche la clé sur mon ordi et que j’utilise DolphinView Advanced, aucun problème. Je vois bien plein de messages qui circulent (beaucoup trop pour les identifier d’ailleurs…). Lorsque j’actionne un module que je connais, je le vois bien sur DolphinView. Donc ma clé EnOcean semble fonctionner correctement, et répond bien même lorsqu’il y a plein de paquets en même temps.

Ok parfait, on continue ici donc.

Votre fichier de configuration me semble correct.
Si je comprends bien, les adresses de vos 2 modules ne sont pas 0xFFFFFFFF, mais bien 2 adresses distinctes que vous avez juste masquées. C’est bien ça ?

Par la suite, j’ai trouvé ce lien qui indique qu’on peut avoir cette erreur lorsqu’on utilise la clé USB300 avec une rallonge usb de plus de 2m.
Je ne sais pas si c’est votre cas.

oui c’est ça pour les adresses. J’ai par exemple 0x059F3C67 ou encore 0x003C3473. Chacune est bien unique (sauf si enocean fait du matériel avec des ID non uniques mais là ce ne serait plus le même problème ^^)

Aucune rallonge, la clé est branchée directement sur le port USB du raspberry Pi :frowning:

Ok côté matériel, pas de problème alors semble-t-il.

Je me demande s’il n’y a pas une blague avec vos 2 clés usb EnOcean et Zigbee.
Si vous avez la possibilité de déconnecter un court instant la clé Zigbee, ça permettrait de nous assurer que le problème persiste ou pas avec la seule USB300 branchée sur les ports USB du Pi4.

Je vous conseille aussi fortement de suivre le point Define persistant device name for EnOcean interface indiqué sur la page github de enoceanmqtt.
ça permet d’attribuer un nom permanent à votre clé USB300.
Utilisez la commande udevadm info -a -n /dev/ttyUSB0 | grep EnOcean | grep product pour pouvoir renseigner correctement votre fichier .rules.

Je suppose aussi que vous n’avez pas installé le service systemd. Sinon le service et votre instance lancée manuellement de enoceanmqtt pourraient se gêner mutuellement.

Par ailleurs, quelle commande utilisez-vous pour lancer enoceanmqtt ? Dans quel répertoire se trouve votre fichier de configuration ?

J’ai fait les tests en ayant débranché la clé Zigbee, mais toujours le même message :frowning:

Alors j’avais suivi la procédure pour attribuer un nom persistent au port de la clé USB300. Seulement, le dossier /etc/udev/rules.d/ n’existe pas par défaut. Je le crée et y mets le fichier avec la règle, mais, lorsque je reboot, ce dossier a été supprimé ! (et donc le lien symbolique n’existe pas, de fait). Je ne me suis pas attardée + que ça sur le problème, et j’utilise donc le chemin en dûr pour l’instant.

Non, je n’ai pas non plus installé systemd. Pour l’instant j’essayais déjà de le faire tourner « à la main » avant de le lancer en arrière plan.

J’utilise le script principal, qui s’appelle tout simplement enoceanmqtt. J’ai fait plusieurs essais :

  • mettre le fichier de conf dans /etc et lancer enoceanmqtt depuis là-bas
  • idem pour le fichier de conf, mais lancer depuis mon home
  • mettre le fichier de conf ailleurs que dans /etc et lancer enoceanmqtt depuis le même répertoire, ou depuis un autre.

Dans tous ces cas, j’ai la même chose. Il se connecte bien au serveur mqtt, il envoie et réceptionne son paquet de test, mais ensuite il termine sur le SerialPort Exception.

Je viens de relire votre message dans l’autre fil de discussion concernant l’installation. J’ai tiqué sur cette phrase

J’ai d’abord installé la librairie python enocean

Enoceanmqtt installe également cette librairie. Il se pourrait donc que vous ayiez peut être 2 instances de cette librairie qui tourne en même temps.
Pour partir d’une base clean, supprimez à la fois la librairie Python EnOcean ainsi que enoceanmqtt. Puis réinstallez uniquement enoceanmqtt via pip.

Concernant le fichier de configuration, il doit être dans /etc et chez moi, enoceanmqtt est installé dans mon home dans le répertoire ~/.local/
Vous n’aurez ensuite qu’à lancer en tapant enoceanmqtt dans un terminal ou enoceanmqtt --debug si vous voulez voir les logs de debug.

Concernant le fichier .rules, c’est bizarre ce que vous décrivez.

J’ai une Pi4 disponible, quelle distribution utilisez-vous ? Je vais voir si vos erreurs se reproduisent chez moi, auquel cas je pourrais mieux vous aider.

J’ai installé directement homeAssistant OS depuis le repo de Raspberry Pi.
J’ai Raspberry Pi Imager sur mon ordi, j’ai choisi other specific purpose os > home assistant and home automation > home assistant > home assistant OS (RPi 4/400), et flashé sur la carte SD.

enocean-mqtt a dans ses dépendances enocean. Mais donc lorsque j’ai installé enocean-mqtt, pypi a juste dit « already installed » pour le package enocean, et pas refait d’installation. Mais au cas où, je viens de tout désinstaller et réinstaller uniquement enocean-mqtt, mais c’est pareil.

Oui, le fichier de config doit être par défaut dans /etc. S’il est ailleurs il faut juste ajouter le chemin vers lui lorsqu’on lance enoceanmqtt.
Il n’y a pas de dossier ~/.local chez moi… Pypi installe par défaut dans /usr/lib/python3.10/site-packages/.

Je ne connais pas du tout HA OS peut être qu’il y a des petites subtilités.
Dans ma config, j’ai installé HA en mode supervisé sur ubuntu server. Du coup j’ai une distribition linux classique et HA tourne via Docker.

Bref, je fais des tests avec un setup similaire au votre et je vous dirai ce qu’il en est.

Bonjour,

J’ai installé HAOS sur ma Pi4, installé enocean-mqtt via pip et pour l’instant (~50 minutes), je n’ai pas d’erreur.

[Installation HOAS]

image: HAOS 8.1 RPi-4 64-bit
Home Assistant Core 2022.6.5
Home Assistant Supervisor 2022.05.3
Home Assistant OS 8.1

[Installation enoceanmqtt]

Pour avoir un terminal dans HAOS, j’ai installé le module complémentaire SSH & Web Terminal version 11.0.1
Ensuite dans le terminal

> pip install enocean-mqtt
> vi /etc/enoceanmqtt.conf

Le contenu du fichier de configuration est le suivant

## the general section defines parameter for the mqtt broker and the enocean interface
[CONFIG]
enocean_port    = /dev/ttyUSB0
log_packets     = 1

# mqtt_host       = localhost
mqtt_host       = aaa.bbb.ccc.ddd
mqtt_port       = pppp
mqtt_client_id  = enogtw   # ensure that this is unique if you use multiple clients

## setting mqtt_keepalive = 0 sets the timeout to infinitive but does not work reliably
## due to an upstream issue https://github.com/eclipse/paho.mqtt.python/issues/473
mqtt_keepalive  = 60

## the prefix is used for the mqtt value names; this is extended by the sensor name
mqtt_prefix     = test/enocean/

## publish received packets as single MQTT message with a JSON payload
# mqtt_publish_json = true

## optionally also set mqtt_user and mqtt_pwd (don't use quotes).
# mqtt_user       = 
# mqtt_pwd        = 

## enable SSL on MQTT connection
## Ensure that mqtt_host matches one of the hostnames contained in the broker's
## certificate, otherwise the client will refuse to connect.
##
## mqtt_ssl_ca_certs: CA certificates to be treated as trusted. Required if
##     the MQTT broker is configured with a self-signed certificate.
## mqtt_ssl_certfile, mqtt_ssl_keyfile: Client certificate and private key.
##     Only required if the broker requires clients to present a certificate.
## mqtt_ssl_insecure: Disable verification of the broker's certificate.
##     WARNING: do NOT use on production systems as this is insecure!
##
# mqtt_ssl          = true
# mqtt_ssl_ca_certs = /path/CA_files_merged.pem
# mqtt_ssl_certfile = /path/client_cert.pem
# mqtt_ssl_keyfile  = /path/client_key.pem
# mqtt_ssl_insecure = true

## Enable MQTT debugging. Requires --debug on the command line.
mqtt_debug      = true

## all other sections define the sensors to monitor

[module/test]
address         = 0xDEADBEEF
rorg            = 0xD2   # VLD
func            = 0x01
type            = 0x0C
log_learn       = 1
command         = CMD
publish_rssi    = 1

[Run]

> enoceanmqtt --debug

Les premières lignes du log donnent:

/usr/lib/python3.10/site-packages/bs4/builder/__init__.py:545: XMLParsedAsHTMLWarning: It looks like you're parsing an XML document using an HTML parser. If this really is an HTML document (maybe it's XHTML?), you can ignore or filter this warning. If it's XML, you should know that using an XML parser will be more reliable. To parse this document as XML, make sure you have the lxml package installed, and pass the keyword argument `features="xml"` into the BeautifulSoup constructor.
  warnings.warn(
2022-06-12 10:15:32,723 INFO: Logging to file: /usr/lib/python3.10/site-packages/enoceanmqtt/../enoceanmqtt.log
2022-06-12 10:15:32,724 INFO: Loading config file /etc/enoceanmqtt.conf
2022-06-12 10:15:32,727 DEBUG: Created sensor: {'name': 'test/enocean/module/test', 'address': ########, 'rorg': 210, 'func': 1, 'type': 12, 'log_learn': 1, 'command': 'CMD', 'publish_rssi': 1}
2022-06-12 10:15:32,728 DEBUG: Global config: {'enocean_port': '/dev/ttyUSB0', 'log_packets': '1', 'mqtt_host': '########', 'mqtt_port': '####', 'mqtt_client_id': 'enogtw', 'mqtt_keepalive': '60', 'mqtt_prefix': 'test/enocean/', 'mqtt_debug': 'true'}
2022-06-12 10:15:32,729 DEBUG: Connecting to host ########, port ####, keepalive 60
2022-06-12 10:15:32,743 DEBUG: Sending CONNECT (u0, p0, wr0, wq0, wf0, c1, k60) client_id=b'enogtw'
2022-06-12 10:15:32,743 INFO: SerialCommunicator started
2022-06-12 10:15:32,744 WARNING: Replacing Packet.optional with default value.
2022-06-12 10:15:32,746 INFO: Sending packet
2022-06-12 10:15:32,747 DEBUG: 0x05 ['0x8'] [] OrderedDict()
2022-06-12 10:15:32,748 DEBUG: Received CONNACK (0, 0)
2022-06-12 10:15:32,749 INFO: Succesfully connected to MQTT broker.
2022-06-12 10:15:32,750 DEBUG: Sending SUBSCRIBE (d0, m1) [(b'test/enocean/module/test/req/#', 0)]
2022-06-12 10:15:32,752 DEBUG: Received SUBACK
2022-06-12 10:15:32,848 DEBUG: 0x02 ['0x0', '0xff', '0xc2', '0xe4', '0x80'] ['0xa'] OrderedDict()
2022-06-12 10:15:32,849 INFO: got response packet: OK
2022-06-12 10:16:19,097 DEBUG: ##:##:##:##->FF:FF:FF:FF (-64 dBm): 0x01 ['0xf6', '0x10', '0x##', '0x##', '0x##', '0x##', '0x20'] ['0x0', '0xff', '0xff', '0xff', '0xff', '0x40', '0x0'] OrderedDict()
2022-06-12 10:16:19,099 INFO: received: ##:##:##:##->FF:FF:FF:FF (-64 dBm): 0x01 ['0xf6', '0x10', '0x##', '0x##', '0x##', '0x##', '0x20'] ['0x0', '0xff', '0xff', '0xff', '0xff', '0x40', '0x0'] OrderedDict()
2022-06-12 10:16:19,102 INFO: unknown sensor: ##:##:##:##
2022-06-12 10:16:19,625 DEBUG: ##:##:##:##->FF:FF:FF:FF (-65 dBm): 0x01 ['0xf6', '0x0', '0x##', '0x##', '0x##', '0x##', '0x20'] ['0x0', '0xff', '0xff', '0xff', '0xff', '0x41', '0x0'] OrderedDict()
2022-06-12 10:16:19,626 INFO: received: ##:##:##:##->FF:FF:FF:FF (-65 dBm): 0x01 ['0xf6', '0x0', '0x##', '0x##', '0x##', '0x##', '0x20'] ['0x0', '0xff', '0xff', '0xff', '0xff', '0x41', '0x0'] OrderedDict()
2022-06-12 10:16:19,628 INFO: unknown sensor: ##:##:##:##
2022-06-12 10:16:32,825 DEBUG: Sending PINGREQ
2022-06-12 10:16:32,829 DEBUG: Received PINGRESP

Merci beaucoup pour votre aide !

La seule différence qu’il pourrait y avoir : est-ce que vous avez déjà des devices appairés sur votre clé enocean ?

Sinon, je peux essayer de faire un backup de mon HA et tout réinstaller de 0 (je n’ai pas d’autre RPi pour tester).

Salut,

Juste une remarque c’est pas dit que ça soit pérenne à la prochaine mise à jour/redémarrage du container HA (parce oui HAOS c’est du container) :

  • le package enoceanmqtt à toutes les chances de ne pas être là le prochain coup
  • le fichier de conf est dans un volume, mais si le volume change ou n’est pas monté, il va disparaitre aussi
  • le lancement de enoceanmqtt --debug n’est pas un service donc au prochain démarrage du container il ne sera pas lancé

Le type de modification tel que décrit là est adapté à une VM, mais sur les containers c’est pas pareil.
Il faut imaginer ça comme une image gravé (un OS live CD, sans stockage), où les modifications ne sont jamais enregistrées (par défaut) et conservées en mémoire. Et quand la mémoire est vidée, les modifs aussi

Soit il existe déjà (ou alors il faut construire) une image/container avec le module et la config. Soit il faut passer par une installation OS + HA en mode supervised pour disposer d’une VM classique. Soit carrément une vm basique à part

Merci pour cette explication :slight_smile:
Cela explique alors pourquoi mon fichier 99-usb.rules « disparait » après reboot !

Concernant enoceanmqtt, avant d’avoir qqc de pérenne, j’essaie déjà que cela fonctionne lorsque je le lance manuellement… Mais si j’arrive à faire fonctionner, ça sera l’étape d’après en effet !
Par rapport aux points abordés :

  • Concernant le fichier de conf, on peut le mettre ailleurs. Je me suis par exemple fait un dossier EnOcean_conf dans config, qui est toujours monté au démarrage (puisqu’il contient le configuration.yaml). Donc ce n’est pas un problème.
  • Pour le package enoceanmqtt, c’est pareil, je peux l’installer dans le dossier config pour qu’il reste là.
  • Par contre la question restera en effet de lancer enoceanmqtt au démarrage.

@asetGem : oui j’ai des devices déjà appairés sur ma clé.
Je pensais aussi à autre chose, vous avez quoi comme alimentation pour votre Pi4 ?
C’est peut être un peu tirer par les cheveux mais si votre alimentation est sous-dimensionnée, à chaque fois que la clé est sollicitée, peut être que ça entraîne une déconnexion/reconnexion de la clé.

@Pulpy :
Oui je sais, c’était juste pour tester un setup équivalent à celui de @asetgem, à savoir Pi4 + HAOS.
Perso je ne suis pas du tout fan de HAOS, mon installation est HA supervisé sur Ubuntu server. Je garde ainsi la main sur tout ce que je fais.

Alimentation « officielle » de la RPi, donc pas de problème de ce côté là.

Tout à fait

Absolument, ça démontre la faisabilité et permet d’avoir un bout de procédure.

C’est une partie de la solution, il faut aussi s’assurer que ledit de fichier de config est bien celui utilisé par la daemon au lancement.

Les éléments installés c’est pas forcément suffisant, il faut aussi que le package soit ‹ vu ›

ça c’est tout le principe du container à la base : 1 image = 1 service. Après il ya moyen de lancer des trucs à la main l’addon appdaemon par exemple permet l’execution de python avec un contexte permanent, mais c’est pas ‹ clé en main ›

Parfait, si c’est bien clair pour tout le monde, ça ira bien. J’aime pas HAOS non plus mais quand on débute, c’est plus simple les 10 premières minutes
Pour info, la base classique c’est plutot du debian que ubuntu (server ou pas d’ailleurs), mais bon ça reste un détail

C’est une partie de la solution, il faut aussi s’assurer que ledit de fichier de config est bien celui utilisé par la daemon au lancement.

ça ce n’est pas un soucis, puisqu’on peut donner un chemin vers ce fichier

Les éléments installés c’est pas forcément suffisant, il faut aussi que le package soit ‹ vu ›

Oui, surement un petit simlink à refaire au démarrage.

Perso je ne suis pas du tout fan de HAOS, mon installation est HA supervisé sur Ubuntu server. Je garde ainsi la main sur tout ce que je fais.

Comme je ne connaissais pas du tout (ni HA, ni les RPi d’ailleurs), j’ai fait au plus simple, qui était l’OS déjà installé. Mais après, si cela me pose des problèmes, je peux essayer un autre setup (j’aurais peut-être besoin d’un tuto par contre).

Mais avant de refaire tout ça, il faudrait déjà que ça fonctionne. Puisque cela fonctionne chez @mak-dev , HA OS n’est pas le problème, ça devrait marcher chez moi aussi :frowning:

Oui, mais ça reste pas aussi simple. Problème est toujours le même :

  • le fichier existe mais le lien symbolique disparaitra
  • installer du python, c’est pas uniquement les binaires :wink:

Je vais réinstaller un HAOS ‹ clean › pour voir si ça fonctionne déjà comme ça.

Petit update de la situation : j’ai installé HAOS sur une nouvelle carte SD. J’ai juste installé les add-ons ssh and web terminal et mosquitto broker. Ensuite, comme avant, j’ai installé et lancé enoceanmqtt dans le terminal et…ça marche :partying_face: !
Du moins, ça tourne sans lancer d’erreur, et ça réagit lorsque j’appuie sur un interrupteur par exemple. Maintenant, il faut que je vois si les appairages fonctionnent bien, et que je passe à la suite de votre tuto.
Ensuite, il faudra que je réinstalle progressivement tout mon HA pour voir à quel moment ça interfert :sweat: