Mqtt switch value_template

So I’ve got a mqtt switch, to turn a screen on/off.
if I publish on or off the message via mqtt it works perfectly!

I’ve added this configuration to to HA:

- platform: mqtt
  name: "Tnix Screen"
  state_topic: "tablet/tnix/screenresult"
  command_topic: "tablet/tnix/screen"
  # availability_topic: "tablet/tnix/heartbeat"
  value_template: '{{ value == "true" }}'
  payload_on: "on"
  payload_off: "off"
  # optimistic: false
  qos: 0
  retain: true

But the switch in the UI always turns off, regardless of the last on or off command.

The documentation for value_template says “Defines a template to extract a value from the payload”, which topic is it extracting this value from; the state_topic or the command_topic?

Right now I’ve got the “tablet/tnix/screenresult” message reporting “true” when the screen is “on” and “false” when the screen is “off”. It’s just calling a shell script, so I can change this output to be whatever.

What am I doing wrong here?

The value_template is for extracting the state from a complex state message. But if your state message just has on and off you don’t need it at all. Just delete the line.

I’ve deleted it, and the switch still defaults to off, regardless of state. Here’s what I’ve got:

- platform: mqtt
  name: "Tnix Screen"
  state_topic: "tablet/tnix/screenresult"
  command_topic: "tablet/tnix/screen"
  # availability_topic: "tablet/tnix/heartbeat"
  # value_template: '{{ value == "true" }}'
  payload_on: "on"
  payload_off: "off"
  # optimistic: false
  qos: 0
  retain: true

You mean it is always off, or is always off when HA starts up?

Does changing the switch on HA work?

If you could paste a copy of the messages being sent, it would also help.

The switch on the UI starts in the “off” position on HA start. If I turn the switch to the “on” position in the UI then “on” gets sent to “tablet/tnix/screen” and the screen on the physical device turns “on”. Then the switch in the HA UI immediately turns “off”, but no MQTT message is sent, and the screen on the physical device remains “on”.

In other words, the switch in the UI works to turn on/off the screen on the physical device. But the current state of the screen, on the physical device, is never reflected in the HA UI. This is where the problem lies.

The message being sent to “tablet/tnix/screen” is “on”/“off” respectively, as illustrated in the component above.
The message being sent from “tablet/tnix/screenresult” is “on”/“off” after the above command is received and the OS command to turn the physical screen on/off is run. This is simply a shell script, so it can be changed to report any value to the topic, if needed.

Hopefully all that makes sense; let me know if more clarification is needed.

I don’t understand mqtt, but I’m trying (slowly) to get my head around it and have read a few threads about it on the journey.

One thing I have picked up is that retain: doesn’t work on the bundled mqtt broker, so if you’re using that you might consider using mosquitto or another alternative.

Apologies if this post is completely irrelevant. :joy:

This is what HA does when it does not receive the status message from the device indicating that the device has turned on. So the problem is certainly with decoding the status message.

What you describe seems correct, and I can only suggest that you dump the output of a capture program like mqtt_sub to ensure that what you think is being sent in the status message actually matches reality.

If that is the case, you can then turn on debugging for the mqtt component, to see what is happening when HA receives the message.

Thanks, I’ll probably have to take the debugging route as I’ve already verified the “tabled/tnix/screenresult” message == “on”/“off”, I’ll post the output here later today.

Since I can change the response that’s being published to tablet/tnix/screenresult, when the command is executed, is there something I should change it to, that would cause this to work? Idk, 1/0, on/off, true/false, foo/bar? What is HA expecting to see?

Also, I know for a fact that MQTT is working within HA, as I’ve had 3x temp/humidity sensors running for years, without any issue.

It is expecting to see a message with a topic of tablet/tnix/screenresult and a payload of on or ‘off’. You can change the message if you like, but you still have to match it with these parameters.

Normally, the problem is a mismatch of case or missing ‘/’.

Here’s the direct output.
(both publish commands turn the screen on/off)
publish on:
mosquitto_pub -h jabba -m on -t tablet/tnix/screen

publish off:
mosquitto_pub -h jabba -m off -t tablet/tnix/screen

result:

strex@droid:~$ mosquitto_sub -h jabba -t tablet/tnix/screenresult
on

off

That all looks fine.

One thing that has reportedly worked in the past is to remove the quotes from the payload lines -so

payload_on: on
payload_off: off

It shouldn’t make any difference, but I don’t have them and as I say, some people have said that it did.

If that doesn’t help, I suggest you enable logging for mqtt on HA and go in to more depth about what HA is doing with the message

logger:
  default: warning
 logs:
      homeassistant.components.mqtt: debug

Thanks @gpbenton I’ll get this implemented tonight, and report back.

@xstrex have you been successful? Got the same problem right now

No I did not figure it out, I went a different route entirely.

I think your issue might because optimistic mode is false when you have a state topic. This causes the mqtt switch to wait for a state confirmation from the device. Your device is not sending a state confirmation, so the mqtt switch sits at off. Try setting optimistic mode to true, this will cause the mqtt switch to toggle each time you change the state.

So, this topic is ancient, but in case anyone else stumbles on it, I figured I would post the “fix”

When I put the mqtt component into debug mode, I noticed that the received “on” of “off” message looked like:

on

off

(notice the \n’s)

So, as a work-around, I’ve added the following, and it worked:

state_on: "on\n"
state_off: "off\n"

Not the best way of handling this, but it works!!

1 Like