Home Assistant beginners

Triggered by the state of binary_sensor.driveway_person_detected at January 19, 2026 at 5:24:30 PM

Test If Driveway Is dark is On

Turn on the light

Wait until there is no motion from device

Still running


That's the trace from right now and it should be off. Strange that it says motion when it's a person detected on or off.
 
And here is the automation. See anything wrong here.

Code: 
1767763179275'
alias: Front Door Light
description: ''
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.driveway_person_detected
    from:
      - 'off'
    to:
      - 'on'
  - trigger: state
    entity_id:
      - binary_sensor.door_sensor
    from:
      - 'off'
    to:
      - 'on'
conditions:
  - condition: state
    entity_id: binary_sensor.driveway_is_dark
    state:
      - 'on'
actions:
  - alias: Turn on the light
    action: light.turn_on
    target:
      entity_id: light.front_door_light
  - alias: Wait until there is no motion from device
    wait_for_trigger:
      - trigger: state
        entity_id:
          - binary_sensor.driveway_person_detected
        from:
          - 'on'
        to:
          - 'off'
        for:
          hours: 0
          minutes: 0
          seconds: 0
      - trigger: state
        entity_id:
          - binary_sensor.door_sensor
        from:
          - 'on'
        to:
          - 'off'
        for:
          hours: 0
          minutes: 0
          seconds: 0
  - alias: Wait the number of seconds that has been set
    delay: 120
  - alias: Turn off the light
    action: light.turn_off
    target:
      entity_id: light.front_door_light
mode: restart
max_exceeded: silent
 
For simplicities sake I’d make another automation to turn the light off when the sensors deactivate.

I can see what you’re trying to do and can’t see any reason for the light not to turn off but from experience I know HA can trip up where there’s potential for repeated restarts of an automation with timers in them.
 
I'll have a look, I think it's something else though. I just opened a door with a door sensor on so very reliable and the light didn't come on. The trace showes the door opening then the light on bit doesn't look completed before it moves on to the wait action.

Could this all be interference, I'm still on channel 20 for ZigBee and did want to move to 23 but it's a right hassle. Unless the chance channel function actually works.
 
Can you see the timeline of the bulb and see if it ever goes unavailable?

If the automation is still running, it sounds like it's either waiting to turn the bulb on, or it's waiting for motion to no longer be 'active'. Does your motion sensor also report any unavailable times, and do you see it go from detected at the time the automation was triggered, and not-detected when it should have stopped the automation?
 
Semple said:
Can you see the timeline of the bulb and see if it ever goes unavailable?

If the automation is still running, it sounds like it's either waiting to turn the bulb on, or it's waiting for motion to no longer be 'active'. Does your motion sensor also report any unavailable times, and do you see it go from detected at the time the automation was triggered, and not-detected when it should have stopped the automation?
Click to expand...
Yes you can see it go from closed to open and the automation saw it then its as if it send the light on command but the light doesnt respond, i closed and reopened the door and it came on. No sign of either being unavailable.


It being cancelled is probably when I reopened the door and a new automation started. But you can see the light on command doesn't look completed.
 
Last edited:
I'd be tempted to strip a load out and build it back up gradually sensor by sensor. Also, removing max_exceeded: silent might give you some more activity entries to see what's going on? And reduce the timeout from 120 to something like 5 so it's quickly to troubleshoot.

When doing stuff like this I've often resorted to consolidating a bunch of sensors into a new binary sensor, so you'd have one sensor that this automation runs on:
Is sensor.outsidereadiness=true for 2 secs + dark=true; then turn on light;
Is sensor.outsidereadiness=false for 2 secs; then turn off light;

Sometimes good to put in some small delays to make sure a sensor isn't bouncing in and out of your desired threshold
 
Okay yes so group the person detect and door open and closed into a single virtual entity. It's possible with different types I guess they are both binary but one is "Closed, Open" the other is "On, Off"


Separate the on and off functions, presume I can still have a delay, it's needed otherwise when you shut the door it would go off.
Or is it best to add the delay to the sensor so it needs to read closed for 120seconds before changing state, rather than a simple wait 120 seconds.

Really appreciate all this help everyone.

What even is the "max_exceeded: silent" bit for?
 
