Feat/manual schedule

[mrbillpapas]

Manual Schedule Feature

Description

This PR implements a manual_schedule configuration option (YAML only) that allows users to define specific brightness and color temperature values for exact times of the day. This is useful for users who want to enforce specific lighting scenes (e.g., getting ready in the morning, dinner time) that might differ from the standard sun-based adaptive curve.

Configuration

The manual_schedule is defined as a list of schedule points. Each point must have a time and can optionally have brightness_pct and color_temp_kelvin.

Example YAML

    
    # NEW: Manual Schedule
    manual_schedule:
      # Pre-dawn
      - time: "06:30"
        brightness_pct: 1
        color_temp_kelvin: 2000
      # Sunrise (07:12): Waking up
      - time: "07:15"
        brightness_pct: 20
        color_temp_kelvin: 2500
      # Morning Ramp
      - time: "08:30"
        brightness_pct: 80
        color_temp_kelvin: 3500
      # Solar Noon Peak
      - time: "11:50"
        brightness_pct: 100
        color_temp_kelvin: 5500
      # Afternoon
      - time: "15:00"
        brightness_pct: 100
        color_temp_kelvin: 4000
      # Sunset (16:29): Evening starts BRIGHT as requested
      - time: "16:30"
        brightness_pct: 100
        color_temp_kelvin: 3000
      # Late Evening: Gradual dim to 60%
      - time: "21:00"
        brightness_pct: 60
        color_temp_kelvin: 2200
      # Bedtime: Deep sleep mode
      - time: "23:00"
        brightness_pct: 1
        color_temp_kelvin: 2000

How it works

• The integration interpolates between these defined points.
• If a time is between two points, the values are calculated based on the linear progression between the previous and next schedule point.
• It handles timezone conversions correctly (matching the configured timezone).
• Min/Max clamping is temporarily bypassed when a manual schedule is active to ensure the defined values are reached, unless Sleep Mode is active (which takes precedence).

[protyposis]

Hi, your implementation is very clean and elegant. I’m wondering, though, whether scheduling functionality really needs to live inside AL itself, given that HA already provides the built-in Schedule integration, which could be used to trigger adaptive_lighting.change_switch_settings at configured times.

I haven't tested this, but I believe the use case you describe can already be achieved out of the box. For example, the first three scheduling points from your example could be implemented using two service calls:

1. At 06:30, call adaptive_lighting.change_switch_settings with:
   • sunrise_time: 06:30
   • min_brightness: 1
   • min_color_temp: 2000
   • max_brightness: 20
   • max_color_temp: 2500
   • sunset_time: 08:00 (yields max at 07:15)
2. At 07:15, call adaptive_lighting.change_switch_settings with:
   • sunrise_time: 07:15
   • min_brightness: 20
   • min_color_temp: 2500
   • max_brightness: 80
   • max_color_temp: 3500
   • sunset_time: 09:45 (yields max at 08:30)
3. The next service call would then occur at 08:30, and so on.

What do you think about this approach? Admittedly, it's less simple and explicit than the proposed schedule syntax, but it should cover the same functional ground. One key difference is that the service calls define transitions rather than discrete settings in time, with the target (“noon”) time being implicit via extrapolation to the configured sunset time.

That said, there may also be room to improve the existing service to support this use case more directly.