Hello,
I probably searched poorly, I would like to send text to a feature of a device, is that possible?
Several examples :
How should we go about it?
Thanks
That’s not possible at the moment but there is a request you can vote for.
Current solution… Use Node-RED to convert!
OK, I just voted, but there are only 2 of us 
I don’t know Node-RED at all, I use bash and Mosquitto for MQTT exchanges.
Thanks
@pierre-gilles made an excellent video about Node-RED:
There is also an MQTT API…
You can then directly ‹ listen › to your button’s topic on the relevant device
I’ll have to take a look but that means only Node-RED becomes usable for managing MQTT, Python and Bash are therefore no longer really compatible…
I just spent several days on this trying to understand and get the system working in Bash…
EDIT : Is the problem the same for dates?
So, I looked at the two links but nowhere is sending text or anything mentioned…
When I try to send something, the device’s value doesn’t update…
whether via mosquitto or via node-red.
Can someone enlighten me please?
Did you see this tutorial @Hizo?
I imagine you’ve solved your problem by now, judging from your tutorial?
Yes, luckily there’s documentation 
I had a bit of trouble understanding everything but now it’s fine.
However, my problem remains…
How to send text and display it in Gladys?
Sending is no problem with MQTT, it goes out fine.
But it’s impossible to display the text in Gladys.
Do you have to use a specific Device Feature that accepts text?
I’m not hiding that right now it’s frustrating me to finish my TUTORIAL on Vacuum <=> BASH <=> GLADYS
It’s the only blocking thing.
I tested in BASH and with Node-RED
It is not possible for @
Well… I don’t know what to think…
An information display system that can’t display text? 
I don’t know how Gladys works but why? How?
Using mainly languages without typed variables, this is incomprehensible to me.
Because it’s possible to cast text to int if needed; if something can do more, it can do less.
Why not just use text rather than numbers?
Is it inherent to Gladys? to MQTT? Or to other elements?
Isn’t it possible to create a « simple » feature that just displays what you give it?
Thanks for shedding some light on this
I replied to you in the other thread 
The data is
OK, the DB typing explains the limitation.
So, Gladys is user-friendly but not at all developer-friendly.
Because it’s impossible to display a custom message, for example, whether it’s informational or an error.
For any text you have to modify Gladys’s source code, it’s extremely heavy and complex if you have to spend your time defining constants, because you need the skills, the time to do it, the time to test, push everything to production… and get the group’s approval for each change…
So it’s impossible to develop your little thing on your own
That really puts me off 
From my point of view as a small developer, the choices should be:
If it’s too complicated, it won’t motivate the small developers to participate.
Anyway, it’s just my opinion.
Thanks to the people supporting my post, I feel less alone 
@pierre-gilles
Do you think there might be a way to find a solution to this problem that could open the door to quite a few possibilities (from my point of view).
Nothing is impossible; that said, regarding your vacuum, I don’t think that’s the solution. We can quite easily create a native vacuum type in Gladys.
Also, regarding your vacuum, I don’t understand what is currently blocking you — what functionality are you missing in Gladys (functionality in the Gladys sense)?
Can you describe, functionally (without speaking technically), what you want to do with this vacuum?
Thanks for your involvement
I think the ability to display text goes far beyond my specific use case for this vacuum.
Ideas :
All of this easily set up via MQTT by the dev and without having to touch Gladys’s source code, because :
In the end, I think you should continue as you’re doing, constants for values, but you should create a Feature « Text » that would allow displaying the text of your choice.
That way, if it’s a specific text you can display it, and if it’s a text that can be turned into a constant, you can display it until the constants and Features are created.
Because yes, it’s nicer to be able to use the proper Feature, with its unit and icon.
To go further, it would also be necessary to develop the ability to use a text value in the scene trigger « Device state change » and « Continue only if ».
And the best would be to allow customizing the icon (yeah I’m annoying to the end ).
My point of view is that you should leave a simple way to display whatever you want so that every junior dev can make their little personal scripts autonomously.
Back to my vacuum, here is the information it can give me :
States that could be defined in Gladys constants :
Value ‹ docked › in the topic ‹ state:state ›.
Value ‹ medium › in the topic ‹ state:fan_speed ›.
Value ‹ Charging › in the topic ‹ attributes:valetudo_state.name ›.
Value ‹ stop › in the topic ‹ command_status:command ›.
Value ‹ state › in the topic ‹ config:schema ›.
Value ‹ ok › in the topic ‹ command_status:message ›.
→ These values can be globally OK but would require handling all values and checking on other vacuums for consistency. The values might depend on the vacuums and the software…
More specific message where you’d have to find all possible values :
Value ‹ No error › in the topic ‹ attributes:last_run_stats.errorDescription ›.
→ Much more specific to my vacuum I think.
Values really specific to my vacuum :
Value ‹ rockrobo › in the topic ‹ config:name ›.
Value ‹ rockrobo › in the topic ‹ config:unique_id ›.
Value ‹ Roborock › in the topic ‹ config:device.manufacturer ›.
Value ‹ roborock.vacuum.s5 › in the topic ‹ config:device.model ›.
Value ‹ rockrobo › in the topic ‹ config:device.name ›.
Value ‹ rockrobo › in the topic ‹ config:device.identifiers ›.
Value ‹ 0.10.9 › in the topic ‹ config:device.sw_version ›.
→ These are just texts that cannot be put into constants.
Here it shows the topics to use, so specific to the software and its config :
Value ‹ valetudo/rockrobo/command › in the topic ‹ config:command_topic ›.
Value ‹ valetudo/rockrobo/state › in the topic ‹ config:state_topic ›.
Value ‹ valetudo/rockrobo/set_fan_speed › in the topic ‹ config:set_fan_speed_topic ›.
Value ‹ valetudo/rockrobo/custom_command › in the topic ‹ config:send_command_topic ›.
Value ‹ valetudo/rockrobo/attributes › in the topic ‹ config:json_attributes_topic ›.
→ These are just texts that cannot be put into constants.
List of possible values for certain commands :
Value ‹ start:pause:stop:return_home:battery:status:locate:clean_spot:fan_speed:send_command › in the topic ‹ config:supported_features ›.
Value ‹ min:medium:high:max:mop › in the topic ‹ config:fan_speed_list ›.
→ Could more or less be put into Gladys but depends on the capabilities of the vacuums.
Date handling (number of milliseconds since 01/01/1970) :
Value ‹ 1676655003668 › in the topic ‹ command_status:updated ›.
Value ‹ 1676655000000 › in the topic ‹ attributes:last_run_stats.startTime ›.
Value ‹ 1676655003000 › in the topic ‹ attributes:last_run_stats.endTime ›.
→ Even if I calculate the date, it’s impossible to display it in Gladys.
→ Yet another Feature idea to develop
In the end, this requires development on your side while everything could go through a Text Feature.
I really appreciate Gladys, its visuals, its ease of use…
That’s why I’m being picky and I think this kind of generic feature would simplify life and allow you not to waste time on more specific requests (other than mine, which are of course a priority 
)
Conclusion : Thank you and long live Gladys !
This completely matches the feature request I already made some time ago!
Ok @Hizo, thanks for your very thorough feedback, it’s very interesting!
I think there are indeed several pieces of feedback that can be addressed separately:
About that « text » type you mentioned, I’m not opposed to the idea of having a way to send custom texts over MQTT, but whether that’s linked to a device, I’m less sure (to be seen). For example, displaying birthdays in the room « devices » box — does that make sense? Not so sure ^^
The project’s philosophy is to offer generic devices so that the whole Gladys ecosystem works around predefined, generic devices without any code adaptation whatever the brand, and even when it comes from a custom device over MQTT.
Thus, we are able to:
All that, without coding!
I understand the idea of surfacing diverse and varied information in Gladys, and we’d be happy to have that, but it must not replace native types.
You’re not annoying, I’m the one who’s annoying in wanting to do things properly rather than taking the easy solution
On the contrary, I think this kind of functionality would end up wasting time, because then the question will be: I can’t control this functionality in scenes? What about Alexa? And the chat? etc…
Our native feature management is quite simple to set up, and in my opinion saves everyone time!
Je créerai une.
Managing a date type: you’re not the first to ask, and indeed it makes sense. The date type could then be used in the ‹ robot vacuum › category to have generic features like ‹ start date of the last cleaning/end date ›.
Yes that would be a generic need, not limited to vacuums.
Error handling for devices: How to communicate with the user when a device has an issue?
Maybe we didn’t understand each other, imagine scenes that send info over MQTT when certain temperatures or other needs occur, it’s picked up by BASH (for example) which executes a program accordingly and if that crashes, we could report the information over MQTT into Gladys.
About that so-called ‹ text › type you mention, I’m not opposed to the idea of having a way to send custom texts over MQTT, but whether it’s linked to a device, I’m less sure? (to be seen).
Typically, displaying birthdays in the ‹ room devices › box, does that make sense? Not so sure ^^
Indeed, that example wouldn’t be well placed, maybe we should propose a special text box as well as a device text feature for the other examples I detailed (version, robot name…).
I understand the idea of surfacing various information in Gladys, and I’d be happy to have that, but it should not replace native types.
It would be in addition, but a very big plus in my opinion that would allow a lot of freedom for small developers who want to customize Gladys for themselves.
On the contrary, I think this kind of feature would waste time in the long run, because then the question will be: I can’t control this feature in the scenes? What about Alexa? And the chat? etc…
We need to specify that it’s text so not exportable.
As for scenes… that would be cool even though I don’t need it at the moment
Our management of native features is pretty simple to implement, and saves everyone time in my opinion!
Is there a tutorial on that?
[quote="Hizo, post:18,
For that we already have a mechanism in Gladys, the « device_param »!
And so, how do we use it without going through the database?
By the way, is it accessible?
The documentation is super important if people need to propose changes.
For example, I was looking at the REST API and at no point does it mention an API key.
It seems that this is only available for Gladys Plus but this is not indicated in the documentation.