Mystery of my garage door that opened in the night :-/

Configuration
1

This morning I woke up to find my garage door open! I went straight to HA and seems it was opened at 23:54:25 the night before. This is taken from my logbook:

image

I have had this garage door setup in HA for 4+ years (it was actually the very thing that made me get HA) and, in general, it works fine. This is the first time I have had this happen. For the most part the door is open via Google Assistant by saying ‘…open the garage door’. The only people who can do this are myself and my wife and both of us were asleep. I do not have any automations that open the garage door.

When I open the door via Google normally it says the same thing in the Logbook - i.e. ‘…opened by Home Assistant Cloud’ so this leads me to think that it was triggered by Google. Yet in both of our My Activity logs in the Google Assistant apps show nothing happening around that time.

I am at a loss to work out what caused this. I also checked the HA log file and there is no mention of the garage door in there at that time. I know this is an odd one but does anyone have any other ideas about how to work out what caused this?

Cheers.

2

Alexa allows you to review past audio calls/triggers

Can’t remember if Google does the same but you should start there

3

What kind of device is opening/closing the garage door? Tasmota driven?

4

Funny you should have this issue as I had it the same last week.

Woke up in the morning to a garage door closed alert on my smartwatch and when I checked my wife had closed it. I have a camera in the garage and it opened at 22:45 the night before. I have an automation that will close it between midnight and 7am but it did not trigger as the garage opened before that.

I am using a Wemos D1 mini running ESPHome. I use MQTT only and not the API as I found that power cycles when using the API would cause it to open if closed.

In my logs last week I could only see an offline alert for another device at the same time so I was thinking that a WiFi glitch caused this to open but I’m not sure.

I now have the automation checking much sooner in the night now and my nightime routine will close it if it was open but a very strange issue.

5

Have you an UniFi-gateway (besides other UniFi gear) in your LAN?

I am asking because I did upgrade the Firmware of the USG-Pro 4 in our LAN from v.4.4.55.5377109 to v.4.4.56.5449062. Soon after some of my Tasmota plugs and switches started to switch on and off by themseves without leaving any traces in the HA logs.

A closer look at the Logs of those devices only showed:

Restart Reason: exception occured
instead of
Restart Reason: Software/System restart

Rolled back to Firmware v.4.4.55.5377109 and no ghostly swtching anymore eversince (~24 hours).

6

Nah, TP link router. No recent updates to it and its never done this before.

7

A few weeks ago, I was at my neighbours a few doors down. Normally when I leave I ask Google to “turn on the garden light” which it does.

Upon returning home though, I discovered every light that is exposed to Google was turned on, and the log claimed they were turned on by Home Assistant Cloud. There was nothing in my Google Activity page - other than me asking for the garden light specifically to be turned on, a request which was understood and responded to with “sure, turning on the Garden Light”.

On the odd occasion where my request to turn on or off a light, is misheard as “turn on/off the lights” which Google takes to mean every single light it knows about, it normally responds with something like “sure, turning on 26 lights”. So I know that Google hasn’t misheard me when I asked for the garden light specifically to be turned on.

8

Check how you are publishing a payload to the command topic. It should not be published as a retained message. If it is, the command is retained (stored) on the MQTT broker. If the D1 restarts, or their’s a temporary glitch in its Wi-Fi connection, the moment it reconnects to the broker and re-subscribes to the command_topic, it will instantly receive the last retained command (which might have been to open the door). This has happened to others and is a common cause of seemingly unsolicited commands.

9

Good point. I just added retain: false to the ESPHome switch component :grinning:

10

It’s Home Assistant that publishes to the device’s command_topic. How is the device modeled in Home Assistant? As an MQTT Cover or MQTT Switch or what? Whatever it is, check its configuration in Home Assistant.

11

The switch is done with ESPHome -

switch:
- platform: gpio
  id: relay
  pin:
    number: D1 # change to D1
    inverted: False
  restore_mode: ALWAYS_OFF
- platform: template
  name: "Garage Door"
  icon: "mdi:garage"
  retain: false
  turn_on_action:
  - switch.turn_on: relay
  - delay: 1s
  - switch.turn_off: relay

I can call the switch from within HA in a card or via NR.

13

I am using a Wemos D1 mini running ESPHome. I use MQTT only and not the API as I found that power cycles when using the API would cause it to open if closed.

Snap! I have exactly the same setup - a Wemo D1 Mini running ESPHome using MQTT.

I will definately be setting up a backup automation to close the door after a certain time now.

14

Have you an UniFi-gateway (besides other UniFi gear) in your LAN?
I am asking because I did upgrade the Firmware of the USG-Pro 4 in our LAN from v.4.4.55.5377109 to v.4.4.56.5449062. Soon after some of my Tasmota plugs and switches started to switch on and off by themseves without leaving any traces in the HA logs.

That is interesting to hear - I also have a USG setup although I do not have the USG-Pro4. I have the USG-3P running v4.4.55.5377096 which was the latest. Although looking today it seems there is a newer version so I wonder if this has had an impact like you have suggested. Cheers.

15

Check how you are publishing a payload to the command topic. It should not be published as a retained message. If it is, the command is retained (stored) on the MQTT broker. If the D1 restarts, or their’s a temporary glitch in its Wi-Fi connection, the moment it reconnects to the broker and re-subscribes to the command_topic, it will instantly receive the last retained command (which might have been to open the door). This has happened to others and is a common cause of seemingly unsolicited commands.

Hmm interesting. I have to admin that I am not an expect at MQTT so once I get it to work it usually gets left in that state. My current cover is configured as :

cover:
  - platform: mqtt
    name: garage_door
    state_topic: "garage/door"
    command_topic: "garage/button"
    payload_open: "OPEN"
    payload_close: "OPEN"
    payload_stop: "OPEN"
    state_open: "OPENED"
    state_closed: "CLOSED"
    optimistic: false
    retain: false
    value_template: "{{ value }}"

Does this relate to the last received command or is that something that is local to the Wemo? Cheers.

16

The MQTT Cover configuration looks good. It has retain: false which means that commands are not retained on the broker and that’s fine.

You should probably keep retain: true for the ESPHome configuration. You want the physical device’s status to be stored on the broker. When Home Assistant restarts and re-connects to the broker, it will immediately receive the device’s (stored) status.