Bizarre! Garage door opener is being triggered by?

Earlier today I discovered my garage door was open. I went to bed about 1:30 am and it was opened (by ???) at 3:02 am and remained that way until I happened to notice in HA it was open (working from home all day) so I closed it. A little while ago, I took the garbage out and tapped the garage door opener to open the door, then tapped it to close the door and returned to my desk. I then looked up a contact on my phone to complete an online form and heard the garage door open. I went to HA and closed it then looked at logbook…

image

I have an automation to announce on Alexa all devices if I am home and if the garage door has been open for 20 minutes but I did not hear that at 3:20 am last night. I modified it to wait another 2 minutes and if the door is still open to toggle the mimolite but that automation was not triggered just now as it was less than 20 minutes since opening/closing it to take out the garbage…
No idea what triggered the mimolite switch…

Short of the MIMOlite malfunctioning and causing the door to open and close on its own I would suggest opening that entity and see what all is related to it - you may find there is a script or automation that is getting triggered and causing it to open on you.

For example, looking here I can see I have two automations for my door, if I was having problems I could drill into those and debug:

Which zwave integration are you using?

OpenZWave (standalone) on RPi 3B+ with ZWave.me card (everything else running on HA Blue)…

I have two “links” to the mimolite:
image

cover:
  - platform: mqtt
    name: "Garage Door Opener"
    unique_id: mqtt-garage-door-opener
    device_class: 'garage'
    device:
      identifiers: "z-wave"
      manufacturer: "FotrezZ"
      model: "MIMOlite"
      name: "MIMOlite"
      sw_version: "1.17"
      via_device: "OpenZWave"
    command_topic: "OpenZWave/1/command/setvalue/"
    state_topic: "OpenZWave/1/node/11/instance/1/commandclass/48/value/189530128/"
    payload_open: '{ "ValueIDKey": 155795472, "Value": true }'
    payload_close: '{ "ValueIDKey": 155795472, "Value": true }'
    payload_stop: '{ "ValueIDKey": 155795472, "Value": true }'
    value_template: "{% if value_json.Value %} open {% else %} closed {% endif %}"
    optimistic: false
    retain: true

It might be the MQTT cover I created a few weeks ago…

Agh! WTF is all this crap?



I’ll have to dig inside the ozw config…

If you’re on an up to date home assistant, then you’d see who did it with a ‘by XYZ’ in the logbook. Seeing that the context is missing from the logbook, you either have an older version of HA or the signal came from the device itself.

You said you’re running OpenZwave (standalone), how is it connected to HA?

It might also be that the door is being opened by a garage door opener remote control, perhaps another person in your neighborhood has a door with the same code, or your opener remote is malfunctioning or needs new batteries. You could try clearing all codes from your garage door opener and re-pair your remotes to re-code them.

@petro ozwdaemon in docker on pi:
image
is seen by the OZW integration:
image

I’m up to date…

System Health

version: 2021.1.5
installation_type: Home Assistant OS
dev: false
hassio: true
docker: true
virtualenv: false
python_version: 3.8.7
os_name: Linux
os_version: 5.9.16
arch: aarch64
timezone: America/Vancouver

GitHub API: ok
Github API Calls Remaining: 4541
Installed Version: 1.10.1
Stage: running
Available Repositories: 787
Installed Repositories: 77

can_reach_server: ok
remaining_requests: 41

logged_in: true
subscription_expiration: February 4, 2021, 4:00 PM
relayer_connected: true
remote_enabled: false
remote_connected: false
alexa_enabled: true
google_enabled: true
can_reach_cert_server: ok
can_reach_cloud_auth: ok
can_reach_cloud: ok

host_os: Home Assistant OS 5.10
update_channel: stable
supervisor_version: 2021.01.7
docker_version: 19.03.13
disk_total: 113.9 GB
disk_used: 17.2 GB
healthy: true
supported: true
board: odroid-n2
supervisor_api: ok
version_api: ok
installed_addons: motionEye (0.11.0), File editor (5.2.0), Home Panel (1.8.3), UniFi Controller (0.20.0), Mosquitto broker (5.1), TasmoAdmin (0.13.1), Samba share (9.3.0), Home Assistant Google Drive Backup (0.103.1), AppDaemon 4 (0.4.0), ESPHome (1.15.3), Log Viewer (0.9.1), Node-RED (8.0.1), JupyterLab Lite (0.3.1), Duck DNS (1.12.4), Glances (0.10.0), InfluxDB (4.0.1), MariaDB (2.2.1), SSH & Web Terminal (7.8.0), NGINX Home Assistant SSL proxy (3.0.1), AdGuard Home (3.0.0)

