Mosquitto + Home Assistant + Tasmota

dariosm commented 7 years ago

I've been adjusting many configuration and parameter values to make the integration possible. The setup is actually quite straightforward and widely discussed out there, but I had some issues regarding inconsistent states (sonoff relay, mosquitto retained messages and HASS toggle indicators). That might be due to bad combination of parameters like retain in light or switch configuration in HASS, persistence in Mosquitto and PowerOnState, PowerRetain and maybe SetOptionx in Tasmota.

This is my mqtt and a light configuration in HASS:

mqtt:
  broker: 127.0.0.1
  port: 1883
  client_id: home-assistant
  keepalive: 60
  protocol: 3.1
  birth_message:
    topic: "tele/hass/LWT"
    payload: "Online"
    qos: 1
    retain: true
  will_message:
    topic: "tele/hass/LWT"
    payload: "Offline"
    qos: 1
    retain: true

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

This are the command results that I consider relevant to this matter:

03:59:41 CMND: PowerOnState
03:59:41 MQTT: stat/sonoff1/RESULT = {"PowerOnState":3}
03:59:44 CMND: PowerRetain
03:59:44 MQTT: stat/sonoff1/RESULT = {"PowerRetain":"ON"}
03:59:48 CMND: SetOption
03:59:48 MQTT: stat/sonoff1/RESULT = {"SetOption1":"OFF"}
03:59:51 CMND: SetOption0
03:59:51 MQTT: stat/sonoff1/RESULT = {"SetOption0":"ON"}

I'm using 5.1.7 Build 2017-06-16T12:56:44

I wonder what is the optimal configuration for the integration. Is light.retain (HASS) needed to preserve the state of the relay, or should this be handled by properly setting PowerOnState and savedata (Tasmota)? Is persistence (Mosquitto) needed to allow HASS recover the current light values (sonoff relay state) on every restart?

Thanks in advance

davidelang commented 7 years ago

retain and poweronstate will fight each other.

pick what components in your system should save state.

should it be the sonoff? (use poweronstate)

should it be the mqtt server? (use retain)

