Skip to content

Add rule1_time_window and rule1_weekday auto modes#133

Merged
partach merged 1 commit into
mainfrom
claude/add-from-grid-plus-mode-iqMQm
May 30, 2026
Merged

Add rule1_time_window and rule1_weekday auto modes#133
partach merged 1 commit into
mainfrom
claude/add-from-grid-plus-mode-iqMQm

Conversation

@partach
Copy link
Copy Markdown
Owner

@partach partach commented May 30, 2026

Two new opt-in select entities (default: manual) that let the user delegate management of the two rule 1 registers the integration was previously leaving alone:

  • rule1_time_window: auto → writes start_time=00:00, stop_time=23:59 (Felicity's 24-hour convention; firmware rejects stop=00:00 or stop=24:00).
  • rule1_weekday: auto → writes effective_week=0x7F (all 7 days).

Implementation:

  • coordinator._apply_rule1_auto_settings() runs every cycle. Writes are idempotent: it reads the current register value back from self.data and only writes when the value differs from the target. After a successful write, self.data is updated locally so subsequent ticks immediately see the match and skip.
  • Called from the main update loop after _calculate_available_info so the warning check (_check_rule1_window_conflict) sees the corrected state in the same cycle.
  • Default is "manual" so existing user-configured restrictions are preserved unless the user explicitly opts into auto.

This complements the rule1_window_warning (advisory banner) — users who don't want to manage rule 1's window themselves can flip both selects to auto and the warning will resolve automatically as the integration brings the registers into sync.

Two new opt-in select entities (default: manual) that let the user
delegate management of the two rule 1 registers the integration was
previously leaving alone:

- rule1_time_window: auto → writes start_time=00:00, stop_time=23:59
  (Felicity's 24-hour convention; firmware rejects stop=00:00 or
  stop=24:00).
- rule1_weekday: auto → writes effective_week=0x7F (all 7 days).

Implementation:
- coordinator._apply_rule1_auto_settings() runs every cycle.  Writes
  are idempotent: it reads the current register value back from
  self.data and only writes when the value differs from the target.
  After a successful write, self.data is updated locally so subsequent
  ticks immediately see the match and skip.
- Called from the main update loop after _calculate_available_info so
  the warning check (_check_rule1_window_conflict) sees the corrected
  state in the same cycle.
- Default is "manual" so existing user-configured restrictions are
  preserved unless the user explicitly opts into auto.

This complements the rule1_window_warning (advisory banner) — users
who don't want to manage rule 1's window themselves can flip both
selects to auto and the warning will resolve automatically as the
integration brings the registers into sync.
@partach partach merged commit c20303b into main May 30, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants