search

arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
22.2k stars 4.81k forks source link

Sonoffs turns equipment on when HASSIO Raspberry Pi server is rebooted #2929

Closed mxplea10 closed 6 years ago

mxplea10 commented 6 years ago

Make sure these boxes are checked [x] before submitting your issue - Thank you!

(Please, remember to close the issue when the problem has been addressed)

Frogmore42 commented 6 years ago

You didn't fill out any part of the form, which makes it really hard to provide any kind of help. But, generally people who use HASSIO have set retain on one or more MQTT message. This causes all sorts of fun problems, just like you are seeing. Since it seems HA recommends this configuration, it might be best to go ask the question there, or switch to a different HA platform. I use NodeRED and don't have this issue.

I took a quick look at the documentation for HA and they don't actually say anything about why you should or should not set retain. The default is off, but the example has it on. My guess is that you have retain set to on/true and that you get a retained message that is causing the problem.

The other possibility is that your device is restarting when the rpi reboots, because it loses contact with the mqtt server, and you have the device configured to turn on, on startup. The information that is required for all issue reports plus the yaml you are using for your configuration would shed some light on the actual problem.

mxplea10 commented 6 years ago

When the Hassio Raspberry Pi server is rebooted, the Flood Lights (Sonoff Basic), test light2 that's being used in place of the Xfinity Modem (Sonoff Dual relay 2) and the test Sonoff Pow v2 all turn on. Enabling the PowerRetain on the sonoffs do not fix the problem. Note that only one of the test lights on the Sonoff Dual is turned on.

The wiringlight (Sonoff Basic) and test light for the Linksys 8-port Switch (Sonoff Dual relay 1) are not being turned on. The Test Raspberry Pi (Sonoff Basic) remains on all the time and it's not being turned off. The devices are connected to the sonoff but the 4CH Pro Sonoff relays for the Linksys 8-port Switch, Pi-Hole Raspberry Pi, Hassio Raspberry Pi and No Device are not being turned on (verified accessing the Sonoff GUI). All the Sonoffs are running Tasmota 5.12.0. I've been trying to figure this out for several days and can't seem to find the issues. status 0.txt

#partial configuration.yaml
mqtt:
  broker: core-mosquitto
  port: 1883
  client_id: home-assistant-1
  keepalive: 60
  username: !secret mqtt_username
  password: !secret mqtt_password
  protocol: 3.1
  birth_message:
    topic: "tele/hass1/LWT"
    payload: "online"
    qos: 1
    retain: true
  will_message:
    topic: "tele/hass1/LWT"
    payload: "offline"
    qos: 1
    retain: true

light: !include lights.yaml

switch: !include switches.yaml

# lights.yaml
# Sonoff Basic Network Lamp Light
  - platform: mqtt
    name: "Eyrie Light"
    state_topic: "stat/wiringlight/POWER"
    command_topic: "cmnd/wiringlight/POWER"
    availability_topic: "tele/wiringlight/LWT"
    qos: 1
    payload_on: "ON"
    payload_off: "OFF"
    payload_available: "Online"
    payload_not_available: "Offline"
    retain: true

# Sonoff Basic Flood Lights
  - platform: mqtt
    name: "Flood Lights"
    state_topic: "stat/FloorLights/POWER"
    command_topic: "cmnd/FloorLights/POWER"
    availability_topic: "tele/FloorLights/LWT"
    qos: 1
    payload_on: "ON"
    payload_off: "OFF"
    payload_available: "Online"
    payload_not_available: "Offline"
    retain: true

# switches.yaml
# Test Raspberry Pi Power Strip
  - platform: mqtt
    name: "Test Raspberry Pi"
    state_topic: "stat/testRPi/POWER"
    command_topic: "cmnd/testRPi/POWER"
    availability_topic: "tele/testRPi/LWT"
    qos: 1
    payload_on: "ON"
    payload_off: "OFF"
    payload_available: "Online"
    payload_not_available: "Offline"
    retain: true

# Primary and Xfinity Modem Power Strip
  - platform: mqtt
    name: "Primary Router"
    state_topic: "stat/primary1/POWER1"
    command_topic: "cmnd/primary1/POWER1"
    availability_topic: "tele/primary1/LWT"
    qos: 1
    payload_on: "ON"
    payload_off: "OFF"
    payload_available: "Online"
    payload_not_available: "Offline"
    retain: true
  - platform: mqtt
    name: "Xfinity Modem"
    state_topic: "stat/primary1/POWER2"
    command_topic: "cmnd/primary1/POWER2"
    availability_topic: "tele/primary1/LWT"
    qos: 1
    payload_on: "ON"
    payload_off: "OFF"
    payload_available: "Online"
    payload_not_available: "Offline"
    retain: true

# Primary Switch and Servers Power Strip
  - platform: mqtt
    name: "Linksys 8-Port Switch"
    state_topic: "stat/primary2/POWER1"
    command_topic: "cmnd/primary2/POWER1"
    availability_topic: "tele/primary2/LWT"
    qos: 1
    payload_on: "ON"
    payload_off: "OFF"
    payload_available: "Online"
    payload_not_available: "Offline"
    retain: true
  - platform: mqtt
    name: "Pi-Hole Raspberry Pi"
    state_topic: "stat/primary2/POWER2"
    command_topic: "cmnd/primary2/POWER2"
    availability_topic: "tele/primary2/LWT"
    qos: 1
    payload_on: "ON"
    payload_off: "OFF"
    payload_available: "Online"
    payload_not_available: "Offline"
    retain: true
  - platform: mqtt
    name: "Hassio Raspberry Pi"
    state_topic: "stat/primary2/POWER3"
    command_topic: "cmnd/primary2/POWER3"
    availability_topic: "tele/primary2/LWT"
    qos: 1
    payload_on: "ON"
    payload_off: "OFF"
    payload_available: "Online"
    payload_not_available: "Offline"
    retain: true
  - platform: mqtt
    name: "No Device"
    state_topic: "stat/primary2/POWER4"
    command_topic: "cmnd/primary2/POWER4"
    availability_topic: "tele/primary2/LWT"
    qos: 1
    payload_on: "ON"
    payload_off: "OFF"
    payload_available: "Online"
    payload_not_available: "Offline"
    retain: true

# Sonoff POW Power
  - platform: mqtt
    name: "Sonoff POW power"
    state_topic: "stat/sonoff10/POWER"
    command_topic: "cmnd/sonoff10/POWER"
    availability_topic: "tele/sonoff10/LWT"
    qos: 1
    payload_on: "ON"
    payload_off: "OFF"
    payload_available: "Online"
    payload_not_available: "Offline"
    retain: true

# automations.yaml
- alias: "Power state on HA start-up"
  hide_entity: True
  trigger:
    platform: homeassistant
    event: start
  action:
    - service: mqtt.publish
      data:
        topic: "cmnd/wiringlight/POWER"
        payload: ""
    - service: mqtt.publish
      data:
        topic: "cmnd/FloorLights/POWER"
        payload: ""
    - service: mqtt.publish
      data:
        topic: "cmnd/testRPi/POWER"
        payload: "" 
    - service: mqtt.publish
      data:
        topic: "cmnd/primary1/POWER1"
        payload: ""
    - service: mqtt.publish
      data:
        topic: "cmnd/primary1/POWER2"
        payload: ""
    - service: mqtt.publish
      data:
        topic: "cmnd/primary2/POWER1"
        payload: ""
    - service: mqtt.publish
      data:
        topic: "cmnd/primary2/POWER2"
        payload: ""
    - service: mqtt.publish
      data:
        topic: "cmnd/primary2/POWER3"
        payload: ""
    - service: mqtt.publish
      data:
        topic: "cmnd/primary2/POWER4"
        payload: ""
    - service: mqtt.publish
      data:
        topic: "cmnd/sonoff10/POWER"
        payload: ""
mxplea10 commented 6 years ago

The retain was set to false on all lights and switches at first. I changed them doing troubleshooting and didn't change them back.

Frogmore42 commented 6 years ago

Power retain is a generally bad idea as it can cause this type of issue, from what I have heard from others who had it on.

What do you have the power on state set to in Tasmota?

What does the serial/web log of Tasmota show when you reboot the server?

mxplea10 commented 6 years ago

I enable Power Retain based on the examples in the Sonoff-Tasmota . I've attached the power on state and provided the console logs for each sonoff after the Hassio server was rebooted. I wasn't able to find the specific logs for serial and web logs. Where are the serial and web logs located?

PowerOnState command results 06072018_0929.txt Console Logs After Hassio Server Rebooted 06072018_0937.txt

Frogmore42 commented 6 years ago

Your logs indicate there are retained messages for each one. See this https://github.com/arendst/Sonoff-Tasmota/issues/2140 for the problems this can cause and how to fix it.

See this https://github.com/arendst/Sonoff-Tasmota/issues/2209 for why Theo doesn't like HA.

Also, you are using an older version of Tasmota. The newer ones make it clearer the command is coming from a retained message. Since it's mqtt, it can't tell you who sent it originally, but that is pretty obvious as you are using HA and have it configured to retain.

Having watched the forums for many months, I can say that many people have had the same issue with retained messages (who are using hassio). I don't believe I have seen that from any other HA system. The documentation on hassio did not explain retain, so I have no idea what benefit it might provide. Clearly, it has some costs 😃.

ascillato commented 6 years ago

Yes,

You are right.

I use HomeAssistant and the embedded MQTT broker and I have never had problems with the following configuration:

mqtt:
  discovery: true
  discovery_prefix: homeassistant

light:
    - platform: mqtt
      name: "Cocina"
      state_topic: "stat/cocina/POWER1"
      command_topic: "cmnd/cocina/POWER1"
      availability_topic: "tele/cocina/LWT"
      qos: 1
      payload_on: "ON"
      payload_off: "OFF"
      payload_available: "Online"
      payload_not_available: "Offline"
      retain: false

I checked the wiki and in the examples retain is set to true.

I will fix that.

mxplea10 commented 6 years ago

@Frogmore42, thanks for the #2140 and #2209. These are informative but left me little confused and left unanswered questions for me.

@curzon01 commented

Second the user configure same topics for status and commands. This mistake leads also in unwanted results.

Is he referring to a MQTT device state_topic and command_topic and if so, shouldn't the topics match exactly for a specific device and be different for every other device? My configuration follows the Sonoff-Tasmota Home Assistant (https://github.com/arendst/Sonoff-Tasmota/wiki/Home-Assistant) example.

Retained message are stored in broker until they are explicit delete. This can not be done by simply send a non-retain message over the retained.

To delete a retained message you have to send a retained null message to broker. If the HASS system does not make that, the wrong retained message will stay forever within broker. THIS will often make the wrong retain cmnd MQTT message which is then subscribed by Tasmota.

Is the retained null being performed by payload: "" in automations.yaml? If a MQTT client is used for this, are there MQTT client recommended for Windows 10 and iOS users and are links and documentation available this site?

I'm new to Home Assistant and Hassio. I like the look Hassio and the easy of use without having to program; however, the documentation isn't very clear in most cases. I'd rather solve the issues with Hassio but will still look at NodeRED, Domoticz or another HA that can run on a Raspberry Pi as a possible replacement for Hassio. Any recommendations would be appreciated. I'll also upgrade the sonoffs.

@ascillato, did you see any problems with my configuration other than retain: true for the lights and switches. As I stated earlier, the retain value was set to false in my initial configuration and did not solve the problem with the sonoffs switching on.

ascillato commented 6 years ago

If your config in your yaml file is with retain to false, so the retain is being done in your mqtt broker. I can't help you with Mosquitto, sorry.