should it be the home automation server? (don't use either)

there is a wiki page on this and if you search closed issues, you will find many people fighting this.

personally I would never want the mqtt server to issue commands to the sonoff, I would want them to keep state themselves, or do what the home automation tells them to do. The mqtt server should just be a transport layer between them.

David Lang

dariosm commented 7 years ago

@davidelang thank you for your comments. Before posting this issue I read this (I think that's the page you mentioned from the Wiki). Correct me if I'm wrong:

retain: true in HASS marks as retained command messages with the form cmnd/<device>/POWER, sent to the broker and then to the subscribed sonoff device
PowerRetain in sonoff marks as retained state messages with the form stat/<device>/POWER sent to mqtt broker as a response to cmnd/<device>/POWER

I agree with you about letting mqtt server to handle only message transportation, no storage, and to achieve that I think both retain parameters mentioned before and persistence in mosquitto.conf should be taken into account.

davidelang commented 7 years ago

On Thu, 22 Jun 2017, Dario Silva Moran wrote:

@davidelang thank you for your comments. Before posting this issue I read this (I think that's the page you mentioned from the Wiki). Correct me if I'm wrong:

retain: true in HASS marks as retained command messages with the form cmnd/<device>/POWER, sent to the broker and then to the subscribed sonoff device

PowerRetain in sonoff marks as retained state messages with the form stat/<device>/POWER sent to mqtt broker as a response to cmnd/<device>/POWER

no, I don't think so.

all commands to the device are cmnd, all messages from the device are stat.

I agree with you about letting mqtt server to handle only message transportation, no storage, and to achieve that I think both retain parameters mentioned before and persistence in mosquitto.conf should be taken into account.

retain tells mosquitto to track things as persistant.

dariosm commented 7 years ago

Correct me if I'm wrong:

retain: true in HASS marks as retained command messages with the form cmnd/<device>/POWER, sent to the broker and then to the subscribed sonoff device

PowerRetain in sonoff marks as retained state messages with the form stat/<device>/POWER sent to mqtt broker as a response to cmnd/<device>/POWER

no, I don't think so.

all commands to the device are cmnd

Yes, that's my first point.

all messages from the device are stat.

And that's the second. What I'm trying to check with you is which is the way to treat those messages (cmnd and stat) as retained, meaning, who is actually setting the flag in each case. Do you agree with my statements?

I agree with you about letting mqtt server to handle only message transportation, no storage, and to achieve that I think both retain parameters mentioned before and persistence in mosquitto.conf should be taken into account.

retain tells mosquitto to track things as persistant.

For the current session, yes. But when mosquitto is restarted, if persistence property in mosquitto.conf is set to false, then there is no way to recover messages flagged with retain. That's why I stated that property should be considered true in all cases, not for sonoff to work properly, but for every other subscribed client to know the current state of the relay.

davidelang commented 7 years ago

On Thu, 22 Jun 2017, Dario Silva Moran wrote:

On Thu, Jun 22, 2017 at 5:14 PM, David Lang notifications@github.com wrote:

On Thu, 22 Jun 2017, Dario Silva Moran wrote:

@davidelang thank you for your comments. Before posting this issue I read this (I think that's the page you mentioned from the Wiki). Correct me if I'm wrong:

retain: true in HASS marks as retained command messages with the form cmnd/<device>/POWER, sent to the broker and then to the subscribed sonoff device

PowerRetain in sonoff marks as retained state messages with the form stat/<device>/POWER sent to mqtt broker as a response to cmnd/<device>/POWER

no, I don't think so.

all commands to the device are cmnd

Yes, that's my first point.

all messages from the device are stat.

And that's the second. What I'm trying to check with you is which is the way to treat those messages (cmnd and stat) as retained, meaning, who is actually setting the flag in each case. Do you agree with my statements?

it's not one flag, and they aren't exclusive (which can cause problems)

I agree with you about letting mqtt server to handle only message transportation, no storage, and to achieve that I think both retain parameters mentioned before and persistence in mosquitto.conf should be taken into account.

retain tells mosquitto to track things as persistant.

For the current session, yes. But when mosquitto is restarted, if persistence property in mosquitto.conf is set to false, then there is no way to recover messages flagged with retain. That's why I stated that property should be considered true in all cases, not for sonoff proper function, but for every other subscribed client to know the current state of the relay.

I don't know how other subscribed clients would query to find the status, shouldn't they just listen for the next tele/ or stat/ message to find what the status is?

David Lang

dariosm commented 7 years ago

I agree with you about letting mqtt server to handle only message transportation, no storage, and to achieve that I think both retain parameters mentioned before and persistence in mosquitto.conf should be taken into account.

retain tells mosquitto to track things as persistant.

For the current session, yes. But when mosquitto is restarted, if persistence property in mosquitto.conf is set to false, then there is no way to recover messages flagged with retain. That's why I stated that property should be considered true in all cases, not for sonoff proper function, but for every other subscribed client to know the current state of the relay.

I don't know how other subscribed clients would query to find the status, shouldn't they just listen for the next tele/ or stat/ message to find what the status is?

Other mqtt broker clients like HASS, which is subscribed to stat/<device>/POWER, for every light <device> configuration.

davidelang commented 7 years ago

subscribing to a message just means that when the message is sent, you get a copy of it. How does that query for a status when a message hasn't been sent?

dariosm commented 7 years ago

@davidelang I apologise but I don't understand your point. I'll try to clarify the scenario I'm refereing to:

sonoff receives a command to power on (or off) its relay
sonoff sends a stat message to mqtt broker (mosquitto in this case)
mosquitto receives a stat message from sonoff and sends a copy of it to all clients subscribed to stat topic
HASS, as a stat topic subscriber, receives a copy of the message and sets the sonoff widget accordingly

Now, HASS can be restarted for any reason. When it is back online, it needs to set the sonoff widget to reflect the current physical state, and to do that it has to query mosquitto by subscribing to the stat topic. If mosquitto session remains the same as before, then as PowerRetain is On in sonoff, the stat message was sent to mosquitto with retain flag on. So, when HASS subscribes to stat topic after restart, it automatically receives the last sent message and sets the sonoff widget back to the proper status.

BUT, if mosquitto is restarted be any reason, and it has not been configured with persistence, when it is back online it has completely lost every messages previously retained, thus HASS (and any other subscribed client) will not be able to set the proper sonoff state. So, my last point was about taking into account the importance of this two lines in mosquitto.conf:

persistence true
persistence_location /var/lib/mosquitto/  #or any other path to store the db

dariosm commented 7 years ago

Regarding my last comment: looking for closed issues as @davidelang suggested, found this post that stands to disable persistence in mosquitto.conf to solve on/off loops and similar situations. I've been there too, and tried to disable persistence. The side effect is the one explained previously (retained messages are lost if they are not stored in the mosquitto's db).

davidelang commented 7 years ago

I use OpenHab for my home automation, and I have it subscribe to the tele/ messages and set the state in openhab based on either a stat/ or tele/ message

when openhab restarts, it will see a tele/ message from all devices shortly (I set the loginterval to 1m instead of the default 5m) and is accurate after that point.

With your approach, does subscribing to a pattern generate copies of all prior messages that follow that pattern? k

dariosm commented 7 years ago

I'll definitely take a look at your approach, may be I can check the same in HASS by subscribing to tele topic.

I'm not at home right now, later I will test the behavior I described and send you the logs. For now, I just can confirm that when HASS starts it receives stat retain messages and given them it sets the sonoff widgets. That's why those messages need to be persistent

••• Lic. Darío Silva Morán |Enviado desde móvil|

El 22 jun. 2017 19:23, "David Lang" notifications@github.com escribió:

I use OpenHab for my home automation, and I have it subscribe to the tele/ messages and set the state in openhab based on either a stat/ or tele/ message

when openhab restarts, it will see a tele/ message from all devices shortly (I set the loginterval to 1m instead of the default 5m) and is accurate after that point.

With your approach, does subscribing to a pattern generate copies of all prior messages that follow that pattern? k

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/536#issuecomment-310519326, or mute the thread https://github.com/notifications/unsubscribe-auth/AKfBIfsk5vCbSV8EUJz1x2tDu3EeqPngks5sGulygaJpZM4OBwmv .

amitubale commented 7 years ago

Darío - let me know what you put in the HAAS yaml..i have been having the same problem i use HAAS (or the toggle switch on gpio 14) to power up a sonoff but it tunrs off again. i was going to post asking if i need to use a pull up resistor on gpio 14...the problem would go away when i remove teh MQTT server IP on the sonoff...so the toggle switch worked fine but i could not use HASS...please let me know..thanks

dariosm commented 7 years ago

@amitubale I soldered a 10k pullup resistor, that solved mi on/off recurrent triggers (at least in the hardware side). You can check my HASS config in the first post.

FigJam23 commented 7 years ago

Yes I'm having a sim issue with sonof Tasmota and Hass . Hit switch in Home Assistant turns sonoff relay on sonoff relay stays on switch in HASS turns off as if it still thinks sonoff is off no matter what I try The stat/sonoff/power ( on/off ) Does not seem to let HASS know that sonoff relay is on five days trying to get a dam relay to turn on and off via HASS talk about going insane lol someone please help solve this issue

DiggiD commented 6 years ago

remove payload info to make light switches in HASS persistent. payload info is then taken from state of HASS toggle switch.

platform: mqtt name: "Display Cabinet" state_topic: "stat/ST-01/POWER" command_topic: "cmnd/ST-01/POWER" value_template: '{{ value_json["POWER"] }}' retain: true qos: 1 optimistic: false

in my setup:

mosquitto persistence is set to true in mosquitto.conf
PowerRetain is ON in Tasmota config

retain flag in Hass retains to persistent mosquitto db retain flag on tasmota retains on tasmota device.

my experience so far....

ASchneiderBR commented 6 years ago

Hello everyone! Thanks for all the information provided here.

I am about to go mad with Home Assistant (Hass.io), mqtt, tasmota and sonoff basic hahah

I cannot get these things to work together stable. Some devices changes state upon mqtt restart, disconnects all the time, toggle state randomly and so on.

I am also using GPIO14 as regular switches but had installed both resistor and a capacitor to minimize "ghost switching", like this:

Solder a 10k resistor between GPIO14 and 3.3v
Capacitor (100-500 pF) between GPIO14 and GND

Did any of you have an example of a stable config?

Here are mine:

MQTT:

broker: 127.0.0.1
port: 1883
keepalive: 60
protocol: 3.1
client_id: hassio
birth_message:
  topic: "tele/hassio/LWT"
  payload: "Online"
  qos: 1
  retain: false
will_message:
  topic: "tele/hassio/LWT"
  payload: "Offline"
  qos: 1
  retain: false

Sonoff running Tasmota:

13:28:17 MQT: stat/muv203operacoes/STATUS = {"Status":{"Module":1,"FriendlyName":["MuvRH 203 - Sala de operações"],"Topic":"muv203operacoes","ButtonTopic":"0","Power":1,"PowerOnState":3,"LedState":0,"SaveData":1,"SaveState":1,"ButtonRetain":0,"PowerRetain":1}}
13:28:17 MQT: stat/muv203operacoes/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://192.168.1.84:80/data/firmwares/sonoff-minimal.bin","RestartReason":"Software/System restart","Uptime":"1T13:25:00","StartupUTC":"","Sleep":0,"BootCount":234,"SaveCount":1917,"SaveAddress":"F7000"}}
13:28:17 MQT: stat/muv203operacoes/STATUS2 = {"StatusFWR":{"Version":"5.14.0","BuildDateTime":"2018-05-21T10:46:12","Boot":31,"Core":"2_3_0","SDK":"1.5.3(aec24ac9)"}}
13:28:17 MQT: stat/muv203operacoes/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"SysLog":0,"LogHost":"domus1","LogPort":514,"SSId":["MuvRH","Antonio e Roberta"],"TelePeriod":300,"SetOption":["00002029","55818000"]}}
13:28:17 MQT: stat/muv203operacoes/STATUS4 = {"StatusMEM":{"ProgramSize":451,"Free":488,"Heap":17,"ProgramFlashSize":1024,"FlashSize":1024,"FlashMode":3}}
13:28:17 MQT: stat/muv203operacoes/STATUS5 = {"StatusNET":{"Hostname":"muv203operacoes-0614","IPAddress":"192.168.1.75","Gateway":"192.168.1.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.1.1","Mac":"5C:CF:7F:58:42:66","Webserver":2,"WifiConfig":2}}
13:28:17 MQT: stat/muv203operacoes/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.1.12","MqttPort":1883,"MqttClientMask":"muvrhluzsalaoperacoes","MqttClient":"muvrhluzsalaoperacoes","MqttUser":"DVES_USER","MqttType":1,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}}
13:28:17 MQT: stat/muv203operacoes/STATUS7 = {"StatusTIM":{"UTC":"Fri Jan 02 13:28:17 1970","Local":"Fri Jan 02 13:28:17 1970","StartDST":"Thu Jan 01 00:00:00 1970","EndDST":"Thu Jan 01 00:00:00 1970","Timezone":1}}
13:28:17 MQT: stat/muv203operacoes/STATUS10 = {"StatusSNS":{"Time":"1970-01-02T13:28:17","Switch1":"OFF"}}
13:28:17 MQT: stat/muv203operacoes/STATUS11 = {"StatusSTS":{"Time":"1970-01-02T13:28:17","Uptime":"1T13:25:00","Vcc":3.246,"POWER":"ON","Wifi":{"AP":1,"SSId":"MuvRH","RSSI":56,"APMac":"10:7B:44:C1:E1:58"}}}

Light yaml:

- platform: mqtt
  name: "muv203operacoes"
  command_topic: "cmnd/muv203operacoes/POWER"
  state_topic: "stat/muv203operacoes/POWER"
  availability_topic: "tele/muv203operacoes/LWT"
  payload_available: "Online"
  payload_not_available: "Offline"
  qos: 1
  retain: true

Thank you very much!

badigit commented 6 years ago

@tatunts I have ghost switching too. Thank you for your experience, but would like to understand the reason why "ghost switching" happens

stale[bot] commented 6 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] commented 6 years ago

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem.

garymcleanuk commented 5 years ago

Im having the same issue. When wifi drops and it looses connection to MQTT, the sonoff will come back on and it will set the relay to the last known state that Hass set it to. If I used the Tasmota GUI or the Sonoff physical button, it turns the relay accordingly and updates the status in Hass, but it will always revert to the last set state by Hass the next time it disconnects from MQTT..

Its like the sonoff is checking a different topic for what its power should be than the topic it used last time to set its power status last

This is driving me mad too

garymcleanuk commented 5 years ago

I see why we get the ghost switching, is because when you set the switch status on the sonoff, it doesn;t update the cmnd/sonoff-xmaslights/POWER [on:off] on the broker.

It only reports the stat/sonoff-xmaslights/POWER =

When tasmota disonnects and reconnects to mqtt, it will set the sonoff device power based off the last cmnd/sonoff-xmaslights/POWER status either if thats off or on.

So if you use home assisstant to set the power to ON, and then use tasmota to set the sonoff to off. If the device drops and reconnects, it will abibe by the last power status set by homeassisstant (cmnd)

ahmeaqas commented 5 years ago

Have a look on to Ghost / Random Switching on Sonoff Devices (MQTT Retained)

arendst / Tasmota

Mosquitto + Home Assistant + Tasmota #536