HA will update the state when it gets a message with the state topic.
To get this to happen when HA starts up, the state topic has to be published with the retain flag set. This causes the broker to keep the message in its database, and send it with the latest state immediately a new client subscribes to the topic.
So I think you have to change the code in the Sonoff to set the retain flag for state messages.
That should be the case, I even enabled retain for the button that I dont ever use:
#define MQTT_BUTTON_RETAIN 1 // [ButtonRetain] Button may send retain flag (0 = off, 1 = on)
#define MQTT_POWER_RETAIN 1 // [PowerRetain] Power status message may send retain flag (0 = off, 1 = on)
#define MQTT_SWITCH_RETAIN 1 // [SwitchRetain] Switch may send retain flag (0 = off, 1 = on)
The console in the sonoff shows:
15:11:31 MQTT: tele/sonoff1/RESULT = {"Info1":{"AppName":"Sonoff 8266 Module", "Version":"3.2.13", "FallbackTopic":"DVES_958A7A", "GroupTopic":"sonoffs"}}
15:11:31 MQTT: tele/sonoff1/RESULT = {"Info2":{"WebserverMode":"Admin", "Hostname":"sonoff1-2682", "IPaddress":"192.168.1.242"}}
15:11:33 MQTT: stat/sonoff1/RESULT = {"POWER":"ON"}
15:11:33 MQTT: stat/sonoff1/POWER = ON
15:11:40 MQTT: tele/sonoff1/TELEMETRY = {"Time":"2017-02-24T15:11:40", "Uptime":0, "POWER":"ON", "Wifi":{"AP":1, "SSID":"Home Benissa", "RSSI":92}}
15:12:00 MQTT: Attempting connection...
15:12:01 mDNS: Query done with 0 mqtt services found
15:12:12 MQTT: Attempting connection...
15:12:13 mDNS: Query done with 0 mqtt services found
15:12:13 MQTT: Connected
15:12:13 MQTT: tele/sonoff1/LWT = Online (retained)
15:16:42 MQTT: tele/sonoff1/TELEMETRY = {"Time":"2017-02-24T15:16:42", "Uptime":0, "POWER":"ON", "Wifi":{"AP":1, "SSID":"Home Benissa", "RSSI":92}}
The restart is at 15:12:00. There’s no stat going over the line?
Is there a way for homeassistant to react to the telemetry messages?
only when I set the switch to on (again) in homeassistant, a STAT is sent:
15:16:42 MQTT: tele/sonoff1/TELEMETRY = {"Time":"2017-02-24T15:16:42", "Uptime":0, "POWER":"ON", "Wifi":{"AP":1, "SSID":"Home Benissa", "RSSI":92}}
15:21:42 MQTT: tele/sonoff1/TELEMETRY = {"Time":"2017-02-24T15:21:42", "Uptime":0, "POWER":"ON", "Wifi":{"AP":1, "SSID":"Home Benissa", "RSSI":90}}
15:26:17 MQTT: stat/sonoff1/RESULT = {"POWER":"ON"}
15:26:17 MQTT: stat/sonoff1/POWER = ON
15:26:42 MQTT: tele/sonoff1/TELEMETRY = {"Time":"2017-02-24T15:26:42", "Uptime":0, "POWER":"ON", "Wifi":{"AP":1, "SSID":"Home Benissa", "RSSI":94}}
I also tried ‘LEGACY’ message format instead of ‘JSON’ but… to no avail.
Can you subscribe with another client, such as mosquitto_sub, to see if the broker is actually honoring the retain flag? e.g.
$ mosquitto_sub -h 'your host ip' -t 'stat/sonoff1/POWER' -v
If the retain flag is set, it should respond immediately with the last value set.
Yes, just define another mqtt sensor that subscribes to that mqtt message. If you want and individual value from the json, you need a value_template field to define which element. See the MQTT sensor example.
Sorry for the noob question, but should I sent that command to the mqtt-server (home assistant) (I’m not sure about the terminology) or to the sonoff? the sonoff says connection refused and the server says
[hbmqtt.broker] [MQTT-3.1.0-1] (client @=192.168.1.19:43950): Can't read first packet an CONNECT: [MQTT-3.1.2-1] Incorrect protocol name: "MQIsdp"
``
AFAIK mosquito is not compatible to the internal broker. Maybe I should think about running an external broker?
Not sure about the telemetry thing, I can't just replace that sate message with the telemetry I suppose?To the broker. All the command is doing is subscribing to a message like HA would, and seeing if it gets the expected result.
mosquitto_sub should connect to the internal broker. Although it uses some of the same libraries as the mosquitto broker, it should connect to any MQTT broker. You can use any other client to subscribe, there are a few out there, including mobile phone apps.
What you can’t do is run both mosquitto and the internal broker at the same time on the same machine, trying to access the same default port.
The internal broker works fine afaik, mosquitto just comes with some handy command line tools that help you figure out what is happening.
If you want to get the state from that, yes you could, but by the looks of things, that doesn’t happen immediately. The normal solution to this problem is to get the broker to do the work it is supposed to do.
There is no harm in creating an automation that triggers off the telemetry message and sets the state to make sure it is always up to date.
I would make sure your sonoff is on the newer version and also make sure it has the retain flag set on the sonoff itself. i know this was an issue for me and that seemed to fix it. You can set the retain flag from the command line on the device web portal.
https://github.com/arendst/Sonoff-Tasmota/wiki/Home-Assistant
This is what my config looks like in HA
Also make sure you use the device name you setup in the alias for the sonoff not the name with the mac address in it.
Hi!
Yes, I think(!) that’s what I found out in the meantime as well. you need to set ‘powerretain’ to ‘on’ in the console of the sonoff. it seems you need to do that even if you set define in userconfig.h to 1. AND, what might first have been the problem: YOU NEED TO REBOOT the sonoff.
Now, the status has been retained when I restart homeassistant. When I rebootet the whole server (incl. mosquitto etc.) the status hadn’t been reatained. again. But I guess that’ll do for now.
AND it still doesn’t work with the internal broker, just with mosquitto (and I really can’t connect to the internal broker via mosqiutto_sub)
In the future, I will suggest that people use mosquitto rather than the internal broker. I had never used the internal broker, but assumed it would work properly as I hadn’t seen any complaints. Thanks for posting this.
Well, you should take everything I write with a grain of salt. I’m jumping from topic to topic and try to fix things without really knowing the details 
But I guess there is a protocol issue between the internal broker and mosquitto_sub, I think I also ready about that before.
About what lead to soccess with msoquitto, I’m not 100% sure yet. maybe it was rebooting the sonoff, maybe I was messing up some other thing.
it’s easier to debug with mosquitto than with the internal broker for sure.
Yes I got curious about this, so I did a test and set up the internal broker. It turns out the the internal broker only talks version 3.1.1 and by default mosquitto_sub uses version 3.1 You can specify that mosquitto_sub use version 3.1.1, and this actually connects.
$ mosquitto_sub -V mqttv311 -t "#" -v
/energenie/eTRV/Command/ValveState/296 2
/energenie/eTRV/Command/ValveState/329 2
Actually I had tried the different protocol versions as well, and have been getting this protocol mismatch in every case, but maybe I made some other mistake. I’ll maybe try again tomorrow.
You were right, it works, don’t know what I did yesterday.
But as you can see, the retained messages (and subscriptions?) are missing in the internal broker.
internal broker:
cs@cs:~$ mosquitto_sub -t "#" -v -V mqttv311
tele/sonoff1/LWT Online
tele/sonoff2/LWT Online
tele/sonoff3/LWT Online
mosquitto:
cs@cs:~$ mosquitto_sub -t "#" -v -V mqttv311 -u user -P xxx
tele/sonoff2/LWT Online
tele/sonoff3/LWT Online
tele/sonoff1/LWT Online
cmnd/sonoff3/POWER OFF
cmnd/sonoff2/POWER OFF
cmnd/sonoff1/POWER OFF
stat/sonoff1/POWER OFF
stat/sonoff2/POWER OFF
stat/sonoff3/POWER OFF
Thanks a lot @sirdir1972 and @zachishi, stumbled upon this thread and found my answer.
SONOFF switch working fine with Mosquitto, but whenever HA restarts, the stats are unknown (Switch is “on”, HA shows “off” until switch is used for the first time).
Changed my SONOFF-Settings with “PowerRetain On” (via Web-Console, then reboot) and now HA is showing the correct stats after rebooting.
Cheers!
Thanks very much! Work fine for me. I google many time to find this!
a couple of things that i do with mine:
all topics start with a “/”. this allows me to subscribe to “/#” and view all messages that come through using mosquitto_sub.
I do not set the retain flag, as the sonoffs send through the status on a regular occurance. So at the start of HA, they will be out of sync, but will sync up pretty quickly (ie <1 minute).
also remember that you can set all of the parameters by using MQTT commands, and there are some issues around retained MQTT and setting the power up settings of the sonoff. The retained state will always overwrite the startup configured state.
good luck - i have about 12 of these in my house, with the latest tasmota firmware.
Hey,
I’m experiencing the exact same problem (using the internal broker).
Did you ever get that one to work? Or do I have to switch to Mosquitto?
Thanks.
Which version of Mosquito are you guys running? 3.1.1?
This is my switches, section.
switch:
- platform: mqtt
name: "Workbench Light"
state_topic: "stat/sonoff1/POWER"
command_topic: "cmnd/sonoff1/POWER"
qos: 1
payload_on: "ON"
payload_off: "OFF"
retain: true
- platform: mqtt
name: "Sonoff2"
state_topic: "stat/sonoff2/POWER"
command_topic: "cmnd/sonoff2/POWER"
qos: 1
payload_on: "ON"
payload_off: "OFF"
retain: true
This is my mqtt settings.
mqtt:
broker: 192.168.0.217
port: 1883
client_id: HASS
keepalive: 60
username: USER1
password: !secret MQTT_password
protocol: 3.1
Sonoff Settings
All working.
Not using mosquitto but gonna install it now to solve this.
This seems to be a problem with the internal broker.
Confirming I don’t see this issue with Mosquitto.
