Add option to force update text input

Feature Requests
1

If you try to update a text with the same text, it wont get updated and thus wont get sent as a command through MQTT. Tuya zigbee infrared devices listen for text input with the infrared code to send. If you have a command like “increase fan speed” that will get executed many times in a row, it won’t work, it only update the first time due to this problem, as listed here How to send 2 identical IR commands on a tuya IR device

Therefore something like this:


id: "1739970022811"
name: ar 25 portatil
entities:
  text.ir_branco_3v_escritorio_ir_code_to_send:
    mode: text
    min: 0
    max: 255
    pattern: null
    assumed_state: true
    friendly_name: ir 1 Ir code to send
    state: CW8MnCUAAvwFAALgAwHgDw/gBxfgHwHANwf8BQACAAIAAg==
metadata: {}

should have an option like: force_update: true

2

That sounds more like an issue with Zigbee2MQTT’s handling of the device… which is outside the scope of Home Assistant Feature Requests.

Are you sure the integration has not provided a dedicated action you can use to send the command rather than using the text entity?

Could you just use the mqtt.publish action?

3

I just tested the mqtt.publish function and it works, I was able to send repeated commands, so the problem is indeed in home assistant

4

related: Make entity text input be larger than 255 (otherwise you cant use tuya IR blasters)

5

How did you come to that conclusion?

From everything you have described Home Assistant is behaving as intended… text entities are not supposed to reset themselves unless the user or underlying integration (Zigbee2MQTT in this case) tells them to. If you want the value to reset after every input, you can automate it as discussed before… otherwise you need to open a Feature Request with Zigbee2MQTT.

All entity states are strings and they are limited to 255 characters. The input for a text entity is stored as its state… this is not going to happen any time soon, if ever.

6

What exactly do you mean by “get updated”?

If you write a value to a text entity that already contains the exact same value, effectively nothing has changed. The text entity’s value is unchanged so there’s no state-change to serve as a trigger.

This behavior applies to many other entities. For example, if you turn on an Input Boolean that’s already on, there’s no state-change so there’s no signal indicating anything happened.

7

yes, and that is the problem. zigbee2mqtt exposes the text entity for tuya IR blasters. Through the MQTT integration, when I set that text, it only gets published if the text changed.

So if I try to send a command like “increase volume” it will only go the first time.

I confirmed that if I do mqtt.publish the text for a volume increase it goes twice or more, so the problem looks like it is because of this text that only gets updated if it changes, so if it had a force update, it would work.

I wonder how people use zigbee tuya infrared blasters. Hasn’t nobody ever complained about this? I tested 3 really popular IR tuya zigbee blasters and they all have this same problem.

8

I use a Tuya ZS06 to control a range hood fan. Even though all the IR codes are shorter than 255 characters, I use mqtt.publish, not the device’s text entity.

You can try calling the homeassistant.update_entity action on the text entity but I have my doubts it will work. It’s normally used to refresh an entity’s state value from its underlying integration.

Like I said, the behavior you’re seeing applies for all entities, not just text. If you write a value to an entity that already has that same value, there’s no state-change to signal that something happened.

Zigbee2MQTT modeled the ZS06 with a text entity for transmitting IR codes. It’s there for convenience but with all the entity limitations mentioned above. For ultimate control, publish the IR code to the device’s MQTT topic.

1 Like