#My doorbell event automation woke up me up at 3am... twice.

1 messages · Page 1 of 1 (latest)

pliant cairn
#

Unifi Protect updated at 3am and came back at 3:10am.

My light flash is triggered based on state changes, so yes, it went unavailable and flashed, then back to available and flashed again.

My wife is surprisingly understandable and wasn't too pissed this morning...

What are the proper states to use for doorbell event presses? Is the answer to add a condition "when event NOT set to unavailable"?

alias: Someone is ringing the doorbell
description: Flash green lights in office when someone rings doorbell
triggers:

  • trigger: state
    entity_id:
    • event.doorbell_doorbell
      conditions: []
      actions:
  • action: light.turn_on
    metadata: {}
    data:
    rgb_color:
    - 52
    - 238
    - 32
    flash: long
    target:
    area_id:
    - mys_office
    - kitchen
    - pantry
    - main_bedroom
    - master_bathroom
    mode: single
tough thicket
#

however to the problem at hand

#

its an issue with how events currently work. if a device disconnects and reconnects the last event is triggered again

pliant cairn
#

Yeah I figured. So I should add a condition to check if the event is not changed to Unknown or Unavailable

#

Ah, but then it'll flick when it comes online

tough thicket
#

the solution is to use a condition on your automation and check that the event is not stale

pliant cairn
#

gracias, I'll take a look

tough thicket
#

its solving the issue with the voice pe button. but its the same problem

#

a templated condition like this

{{ (now() - as_datetime(states('event.doorbell_doorbell')) ) < timedelta(seconds=10) }} should solve the issue

#

checks to make sure the event its triggering from is less than 10 seconds old

pliant cairn
#

I'll test it out. But wouldn't it still trigger wihtin 10 seconds of going unavailable?

tough thicket
#

the time on the event itself doesnt change its not a new event

#

its just it gets replayed with its real (old) time

#

say doorbell rings at 12:00:00
event fires with time of 12:00:00
(its not stale so condition passes)

then at 14:00 the device disconnects and reconnects
event fires with time of 12:00:00
(its stale so condition fails)

pliant cairn
#

Ah I see. the offline/unavailable event doesn't provide the event fired time? Something like that?

tough thicket
#

when device comes back online it restores to previous event as "last event" but this also triggers the event trigger

pliant cairn
#

Ahhh I see now

tough thicket
#

its a known bug and an issue with how events work currently. there is a plan to overhaul events. when that will actually happen I do not know.

#

in the mean time the condition work around should prevent middle of the night chaos

pliant cairn
#

Awesome thanks for the help