I already mentioned it in several post comments but without creating a proper thread and without much attention.
So far in Gladys, when a device is connected to Gladys (notably via MQTT or Zigbee2MQTT, but this should be true for other integration methods), the retrieved and displayed data are of numeric type (integer or float…) occasionally associated with a unit!
My request would be that, notably for the MQTT « fake feature » coming from external manipulations (Node-RED processing, for example), one or more features be able to retrieve and display data of type text, char…
This functionality could be the existing « unknown » feature which could be enriched with characteristics (for example: neutralize the requirement for min and max value, but other options are conceivable…)
This should be doable since currently for some features you can attach text via the unit.
Some object processing via Node-RED typically returns text data (e.g. info from telehealth devices: heart monitoring, weight, pre-diagnosis, …)
But there can be other devices (weather station, feedback from PLC/robot…)
30/1: I am adding to this request the possibility to also retrieve data in date and/or time format
I worked this afternoon on this topic because I think it can bring a lot to Gladys, mainly for an advanced user who is in Node-RED mode and who may want to display on their dashboard information retrieved from Node-RED
What I propose is, in the MQTT integration, a new feature type « Text »:
I should point out that this feature is really interesting in the context of the MQTT integration, for advanced use.
I don’t think it would be desirable to use this feature in other integrations outside MQTT; the idea is not to use sensors as a way to store information that has no link to data collection (error messages, etc…).
The « last_value_string » attribute on « device_feature » has existed in Gladys for a long time, it’s not new It’s currently used by the camera integration!
[quote=« pierre-gilles, post:8, topic:7864 »]
The only thing to keep in mind is that these values are not stored historically, only the last value is kept (unlike numeric values)
hello @pierre-gilles,
great that you were able to make some progress on this text data issue because quite a few devices send or may send text.
thanks again!
however, regarding the lack of history storage I remain perplexed and skeptical.
to me this can be useful.
one example, though not the only one:
local weather station from which we retrieve the data via Node-RED as you explained;
the wind vane returns text-type data (N, S, SE, …), instant display is fine, no problem, but for example if we want to make a graph to visualize changes in wind direction over a day, 7 days… without storing history it’s not possible.
so a nice advancement that I’m eager to see in production, but there are still potentially other developments to integrate on this topic in my opinion.
)