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.
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.
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.
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 ‘/’.
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.