Hi,
I notice my lights were turning on by itself at random hours.
They are connect to a Sonoff T1 (3 gang) with TASMOTA.
On the history tab I notice the T1 became unavailable for some time rigth before HA turned the light on.
How can I solve this problem ?
It is a pain when this happens at 3am.
I´m running the latest Hass.io on a Raspberry Pi 3b
It would be very useful to see how you have your yaml-code set up.
and it would be great to see Logbook records covering that period of time, too.
- platform: mqtt
name: "SuiteTeto"
command_topic: "cmnd/Suite/POWER1"
state_topic: "stat/Suite/POWER1"
qos: 1
payload_on: "ON"
payload_off: "OFF"
retain: true
icon: mdi:lightbulb-on
As we can see from the Log, my Google Home speakers became unavailable at 01:04am and at 01:11am and 01:13am my lights started to change to ON.
Right after that I turned them Off.
Looking at the History tab, nothing else happened at this period.
In your OP you said
but now you say
To me these 2 statements contradict each other so you need to elaborate…
Sorry.
What I can imagine is that, at some time my wi-fi was down, and when it came back on it turned my lights ON.
Is there a way to see if my switch was down (no connection) during this period ?
This is inadvisable.
It instructs Home Assistant to publish retained messages to command_topic. Thay means the MQTT broker will store a copy of the command.
If your Sonoff device lose its Wifi connection then regains it, it will reconnect to the MQTT broker, resubscribe to topics, and immediately receive the last retained message … which might have been a command to turn on the light.
To undo this, it will take more than just settingretain: false. You will also have to purge the retained message from the broker. The easiest way to do that is with MQTT Explorer.
Agree with @123 It is retain: true causing this so change that to false and use MQTT Explorer to delete it as advised.
If they frequently go unavailable, what Tasmota firmware are you using? What core does it use? Tasmota is rock solid but MQTT disconnects were very common for many people with 6.4.x which used core 2.4.2… so I’d also be looking at that.
All my switches are on 6.5.0
Ok - that will be core 2.3.0 unless you changed something and that is very stable.
There’s also a setting in Tasmota that controls its startup behavior. Upon startup it can turn the connected device on, off, or whatever it was previously (something like that; I don’t have any Sonoff devices). Anyway, if it has been programmed to activate the device relay on startup, it only take a momentary power-glitch to cause the sonoff to restart and … turn on the attached device.
You should check the MQTT Broker’s log around the time when the sonoff turned on the light (all by itself). If the log shows the sonoff disconnecting/re-connecting to the broker, that means it either lost/regained WiFi or restarted.
I believe the default behavior is to do restart if they lose connection to either MQTT or Wifi, too, and you would end up with the same result even without a power blip.
Geez, all the more reason to pay close attention to the programming of its power-on behavior (and avoiding the use of retain: true).
I have never seen mine do that.
Sure.
The easiest way is to subscribe to its status mqtt topic and you’ll see all online/offline messages.
Or you can create a simple automation that notifies you somehow/writes to Logbook when your switch changes its state to Unavailable/goes back online, that’s easy (and you actually have that information already in your Logbook unless it’s excluded on recorder level).
There’s also a special mqtt status topic that looks like this:
I also have a lovelace card
Using the template card to extract that info and display it
So when you quoted me, you either didn’t know the context or took my quote out of context.
If you read the entire thread, you’d know the context of the discussion was the use of retain: true in the configuration of the MQTT Light component. It’s used for publishing a command message to command_topic. That’s what I said was inadvisable in my very first post and when I stated “and avoiding the use of retain: true”.
Publishing state-related information as retained messages is advisable (for the purpose of providing Home Assistant with data the moment it connects and subscribes with the broker). However that’s the responsibility of the device publishing its state.
Your so-called “summary” quoted me directly, was phrased as a rebuttal, and ended with this remark:
As for this:
a short but useful “bottom line”.
It was anything but that.
So, this is extracted from my Sonoff T1 (3CH Module) Tasmota console, just after my lights went off (for no reason)
As we can see it was a mqtt connection fail.
Any sugestions?
My wife is getting a little $ˆ$#%#$ because of this. It happens a few times a day.
00:14:27 MQT: Attempting connection...
00:14:34 MQT: Connect failed to 192.168.1.94:1883, rc -2. Retry in 10 sec
00:14:44 MQT: Attempting connection...
00:14:50 MQT: Connect failed to 192.168.1.94:1883, rc -2. Retry in 10 sec
00:15:01 MQT: Attempting connection...
00:15:07 MQT: Connect failed to 192.168.1.94:1883, rc -2. Retry in 10 sec
00:15:18 MQT: Attempting connection...
00:15:24 MQT: Connect failed to 192.168.1.94:1883, rc -2. Retry in 10 sec
00:15:29 RSL: stat/Escritorio/STATUS = {"Status":{"Module":30,"FriendlyName":["Escritorio Teto","Escritorio Cubo","Escritorio Abajur"],"Topic":"Escritorio","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":1}}
00:15:29 RSL: stat/Escritorio/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"Escritorio","OtaUrl":"http://thehackbox.org/tasmota/release/sonoff.bin","RestartReason":"Software/System restart","Uptime":"3T06:19:17","StartupUTC":"2019-05-24T16:56:12","Sleep":50,"CfgHolder":4617,"BootCount":50,"SaveCount":1683,"SaveAddress":"F9000"}}
00:15:29 RSL: stat/Escritorio/STATUS2 = {"StatusFWR":{"Version":"6.5.0(release-sonoff)","BuildDateTime":"2019-03-19T12:24:10","Boot":6,"Core":"2_3_0","SDK":"1.5.3(aec24ac9)"}}
00:15:29 RSL: stat/Escritorio/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["LobaoFotografia",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["00008029","280500000100000000000000000000000000","00000000"]}}
00:15:29 RSL: stat/Escritorio/STATUS4 = {"StatusMEM":{"ProgramSize":507,"Free":496,"Heap":12,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"144051","FlashMode":3,"Features":["00000809","0FDAE394","000783A0","23B617CE","00003BC0"]}}
00:15:29 RSL: stat/Escritorio/STATUS5 = {"StatusNET":{"Hostname":"Escritorio-4120","IPAddress":"192.168.1.142","Gateway":"192.168.1.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.1.1","Mac":"xx:xx:xx:xx:xx:xx","Webserver":2,"WifiConfig":2}}
00:15:29 RSL: stat/Escritorio/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.1.94","MqttPort":1883,"MqttClientMask":"escritorio","MqttClient":"escritorio","MqttUser":"luizlobao","MqttCount":69,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}}
00:15:29 RSL: stat/Escritorio/STATUS7 = {"StatusTIM":{"UTC":"Mon May 27 23:15:29 2019","Local":"Tue May 28 00:15:29 2019","StartDST":"Sun Mar 31 02:00:00 2019","EndDST":"Sun Oct 27 03:00:00 2019","Timezone":"+01:00","Sunrise":"04:54","Sunset":"20:40"}}
00:15:29 RSL: stat/Escritorio/STATUS10 = {"StatusSNS":{"Time":"2019-05-28T00:15:29"}}
00:15:29 RSL: stat/Escritorio/STATUS11 = {"StatusSTS":{"Time":"2019-05-28T00:15:29","Uptime":"3T06:19:17","Vcc":3.220,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":172,"POWER1":"OFF","POWER2":"OFF","POWER3":"OFF","Wifi":{"AP":1,"SSId":"LobaoFotografia","BSSId":"xx:xx:xx:xx:xx:xx","Channel":1,"RSSI":100,"LinkCount":38,"Downtime":"0T00:01:41"}}}`Preformatted text`