You can also use these two things to do it from the HA frontend: https://gist.github.com/techwithjake/e3907228be08c217de3ce350d774a384
It’s what I use.
4 Likes
you can run a mosquitto client from anywhere…or just an MQTT client of some sort that lets you send flags
1 Like
I think you can publish a new message to your Mosquito from either the Hass.IO front-end (using the MQTT developer tool - next to last icon from the right at the bottom of the left hand side panel).
Alternatively, there is a Chrome add-on called MQTTLens that you can use to login to your broker and subscribe or publish to a MQTT topic.
Hope this helps
Did they finally fix that add-on?
It was my favorite, and a Chrome update broke it, and they refused to fix it for over a year
Also remember you need to send an empty payload that has the retain flag set also.
So, IOW, you need to send a retained empty payload.
With Hassio, the easy way is to remove the addon and then add it back again - this deletes the persistence database.
There is a video kicking around that has an excellent walk through of fixing these screwups with retention as well. https://youtu.be/31IyfM1gygo
Effectively, that guy recommends Make sure you have set the retain: false in home assistant configuration (not a command! just make sure you do this and then restart the home assistant server) and then sending these commands to the sonoff in the console:
switchretain off
buttonretain on
buttonretain off
poweronstate 3
powerretain on
I also have this automation that clears stuff out every time HA restarts:
- id: '1532478833428'
alias: "Power State Sonoff on HA Start-Up"
initial_state: 'on'
trigger:
platform: homeassistant
event: start
action:
- service: mqtt.publish
data:
topic: "cmnd/sonoffs/power1"
payload: ""
- service: mqtt.publish
data:
topic: "cmnd/sonoffs/power2"
payload: ""
- service: mqtt.publish
data:
topic: "cmnd/sonoffs/Power3"
payload: ""
- service: mqtt.publish
data:
topic: "cmnd/sonoffs/power4"
payload: ""
So all my switches behave now… I’m not sure the automation is even needed…
2 Likes
Did this, based on your recommendation @DavidFW1960 and I only got it working with the automation.
1 Like
Thanks for that. I’m not sure that the automation needs to be perpetual though - might only need to be run once… dunno.
Are you using MQTT discovery? If you aren’t then maybe you need to have retain: false in the switch config. I believe it uses the Tasmota settings when you use discovery.
Don’t have time to try and reboot today but I’ll definitely will give it a try without the startup automation.
I am using discovery, so we’ll see.
Just out of curiosity, how were you doing this? Was retain=true in effect?
Thanks to everyone for their responses, I must admit I didn’t expect this to become such a useful thread.
@DavidFW1960, yes I have seen that video and I have sent all those commands for my Sonoffs but I had some old Owntracks retained messages that I wanted to clear out.
Interestingly last night while I was messing around with this I restarted the Mosquitto add-on a few times while my Sonoff controlled lights were on and at some point they turned off. I must still have something not quite right 
Maybe I will try removing Mosquitto and re-adding it so I can start from scratch…
@123 First time I tried using the hassio MQTT Developer Tools page but I wasn’t setting the retain flag, partly because I didn’t think of it (doh!) but partly and perhaps because, I couldn’t see how to set it on that page.
Second time I tried using MQTT.fx but again I didn’t set the retain flag, this time entirely because I didn’t think of it.
It’s funny how sometimes some very small gaps in knowledge can lead to big misunderstandings. Thanks again for all the pointers.
if you shell into the hassio instance you can enter these commands and hit enter… 
example:
mosquitto_pub -h IP-ADDRESS -p 1883 -u USERNAME -P PASSWORD -t “homeassistant/sensor/tradfri_motion_sensor_3_battery/state” -r -n
of course the topic can be any topic, and any level in that topic you need, or use # to delete all topics retained
You mean SSH will accept these commands??
I never knew that either. I thought it would only take a very few commands which were specific to HA e.g. shutting down or restarting.
But then I have very rarely had the need to use SSH.
Thanks for that info!
o yes:
core-ssh:~# mosquitto_pub --help
mosquitto_pub is a simple mqtt client that will publish a message on a single topic and exit.
mosquitto_pub version 1.4.15 running on libmosquitto 1.4.15.
Usage: mosquitto_pub [-h host] [-k keepalive] [-p port] [-q qos] [-r] {-f file | -l | -n | -m message} -t topic
[-A bind_address] [-S]
[-i id] [-I id_prefix]
[-d] [--quiet]
[-M max_inflight]
[-u username [-P password]]
[--will-topic [--will-payload payload] [--will-qos qos] [--will-retain]]
[{--cafile file | --capath dir} [--cert file] [--key file]
[--ciphers ciphers] [--insecure]]
[--proxy socks-url]
mosquitto_pub --help
-A : bind the outgoing socket to this host/ip address. Use to control which interface
the client communicates over.
-d : enable debug messages.
-f : send the contents of a file as the message.
-h : mqtt host to connect to. Defaults to localhost.
-i : id to use for this client. Defaults to mosquitto_pub_ appended with the process id.
-I : define the client id as id_prefix appended with the process id. Useful for when the
broker is using the clientid_prefixes option.
-k : keep alive in seconds for this client. Defaults to 60.
-l : read messages from stdin, sending a separate message for each line.
-m : message payload to send.
-M : the maximum inflight messages for QoS 1/2..
-n : send a null (zero length) message.
-p : network port to connect to. Defaults to 1883.
-P : provide a password (requires MQTT 3.1 broker)
-q : quality of service level to use for all messages. Defaults to 0.
-r : message should be retained.
-s : read message from stdin, sending the entire input as a message.
-S : use SRV lookups to determine which host to connect to.
-t : mqtt topic to publish to.
-u : provide a username (requires MQTT 3.1 broker)
-V : specify the version of the MQTT protocol to use when connecting.
Can be mqttv31 or mqttv311. Defaults to mqttv31.
--help : display this message.
--quiet : don't print error messages.
--will-payload : payload for the client Will, which is sent by the broker in case of
unexpected disconnection. If not given and will-topic is set, a zero
length message will be sent.
--will-qos : QoS level for the client Will.
--will-retain : if given, make the client Will retained.
--will-topic : the topic on which to publish the client Will.
--cafile : path to a file containing trusted CA certificates to enable encrypted
communication.
--capath : path to a directory containing trusted CA certificates to enable encrypted
communication.
--cert : client certificate for authentication, if required by server.
--key : client private key for authentication, if required by server.
--ciphers : openssl compatible list of TLS ciphers to support.
--tls-version : TLS protocol version, can be one of tlsv1.2 tlsv1.1 or tlsv1.
Defaults to tlsv1.2 if available.
--insecure : do not check that the server certificate hostname matches the remote
hostname. Using this option means that you cannot be sure that the
remote host is the server you wish to connect to and so is insecure.
Do not use this option in a production environment.
--proxy : SOCKS5 proxy URL of the form:
socks5h://[username[:password]@]hostname[:port]
Only "none" and "username" authentication is supported.
See http://mosquitto.org/ for more information.
core-ssh:~#
2 Likes
Just as an alternative, you can use the mqtt.publish service from the services developer tools page.
2 Likes
@DavidFW1960 Just a quick clarification about your automation. Do you not have any Sonoff basics? I ask because you are only publishing to ‘power1’, 2, 3 and 4. I only see retained messages for these topics on my 4 Channel Sonoff, all my basics only have ‘power’ (no numerical suffix).
I only have basics. The sonoff group is a catch all for all sonoff. (It’s a published automation on the Tasmota Github)
My guess is you have retain: true specified for your MQTT Lights in configuration.yaml. Ensure it is set to retain: false (which happens to be the default).
Ideally, you only want state topics to be retained, not command topics. Generally speaking, that means your MQTT lights in Home Assistant ought to be configured retain: false and the physical lights (using Tasmota, ESPurna, ESPEasy, etc) configured retain: true.
Why? Because if a command topic is retained, you’re telling the MQTT broker to supply the topic’s message to every subscriber upon connection. That’s rarely desirable.
For example, let’s say home/garage_door_opener/command is retained.
- You command the door to open (command topic’s message is
on). - Then someone closes the door manually (command topic’s message is still
on). - The MQTT broker reboots and informs its subscribers of all its retained topics.
- The garage door opener receives the command
on. - Uh-oh, probably not the behavior you want!
Basically, all you retain are state topics. After the broker reboots (or a subscriber like Home Assistant reconnects) it reports to subscribers what’s currently on/off, opened/closed, etc (state topic) as opposed to instructing subscribers to turn on/off, open/close, etc (command topic).
3 Likes