MQTT Setup Help for Newbie

Configuration
1

I’m an MQTT newbie, so please be patient. I’m on hassio 0.58.1.

I’m using the default mqtt broker and my yaml looks like this:

mqtt:

switch:

  • platform: mqtt
    name: “Sonoff power”
    command_topic: “cmnd/sonoff/POWER”
    state_topic: “stat/sonoff/POWER”
    qos: 1
    payload_on: “ON”
    payload_off: “OFF”
    retain: true

I successfully flashed my S20 with sonOTA and I think it’s connecting to the mqtt server. If i look at the console in the web interface, I see:

22:17:47 MQT: Connect failed to 192.168.192.79:1883, rc -2. Retry in 10 sec
22:17:58 MQT: Attempting connection…
22:17:59 DNS: Query done. MQTT services found 0
22:18:03 MQT: Connected
22:18:03 MQT: ha/sonoff/LWT = Online (retained)
22:18:03 MQT: ha/sonoff/cmnd/POWER =
22:21:11 MQT: ha/sonoff/STATE = {“Time”:“2017-12-04T22:21:11”, “Uptime”:0, “Vcc”:3.138, “POWER”:“OFF”, “Wifi”:{“AP”:1, “SSId”:“TP-LINK_3F9F”, “RSSI”:78, “APMac”:“EC:08:6B:F9:3F:9F”}}

If I look at the startup messages in home assistant, I see:

Timer got out of sync. Resetting
21:38 core.py (ERROR)
Setup of tts is taking over 10 seconds.
21:38 bootstrap.py (WARNING)
When targeting Google Home, listening port has to be port 80
21:38 components/emulated_hue/init.py (WARNING)
Listen IP address not specified, auto-detected address is 192.168.192.79
21:38 components/emulated_hue/init.py (WARNING)
Setup of sensor is taking over 10 seconds.
21:37 bootstrap.py (WARNING)
Setup of mqtt is taking over 10 seconds.
21:37 bootstrap.py (WARNING)
When I click the switch toggle on the main states page, the toggle moves for a second and the reverts. Nothing happens with the switch.

I can control the switch directly through the tasmota web interface.

What am I missing?

Thanks

2

Your topics aren’t the same and they have to be exactly the same at both ends.

Your sonoff is publishing to ha/sonoff/STATE and HA is subscribing to stat/sonoff/POWER
and the sonoff is subscribing to ha/sonoff/cmnd/POWER and HA is publishing to cmnd/sonoff/POWER

3

Looks like your topics are a bit screwy, from the look of the Sonoff log the command topic is actually:

ha/sonoff/cmnd/POWER

And the state topic is:

ha/sonoff/STATE

In your configuration.yaml you’ll also want to set retain to false and qos 0 so you don’t have unexpected and unwanted toggling of the switch.

Try that. It looks like the sonoff may also be publishing a JSON payload on the state topic, in which case you’ll also need to add…

value_template: '{{ json_value.POWER }}'

…underneath the other mqtt switch parameters in configuration.yaml.

4

I have qos: 1 and retain: true as per all the guides out there and don’t get any unwanted toggling, they all work perfectly.

5

The only issue with setting retain is that if you have any network connectivity issues, causing the sonoff to disconnect and reconnect, then when it reconnects it’s going to toggle according to the retained message.

I suppose this is OK for lights where it doesn’t really matter that much whether the light is on or off, but does matter for devices like garage doors, where you want to know for sure that the device is only going to react when you tell it to, and in the way you expect it to. For that reason in my view it’s better to leave retain off for command topics, though it is important for a device to publish state messages with the retain flag since then HASS won’t show the state as Unknown on startup. Just my 2 cents.

6

Interesting, I have PowerRetain 1 set in Tasmota which I thought was to ensure that didn’t happen or is that what you meant?

7

Hi

I also tried with

command_topic: "cmnd/ha/sonoff/POWER"
state_topic: "stat/ha/sonoff/POWER"

but it still doesn’t work.

This is how my Sonoff is setup when I log into the web interface at sonoff-XXXX.local:

Host: 192.168.192.79
Port: 1883
Client: Sonoff1
User: homeassistant
Password: **********
Topic: sonoff
Full topic ha/sonoff/

Can you please tell me what my yaml entry should be?

Thanks

8

The MQTT log tells you what they should be …

22:18:03 MQT: ha/sonoff/cmnd/POWER
22:21:11 MQT: ha/sonoff/STATE

command_topic: “ha/sonoff/cmnd/POWER”
state_topic: “ha/sonoff/STATE”

As marthocoo said above you will probably need a value template for the state payload

9

I don’t use sonoff devices or tasmota, but my understanding is that option in tasmota causes it to store its state and restore on restart. So e.g. if your light is on, and there is a power failure, when the power comes back on and the sonoff restarts, it will remember it was on and turn the light on.

