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 :
- Modifier le type de la DB (avec tous les problèmes que ça peut apporter, donc beurk).
- Créer une autre table spécifique au texte qui serait utilisée uniquement par une nouvelle fonctionnalité d’appareil.
- Pouvoir définir de nouvelles constantes via un fichier externe ne nécessitant pas de modifier le code source de Gladys.
Si c’est trop compliqué, ça ne motivera pas les petits dev à participer.
Enfin ce n’est que mon avis.
2 « J'aime »
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).
1 « J'aime »
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 :
- Bloc « Anniversaires du jour » qui indiquerait le nom des gens à qui le fêter.
- Bloc « Message perso » qui changerait en fonction des besoin.
- Bloc « Maxime du jour » (perso ma console m’affiche toujours une petite pensée de Chuck Norris, là c’est « Chuck Norris peut détruire le vide »).
- Bloc « Dernier SMS » qui afficherait le dernier SMS reçu.
- Bloc « Message d’erreur » d’une commande spécifique (comme wakeonlan ou autre commande régulièrement exécutée depuis le Raspberry). Impossible de liste toutes les erreurs de toutes les commandes et on perdrait la possibilité de préciser une erreur ou d’afficher un texte personnalisé.
- …
Tout ça facilement mis en place via du MQTT par le dev et sans avoir à toucher au code source de Gladys, car :
- C’est compliqué.
- Nous sommes dépendant de vous.
- Il vous faut du temps.
- C’est bloquant le temps que ce soit développé.
- Ça ne fait pas sens de développer des besoins perso dans Gladys.
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 !
1 « J'aime »
cela rejoint completement la demande de fonctionnalité que j ai dejà faite depuis qq temps !
1 « J'aime »
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 :
- Ajouter un ensemble de fonctionnalités liés aux aspirateurs robots : Il y a un petit travail pour se renseigner un peu sur le marché, et proposer des constantes qui soient « générique » et pas lié à une marque d’aspirateur en particulier. Peux-être que tu pourrais créer (si elle n’existe pas déjà) une demande de fonctionnalité pour qu’on discuter du sujet avec d’autres utilisateurs d’aspirateurs robots ?
- 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 ».
- Gestion des erreurs pour les devices : Comment communiquer avec l’utilisateur quand un appareil à un souci ?
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:
- Dans les scènes, d’avoir des scènes complètement générique, indépendante de la marque et du fonctionnement en bout de chaine.
- Contrôle via Google Home / Alexa, même d’appareils maisons
- Contrôle dans le chat Gladys
- etc…
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.
1 « J'aime »
Pas de tutoriel non, je suis d’accord que ça mériterait d’être un peu mieux documenté
La doc est super importante si les gens doivent proposer des modifications.
C’est une vraie nécessité (même si il y a déjà une base écrite et vidéo), il faudrait une doc écrite sur la structure générale de Gladys tant frontend que background (répertoire, fichiers de config, interaction) même succincte au départ et qui puisse être étoffée de la même manière que pour le matériel compatible. Pour quelqu’un qui arrives sur le projet et qui voudrait aider au niveau développement c’est un peu compliqué d’avoir une vue d’ensemble, voir par ou commencer, sur un projet open-source la communauté est la première force pour aider au développement tant en terme de logiciel que de déploiement ! 
Je parles de doc sur la partie Gladys, celle qui est nécessaire pour développer des intégrations ou améliorer le frontend, elle est pas nécessaire à mon sens pour la partie Gladys Plus.
2 « J'aime »
on en revient à la demande de fonctionnalité que j ai faite il y a qq temps pour integrer des data de type text ou datetime dans les fonctionnalités des devices, notamment pour les fake device avec le couple mqtt-nodered.
on en parle beaucoup là, mais peu dans ma demande de fonctionnalité
?Permettre la recuperation de data de type text ou alpha!
1 « J'aime »
@Einstein8854 Je soutiens ta demande avec force
Ajoute un lien vers ce sujet sur le tien, comme ça on retrouvera toutes les informations.
Je me permets de te relancer pour en savoir plus sur ce sujet, comment l’utiliser ?
J’attends plus que la prise en compte des textes pour prendre Gladys Plus 
Salut @Hizo !
Désolé de ma réponse tardive, j’étais en congés
Les device_params ne sont pas accessible dans l’intégration MQTT.
Bonne reprise !!
2 « J'aime »
Il était temps !!! 
Tu va pouvoir ranger la crème à bronzer ! 
Depuis le début de tes vacances Il y a quand même eu 53 nervous break down 
et 12 appels à disparition lancés !!! 
Plus sérieusement, j’espère qu’elle ont été profitables et que t’es revenu avec plein de pêches et d’idées pour Gladys ! Et comme dis un copain coté santé il faut toujours être aux p’tits soins car « Qui veux aller loin ménage sa monture ! » 
1 « J'aime »
@pierre-gilles
Mince, bon bah reste plus qu’à attendre que la demande de fonctionnalité Permettre la recuperation de data de type text ou alpha! soit réalisée…
Bon retour et bon courage
1 « J'aime »
@Hizo Tu as quand même pu connecter ton aspirateur à Gladys ? Au moins pour les fonctionnalités « simples » (start/stop), car c’est déjà possible ^^
Et est-ce qu’il y a bien une demande de fonctionnalité pour ajouter un type « aspirateur robot » dans Gladys ?