Journey event  ·  14 Sep 2026

lights_on_only never suppresses a capture — it reads a hub key that is not in hub values

lights_on_for() looks up hub_values['window_4x8_open'] / ['window_2x4_open'], but the live hub values dict carries no such top-level keys - the window state only exists nested as v

  state copied from the tracker, never improved

  event date 2026-09-14

Event date 2026-09-14
Version found
Version fixed
Expected kit firmware
Release file
SHA-256
Served count
Source https://app.notion.com/3d92b4cda370819a8e60ede064a9c7f6

lights_on_for() looks up hub_values[‘window_4x8_open’] / [‘window_2x4_open’], but the live hub values dict carries no such top-level keys – the window state only exists nested as values[‘binaries’][‘binary_sensor.dsc_hub_4x8_window_open’]. Those flat names exist solely as history metric names in _WINDOW_HISTORY_METRICS. So lights_on_for always returns None, should_capture takes the ‘window unknown – captured anyway’ branch, and lights_on_only is dead config for both spaces. Observed on 4×8-corner on 2026-09-12: 76 frames stored right through the 03:00-15:00 dark period on a camera configured lights_on_only: true, every one of them a black frame. Fix: read the nested binary (or publish the flat keys into hub values) and add a test that a dark window actually skips.

All events  ·  DSC  ·  CannaLib  ·  Site  ·  Firmware releases

Empty rows are honest

A blank cell means the tracker has no value for it. Nothing on this page is filled in to look complete.