Bonjour,
j’ai sûrement mal cherché, je voudrais envoyer du texte à une fonctionnalité d’un appareil, est-ce possible ?
Plusieurs exemple :
Comment peut on s’y prendre ?
Merci
Ça n’est pas possible pour le moment mais il y a une demande pour laquelle tu peux voter.
Solution actuelle… Passer par node-red pour convertir!
OK, je viens de voter, mais on est que 2 
Je ne connais pas du tout node-red, j’utilise bash et mosquitto pour les échanges MQTT.
Merci
@pierre-gilles avait fait une excellent vidéo au sujet de node-red:
Il existe une API MQTT aussi…
Tu peux alors directement faire ‹ écouter › le topic de ton bouton directement sur le périphérique concerné
Il faudra que je regarde mais ça veut dire que seul node-red devient utilisable pour la gestion de MQTT, python et bash ne sont donc plus vraiment compatibles…
Je viens de passer plusieurs jours sur le sujet pour réussir à comprendre et faire fonctionner le systeme en bash…
EDIT : Le problème est le même pour les dates ?
Du coup, j’ai regardé les 2 liens mais à aucun moment il n’est évoqué l’envoi de texte ou autre…
Quand j’essaie d’en envoyer, la valeur de l’appareil ne se met pas à jour…
que ce soit via mosquitto ou via node-red.
Quelqu’un peut il m’éclairer svp ?
Tu avais vu ce tutoriel @Hizo ?
J’imagine que tu as résolu ton problème depuis au vu de ton tutoriel ?
Oui, heureusement qu’il y a de la doc 
J’ai eu un peu de mal à tout piger mais là c’est bon.
Par contre, mon problème reste entier…
Comment envoyer du texte et l’afficher dans Gladys ?
Envoyer, pas de souci en MQTT, ça part bien.
Par contre impossible d’afficher le texte dans Gladys.
Faut il utiliser une Fonctionnalités d’Appareil spécifique qui accepte le texte ?
Je ne te cache pas qu’actuellement ça me frustre pour terminer mon TUTO sur Asiprateur <=> BASH <=> GLADYS
C’est la seule chose bloquante.
J’ai testé en BASH et avec node-red.
Dans le cas de ce dernier j’ai simplement fait l’inject d’un msg.payload au format string à une Fonctionnalité MQTT, et la même fonctionnalité en input avec un debug.
Lorsque j’envoie le texte, on voit son arrivé dans le debug.
Donc tout fonctionne au niveau échange MQTT.
Mais voilà, comment l’afficher dans Gladys…
Merci pour ton taf.
Ce n’est pas possible @Hizo de stocker du texte dans gladys.
Alors là… je ne sais que penser…
Un système d’affichage d’informations ne permettant pas d’afficher du texte ? 
Je ne sais pas comment fonctionne Gladys mais pourquoi ? Comment ?
Utilisant principalement des langages sans variables typées, ça m’est incompréhensible.
Car il est possible de caster du texte en int si besoin, qui peut le plus peut le moins.
Pourquoi ne pas utiliser que du texte plutôt que des nombres ?
Est-ce inhérent à Gladys ? à MQTT ? Ou d’autres d’éléments ?
N’est il pas possible de créer « simplement » une fonctionnalité se contentant d’afficher ce qu’on lui donne ?
Merci d’éclairer ma lanterne
Je t’ai répondu de l’autre côté 
La donnée est typé en db c’est du numérique. Donc non aujourd’hui ça n’est pas possible
OK, le typage de la DB explique la limitation.
Du coup, Gladys est UserFriendly mais pas du tout DevFriendly.
Car impossible d’afficher un message personnalisé par ex, que ce soit d’information ou d’erreur.
Pour tout texte il faut modifier le code source de Gladys, c’est ultra lourd et complexe s’il faut passer son temps à définir des constantes, car il faut les compétences, le temps de le faire, le temps de tester, pousser le tout en prod… et avoir l’accord du groupe pour chaque modification…
Donc impossible de développer son petit truc dans son coin
Ça me refroidit grave 
De mon petit point de vue de petit dev, il faudrait au choix :
Si c’est trop compliqué, ça ne motivera pas les petits dev à participer.
Enfin ce n’est que mon avis.
Merci aux personnes soutenant mon post, je me sens moins seul 
@pierre-gilles
Tu penses qu’il y aurait moyen d’avoir une solution à ce problème qui pourrait ouvrir la porte à pas mal de possibilités (de mon point de vue).
Rien n’est impossible, après pour ton cas d’aspirateur, je ne pense pas que ce soit la solution. On peut tout à fait créer un type aspirateur natif dans Gladys.
D’ailleurs, pour ton aspirateur, je ne comprend pas ce qui te bloque actuellement, quelle est la fonctionnalité qui te manque dans Gladys (Fonctionnalité au sens Gladys) ?
Peux tu me décrire fonctionnellement (sans parler technique) qu’est ce que tu veux faire avec cet aspirateur ?
Merci de ton implication
Je pense que la possibilité d’afficher du texte va bien au delà de mon utilité spécifique à cet aspirateur.
Idées :
Tout ça facilement mis en place via du MQTT par le dev et sans avoir à toucher au code source de Gladys, car :
Au final, je pense qu’il faut continuer comme vous le faites, des constantes pour des valeurs mais il faut créer une Fonctionnalité ‹ Texte › qui permettrait d’afficher le texte de son choix.
De cette façon, si c’est un texte spécifique on peut l’afficher et si c’est un texte pouvant être mis en constante, on peut l’afficher le temps que les constantes et Fonctionnalités soient créées.
Car oui, c’est plus sympa de pouvoir utiliser la bonne Fonctionnalité, avec son unité et son icône.
Pour aller plus loin, il faudrait également développer la possibilité d’utiliser une valeur texte dans le déclencheur de scène « Changement d’état de l’appareil » et « Continuer seulement si ».
Et le top serait de permettre de personnaliser l’icône (ouais je suis chiant jusqu’au bout ).
Mon point de vue, c’est qu’il faut laisser une façon simple d’afficher ce que l’on veut afin que chaque bébé dev puisse faire ses petits scripts perso de façon autonome.
Pour en revenir à mon aspirateur, voici les infos qu’il peut me donner :
États que l’on pourrait définir dans des constantes Gladys :
Valeur ‹ docked › dans le topic ‹ state:state ›.
Valeur ‹ medium › dans le topic ‹ state:fan_speed ›.
Valeur ‹ Charging › dans le topic ‹ attributes:valetudo_state.name ›.
Valeur ‹ stop › dans le topic ‹ command_status:command ›.
Valeur ‹ state › dans le topic ‹ config:schema ›.
Valeur ‹ ok › dans le topic ‹ command_status:message ›.
→ Ces valeurs peuvent être globales OK mais demanderont à gérer toutes les valeurs et à vérifier sur d’autres aspi la concordance. Les valeurs dépendraient peut être des aspirateur et des logiciels…
Message plus spécifique où dont il faudrait réussir à trouver toutes les possibilités :
Valeur ‹ No error › dans le topic ‹ attributes:last_run_stats.errorDescription ›.
→ Bien plus spécifique à mon aspi je pense.
Valeurs vraiment spécifiques à mon aspi :
Valeur ‹ rockrobo › dans le topic ‹ config:name ›.
Valeur ‹ rockrobo › dans le topic ‹ config:unique_id ›.
Valeur ‹ Roborock › dans le topic ‹ config:device.manufacturer ›.
Valeur ‹ roborock.vacuum.s5 › dans le topic ‹ config:device.model ›.
Valeur ‹ rockrobo › dans le topic ‹ config:device.name ›.
Valeur ‹ rockrobo › dans le topic ‹ config:device.identifiers ›.
Valeur ‹ 0.10.9 › dans le topic ‹ config:device.sw_version ›.
→ Ce ne sont que des textes que l’on ne peut mettre dans des constantes.
Ici il indique les topics à utiliser, donc spécifique au logiciel et à sa config :
Valeur ‹ valetudo/rockrobo/command › dans le topic ‹ config:command_topic ›.
Valeur ‹ valetudo/rockrobo/state › dans le topic ‹ config:state_topic ›.
Valeur ‹ valetudo/rockrobo/set_fan_speed › dans le topic ‹ config:set_fan_speed_topic ›.
Valeur ‹ valetudo/rockrobo/custom_command › dans le topic ‹ config:send_command_topic ›.
Valeur ‹ valetudo/rockrobo/attributes › dans le topic ‹ config:json_attributes_topic ›.
→ Ce ne sont que des textes que l’on ne peut mettre dans des constantes.
Liste des valeurs possibles de certaines commandes :
Valeur ‹ start:pause:stop:return_home:battery:status:locate:clean_spot:fan_speed:send_command › dans le topic ‹ config:supported_features ›.
Valeur ‹ min:medium:high:max:mop › dans le topic ‹ config:fan_speed_list ›.
→ Pourrait plus ou moins être mis dans Gladys mais dépend des capacités des aspirateurs.
Gestion de dates (nombre de millisecondes depuis la 01/01/1970) :
Valeur ‹ 1676655003668 › dans le topic ‹ command_status:updated ›.
Valeur ‹ 1676655000000 › dans le topic ‹ attributes:last_run_stats.startTime ›.
Valeur ‹ 1676655003000 › dans le topic ‹ attributes:last_run_stats.endTime ›.
→ Même si je calcule la date, impossible de l’afficher dans Gladys.
→ Encore une idée de Fonctionnalité à développer
Au final, ça demande du dev de votre coté alors que tout pourrait passer par une Fonctionnalité Texte.
J’apprécie réellement Gladys, son visuel, sa simplicité d’utilisation…
C’est pour ça que je suis chiant et que je me dis que ce genre de fonctionnalité générique simplifierait la vie et te permettrait de ne pas perdre de temps sur des demandes plus spécifiques (autres que les miennes qui sont bien évidemment prioritaires 
)
Conclusion : Merci à toi et vive Gladys !
cela rejoint completement la demande de fonctionnalité que j ai dejà faite depuis qq temps !
Ok @Hizo, merci pour ton retour très complet, c’est très intéressant !
Je pense qu’effectivement il y a plusieurs retours, qui peuvent être traité séparément :
Pour ce fameux type « text » dont tu parles, je ne suis pas opposé à l’idée d’avoir une façon d’envoyer des textes custom en MQTT, après est-ce que c’est lié à un device, ça je suis moins sûr ? (à voir). Typiquement, afficher des anniversaires dans la box « appareils de la pièce », ça fait sens ? Pas si sûr ^^
La philosophie du projet, c’est de proposer des appareils générique pour que justement tout l’écosystème Gladys fonctionne autour d’appareils pré-défini, générique, sans aucune adaptation de code quel que soit la marque, et même quand ça vient d’un appareil custom en MQTT.
Ainsi, on est capable:
Tout ça, sans coder !
Je comprend l’idée de faire remonter de l’information diverse et variés dans Gladys, et ça serait avec plaisir d’avoir ça, mais ça ne doit pas se substituer à des types natifs.
Tu n’es pas chiant, c’est moi qui le suit à vouloir bien faire les choses plutôt que de faire la solution de la simplicité
Au contraire, je pense que ce genre de fonctionnalité ferait perdre du temps en bout de course, car ensuite la question sera: je ne peux pas contrôler cette fonctionnalité dans les scènes ? Quid d’Alexa ? Et le chat ? etc…
Notre gestion des fonctionnalités native est assez simple à mettre en place, et fait gagner du temps à tout le monde à mon avis !
Je créerai une.
Gestion d’un type date: tu n’es pas le premier à demander, et effectivement ça fait sens. Le type date pourra être utilisé dans la category « aspirateur robot » ensuite pour avoir des features génériques « date de démarrage du dernier nettoyage/date de fin ».
Oui ça serait générique comme besoin, pas limité aux aspirateurs.
Gestion des erreurs pour les devices : Comment communiquer avec l’utilisateur quand un appareil à un souci ?
On s’est peut être pas compris, imagine des scènes qui envoient des infos sur un MQTT lors de certaines températures ou autres besoins, c’est capté par BASH (par ex) qui exécute un programme en conséquence et si celui-ci plante, on pourrait remonter l’information en MQTT dans Gladys.
Pour ce fameux type « text » dont tu parles, je ne suis pas opposé à l’idée d’avoir une façon d’envoyer des textes custom en MQTT, après est-ce que c’est lié à un device, ça je suis moins sûr ? (à voir).
Typiquement, afficher des anniversaires dans la box « appareils de la pièce », ça fait sens ? Pas si sûr ^^
En effet, cet exemple ne serait pas bien placé, il faudrait peut être proposer une boite spéciale texte ainsi qu’une fonctionnalité de texte d’appareil pour les autres exemples données que j’ai détaillé (version, nom du robot…).
Je comprend l’idée de faire remonter de l’information diverse et variés dans Gladys, et ça serait avec plaisir d’avoir ça, mais ça ne doit pas se substituer à des types natifs.
Ça serait en plus, mais un très gros plus à mon avis qui permettrait beaucoup de liberté aux petits dev qui veulent personnaliser pour eux Gladys.
Au contraire, je pense que ce genre de fonctionnalité ferait perdre du temps en bout de course, car ensuite la question sera: je ne peux pas contrôler cette fonctionnalité dans les scènes ? Quid d’Alexa ? Et le chat ? etc…
Il faut préciser que c’est du texte donc non exportable.
Par contre les scènes… ça serait cool même si j’en ai pas l’utilité pour le moment
Notre gestion des fonctionnalités native est assez simple à mettre en place, et fait gagner du temps à tout le monde à mon avis !
Y a t il un tuto là dessus ?
Pour cela on a déjà un mécanisme dans Gladys, les « device_param » !
La modélisation actuel d’un « device » dans Gladys :
(Cf: Modélisation DB | Gladys Assistant )
Pas de tutoriel non, je suis d’accord que ça mériterait d’être un peu mieux documenté
Pour cela on a déjà un mécanisme dans Gladys, les « device_param » !
Et du coup, comment on l’utilise sans passer par la base de données ?
D’ailleurs, celle-ci est elle accessible ?
La doc est super importante si les gens doivent proposer des modifications.
Par ex, je regardais l’API REST et aucun moment ça ne parle de clé.
Il semble que ce ne soit disponible que pour Gladys Plus mais ce n’est pas indiqué dans la doc.
