The blueprint was unconditionally overriding use_defaults to 'current',
preventing modes from specifying their own use_defaults value. This caused
Adaptive mode (which uses use_defaults: 'configuration') to keep the current
settings instead of resetting to configuration defaults.
Modified the data template to conditionally add use_defaults: 'current' only
when not already present in al_config, allowing modes like Adaptive to use
their specified value while maintaining backward compatibility.
Replace block scalar (>-) with regular quoted strings for settings_entity
templates. The block scalar was causing Home Assistant to wrap lines in
the middle of the replace() function call, breaking the template parsing.
This fixes:
- LED color not updating in mode cycling automation
- Mode settings not being applied in apply mode automation
The templates now stay on a single line and parse correctly.
Move input definitions from root level to be nested under the blueprint
section. Home Assistant requires input declarations to be under
blueprint.input, not at the root level.
This fixes import errors:
- "Missing input definition for adaptive_lighting_switch, led_color_entity, mode_input_select"
- "Missing input definition for sunrise_time, sunset_time, weekend_mode_boolean, adaptive_lighting_switch, max_brightness"
- "Missing input definition for toggle_time, weekend_mode_boolean"
Implement three core blueprints using convention-based entity lookup:
- apply_lighting_mode: Dynamic mode application with behavior polymorphism
- weekend_mode_schedule: Auto-enable/disable based on day of week
- weekend_mode_apply_settings: Apply AL adjustments for weekends
Blueprints use convention over configuration, allowing unlimited custom
modes without code changes. Modes discovered via naming pattern:
input_text.adaptive_lighting_settings_{{mode}}