Last edited:
Personally i think it is the bulb not receiving and / or not reacting to the trigger.
I also think Bluecube and Nutrition are right and you should rewrite the code
 
Haha, that was only a guess on my part, I think it hides repeated entries in logs, but also might be hiding failures. Fine for when everything's working

And yeah you can still use a timer, but if you wrap all your contributing sensors into one you can watch for 'has this sensor been off/false for 120 secs'

Might be unnecessary, but you don't have to define which state a sensor came from, say, changing from ON to OFF. You only usually care about the OFF bit, doesn't matter eg. if it came from ON or UNAVAILABLE. So you can leave the from field blank.
 
964rs said:
Personally i think it is the bulb not receiving and / or not reacting to the trigger.
I also think Bluecube and Nutrition are right and you should rewrite the code
Click to expand...
I'm only using the blueprints at the minute if that's what you call them, the inbuilt guide where you just select the actions and devices/entities.
But I will definitely try to simplify them and do a separate on and off one.

I have never had an issue just manually turning lights on and off, granted that's not as often as the automations. They only ever fail when via an automation.
 
Last edited:
Redone the automation as two separate ones with a group.

Code: 
alias: Porch light on
description: ""
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.porch_light_sensors
    to:
      - "on"
conditions:
  - condition: state
    entity_id: binary_sensor.driveway_is_dark
    state:
      - "on"
actions:
  - action: light.turn_on
    metadata: {}
    target:
      entity_id: light.front_door_light
    data: {}
mode: restart

Code: 
alias: Porch light off
description: ""
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.porch_light_sensors
    to:
      - "off"
    for:
      hours: 0
      minutes: 2
      seconds: 0
conditions: []
actions:
  - action: light.turn_off
    metadata: {}
    target:
      entity_id: light.front_door_light
    data: {}
mode: restart

Does that look correct taking on board previous suggestions. Both set to Restart presume that's correct.
 
Last edited:
In principle yes. Now navigate to the developer page in HAOS on your phone, filter by porch_light_sensors and wait for dark :D

Check the group sensor is going on and off when expected, then it's a case of watching that to see if it's misbehaving while you count to 120 to see the light go off.
 
I have a Hue smart wireless dimmer V2 (the rectangular one with three sections), and it's attached over my light switch using one of these — IYOKI Standard Switch Cover for Hue Dimmer V2 — https://amzn.eu/d/7UXJGSK

The switch cover is fine; it does what it says on the tin. However, compared to the official Hue plate that comes with the dimmer switch, the recess that holds the switch isn't as deep, and the magnet isn't as strong. So inevitably, it's quite easy to knock the switch off the holder and send it flying across the room. Not ideal.

Can anyone recommend an alternative to the IYOKI cover that does a better job? Either another brand that makes an improved model (although I assume they all come from the same factory in China with a different brand name) or an alternative solution that covers the light switch and holds the dimmer switch better?

Cheers for any suggestions.
 
Irish_Tom said:
I have a Hue smart wireless dimmer V2 (the rectangular one with three sections), and it's attached over my light switch using one of these — IYOKI Standard Switch Cover for Hue Dimmer V2 — https://amzn.eu/d/7UXJGSK

The switch cover is fine; it does what it says on the tin. However, compared to the official Hue plate that comes with the dimmer switch, the recess that holds the switch isn't as deep, and the magnet isn't as strong. So inevitably, it's quite easy to knock the switch off the holder and send it flying across the room. Not ideal.

Can anyone recommend an alternative to the IYOKI cover that does a better job? Either another brand that makes an improved model (although I assume they all come from the same factory in China with a different brand name) or an alternative solution that covers the light switch and holds the dimmer switch better?

Cheers for any suggestions.
Click to expand...
There's quite a few options if you know someone with a 3D printer https://www.printables.com/search/models?q=hue+light+switch
 
NutritioN said:
Is there any space behind it to double up the magnets? Get a pack of those thin disk magnets.
Click to expand...
Good question. I'm not sure, but I could take a look.

To be honest, I think the shallower tray is more of an issue than the magnet — I would feel happier if the dimmer switch was more recessed.
 
You must log in or register to reply here.
Back
Top Bottom