Feature Request: Scheduler for Jitter Lock

[Gorillix]

Problem

The Jitter Lock feature is very useful for keeping a computer active. However, it currently lacks a time-of-day awareness. If a user forgets to disable it, Jitter Lock can activate based on PC idle time (idle_time_initial and idle_time_max) and keep monitors on unnecessarily (e.g., overnight or on weekends), leading to wasted energy and potential screen wear.

Desired Solution Goal

To introduce a simple, configurable daily schedule for the Jitter Lock feature. This would allow users to define specific hours during which Jitter Lock is permitted to operate. The configuration, including setting the device's current time, would be managed via the existing config.htm page, utilizing the Pico's software RTC (Real-Time Clock) capabilities. This approach avoids hardware modifications.

Possible Solutions (Time Setting via config.htm)

Solution A: Manual Time Input (Minimal Code Change Focus)

• Concept: Users manually input the current local time alongside scheduler settings directly into fields on the config.htm page.
• Configuration Changes (config.htm):
  • jitter_schedule_enable: Checkbox to turn the scheduler on/off.
  • jitter_schedule_start_hour: Input field for the hour (0-23) when Jitter Lock can start.
  • jitter_schedule_end_hour: Input field for the hour (0-23) when Jitter Lock should stop.
  • set_current_hour: Input field for the user to manually enter the current hour (0-23).
  • set_current_minute: Input field for the user to manually enter the current minute (0-59).
• Firmware Logic:
  1. When the configuration is saved, the firmware parses set_current_hour and set_current_minute to initialize/update its internal software RTC.
  2. If jitter_schedule_enable is active, the firmware checks the current time from its software RTC. Jitter Lock (including its standard idle_time_initial check) is only allowed to proceed if the current hour is within the jitter_schedule_start_hour and jitter_schedule_end_hour window.
• Why "Minimal": This approach minimizes JavaScript complexity in config.htm for time acquisition, relying on simple HTML input fields and firmware-side parsing of these values.

Solution B: JavaScript-Fetched Time (Enhanced User Experience)

• Concept: Users click a button on the config.htm page, which uses JavaScript to fetch the current time from their computer and sends it to the DeskHop.
• Configuration Changes (config.htm):
  • jitter_schedule_enable: Checkbox.
  • jitter_schedule_start_hour: Input field (0-23).
  • jitter_schedule_end_hour: Input field (0-23).
  • A "Sync Time with PC" button.
• config.htm / Firmware Logic:
  1. The "Sync Time with PC" button, when clicked, uses JavaScript (new Date()) to get the local time from the user's browser.
  2. When the configuration is saved, these time components (hour, minute) are transmitted to the DeskHop (likely via the existing WebHID mechanism used for saving other settings).
  3. The firmware uses these components to initialize/update its software RTC.
  4. Scheduler operational logic is the same as in Solution A.
• Advantages: More user-friendly, reduces risk of manual time input errors, and leverages existing JavaScript/WebHID capabilities if config.htm already uses them for saving configurations.

Important Considerations for Both Solutions

• Power Loss: Since the Pico has no battery-backed hardware RTC, its software RTC will reset upon power loss. The user will need to re-set the current time via config.htm after each power cycle for the scheduler to function correctly according to wall-clock time.
• Clock Drift: The Pico's internal software clock will experience some drift over time. Periodic re-syncing/setting of the time would be beneficial.
• Scope: For initial simplicity, this request focuses on a daily hour-based schedule. Extending it to include day-of-the-week scheduling (e.g., M-F only) would be a further enhancement, requiring a way to set/sync the current day as well.

This proposal aims to provide a useful scheduling feature with a low barrier to implementation by leveraging existing mechanisms and avoiding hardware changes.

[hrvach]

I must confess this is the best and most thoroughly written feature suggestion I've seen!

Btw did you try the screensaver max time setting? The idea is that it can work up to X and then deactivates itself. This would address the weekends and nights with long inactivity periods. Would having a time/clock based solution still be preferable?

[Gorillix]

Wow, thanks so much for the compliment! I really appreciate that. And yeah, I definitely wanted to make sure I did my homework this time, especially after my little "keyboard in the wrong port" flub in issues post earlier. I even enlisted Gemini's help to get my thoughts and findings organized.

To answer your question, yes, I did try the screensaver max time setting. It did work some of the time with a 4-hour setting, and you're right, it's a pretty good workaround for those long inactivity periods like weekends (assuming no curious cats jump on the keyboard while I'm away!). The main snag I hit is that if I happen to touch the PC after the timeout kicks in, it seems to reset the timer, which can be a bit annoying late at night.

Given that my PCs are rarely turned off (unless a Python script decides to go full murderhobo on my PC!), a dedicated time/clock-based solution would still be my preferred approach for consistency.