Page 1 of 1
Why different handling from number than text type
Posted: Saturday 06 December 2025 16:17
by akamming
Hi,
I was just wondering:
- Input sensors of the type number are show in domoticz in configuration of the hardware (meaning, you can see and change them if you go to the hardware page and press settings button on the MQTT AD Hardware line
- Input sensors of the type text are shown are treated as "normal" devices, but you can change them using the update button on the sensor.
They are basically the same, the only difference is that one is used for sending text, the other for numbers. So shouldn't they be treated the same in domoticz (so either move the text devices also to the settings page of mqtt ad hardware, or move the numbers to "normal" devices in domoticz, but do add the functionality to change them with a "update" button)
Does anyone know why they are treated differently?
EDIT: Just to be specific: I mean devices/settings which are in MQTT under "homeassistant/number/xxxx" and "homeassistant/text/xxxx" .... Number of text devices which just display text or numbers are under "homeassistant/sensor", so i'm not talking about those.
Re: Why different handling from number than text type
Posted: Sunday 07 December 2025 1:57
by waltervl
Do you have an example how that works? Sending a text message to a device over mqtt to change the setting?
Re: Why different handling from number than text type
Posted: Sunday 07 December 2025 11:37
by akamming
It works exactly the same as for a number device, this is an example of the discovery message:
Code: Select all
{"name":"MQTTTemperatureTopic","unique_id":"domesphelper_MQTTTemperatureTopic","stat_t":"domesphelper/text/MQTTTemperatureTopic/state","cmd_t":"domesphelper/text/MQTTTemperatureTopic/set","availability_topic":"domesphelper/status","dev":{"ids":"E8DB8498C1DF","name":"domesphelper","sw":"domesphelper_Dec 6 2025_22:33:33","mdl":"d1_mini","mf":"espressif","cu":"http://my_ip_adress/"}}
you can send a text message publishing it on the command topic (cmd_t in the discovery json)
This is already implemented in domoticz (by gizmocuz, I was just wondering wondering why it the text device is implemented differently than the number. I think it makes sense to treat them the same (with my personal preference that for number mqtt devices, also domoticz devices with an update button are created as well)
But maybe there's a reason this is different, so i am curious what would that reason is.
Re: Why different handling from number than text type
Posted: Sunday 07 December 2025 13:28
by waltervl
I mean what would be the use case to send a text to the device? For a number this normally is a setting, eg range, , polling interval etc These setting devices should not end up as Domoticz devices in your user interface. That is why gizmocuz set it differently than the other MQTT AD devices.
But what use is there to send a text to for example a zigbee or zwavejs device?
Re: Why different handling from number than text type
Posted: Sunday 07 December 2025 14:17
by akamming
waltervl wrote: Sunday 07 December 2025 13:28
I mean what would be the use case to send a text to the device? For a number this normally is a setting, eg range, , polling interval etc These setting devices should not end up as Domoticz devices in your user interface. That is why gizmocuz set it differently than the other MQTT AD devices.
But what use is there to send a text to for example a zigbee or zwavejs device?
I don’t think there is a use case for zigbee or zwave. But mqtt ad is used much broader. Text is a device are described Here:
https://www.home-assistant.io/integrations/text.mqtt/
And it works quite well in domoticz.
So i don’t have a problem with it, it’s just that the use case is also Configuration, so wondering why the Implementation is different…
Re: Why different handling from number than text type
Posted: Sunday 07 December 2025 21:04
by waltervl
Still you dont give an example how sending a text could be configuration.
Re: Why different handling from number than text type
Posted: Sunday 07 December 2025 22:57
by akamming
The discovery message above is one i’m using, so a good example of a text configuration
Re: Why different handling from number than text type
Posted: Monday 08 December 2025 0:13
by waltervl
So you want to set a state with a text?
stat_t":"domesphelper/text/MQTTTemperatureTopic/state"
I still do not understand why you would like to do it this way? Did you look how zigbee2mqtt and zwave deal with this state topics that hold text (like auto, heating, cooling, dry)?
Re: Why different handling from number than text type
Posted: Monday 08 December 2025 11:23
by akamming
waltervl wrote: Monday 08 December 2025 0:13
So you want to set a state with a text?
stat_t":"domesphelper/text/MQTTTemperatureTopic/state"
I still do not understand why you would like to do it this way? Did you look how zigbee2mqtt and zwave deal with this state topics that hold text (like auto, heating, cooling, dry)?
auto/heating/cooling etc.. indicates a climate or select device, see sample discovery messages:
for climate
Code: Select all
{"min_temp":5,"max_temp":30,"name":"Climate","unique_id":"domesphelper_Climate","temp_cmd_t":"domesphelper/climate/Climate/cmd_temp","temp_stat_t":"domesphelper/climate/Climate/state","temp_stat_tpl":"{{value_json.seltemp}}","temp_step":0.5,"temp_unit":"C","precision":0.1,"curr_temp_t":"domesphelper/climate/Climate/Air_temperature","curr_temp_tpl":"{{ value_json.value }}","modes":["off","heat","cool","auto"],"mode_stat_t":"domesphelper/climate/Climate/mode","mode_cmd_t":"domesphelper/climate/Climate/mode/set","mode_stat_tpl":"{{ {0: \"off\", 1: \"heat\", 11: \"cool\", 21: \"auto\"}[value_json.value] | default('off') }}","availability_topic":"domesphelper/status","dev":{"ids":"E8DB8498C1DF","name":"domesphelper","sw":"domesphelper_Dec 6 2025_22:33:33","mdl":"d1_mini","mf":"espressif","cu":"http://IP_ADRESS/"}}
for select
Code: Select all
{"name":"Curvature","unique_id":"domesphelper_Curvature","stat_t":"domesphelper/select/Curvature/state","cmd_t":"domesphelper/select/Curvature/set","platform":"select","val_tpl":"{{ value_json.curvature }}","options":["none","small","medium","large","extralarge"],"availability_topic":"domesphelper/status","dev":{"ids":"E8DB8498C1DF","name":"domesphelper","sw":"domesphelper_Dec 6 2025_22:33:33","mdl":"d1_mini","mf":"espressif","cu":"http://IP_ADRESS/"}}
These work also fine in domoticz but cannot be used for free texts....
For text there are several use cases (always in the case you have no preselected texts):
- The above example sets a MQTT topic used by the device (so a configuration case). It is free text, so you cannot use select or climate
- But an esphome ledpanel with texts also uses this text device for showing texts on your ledpanel
- probably more use cases, but these two i'm aware of..
Re: Why different handling from number than text type
Posted: Monday 08 December 2025 17:27
by waltervl
If you want to steer the text of a led display on a esphome device then you have to make a text device in Domoticz too and not a settings device like the number device.
And to use free text to configure something seems strange. I cannot think of a proper example.
So to come back to the original question: MQTT AD Number devices are treated differently because they are used incidentally to configure a connected hardware device/sensor (zigbee, zwave, esphome etc). For MQTT AD text devices they are not considered as setting devices and therefore a Domoticz device is created.
Re: Why different handling from number than text type
Posted: Monday 08 December 2025 18:57
by waltervl
Additional, If you want to use predefined texts for sending state texts to an ESPHOME device you can also use the MQTT AD select type
https://www.home-assistant.io/integrations/select.mqtt/
It is supported in Domoticz MQTT Autodiscover
https://github.com/domoticz/domoticz/bl ... .cpp#L1966