[slider]

The display schedule (CEC power-off plus local blanking) used one pair of on/off times for every active day. Shops rarely keep the same hours all week.

Adds an optional per-weekday override stored as
display_power_day_times ('D=HH:MM-HH:MM', comma-separated). A weekday without an entry keeps using the shared on/off times, and the default is empty, so existing schedules behave exactly as before.

• lib/display_power: parse/format helpers and should_be_on() taking the overrides. An overnight period still belongs to the day it starts, now with that day's own off time.
• Settings page: a "Different hours per day" toggle that swaps the shared time fields for one row per weekday (day chip + on/off times). Switching it on seeds every row from the shared times.
• v2 device settings: new display_power_day_times field on GET and PATCH (additive; malformed entries or a weekday given twice are a 400).

Checklist

• I have performed a self-review of my own code.
• New and existing unit tests pass locally and on CI with my changes.
• I have done an end-to-end test for Raspberry Pi devices.
• I have tested my changes for x86 devices.
• I added a documentation for the changes I have made (when necessary).

[vpetersson-bot]

LGTM. Approving.

What I checked:

• should_be_on rewrite. With no per-day overrides, I compared the new function against the previous implementation on 20,000 random (on, off, days, now) combinations, including overnight windows and partial day sets. The results were identical, so existing schedules behave exactly as before. The new per-day and overnight-tail tests in tests/test_display_power.py pass locally. The "tail of yesterday's window first, then today's own window" ordering handles the mixed cases well: a shared overnight window running into an overridden morning, and an override rescuing shared times that can't be used.
• Storage/API. parse_day_times is lenient for the beat and parse_day_time is strict for the v2 serializer, which matches how parse_hhmm/parse_days are already split. Rejecting a weekday given twice with a 400, instead of silently picking one, is the right call. The empty default keeps existing installs unchanged.
• Settings form. Each set of day chips is disabled both server-side and through :disabled when it's hidden, so display_power_days is posted exactly once with or without JS. An invalid per-day row keeps that day's previous hours and shows an error, consistent with the shared time fields.

Non-blocking follow-ups:

1. website/content/docs/display-schedule.md still describes a single on/off pair. The field reference table is missing display_power_day_times (format D=HH:MM-HH:MM, Monday=0, empty = shared times). The "Days and overnight schedules" section should also say that an overnight period ends on its starting day's off time. The checklist marks docs as done, but this page wasn't touched. Fine as a quick follow-up PR. (website/data/openapi.json is regenerated on deploy, so nothing to do there.)
2. Nit: import re inside test_settings_renders_per_day_hours should move to the module imports.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[vpetersson-bot]

Re-approving at 3d14deb. The dismissal followed the new commit, which only changes docs and test imports.

• display-schedule.md: I checked it against the code. The overnight example matches should_be_on: Friday 18:00 → 02:00 is still on at Sat 01:00, off at 02:00, and Saturday's own window starts at 10:00. "Switching it off clears the per-day hours" matches _apply_display_power_day_times. The API rules match validate_display_power_day_times: sorted HH:MM output, a 400 for a malformed entry, identical on/off times or a duplicate weekday, and blank clears every entry. "The form rejects identical times" matches too: the row is ignored with an error message and the day keeps its previous hours.
• tests/test_template_views.py: the function-local import re statements move to a single module-level import. No behaviour change.

[vpetersson-bot]

False positive. str(exc) here is only ever one of the operator-readable ValueError messages raised in display_power.parse_day_time (format, weekday range, HH:MM, on == off). parse_hhmm returns None rather than raising, so no traceback or internal state reaches the response. It's the same 400-with-message pattern validate_display_power_days already uses. Safe to dismiss as "false positive"; my approval at 3d14deb stands.