Enocean via enoceanmqtt

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

@mak-dev Je vais avoir besoin de votre aide. Où peut-on trouver les xml des EEP qui ne sont pas encore dans la librairie python ? En l’occurrence, D2-01-12… Il faut les faire soi-même ou il y a une librairie « toute faite » ?

Désolé je viens seulement de voir les nouveaux messages.
Parfait donc ! :+1:

Concernant EEP.xml, il faut rajouter soit-même les EEP manquants en s’aidant de l’EEP Viewer disponible sur le site de l’alliance enocean.

Je l’ai déjà fait pour gérer quelques commandes des D2-01-12.

      <profile type="0x12" description="Slot-in Module with 2 channels and no metering capabilities">
        <command description="Command identifier" shortcut="CMD" offset="4" size="4">
          <item description="Actuator Set Output" value="1" />
          <item description="Actuator Status Query" value="3" />
          <item description="Actuator Status Response" value="4" />
        </command>
        <data command="3" bits="2">
          <enum description="Command identifier" shortcut="CMD" offset="4" size="4">
            <rangeitem description="Command ID {value}" start="0" end="13" />
          </enum>
          <enum description="I/O channel" shortcut="IO" offset="11" size="5">
            <rangeitem description="Output channel {value} (to load)" start="0" end="29" />
            <item description="All output channels supported by the device" value="30" />
            <item description="Input channel (from mains supply)" value="31" />
          </enum>
        </data>
        <data command="4" bits="3">
          <enum description="Power Failure" shortcut="PF" offset="0" size="1">
            <item description="Power Failure Detection disabled/not supported" value="0" />
            <item description="Power Failure Detection enabled" value="1" />
          </enum>
          <enum description="Power Failure Detection" shortcut="PFD" offset="1" size="1">
            <item description="Power Failure Detection not detected/not supported/disabled" value="0" />
            <item description="Power Failure Detection Detected" value="1" />
          </enum>
          <enum description="Command identifier" shortcut="CMD" offset="4" size="4">
            <rangeitem description="Command ID {value}" start="0" end="13" />
          </enum>
          <enum description="Over current switch off" shortcut="OC" offset="8" size="1">
            <item description="Over current switch off: ready / not supported" value="0" />
            <item description="Over current switch off: executed" value="1" />
          </enum>
          <enum description="Error level" shortcut="EL" offset="9" size="2">
            <item description="Error level 0: hardware OK" value="0" />
            <item description="Error level 1: hardware warning" value="1" />
            <item description="Error level 2: hardware failure" value="2" />
            <item description="Error level not supported" value="3" />
          </enum>
          <enum description="I/O channel" shortcut="IO" offset="11" size="5">
            <rangeitem description="Output channel {value} (to load)" start="0" end="29" />
            <item description="Not applicable, do not use" value="30" />
            <item description="Input channel (from mains supply)" value="31" />
          </enum>
          <enum description="Local control" shortcut="LC" offset="16" size="1">
            <item description="Local control disabled / not supported" value="0" />
            <item description="Local control enabled" value="1" />
          </enum>
          <enum description="Output value" shortcut="OV" offset="17" size="7">
            <item description="Output value 0% or OFF" value="0" />
            <rangeitem description="Output value {value}% or ON" start="1" end="100" />
            <rangeitem description="Not used" start="101" end="126" />
            <item description="output value not valid / not set" value="127" />
          </enum>
        </data>
        <data command="1" bits="3">
          <enum description="Command identifier" shortcut="CMD" offset="4" size="4">
            <rangeitem description="Command ID {value}" start="0" end="13" />
          </enum>
          <enum description="Dim value" shortcut="DV" offset="8" size="3">
            <item description="Switch to new output value" value="0" />
            <item description="Dim to new output level - dim timer 1" value="1" />
            <item description="Dim to new output level - dim timer 2" value="2" />
            <item description="Dim to new output level - dim timer 3" value="3" />
            <item description="Stop dimming" value="4" />
          </enum>
          <enum description="I/O channel" shortcut="IO" offset="11" size="5">
            <rangeitem description="Output channel {value} (to load)" start="0" end="29" />
            <item description="All output channels supported by the device" value="30" />
            <item description="Input channel (from mains supply)" value="31" />
          </enum>
          <enum description="Output value" shortcut="OV" offset="17" size="7">
            <item description="Output value 0% or OFF" value="0" />
            <rangeitem description="Output value {value}% or ON" start="1" end="100" />
            <rangeitem description="Not used" start="101" end="126" />
            <item description="output value not valid / not set" value="127" />
          </enum>
        </data>
      </profile>

Il faut le rajouter dans la section telegram rorg="0xD2" / profiles func="0x01"

Je pourrai partager plus tard mon fichier EEP.xml via mon github. J’ai quelques uns des D2-01-XX.

Super merci !
J’avais commencé à faire un truc dans le genre pour la commande 1, mais entre temps j’ai fait autre chose. C’est étonnant qu’il n’y soit pas par « défaut ». Peut-être une pull request sur le dépot git ? Ce sont des modules assez courants.

Sinon, j’ai réussi à fermer un VR via un script HA :raised_hands: grand progrès ! Prochaine étape : la communication dans l’autre sens pour connaitre l’état d’un VR par exemple (enfin idéalement qu’il se mette à jour tout seul).
Je viens aussi de mettre ma clé zigbee, et enocean continue à tourner correctement… Vraiment étrange ce bug.

Par contre, je n’y connais vraiment rien sur enocean, donc j’ai du mal à saisir. Lorsque je mets en mode appairage, le « learning » se fait automatiquement quand enoceanmqtt tourne. Mais il appaire avec quoi ? Avec la clé ? Si je mets la clé sur un autre RPi (ou sur mon ordi) ce sera toujours appairé ?

Il appaire avec la clé effectivement.
Sur une autre Pi, plus besoin d’appairer. Il faut juste redéclarer le module dans le fichier de config enoceanmqtt.

Pour avoir l’état dans HA, vous avez la plateforme cover MQTT

Pour avoir l’état dans HA, vous avez la plateforme cover MQTT

Ok, j’irai regarder ça merci. J’avais pensé le faire à la main, mais s’il y a déjà une intégration pour ça c’est encore mieux.

Sur une autre Pi, plus besoin d’appairer. Il faut juste redéclarer le module dans le fichier de config enoceanmqtt.

Ok :+1: Mais par contre le déclarer dans le fichier de conf ne suffit pas pour l’appairer, il faut aller physiquement le mettre en mode appairage la première fois c’est bien ça ?
Comment sait-on quels modules doivent être appairés et lesquels non ? Par exemple, pas besoin pour les interrupteurs, les thermomètres…
A propos d’interrupteurs : si j’ai déclaré un interrupteur et un VR (que j’ai appairé également) dans mon fichier de conf, pensez-vous qu’il est possible d’appairer le VR à l’interrupteur par enoceanmqtt ? Pour que l’interrupteur ouvre/ferme le volet, même en absence de enoceanmqtt ou toute autre plateforme.