Add configurable update interval for LTR390 sensor

[bharvey88]

Summary

This PR implements the configurable update interval requested in #54 for the LTR390 light sensor.

• LTR390 Update Interval: Allows users to adjust the sensor update frequency from the default 60 seconds to any value between 1-300 seconds

Changes

Number Input Added

• LTR390 Update Interval - Configurable sensor polling rate (1-300 seconds, default: 60s)

Sensor Configuration Updates

• Set LTR390 update_interval to never (disables automatic polling)
• Added global variable ltr390_last_update to track last sensor update time
• Added interval component that runs every 1 second to check if configured interval has elapsed
• Manually triggers sensor update via component.update() when needed

Technical Details

Why use interval component?
ESPHome sensor platforms don't support templatable update_interval parameters. Attempting to use a lambda for update_interval results in compilation error: "This option is not templatable!"

How it works:

1. LTR390 sensor automatic updates are disabled (update_interval: never)
2. A 1-second interval checks elapsed time since last update
3. When configured interval is reached, manually triggers id(ltr_390).update()
4. Tracks update time in global variable for next interval calculation

The setting:

• Uses ESPHome template number platform
• Is categorized as CONFIG entity for proper grouping in the web UI
• Persists values across device reboots (restore_value: true)
• Is immediately accessible through the device's web interface on port 80
• Updates take effect immediately without reboot

Benefits

Users can now adjust the LTR390 sensor update frequency without:

• Editing YAML configuration files
• Recompiling firmware
• Reflashing the device
• Rebooting the device

Simply adjust the value through the web interface and the sensor will update at the new interval.

Testing

• YAML syntax validated
• Configuration follows existing patterns (similar to DPS Temperature Offset)
• Backward compatible (uses default value of 60s matching current behavior)
• Interval component approach is standard ESPHome pattern for dynamic timing

Resolves

Closes #54

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features
  • Added a configurable update-interval setting for the LTR390 light sensor to control reading frequency.
• Improvements
  • Sensor now uses interval-based polling for consistent, timed updates.
  • Added tracking of the last update time to ensure accurate scheduling and prevent redundant updates.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Warning

Rate limit exceeded

@bharvey88 has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 46 minutes and 49 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

Walkthrough

Added a public template number entity and a global timestamp, and implemented interval-based polling (1s timer) to drive LTR390 updates by comparing now vs last update and calling the sensor's update when the user-configurable interval elapses. Two identical 1s interval blocks were added.

Changes

Cohort / File(s)	Summary
Core integration + globals Integrations/ESPHome/Core.yaml	Added global ltr390_last_update (uint32_t) with initial 0 and restore_value: no.
User-configurable number entity Integrations/ESPHome/Core.yaml	Added number.ltr390_update_interval (template number) — initial 60s, min 1s, max 300s, CONFIG category, optimistic.
LTR390 polling logic Integrations/ESPHome/Core.yaml	Set LTR390 sensor update_interval: never. Added two identical 1s interval blocks that read current time and ltr390_last_update, compare against ltr390_update_interval, call ltr_390.update() when elapsed, and store current_time to ltr390_last_update.

Sequence Diagram(s)

sequenceDiagram
    autonumber
    participant User as User (UI/Config)
    participant Num as Number Entity\n`ltr390_update_interval`
    participant Timer as 1s Interval Timer
    participant Globals as Global Storage\n`ltr390_last_update`
    participant Sensor as LTR390 Sensor

    User->>Num: set interval (seconds)
    Note right of Num: stored as entity state
    Timer->>Globals: read `ltr390_last_update`
    Timer->>Num: read `.state` (interval)
    Timer->>Timer: compute current_time = millis()/1000
    alt current_time - last_update >= interval
        Timer->>Sensor: call update()
        Sensor-->>Globals: return (success)
        Timer->>Globals: write `ltr390_last_update = current_time`
    else not yet elapsed
        Timer-->>Timer: wait next tick
    end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐇 I hop the seconds, count each beat,
A dial for light, now quick and neat,
I store the time, then call the sun,
Small paws, big changes — updates run.

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Linked Issues check	⚠️ Warning	The PR partially addresses issue #54: it implements the configurable update interval requirement but does not implement the requested lux offset setting.	Implement the lux offset setting as requested in issue #54 to fully satisfy the linked issue requirements.
Out of Scope Changes check	⚠️ Warning	The PR contains out-of-scope changes: a duplicate interval block performing identical update logic appears to be redundant and unrelated to core functionality.	Remove the duplicate interval block to eliminate redundant update polling and clarify the intended behavior.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change—adding a configurable update interval for the LTR390 sensor—and is clear and specific.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feature/ltr390-configurable-settings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@Integrations/ESPHome/Core.yaml`:
- Around line 164-176: Add a new template number sensor named ltr390_lux_offset
(same pattern as DPS310 temperature offset: restore_value true, initial_value 0,
wide min/max, unit "lx", entity_category "CONFIG", optimistic true,
update_interval never, step 1, mode box) right after the existing template
numbers block; then update the LTR390 light filter lambda so the filter uses the
offset by changing the current_value assignment from the hardcoded value to
incorporate the offset (replace the current_value assignment with one that adds
id(ltr390_lux_offset).state), ensuring you reference the id ltr390_lux_offset in
the lambda.