Sonoff with embedded mqtt

sirdir1972 · February 23, 2017, 9:09pm

Hi!
Sorry for spamming the forum, I hope that’s the last thread for some time.
I’m no expert to MQTT, so I may make a very fundamental error.
I have some sonoff wifi switches with the arendst/Sonoff-MQTT-OTA-Arduino firmware.

configuration in homeassistant:

light 1:
  platform: mqtt
  command_topic: "cmnd/sonoff1/POWER"
  name: "Ballustrade"
  state_topic: "stat/sonoff1/POWER"
  qos: 1
  retain: true
  payload_on: "ON"
  payload_off: "OFF"
  optimistic: false

(I’ve tried variations, but no change)
Problem: Works so far, but when I restart home assistant (or, probably, if sonoffs reboot), the state is not correct. When home asssistant restarts, state is always off, even if the sonoffs are on.
As far as I understand, the state_topic should take care of that.
the sonoffs are also sending ‘telemetry’ messages, but I guess those are ignored anyway.

Any idea?

gpbenton · February 24, 2017, 7:17am

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.

sirdir1972 · February 24, 2017, 2:17pm

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.

gpbenton · February 24, 2017, 2:35pm

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.

sirdir1972 · February 24, 2017, 2:40pm

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?

gpbenton · February 24, 2017, 3:03pm

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.

zachishi · February 24, 2017, 3:39pm

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

platform: mqtt
name: “TestSonoff2”
state_topic: “stat/sonoffRF3/POWER”
command_topic: “cmnd/sonoffRF3/POWER”
qos: 1
payload_on: “ON”
payload_off: “OFF”
retain: true

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.

sirdir1972 · February 24, 2017, 3:53pm

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)

gpbenton · February 24, 2017, 4:42pm

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.

sirdir1972 · February 24, 2017, 4:47pm

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.

gpbenton · February 24, 2017, 4:54pm

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

sirdir1972 · February 25, 2017, 1:23am

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.

sirdir1972 · February 25, 2017, 12:33pm

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

Vayain · April 26, 2017, 2:30pm

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!

hoatienii · July 21, 2017, 2:26am

Thanks very much! Work fine for me. I google many time to find this!

palitu · July 21, 2017, 3:45am

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.

rmgn · December 8, 2017, 1:19am

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.

NK553 · December 8, 2017, 1:43am

Which version of Mosquito are you guys running? 3.1.1?

NK553 · December 8, 2017, 1:55am

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.

rmgn · December 8, 2017, 2:40am

Not using mosquitto but gonna install it now to solve this.
This seems to be a problem with the internal broker.