Je suis pas chez moi donc je peux pas tester mais oui par défaut zigbee2mqtt utilise homeassistant par défaut et classe dedans les sensor etc…
Par contre le
position_open: "0"
position_closed: "100"
N’est pas propre au module, mais au volet en lui même. C’est dépend du sens du moteur qui lui ai dépend de l’arrivée électrique souvent. Au pire faut changer le cablage du module pour tout uniformiser
Donc si j’ai bien compris, ça sous-entend que zigbee2mqtt utilise
homeassistant/comme prefix de discovery.
A priori oui. Avec mqtt explorer, je vois bien des sous-topics de « homeassistant », mais il y a aussi un topic « zigbee2mqtt ». Donc je ne sais pas trop comment c’est organisé.
Pour les VR, si je comprends bien,
0 = openet100 = closedavec nos modules D2-05-00 ? (→ edit:confirmer dans la doc EEP).
Je suis un peu perdu par rapport à la manière dont HA interprète le code vu que mqtt.cover utilise comme valeur par défaut0 = closedet100 = open.
C’est très étrange, je suis aussi un peu perdue.
Si j’ouvre complètement mon VR (physiquement), dans mqtt-explorer j’ai POS=0. Dans HA, j’ai current_position: 100 dans les attributs, et open pour l’état.
Bonjour,
Alors pour les VR, du coup, j’utilise :
set_position_template: "{\"CMD\":\"1\",\"POS\":\"{{ 100- position }}\",\"ANG\":\"0\",\"REPO\":\"0\",\"LOCK\":\"0\",\"CHN\":\"0\",\"send\":\"clear\"}"
position_open: 0
position_closed: 100
Pour que les commandes dans HA correspondent bien à la réalité.
J’ai essayé d’ajouter mon détecteur de fumée, mais je n’obtiens que les entités RSSI et delete, pas l’état du détecteur… Voilà ma config dans mapping.yaml :
0xF6:
0x05:
0x02:
- component: binary_sensor
name: "smoke detector"
config:
state_topic: "SMO"
payload_on: "10"
payload_off: "0"
device_class: smoke
config_json:
state_topic: ""
value_template: "{{ value_json.SMO }}"
payload_on: "10"
payload_off: "0"
device_class: smoke
D’après la doc EEP : http://tools.enocean-alliance.org/EEPViewer/profiles/F6/05/02/F6-05-02.pdf
Et dans mon enoceanmqtt.conf :
[detecteur fumee]
address = 0x00000000
rorg = 0xF6
func = 0x05
type = 0x02
log_learn = 1
persistent = 1
publish_rssi = 0
Vois-tu où est le problème ?
Hello,
Merci pour le test sur les VR.
Quand on modifie mapping.yaml il faut dans HA, supprimer les appareils impactés par ces modifications et relancer enoceanmqtt.
J’ai rajouté une section destinée aux développeurs dans le readme qui explique tout ça.
Aussi, évite les espaces dans les noms de modules.
En général, mieux vaut éviter les espaces, les accents, etc.
Je ne sais plus comment c’est géré au niveau MQTT et au niveau enoceanmqtt, mais une chose est sûre, je n’ai pas géré les noms de modules avec espace dans l’overlay.
Et pour ton détecteur de fumée, c’est plutôt payload_on : "16" (0x10 = 16)
Quand on modifie mapping.yaml il faut dans HA, supprimer les appareils impactés par ces modifications et relancer enoceanmqtt.
J’ai rajouté une section destinée aux développeurs dans le readme qui explique tout ça.
Oui oui, j’avais bien fait tout ça 
J’ai changé le payload_on à 16, merci.
C’est bon, ça fonctionne, tu peux rajouter le F6 05 02 à la liste 
Prochaine étape : tester le ewattch ( A5 12 01 ou A5 12 00).
Top ! Merci
Pour compléter F6-05-02 et gérer le cas où on a le message ENERGY LOW:
0xF6:
0x05:
0x02:
- component: binary_sensor
name: "alarm"
config:
state_topic: "SMO"
payload_on: "on"
payload_off: "off"
value_template: >-
{% if value == "16" %}on{% else %}off{% endif %}
device_class: smoke
config_json:
state_topic: ""
payload_on: "on"
payload_off: "off"
value_template: >-
{% if value_json.SMO == 16 %}on{% else %}off{% endif %}
device_class: smoke
- component: binary_sensor
name: "battery"
config:
state_topic: "SMO"
payload_on: "on"
payload_off: "off"
value_template: >-
{% if value == "48" %}on{% else %}off{% endif %}
device_class: battery
config_json:
state_topic: ""
payload_on: "on"
payload_off: "off"
value_template: >-
{% if value_json.SMO == 48 %}on{% else %}off{% endif %}
device_class: battery
Vu que je n’ai pas encore documenté mapping.yaml, je profite de ton exemple pour le faire.
name correspond en fait au suffixe qui sera rajouté au nom de l’appareil pour former le nom de l’entité.e2m_<sensor_name>_<suffix> où <sensor_name> est le nom défini dans enoceanmqtt.conf.e2m_<sensor_name>.component correspond au type de l’entité.config correspond à la configuration de l’entité dans le cas où on n’utilise pas le format JSON pour publier les messages depuis EnOcean vers MQTT.config_json idem que config mais pour le cas où le format JSON est utilisé.Ainsi, si dans enoceanmqtt.conf tu as:
[detecteur_fumee]
address = 0xBABECAFE
rorg = 0xF6
func = 0x05
type = 0x02
alors on aura dans HA un nouvel appareil avec quatre entités:
e2m_detecteur_fumee
e2m_detecteur_fumee_alarm
e2m_detecteur_fumee_battery
e2m_detecteur_fumee_rssi (le RSSI du device)
e2m_detecteur_fumee_delete (pour supprimer le device de HA et de la database).
D’où le fait d’ailleurs d’éviter l’utilisation des espaces dans les noms
@asetGem
Je viens d’y penser, pour tes F6-02-02 qui ne fonctionnait pas, si tu as toujours le soucis, rajoute log_learn = 1 dans la configuration de tes F6-02-02 dans enoceanmqtt.conf. Ça va être OK avec ça.
J’avais déjà le log_learn = 1. Mais depuis la version avec l’overlay c’est bon, ils fonctionnent
Merci pour les précisions sur le mapping.yaml. ça confirme bien ce que j’avais compris. La seule question que je me posais était à quel moment on utilise config vs config_json? Y a-t-il besoin de définir les 2 à chaque fois, le config_json ne suffirait-il pas ?
Dans les faits, on utilise toujours config_json puisque actuellement je force en interne publish_json = 1 pour tous les devices.
Donc on pourrait se contenter de définir uniquement config_json.
Mais vu que je ne sais pas encore si mon parti pris de forcer publish_json sera tout le temps justifié, je préfère faire l’exercice de définir les deux configs à chaque fois pour l’instant.
bonjour,
sur jeedom passerelle pour les interrupteurs enocean (TCM310) qui pilotes les lumière de ma Fibaro home center 3.
j’ai depuis un crash de problème avec jeedom. a 90 % les interrupteur ne réagisse pas.
j’ai donc cherche et je suis tombe sur home assistant. graphique super, reconnait tous mes appareille.
saufe le usb enocean TCM 310
j’ai suivi tout les étape mais rien n’y fait.
pouvez vous m’aider
je sus sur raspberry 3 32 bit
Bonjour, la TCM310 est-elle reconnue par votre Raspberry Pi, hors home assistant ?
Rebonjour,
J’ai commencé à intégrer mon ewattch. Au départ, je n’avais que les entités delete, RSSI et tariff qui apparaissaient dans HA. J’ai l’impression que, comme l’envoi de energy et power sont quasi en même temps, le paramètre availability bloquait.
Plutôt que jouer sur availability pour récupérer la valeur de energie ou power, j’ai utilisé une condition directement dans le value_template. Avec cette config, j’ai bien les 2 entités, avec les valeurs qui correspondent :
0x01:
- component: "sensor"
name: "power"
config:
state_topic: "MR"
state_class: "measurement"
device_class: "power"
unit_of_measurement: "W"
config_json:
state_class: "measurement"
state_topic: ""
value_template: >-
{% if value_json.DT == 1 %}{{ value_json.MR/(10**value_json.DIV) }}{% else %} {{ states("sensor.e2m_ewattchtic_power") }} {% endif %}
device_class: "power"
unit_of_measurement: "W"
- component: "sensor"
name: "energy"
config:
state_topic: "MR"
state_class: "total"
device_class: "energy"
unit_of_measurement: "kWh"
config_json:
state_topic: ""
state_class: "total"
value_template: >-
{% if value_json.DT == 0 %} {{ value_json.MR/(10**value_json.DIV) }} {%else %} {{ states("sensor.e2m_ewattchtic_energy") }} {% endif %}
device_class: "energy"
unit_of_measurement: "kWh"
- component: "sensor"
name: "tariff"
config:
state_topic: "TI"
config_json:
state_topic: ""
value_template: "{{ value_json.TI }}"
J’ai également ajouté les state_class, pour pouvoir utiliser energy en tant statistique, que j’ai intégré dans l’onglet énergie de home assistant :
Pour l’instant, tout a l’air de fonctionner correctement. A voir à l’usage.
Par contre, ça ne fonctionne qu’en utilisant config_json, donc à voir comment adapter s’il y a besoin d’utiliser config par la suite.
Il y a aussi le problème que ce n’est plus générique. Je rentre « en dur » la valeur de référence de l’entité. J’imagine qu’il y a un moyen de juste demander d’‹ ignorer › le message MQTT si DT n’a pas la bonne valeur ?
Concernant mon A5-12-00, je n’arrive pour l’instant pas à l’intégrer. Je ne suis pas sure d’avoir le bon ID, il faut que j’investigue.
Hello @asetGem
Oui il y a des limitations lorsqu’on n’utilise pas JSON. Ça va sauter tôt ou tard je pense …
Est-ce que tu pourrais essayer avec states(entity_id) à la place de states("sensor.e2m_ewattchtic_energy") ? De la sorte, ça redevient générique.
J’ai été confronté à ce soucis mais je n’ai pas trouvé de réponse pour l’instant. Je pense effectivement que mqtt.sensor devrait gérer ce cas là plutôt que de rajouter un else pour conserver l’état.
Autre possibilité, ce serait de rajouter channel = DT dans la configuration du ewattch dans enoceanmqtt.conf, vu que d’après ce que tu indiques, on a bien les deux informations puissance et énergie qui sont remontées en même temps.
Ainsi, on aurait les infos pour la puissance sur le topic DT1 et l’énergie sur le topic DT0. Plus besoin dans ce cas de faire une condition dans value_template. C’est peut être ce qu’il y a de mieux à faire je pense. Et ça fonctionnerait même sans utiliser JSON.
Bonjour,
Est-ce que vous pouvez transférer votre message sur ce sujet svp : Problème reconnaissance clé TCM310 enocean
Ce sera + facile à retrouver par d’autres utilisateurs dans votre cas.
Merci !
Est-ce que tu pourrais essayer avec
states(entity_id)à la place destates("sensor.e2m_ewattchtic_energy")? De la sorte, ça redevient générique.
Je cherchais justement par quelle variable était représentée la valeur actuelle.
ça fonctionne comme ça oui.
Autre possibilité, ce serait de rajouter
channel = DTdans la configuration du ewattch dansenoceanmqtt.conf, vu que d’après ce que tu indiques, on a bien les deux informations puissance et énergie qui se remontées en même temps.
Ainsi, on aurait les infos pour la puissance sur le topicDT1et l’énergie sur le topicDT0. Plus besoin dans ce cas de faire une condition dansvalue_template. C’est peut être ce qu’il y a de mieux à faire je pense. Et ça fonctionnerait même sans utiliser JSON.
En effet, c’est encore mieux !
Alors par contre je me suis peut-être mal exprimée. Les deux valeurs ne sont pas remontées en même temps. Il y a 2 messages mqtt différents : { DT = 1, MR = X} qui correspond à la puissance, et { DT=0, MR=Y} qui correspond à l’énergie. Mais donc ça correspond en mettant channel=DT.
Voilà la nouvelle configuration pour ces devices dans mapping.yaml (TI ne dépendant pas du channel, je l’ai affecté à DT1 par défaut… ) :
0xA5:
0x12:
0x01:
- component: "sensor"
name: "power"
config:
state_topic: "DT1/MR"
state_class: "measurement"
device_class: "power"
unit_of_measurement: "W"
config_json:
state_class: "measurement"
state_topic: "DT1"
value_template: "{{ value_json.MR/(10**value_json.DIV) }}"
device_class: "power"
unit_of_measurement: "W"
- component: "sensor"
name: "energy"
config:
state_topic: "DT0/MR"
state_class: "total"
device_class: "energy"
unit_of_measurement: "kWh"
config_json:
state_topic: "DT0"
state_class: "total"
value_template: "{{ value_json.MR/(10**value_json.DIV) }}"
device_class: "energy"
unit_of_measurement: "kWh"
- component: "sensor"
name: "tariff"
config:
state_topic: "DT1/TI"
config_json:
state_topic: "DT1"
value_template: "{{ value_json.TI }}"
avec, dans enoceanmqtt.conf:
[EwattchTIC]
address = 0x00000000
channel = DT
rorg = 0xA5
func = 0x12
type = 0x01
log_learn = 1
persistent = 1
Je me demandais s’il serait possible de choisir le nom des entités quand on définit un channel :
Pour le A5 12 01, les 2 channels sont power et energy, par définition de l’EEP.
Par contre, pour les lumières, IO correspond à 2 lampes différentes. On choisit le nom du device (entre [] ), mais les entités sont ensuite automatiquement nommées <device_name>_IO[0-1], ce qui n’est pas forcément très parlant.
Est-ce qu’on ne pourrait pas ajouter, dans le cas de multi-channel, quelque chose comme :
[lumiere_salon-et-entree]
address = 0x0000000
rorg = 0xD2 # VLD
func = 0x01
type = 0x12
channel = IO
channel1 = "entree"
channel0 = "salon"
log_learn = 1
publish_rssi = 0
command = CMD
persistent = 1
Ce qui donnerait les entités light.e2m_lumiere_salon-et-entree_entree et light.e2m_lumiere_salon-et-entree_salon
Je ne sais pas si ça aurait du sens de faire ça, ni à quel point ça demande de changements dans le code. Après, il y a peut-être des modules avec + que 2 channels différents, et ça rendrait le enoceanmqtt.conf un peu plus verbeux…
J’avais pensé à un truc comme ça à un moment.
Finalement je me suis dit que ce n’était pas nécessaire dans la mesure où on peut changer les noms des entités dans HA.
Oui bien sur on peut les changer après. Mais c’était histoire de tout définir en une seule fois, sans avoir besoin de repasser à plusieurs endroits. Mais c’est du détail, c’est très bien comme ça 
Autre chose que je cherche à faire, c’est appairer 2 appareils entre eux « physiquement ». Par exemple, j’ai un device interrupteur et un light pairés avec ma clé enocean, qui apparaissent dans HA. Je peux faire une automation pour que, lorsqu’on appuie sur l’interrupteur, ça allume la lumière. Seulement, si pour une raison ou une autre HA est down, on ne pourra plus allumer la lumière.
D’un autre côté, je sais qu’on peut pairer un interrupteur avec une lumière, en allant appuyer sur le module.
Dans la mesure où les 2 sont pairés avec la clé, il doit être possible de les faire pairer entre eux, donc sans avoir besoin de redémonter la lampe pour aller chercher le module. Sais-tu comment faire ça ?
