đź’ˇ Sensor Light - Motion Sensor - Door Sensor - Sun Elevation - LUX Value - Scenes - Time - Light Control - Device Tracker - Night Lights

Blueprints Exchange
, , , ,
4439

Hi Blacky,

First off, thanks for all the work on this blueprint — I’ve been using it for years.

I think I’ve found a bug in the bypass release logic (motion_bypass_lights_stop, trigger t8_stop) in v8.7. I’m using this in combination with the Sensor Light Add-On (movie mode), following your documented integration pattern exactly (♾ Sensor Light Add On - Media & Movie Lights - House Alarm Lights - Smoke Alarm Lights & Exhaust Fans + More - #4 by Blacky).

Setup:

  • include_bypass: bypass_enabled_stop only
  • motion_bypass_lights_stop: input_boolean.automat_link_film (the Add-On’s automation link helper)
  • bypass_time_delay: 5 (minutes) — matches my main time_delay (also 5), per your recommendation
  • Auto OFF for this bypass: not enabled, per your recommendation
  • motion_trigger: a group of 4 motion/occupancy sensors, binary_sensor.bevaegelse_2_sal

Expected behavior (per the blueprint code):
When motion_bypass_lights_stop goes from on to off (trigger t8_stop) and the motion trigger is already off, the code goes into the “By-pass is turned off & check if the motion trigger is off” branch, which does:

delay: minutes: !input bypass_time_delay

before turning the lights off. With bypass_time_delay: 5, I’d expect a 5-minute wait before the lights turn off.

Actual behavior:
The lights turn off within milliseconds of the bypass releasing — no 5-minute delay at all.

Log evidence (times in local CEST):

  • 19:56:41 — media player (movie) goes to off
  • 19:57:13.374 — input_boolean.automat_link_film goes on → off (this is the Add-On’s automation_link_time_delay of 0.5 min after the media player stopped)
  • 19:57:13.506 to 19:57:13.825 — all four stue lights (light.floss_standerlampe, light.tecnolumen_hojre, light.tecnolumen_venstre, light.floss_gulvlampe) turn off, logged as “triggered by state of input_boolean.automat_link_film” via automation.sensor_light_stue

That’s a ~130ms–450ms gap, not 5 minutes.

Confirmed the motion trigger really was off at that moment (not a sensor flakiness issue): binary_sensor.bevaegelse_2_sal was continuously on from well before the movie started until 20:27:46 — so actually the trigger’s motion state condition itself seems to have evaluated incorrectly too, since the “motion is off” branch appears to have fired despite the group sensor showing on throughout.

So there seem to be two possible issues, either of which would explain what I saw:

  1. The motion_trigger state check in the t8_stop condition branching (off vs. on) isn’t reading the live/current state correctly, and/or
  2. The bypass_time_delay wait is being skipped or bypassed somewhere in that sequence.

Happy to share the full automation trace (JSON) if that helps debug it — just let me know. Thanks again for maintaining this, it’s an incredibly capable blueprint.

Best regards