Skip to content

Latest commit

 

History

History
101 lines (70 loc) · 4.05 KB

File metadata and controls

101 lines (70 loc) · 4.05 KB

Changelog

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

[1.1.3] - 2026-05-19

Fixed

  • Better pseudo timer initialization

[1.0.9] - 2026-05-05

Fixed

  • Missed-event replay after reboot restored to full 24 h behavior — The 1.0.8 30-minute age cap for missed schedules prevented correct state restoration after longer outages (for example: last schedule was ON at 20:00, reboot/time sync at 03:00 should still replay that event so the device returns to the expected night state). find_missed now again replays the latest valid event from the last 24 h.

[1.0.8] - 2026-05-05

Fixed

  • Sunrise/sunset schedules fired hours late via missed-event detection — On first time sync (e.g. device booted at 07:38 and received time from hub), find_missed looked 24 h back and treated a sunrise event from 05:06 as "missed", firing it immediately at 07:38. Added JKK_SCHEDULE_MISSED_MAX_AGE_S (default 1800 s / 30 min): events older than 30 minutes are silently skipped rather than fired immediately. Fixed-time schedules missed by a few minutes (e.g. after a brief reboot) still fire.

[1.0.7] - 2026-05-04

Fixed

  • Sunrise/sunset+boundary schedule fired immediately via missed-schedule detection — When a schedule had both an astronomical trigger and a fixed-time boundary, two calls to jkk_schedule_get_next_time_diff() were made (sun path and boundary path). The second call overwrote trigger->next_scheduled_time_utc with the boundary time, even though the scheduler correctly selected the sun time (via MAX/MIN). On the next jkk_schedule_run_all() call the stored UTC pointed to the earlier boundary time, making the schedule appear "missed" and fire immediately. Fixed by saving and restoring next_scheduled_time_utc to match whichever path (sun or boundary) was actually chosen. Affects all four sun+boundary combinations (DAYS_OF_WEEK_SUNRISE/SUNSET, DATE_SUNRISE/SUNSET).

[1.0.6] - 2026-05-03

Fixed

  • Sunrise/sunset schedule could fire twice with a fixed-time boundary — When a sunrise or sunset schedule had both an astronomical trigger and a fixed boundary time, a post-trigger re-evaluation could incorrectly pick the boundary again later the same day. This happened because the next sun event was already on the next day, while the fixed boundary diff still pointed to "today". The scheduler now skips the same-day boundary once the matching sun event has already passed and correctly waits for the next astronomical event.

[1.0.5] - 2026-05-02

Added

  • Simplified Chinese README (README_CN.md) — ESP Component Registry and GitHub serve the appropriate language based on the browser's Accept-Language header.

[1.0.4] - 2026-05-02

Fixed

  • Sunrise/sunset with negative offset fires at wrong time — When a schedule used JKK_SCHEDULE_TYPE_DAYS_OF_WEEK_SUNRISE with a negative relative_seconds offset (e.g. -900 = 15 minutes before sunrise), the "advance to tomorrow" guard compared the current time against the raw sunrise minute instead of the effective trigger time (sunrise + offset). If the scheduler was evaluated in the window between the effective trigger and actual sunrise, the sun-based diff became negative, which as a uint32_t wrapped to a huge value. The min/max selection in jkk_schedule_get_next_schedule_time_diff then picked the fallback fixed-time (cap) instead of the sun trigger. The fix uses _cur_sec >= (int)sun * 60 + relative_seconds as the guard condition. The analogous positive-offset case for SUNSET was also affected and is corrected by the same change.

[1.0.3] - 2025

Changed

  • Cosmetic code changes.

[1.0.2] - 2025

Added

  • Description of sunrise/sunset time boundary behaviour.
  • Polish README (README_PL.md).

[1.0.1] - 2025

Added

  • Initial ESP Component Registry release setup.