Bien-sûr! Je n’avais pas défini les routes sortantes par simple manque de temps. Dans la v4 tu l’as vu je prend le temps de bien définir les choses et de faire ça bien, je préfère ne pas développer quelque chose plutôt que de le développer vite et mal 
Je suis d’accord, à mon avis il vaut mieux recommander aux développeurs de code MQTT de demander à l’utilisateur de créer les devices dans l’UI (comme c’est le cas pour les autres services), sinon dès que ça se passe en background, l’utilisateur n’a aucun feedback si ça réussit ou ça rate. Et si ça rate, à part regarder les logs (ce qu’on ne veut pas dans la v4), il ne peut rien faire.
Pour ce topic, non, mais pour d’autres topics oui. Et comme on veut garder les mêmes conventions de nommage partout pour rester consistent, si on le met autre part, il faut le mettre ici aussi.
Je propose d’utiliser les attributs exactes pour rester consistent.
Le
gladys/master/device/custom:12/feature/custom:12:temperature:1/last_value
Me plaisait bien !
Oui ! Appelle ça forwarding si tu veux, après dernière ça sera juste l’implémentation de quelques routes « custom » qui effectivement appelleront les mêmes méthodes dans Gladys 
Bon du coup c’est quoi la next step pour ça? @Boimb tu peux faire une proposition de doc qui recap ce qu’on s’est dit? (Ou tu veux: Ici, dans une issue github, comme tu le sens)