dashboards: 2
mode: storage
views: 1
resources: 44

That’s a possibility too, thanks.
My ex had trouble with one of her doors spontaneously opening. Tried everything…in the end she just left it unplugged. Recently she got a new opener…

I have the same thing for my mimolite. Not sure what those values are, I have nothing hooked up to them.

I do have 1 question, why do you have an MQTT cover as well as the openzwave integration devices?

For clarification, I’m using a template cover, not an MQTT cover to marry the switch & tilt sensor:

  - platform: template
    covers:
      garage_door:
        friendly_name: "Garage Door"
        value_template: "{{ is_state('binary_sensor.garage_door_tilt', 'on') }}"
        open_cover:
          service: switch.turn_on
          entity_id: switch.fortrezz_mimolite_switch
        close_cover:
          service: switch.turn_on
          entity_id: switch.fortrezz_mimolite_switch
        stop_cover:
          service: switch.turn_on
          entity_id: switch.fortrezz_mimolite_switch

Here’s a potential source of the problem:

The option instructs Home Assistant to publish payloads to command_topic as retained messages. It means when Home Assistant sends a command to open the door, that command is stored on the MQTT Broker.

Let’s say the OpenZwave integration disconnects from the MQTT Broker. When it reconnects, it re-subscribes to all topics. If any of those topics contain a stored payload, and they will if they were published as retained messages, that payload is passed to the device. In other words, the last command Home Assistant published to command_topic is immediately received by the device. If the last command was to open the door, that’s what the device will do.

If you search this forum, you’ll find other examples of ‘spooky behavior’ where lights, switches, and garage doors activated themselves in the wee hours of the night. Most often it’s because the command was published as a retained message and the device disconnected/re-connected.

As a rule of thumb, it’s best to avoid publishing a command as a retained message. Conversely, it’s useful if a device publishes its status as a retained message.

To fix the problem, you need to:

  1. Set retain: false
  2. Restart Home Assistant
  3. Purge the retained message

An easy way to purge a retained message is directly from Home Assistant as described here:

1 Like

The impetus for creating the cover entity was Alexa. It needed to be cover.garage_door_opener so that device_class: could be garage.

Is yours defined under cover: or sensor: ?
I originally tried code like that in my covers.yaml but HA complained about something…
I retried my code and the message was about toggle. I don’t know why I had it there…likely a copy/paste from somewhere.
This code works:

(cover:)
  - platform: template
    covers:
      garage_door:
        friendly_name: "Garage Door Opener"
        unique_id: zwave-garage-door-opener
        device_class: 'garage'
        value_template: >-
         {{ is_state('switch.mimolite_switch','on') }}
        open_cover:
          service: switch.turn_on
          entity_id: switch.mimolite_switch
        close_cover:
          service: switch.turn_on
          entity_id: switch.mimolite_switch
#        toggle:
#          service: switch.toggle
#          entity_id: switch.mimolite_switch
        stop_cover:
          service: switch.turn_on
          entity_id: switch.mimolite_switch

and Alexa is happy with it. So I will abandon the MQTT approach although the retain: true was the likely ghost that opened my door!

That is the item in the mqtt config that I was suspecting and was going to try changing!
Thanks for clarifying it.

You’re welcome. After making the change and restarting Home Assistant, don’t overlook to purge the existing retained message as described in the link. That’s an important step to erase whatever is already there.

it’s a template cover and I use it with alexa.

How are you integrated with Alexa? Via Alexa Smart Home Skill, Hasska, or NabuCasa?

I’ve changed config from MQTT cover to a templated cover, HA restarted, old MQTT entity deleted from HA, topic purged via HA service (although I likely could have just deleted the topic via MQTT Explorer as that seems to have been the result of the HA servcie call) and deleted the old entity from Alexa. Hopefully no more ghosts at 3am checking out my precious garage junk!

I first configured he Alexa Smart Home Skill. I’ve since enabled NabuCasa and I rather like it’s UI to immediately expose/hide entities/domains rather than having to edit yaml and restart HA when there were changes to be made. I’ve got 9 days left on the 30-day trial…

Make a user/person named Alexa. When you sign into home assistant via the alexa app, use that log in. Then your logbook will let you know that Alexa performed actions.

Well that’s certainly another way to circumvent the whole retain: true issue. :slight_smile:

I didn’t realize you had MQTT Explorer, otherwise I would have suggested it because it makes purging a retained message a trivial task. Anyway, now you know the mechanics of it and that it can be done from any MQTT client.

Let us know if you get any more unsolicited openings of the garage door.

1 Like