mxplea10 commented 6 years ago

Should the retain value be false in the configuration (partial configuration.yaml file) below also?

mqtt:
  broker: core-mosquitto
  port: 1883
  client_id: home-assistant-1
  keepalive: 60
  username: !secret mqtt_username
  password: !secret mqtt_password
  protocol: 3.1
  birth_message:
    topic: "tele/hass1/LWT"
    payload: "online"
    qos: 1
    retain: true
  will_message:
    topic: "tele/hass1/LWT"
    payload: "offline"
    qos: 1
    retain: true
Frogmore42 commented 6 years ago

LWT messages are normally retained without issue, as far as I know.

If you read closely 2140, you will see how people solved removing the retained messages. There are at least three ways it can be done. You can send a new null retained message to delete the current one, with NodeRED or with mosquito. Or you can shut down mosquito, delete its retained message file and then restart it. Pretty sure there was a mention of all three of those. Since you have a lot of retained messages, the delete the file is probably best. Before you do that make sure you have updated the yaml to set retain to false for all commands.

Once you have updated all of that, if there is still an issue it will be clearer what it isn't.

GasTurbineMan commented 6 years ago

@mxplea10, I had similar issue as you and it did boil down to "retained messages".

1> In Tasmota web admin page, go to Config->Other and disable (uncheck) the MQTT Enable box. Then reboot Pi server and see if your Sonoff remains in the correct state. If is does, then your issue is MQTT. (don't forget to recheck the MQTT Enable box when you are through testing)

2> I deleted (set to null) my Retained topic commands using Node-Red using an INJECT node, set up as String with an empty payload box and empty topic. Connect the inject node to a MQTT output node with your complete topic (ie. cmnd/sonoffxx/POWER), QOS = 1 and Retain set True. Then put a MQTT input node and configure with same topic as above and connect it to a DEBUG output node, configured to send the message payload to the debug window. Press the DEPLOY button and then press the left end of the INJECT node. You should see in the debug window a message stating: cmnd/sonoffxx/POWER : msg.payload : string[0]

To me, the documentation as to exactly what Tasmota does and does not "publish" to the Broker is a bit confusing - as is exactly what the "PowerRetain" setting means. In my application, I am using HomeRemote and MQTT Broker on RPi3. I originally had HomeRemote configured to "publish" topics cmnd/sonoffxx/POWER set to be retained by the broker. This was wrong and was the source of my retained messages. I have since unchecked the retain box and no longer retain the topic cmnd/sonoffxx/POWER.

I believe Tasmota DOES publish the topic stat/sonoffxx/POWER to a broker. I would ask that anyone correct me if I am wrong, but I thing the "PowerRetain" option in Tasmota is telling the Broker to retain the published topic stat/sonoffxx/POWER. I choose to set PowerRetain = ON so that the broker retains the state of the relay. This way when new clients subscribe to the topic, they immediately get the current state of the relay and do not have to wait on the next relay state change, when Tasmota will publish the new state in topic stat/sonoffxx/POWER.

I do not believe PowerRetain has anything to do with the retained messages on topic cmnd/sonoffxx/POWER.

Frogmore42 commented 6 years ago

Tasmota only listens to the cmnd messages, so it is not responsible for them being retained. Only the publisher can specify that a message be retained.

mxplea10 commented 6 years ago

The problem seems to have been the retain messages in the MQTT Broker as many of you stated. Using MQTT.fx, I noticed that a lot of the topic names that I used while testing different Sonoffs were still recognized by the MQTT Broker. I cleared the retain messages of the topics that I thought were the problem with both the MQTT.fx client and with the mosquitto_pub command line by access Hass.io using SSH. This didn’t solve the problem. I verified that my configuration followed the recommended formats and that the devices were configured as recommended. I then uninstalled and reinstalled the Mosquito Broker add-on. Although it's been less than 24 hours and Home Assistant hasn't been put into production yet, this corrected the problem.

Thank you all for your input, recommendations and suggestions.