What I’m talking about it a bit different. The retain: true option in HA causes HA to publish commands with the retain flag set. This means that once the message is at the broker, each subscribing client is going to get that message delivered to it on startup. Which means for example if you toggle the switch in HASS to ON, ON gets published with the retain flag set. Now, every time the Sonoff reconnects, it’s going to get the ON command and turn on. Which may be perfectly fine. Or, it may cause you to wonder why the device turns on even when HA is off, for example, or when you’ve manually turned it off via the switch.

Maybe I’m making a mountain out of a molehill. But to me its important to know that my devices are only going to change state or react when I intend them to.

1 Like
10

I tried that and it still doesn’t work. Also seems different to what I have configured the sonoff to subscribe to.

11

To be clear your configuration.yaml entry should look like this; stick with the basics until you know it’s working:

switch:
  - platform: mqtt
    name: "Sonoff power"
    command_topic: "ha/sonoff/cmnd/POWER"
    state_topic: "ha/sonoff/STATE"
    payload_on: "ON"
    payload_off: "OFF"
    value_template: '{{ value_json.POWER }}'
12

Here is my light

  - platform: mqtt
    name: Basement Hall Light
    state_topic: "stat/basement_light/POWER"
    command_topic: "cmnd/basement_light/POWER"
    payload_on: "ON"
    payload_off: "OFF"
    retain: true

and the sonoff setup is

MQTT Host 192.168.xxx.xxx
MQTT Port 1883
MQTT Client &
Fallback Topic DVES_57EF77
MQTT User DVES_USER
MQTT Topic basement_light
MQTT Group Topic sonoffs
MQTT Full Topic cmnd/basement_light/

13

I’m really derailing OP’s thread here but here’s a real world example where you don’t want to use retain:true.

Take an MQTT garage door opener. You can open the door through HA and also manually via a switch or remote control. You open the door with HA, which publishes OPEN to the command topic with the retain flag set. You go outside and do what you need to do in the garage, then close it via the pushbutton beside the door. No problem! Now you go to bed for the night. In the morning you wake up and the garage door is open and your lawnmower has been stolen. What happened? During the night there was a momentary wifi blip, which caused the garage door opener device to disconnect. When it reconnected to wifi and the MQTT broker, it subscribed to the command topic and received the retained message on that topic - OPEN. So it did what it was supposed to do, which is open the door when it receives that message.

Like I said, maybe not a big deal for lights, but to me it’s still better to not have retained messages on command topics.

1 Like
14

Thank you! it’s now working! I don’t know exactly what worked, but I copied your YAML entry and just substituted a few minor bits. No working a dream!

15

That makes sense :slight_smile:

17

Thinking about this again, and I don’t pretend to understand exactly what’s going on so this may be rubbish, will the switch not replace the ON that HA sent with an OFF when you press the button? Or am I confusing command and state topics?

These things are why I tell people having problems with MQTT NOT to try to understand it first and just go with whatever the guides say and why I myself avoided it for so long :smile:

18

You are confusing command and state topics. If what you are thinking was the case, there’d be no need for separate command and state topics. You’d just have one topic that reported status and accepted commands. But part of the reason for not doing this is that commands and states might be different (eg a lock that accepts LOCK and UNLOCK commands but returns the state of the device as LOCKED or UNLOCKED), and also to avoid a feedback loop where the device was constantly getting a command, then reporting state, which again became a command, causing the device to report its state…

Of course, the clearest way to avoid the whole problem of needing to replace the ON command message with OFF when the light turns off is just to not use retain when publishing to the command topic. Then the fact that ON was previously sent to the command topic won’t matter if the device disconnects and reconnects, since it will only receive messages that are published while it is connected.

1 Like
19

Thought that might be the case, going to change mine over.

Ironically, I thought my outside lights had suffered from a dose of this in the early hours of this morning and spent ages checking logs to narrow down the cause. Turned out the missus had got up for a wee and decided she didn’t like the original light switch looking like it was on when the light was off, it’s now set as a toggle connected to the gpio, and had turned the light on with Alexa and then used the switch to turn it back off again. Oddly, two way switches never seem to bother her though…women are never happy!

20

I have spent more time than I care to admit researching and designing my system while trying to answer the question “What will my wife think/say about this?”. Also I have small kids so telling them to leave a light switch in the “on” position so that the light will turn on when you walk past the motion sensor… unfortunately a lot of smart tech just isn’t at that intuitive stage yet.

21

And is the biggest reason mugs pay through the nose for Hue stuff i guess, same principle as iPhones, may not be the cleverest but just works without having to think about it…or boring and expensive depending on your viewpoint.