Bonjour
je cherche des exemples d’organisation des topics mqtt.
Y a t il une logique à prendre en compte pour HA ?
exemples :
rdc/cuisine/sondes/temperature
ou
rdc/cuisine/sondes et json {temperature=xx, humidite=xx, etc.}
y a t il un intérêt à indiquer l’étage (rdc, étage, soussol) ?
Vaut il mieux regrouper les éléments par types :
prises/cuisine/four
prises/salon/tv
lumieres/wc
etc.
A lire vos avis sur la question 
Salut et bienvenue,
a moins que tu ne comptes faire en grand nombre de capteurs DIY, ou que tu veux faire parler plusieurs appareils que tu contrôle toi même, l’organisation des topics n’a que peu d’importance.
Les logiques par pièce ou type d’appareils sont assez équivalentes et la meilleure dépend au final de ce que tu prévois d’avoir à couvrir… si la majorité des pièces n’aura qu’un topic autant je pas mettre la pièce en premier et commencer avec le type d’appareil…
Merci pour l’accueil.
Oui il y a un grand nombre de capteurs, sondes, prises, lumières et autres objets connectés en DIY. C’est pour ma prochaine maison que je vais bientôt construire.
J’avais un système perso (et unique) pour gérer ma domotique. Là je regarde si HA me permettrait d’être plus ouvert sur les objets du commerce et surtout d’avoir une bonne intégration UX/UI sans que je passe trop de temps à développer.
Le protocole mqtt est particulièrement intéressant et s’intègre bien dans HA et mes ESP. Il est aussi adaptable sur mes anciens serveurs domotiques.
En fait je ne voudrais pas à avoir à tout ré-écrire et reflasher parce que HA gère d’une certaine manière et que j’aurai fait le choix d’une moins bonne façon de faire.
En fait HA dispose d’un système d’auto-discovery pour les appareils sous mqtt. Si tu respecte ce protocole, les entités sont découvertes et ajoutées automatiquement dans HA.
Il faut publier des infos en respectant le protocole auto discovery
Pour Zigbee2mqtt / zwave.js et certains autres services c’est géré en natif.Pour tes ESP je te conseille de les passer sous ESPHome avec l’addon kivabien dans HA et gère aussi le discovery.
De toutes façons le topic ne jouera pas là dedans.
Tu peux avoir n’importe quelle organisation si tu veux ça n’a pas d’impact.
Si tu veux autoconfigurer tes appareils et entités dans HA, ça se fait en publiant sur un topic « homeassistant/… » comme expliqué dans le lien d’auto discovery. Ceci donnera le topic auquel s’abonner pour avoir l’état.
Si on ne veux pas en passer par là, et ne pas tout recompiler, il est possible de simplement définir les entités MQTT dans le fichier de configuration. Et décrire leurs propriétés et topics respectifs.
switch:
- name: "Shelly Plug S"
command_topic: "shellies/shellyplug-s-A33C3A/relay/0/command"
state_topic: "shellies/shellyplug-s-A33C3A/relay/0"
payload_off: "off"
payload_on: "on"
sensor:
- name: "Compteur Puissance"
state_topic: "compteur/puissance"
unit_of_measurement: "W"
device_class: power
- name: "Compteur IMAX Phase 1"
state_topic: "compteur/maxp1"
unit_of_measurement: "A"
device_class: current
- name: "Temp.Exterieur"
state_topic: "temperatures/exterieur"
unit_of_measurement: "°C"
device_class: temperature
- name: "Temp.SalonThermostat"
state_topic: "temperatures/salon_thermostat"
unit_of_measurement: "°C"
device_class: temperature
- name: "Temp.Garage"
state_topic: "temperatures/Garage"
unit_of_measurement: "°C"
device_class: temperature
- name: "Temp.ChambreGauche"
state_topic: "temperatures/ChambreGauche"
unit_of_measurement: "°C"
device_class: temperature
- name: "Temp.CouloirEtage"
state_topic: "temperatures/CouloirEtage"
unit_of_measurement: "°C"
device_class: temperature
ils est aussi possible de récupérer le JSON d’un même topic pour le coller dans plusieurs entités:
- name: "Serveur2 Ram"
state_topic: "monitoring/proxtwo"
unit_of_measurement: "%"
value_template: "{{ value_json.ram_used }}"
- name: "Serveur2 CPU Temp"
state_topic: "monitoring/proxtwo"
unit_of_measurement: "°C"
value_template: "{{ value_json.cpu_temp }}"
- name: "Serveur2 Boot Used"
state_topic: "monitoring/proxtwo"
unit_of_measurement: "%"
value_template: "{{ value_json.boot_used }}"
Merci des réponses, ça répond partiellement à ma question.
Je connais les fonctions de discovery et comment envoyer, recevoir et traiter les trames mqtt dans HA.
Je ne passe pas par ESPhome pour 2 raisons : ma programmation est certainement plus optimisée que celle d’ESPhome, plus sécurisée aussi. ESPhome est une boite noire. La 2e raison est que j’envoie des datas sur un 2e serveur qui n’a rien à voir avec HA et via un autre protocole que mqtt.
C’est bien plus efficient de programmer en arduino ou C que des config en yaml (pour mes besoins je précise)
Ce que je retiens c’est que peu importe l’arborescence choisie, il faut trouver sa propre logique pour s’y retrouver.
L’exemple que tu envoies AlexHass est typiquement dans les questions que je me pose en terme d’efficience.
Je résume dans l’exemple ci-dessous, un objet qui mesure la température, l’humidité, la luminosité. (il pourrait renvoyer bien plus de variables )
Cas 1 : 3 trames mqtt par mise à jour
- name: "cuisine temperature"
unique_id: "cuisine_temperature"
state_topic: "cuisine/temperature"
unit_of_measurement: "°C"
- name: "cuisine humidite"
unique_id: "cuisine_humidite"
state_topic: "cuisine/humidite"
unit_of_measurement: "%"
- name: "cuisine luminosite"
unique_id: "cuisine_luminosite"
state_topic: "cuisine/luminosite"
unit_of_measurement: "%"
Cas 2 : 1 trame mqtt avec un parse du json sur le backend
- name: "cuisine temperature"
unique_id: cuisine_temperature
state_topic: "cuisine/sonde"
unit_of_measurement: "%"
value_template: "{{ value_json.temperature }}"
- name: "cuisine humidite"
unique_id: cuisine_temperature
state_topic: "cuisine/sonde"
unit_of_measurement: "%"
value_template: "{{ value_json.humidite }}"
- name: "cuisine luminosite"
unique_id: cuisine_luminosite
state_topic: "cuisine/sonde"
unit_of_measurement: "%"
value_template: "{{ value_json.luminosite }}"
En terme de trafic, le cas 2 semble bien plus efficace que le cas 1.
Il y a surement des best practices et des retours d’expérience intéressants sur des réseaux domotiques conséquents ( > 800 entités)
J’ai beau cherché sur le web, il n’y a vraiment rien de probant hormis des dizaines de tutos identiques qui expliquent ce qu’est mqtt.
C’est surement plus optimisé en termes de traffic de grouper les entités par appareil en JSON, après le MQTT c’est assez léger. Et ça dé"pend aussi de la fréquence de mise à jour…
J’ai 782 entités qui viennent par MQTT, toutes ne sont pas mises à jour trop régulièrement, et la majorité c’est Zigbee2MQTT, mais le MQTT suit sans soucis…
Pour répondre à la question il faudrait savoir ce qui est le plus gourmand en ressources :
1- Faire transiter un grand nombre de données simple
2- Parser du JSON pour y retrouver la données qui nous intéresse
A mon avis, dans un cas comme dans l’autre, si tu optimises d’un côté, tu perds de l’autre.
