Telegram support #18
Telegram support #18
Conversation
WalkthroughThe pull request modifies the Home Assistant auto-update scheduled blueprint, introducing significant enhancements to update automation. The changes include new input fields for more granular control over update scheduling, backup processes, and entity selection. The blueprint now supports more flexible update windows, allows specific entity inclusion modes, and provides improved logging and notification mechanisms. The version has been updated to reflect these substantial modifications. Changes
Assessment against linked issues
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (4)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml (4)
391-400: Add validation for Telegram target ID.The Telegram target ID input should include validation to ensure it's a valid numeric value. Consider adding a pattern validator.
selector: text: + pattern: "^-?\\d+$" + type: number
283-294: Consider reducing the maximum backup timeout.The maximum backup timeout of 600 minutes (10 hours) seems excessive and could lead to very long automation runs. Consider reducing this to a more reasonable value, such as 180 minutes (3 hours).
max: 600 + max: 180 unit_of_measurement: minutes
573-582: Simplify the monthday scheduling logic.The monthday scheduling logic is complex and could be simplified for better maintainability. Consider extracting the template into a reusable macro.
value_template: > + {%- macro is_valid_update_day() -%} {{ (now().day >= input_schedule_monthday_earliest or input_schedule_monthday_earliest == 0) and ( now().day <= input_schedule_monthday_last or input_schedule_monthday_last == 0 or input_schedule_monthday_last < input_schedule_monthday_earliest ) }} + {%- endmacro -%} + {{ is_valid_update_day() }}
842-855: Improve Telegram message formatting.The Telegram messages could be better formatted using Markdown for improved readability.
data: title: '{{ telegram_title }}' target: "{{ input_notification_telegram_target_id }}" disable_notification: '{{ input_notification_telegram_disable_notification }}' + parse_mode: "MarkdownV2" + message: '*{{ telegram_title }}*\n\n{{ log_message | replace(".", "\\.") | replace("-", "\\-") | replace("_", "\\_") }}' - message: '{{ log_message }}'
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml(13 hunks)
🔇 Additional comments (2)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml (2)
Line range hint
1-1526: Great implementation of Telegram notifications!The overall implementation of Telegram notifications is well-structured and comprehensive. The code:
- Provides flexible configuration options
- Allows selective notification of different update stages
- Includes proper error handling
- Maintains good separation of concerns
34-34: Version number indicates a future date.The version number
v2025.1.0appears to use a future date. Consider using the current year (2024) for the version number.
| update_timeout: | ||
| name: Update Timeout | ||
| description: | | ||
| Maximum time to wait for each update to complete. | ||
|
|
||
| This protects the automation of waiting forever for an update that fails. | ||
|
|
||
| Usually updates don't take that very long, | ||
| so feel free to ajust this time to something that fits better your environment. | ||
|
|
||
| The default is 600 seconds (10 minutes). | ||
| You can select any value between 10 seconds and 7200 seconds (2 hours). | ||
|
|
||
| If an update times out: | ||
| - The automation will log an error message | ||
| - The automation will continue with the next update | ||
| - The timed-out update may still complete in the background | ||
| default: 600 | ||
| selector: | ||
| number: | ||
| min: 10 | ||
| max: 7200 | ||
| step: 10 | ||
| unit_of_measurement: seconds |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Increase the default update timeout.
The default update timeout of 600 seconds (10 minutes) might be too short for some updates, especially for core updates or large addons. Consider increasing the default to 20 minutes while keeping the range configurable.
default: 600
+ default: 1200
selector:
number:
min: 10
max: 7200📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| update_timeout: | |
| name: Update Timeout | |
| description: | | |
| Maximum time to wait for each update to complete. | |
| This protects the automation of waiting forever for an update that fails. | |
| Usually updates don't take that very long, | |
| so feel free to ajust this time to something that fits better your environment. | |
| The default is 600 seconds (10 minutes). | |
| You can select any value between 10 seconds and 7200 seconds (2 hours). | |
| If an update times out: | |
| - The automation will log an error message | |
| - The automation will continue with the next update | |
| - The timed-out update may still complete in the background | |
| default: 600 | |
| selector: | |
| number: | |
| min: 10 | |
| max: 7200 | |
| step: 10 | |
| unit_of_measurement: seconds | |
| update_timeout: | |
| name: Update Timeout | |
| description: | | |
| Maximum time to wait for each update to complete. | |
| This protects the automation of waiting forever for an update that fails. | |
| Usually updates don't take that very long, | |
| so feel free to ajust this time to something that fits better your environment. | |
| The default is 600 seconds (10 minutes). | |
| You can select any value between 10 seconds and 7200 seconds (2 hours). | |
| If an update times out: | |
| - The automation will log an error message | |
| - The automation will continue with the next update | |
| - The timed-out update may still complete in the background | |
| default: 1200 | |
| selector: | |
| number: | |
| min: 10 | |
| max: 7200 | |
| step: 10 | |
| unit_of_measurement: seconds |
There was a problem hiding this comment.
I've implemented this locally and it will be included in the next commit.
There was a problem hiding this comment.
@edwardtfn Thanks for implementing the change! Looking forward to seeing it in the next commit.
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
| value_template: > | ||
| {{ ( states.update | ||
| | selectattr('state', 'eq', 'on') | ||
| | selectattr('entity_id', 'in', pending_update_list) | ||
| | rejectattr('entity_id', 'in', core_update_entity) | ||
| | rejectattr('entity_id', 'in', os_update_entity) | ||
| | selectattr('entity_id', 'in', firmware_update_entities) | ||
| | rejectattr('entity_id', 'in', input_update_exclusions) | ||
| | map(attribute='entity_id') | ||
| | list | count | int(0) ) > 0 | ||
| }} | ||
| - if: "{{ input_verbose_logging_bool }}" | ||
| then: | ||
| - alias: "Update - Core - Logbook - Updating" | ||
| continue_on_error: true | ||
| action: logbook.log | ||
| data: | ||
| name: Auto-update | ||
| entity_id: '{{ this.entity_id }}' | ||
| message: "Updating {{pending_update_list[0]}} of {{pending_update_list}} ..." | ||
| - alias: "Update - Core - Install" | ||
| continue_on_error: true | ||
| action: update.install | ||
| data: {} | ||
| target: | ||
| entity_id: '{{ pending_update_list[0] }}' | ||
| - alias: "Update - Core - Wait" | ||
| continue_on_error: true | ||
| wait_template: "{{ is_state(pending_update_list[0], 'off') }}" | ||
| continue_on_timeout: true | ||
| timeout: '3600' | ||
|
|
||
| ########## Update OS ########## | ||
| - *recalc_update_list | ||
| - *logbook-variables | ||
| - alias: "Update - OS" | ||
| continue_on_error: true | ||
| repeat: | ||
| while: | ||
| - "{{ input_core_os_update_mode in ['patches', 'major_and_minor', 'all'] }}" | ||
| - condition: state | ||
| entity_id: !input schedule_entity | ||
| state: "on" | ||
| - condition: template | ||
| value_template: > | ||
| {{ ( states.update | ||
| | selectattr('state','eq','on') | ||
| | selectattr('entity_id', 'in', pending_updates_list) | ||
| | rejectattr('entity_id', 'in', core_update_entity) | ||
| | selectattr('entity_id', 'in', os_update_entity) | ||
| | rejectattr('entity_id', 'in', firmware_update_entities) | ||
| | rejectattr('entity_id', 'in', input_update_exclusions) | ||
| | map(attribute='entity_id') | ||
| | list | count | int(0) ) > 0 | ||
| }} | ||
| sequence: | ||
| - if: "{{ input_verbose_logging_bool }}" | ||
| then: | ||
| - alias: "Update - OS - Logbook - Starting" | ||
| continue_on_error: true | ||
| action: logbook.log | ||
| data: | ||
| name: Auto-update | ||
| entity_id: '{{ this.entity_id }}' | ||
| message: "Starting sequence of OS update..." | ||
| - variables: | ||
| pending_update_list: > | ||
| {{ states.update | ||
| | selectattr('state','eq','on') | ||
| | selectattr('entity_id', 'in', pending_updates_list) | ||
| | rejectattr('entity_id', 'in', core_update_entity) | ||
| | selectattr('entity_id', 'in', os_update_entity) | ||
| | rejectattr('entity_id', 'in', firmware_update_entities) | ||
| | rejectattr('entity_id', 'in', input_update_exclusions) | ||
| | map(attribute='entity_id') | ||
| | list | ||
| sequence: | ||
| - variables: | ||
| log_message: "Starting sequence of Devices firmware update" | ||
| - *logbook_update | ||
| - if: '{{ "update_progress" in input_notification_telegram_select_notifications }}' | ||
| then: | ||
| - *send_telegram_message | ||
|
|
||
| - variables: | ||
| pending_update_list: > | ||
| {{ states.update | ||
| | selectattr('state', 'eq', 'on') | ||
| | selectattr('entity_id', 'in', pending_update_list) | ||
| | rejectattr('entity_id', 'in', core_update_entity) | ||
| | rejectattr('entity_id', 'in', os_update_entity) | ||
| | selectattr('entity_id', 'in', firmware_update_entities) | ||
| | map(attribute='entity_id') | ||
| | list | ||
| }} | ||
|
|
||
| - *log_updating | ||
| - *update_install | ||
| - *update_wait | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add retry mechanism for failed updates.
The update process doesn't handle transient failures well. Consider adding a retry mechanism with exponential backoff for failed updates.
- alias: Update generic
if:
- '{{ is_there_anything_to_update }}'
- condition: state
entity_id: !input schedule_entity
state: 'on'
then:
- *recalc_update_list
+ - variables:
+ max_retries: 3
+ retry_delay: 30
- variables:
log_message: "Update generic items"
- *logbook_update
- alias: "Update - Generic"
continue_on_error: true
repeat:
while:
- "{{ input_general_update_mode in ['patches', 'major_and_minor', 'all'] }}"
- condition: state
entity_id: !input schedule_entity
state: "on"
+ - condition: template
+ value_template: "{{ max_retries > 0 }}"Committable suggestion skipped: line range outside the PR's diff.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml (3)
34-34: Adjust version number to match current date.The version number
v2025.1.0uses a future date. Consider using the current year and month (v2024.1.0) to maintain consistency with semantic versioning practices.- ## v2025.1.0 + ## v2024.1.0
283-294: Consider reducing the default backup timeout.The default backup timeout of 60 minutes might be excessive for most installations. Consider reducing it to 30 minutes while keeping the range configurable. This would help prevent unnecessarily long waits when backups complete faster.
- default: 60 + default: 30 selector: number: mode: box min: 1 max: 180 unit_of_measurement: minutes
Line range hint
1-1504: Well-structured implementation with room for improvement.The blueprint successfully implements Telegram support with comprehensive notification options. The code is well-documented and includes proper error handling. However, consider addressing the following architectural points:
- Add proper synchronization between update and restart processes
- Implement stronger backup verification
- Add input validation for critical fields
- Adjust timeouts for better user experience
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml(13 hunks)
🔇 Additional comments (2)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml (2)
1277-1322:⚠️ Potential issuePotential race condition in update process.
The "Update - Remaining" sequence might conflict with the restart process if updates complete right after the check but before the restart. Consider adding a small delay or implementing a proper synchronization mechanism.
950-987: Enhance backup verification process.The backup verification only checks the backup state and age but doesn't verify the backup's integrity or accessibility. Consider adding additional checks:
- Verify backup file exists at the specified location
- Check backup file size is non-zero
- Validate backup file format
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml (1)
995-1024: Enhance backup error handling.The backup process could benefit from additional error handling:
- The backup service call is marked with
continue_on_error: truebut there's no explicit error capture- The automation relies solely on a timeout to determine if the backup completed
Consider adding:
- Error state checking after the backup service call
- Backup size verification
- Backup integrity check if available through the API
Example enhancement:
- alias: "Call backup service" action: hassio.backup_full data: compressed: true continue_on_error: true + response_variable: backup_result + +- if: "{{ backup_result is defined and backup_result.success }}" + then: + - variables: + log_message: "Backup completed successfully" + else: + - variables: + log_message: "Backup failed or status unknown"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml(13 hunks)
🧰 Additional context used
📓 Learnings (1)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml (1)
Learnt from: edwardtfn
PR: edwardtfn/HomeAssistant-Config#18
File: blueprints/automation/EdwardTFN/auto_update_scheduled.yaml:391-402
Timestamp: 2025-01-21T10:50:12.444Z
Learning: Home Assistant YAML selectors do not support the `pattern` attribute for text input validation.
🪛 yamllint (1.35.1)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml
[error] 784-784: trailing spaces
(trailing-spaces)
[error] 797-797: trailing spaces
(trailing-spaces)
[error] 801-801: trailing spaces
(trailing-spaces)
[error] 802-802: trailing spaces
(trailing-spaces)
🪛 GitHub Check: Validate YAML
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml
[failure] 784-784:
784:78 [trailing-spaces] trailing spaces
[failure] 797-797:
797:1 [trailing-spaces] trailing spaces
[failure] 801-801:
801:43 [trailing-spaces] trailing spaces
[failure] 802-802:
802:56 [trailing-spaces] trailing spaces
🪛 GitHub Actions: Validate Blueprint YAML
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml
[error] 784-784: Trailing spaces detected at position 78
🔇 Additional comments (4)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml (4)
Line range hint
1-54: Well-documented header with comprehensive information!The documentation clearly outlines the purpose, risks, and security considerations of auto-updates. The inclusion of community discussion links and support channels is particularly helpful.
391-402: Consider adding input validation for Telegram chat ID.The Telegram chat ID input field could benefit from validation to ensure it matches the expected format (negative numbers for groups, positive for users).
Note: This suggestion was previously made and the user clarified that Home Assistant YAML selectors do not support the
patternattribute for text input validation.
516-541: Consider increasing the default update timeout.While the current default of 1200 seconds (20 minutes) is reasonable for most updates, some updates (especially core updates or large addons) might need more time. Consider increasing the default while keeping the range configurable.
Note: This suggestion was previously made and the user confirmed it will be implemented in the next commit.
1025-1167: Consider implementing retry mechanism for failed updates.The update process doesn't handle transient failures well. Consider adding a retry mechanism with exponential backoff for failed updates.
Note: This suggestion was previously made in a past review.
| {% endif %} | ||
| combined_list: >- | ||
| {% set entities = namespace(list=[]) %} | ||
| {%- for entity in [firmware_update_entities, general_update_entities, |
There was a problem hiding this comment.
Remove trailing spaces.
There are trailing spaces in the following lines that should be removed to maintain consistent formatting:
- Line 784: After the comma in the list comprehension
- Line 797: Empty line with spaces
- Lines 801-802: After conditions in the if statement
- core_update_entity, os_update_entity, supervisor_update_entity] %}
+ core_update_entity, os_update_entity, supervisor_update_entity] %}
-
+
- {%- if (entity.state == "on" and
- entity.entity_id in combined_list and
+ {%- if (entity.state == "on" and
+ entity.entity_id in combined_list andAlso applies to: 797-797, 801-802
🧰 Tools
🪛 yamllint (1.35.1)
[error] 784-784: trailing spaces
(trailing-spaces)
🪛 GitHub Check: Validate YAML
[failure] 784-784:
784:78 [trailing-spaces] trailing spaces
🪛 GitHub Actions: Validate Blueprint YAML
[error] 784-784: Trailing spaces detected at position 78
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml (4)
14-17: Enhance security warnings section.Consider adding these important security considerations:
- Risk of breaking changes in major version updates
- Importance of testing updates in a development environment first
- Network connectivity requirements during updates
##### - SECURITY WARNING: ##### ##### - Ensure you have reliable backups before enabling automatic updates ##### ##### - Auto-updates in production environments may lead to system instability ##### ##### - Updates may affect connected devices and integrations ##### +##### - Major version updates may contain breaking changes ##### +##### - Test updates in a development environment when possible ##### +##### - Ensure stable network connectivity during updates #####
204-235: Add descriptions for update mode implications.The update inclusion mode selector would benefit from additional descriptions about the implications of each mode, particularly regarding system stability and performance.
description: >- Please select the entity inclusion mode. * All: - Just build the update entity list from all available update.* entities, which are in state 'on'. + Just build the update entity list from all available update.* entities, which are in state 'on'. + Note: This mode may impact system performance if many updates are available simultaneously. * Specified/Specified-Single: Build the update entity list from the specified entity list, filtering for entities in 'on' state. - Specified: Updates all matching entities - Specified-Single: Updates only the first matching entity + Note: Recommended for controlled, selective updates of critical components.
590-599: Optimize trigger template for better readability.The trigger template for new day validation could be simplified for better maintainability.
- {{ - (now().day >= input_schedule_monthday_earliest or input_schedule_monthday_earliest == 0) and - ( - now().day <= input_schedule_monthday_last or - input_schedule_monthday_last == 0 or - input_schedule_monthday_last < input_schedule_monthday_earliest - ) - }} + {% set current_day = now().day %} + {% set is_after_earliest = current_day >= input_schedule_monthday_earliest or input_schedule_monthday_earliest == 0 %} + {% set is_before_last = current_day <= input_schedule_monthday_last or input_schedule_monthday_last == 0 %} + {% set is_valid_range = input_schedule_monthday_last < input_schedule_monthday_earliest %} + {{ is_after_earliest and (is_before_last or is_valid_range) }}
509-513: Add monitoring capabilities for update statistics.Consider adding input options for monitoring update success rates and timing statistics.
verbose_logging_bool: name: Log addon progress with verbosity to the logbook? (optional) default: false selector: boolean: {} + update_statistics_sensor: + name: Statistics Helper Sensor (optional) + description: > + Select a helper sensor to store update statistics like success rates, + average update duration, and failure counts. + default: [] + selector: + entity: + domain: sensor
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml(13 hunks)
🧰 Additional context used
📓 Learnings (1)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml (1)
Learnt from: edwardtfn
PR: edwardtfn/HomeAssistant-Config#18
File: blueprints/automation/EdwardTFN/auto_update_scheduled.yaml:391-402
Timestamp: 2025-01-21T10:50:12.444Z
Learning: Home Assistant YAML selectors do not support the `pattern` attribute for text input validation.
🔇 Additional comments (2)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml (2)
1101-1108: 🛠️ Refactor suggestionAdd retry mechanism for failed updates.
The update installation sequence should include a retry mechanism for transient failures.
alias: "Update - Install" continue_on_error: true + variables: + max_retries: 3 + retry_delay: 30 + current_try: 1 + repeat: + sequence: + - if: "{{ current_try > 1 }}" + then: + - delay: + seconds: "{{ retry_delay * (current_try - 1) }}" + - service: update.install + data: {} + target: + entity_id: '{{ current_update_entity }}' + until: "{{ is_state(current_update_entity, 'off') or current_try > max_retries }}" + repeat: + variable: current_try + in: "{{ range(1, max_retries + 1) | list }}" - action: update.install - data: {} - target: - entity_id: '{{ current_update_entity }}'Likely invalid or redundant comment.
283-294: Validate backup timeout against system resources.The backup timeout should consider system resources and backup size. The current maximum of 180 minutes might be insufficient for large systems.
| - &send_telegram_message | ||
| alias: Send telegram message | ||
| if: | ||
| - condition: template | ||
| value_template: '{{ input_notification_telegram_enable }}' | ||
| alias: Check if telegram notifications are enabled | ||
| then: | ||
| - alias: Telegram bot - Send message | ||
| action: telegram_bot.send_message | ||
| data: | ||
| title: '{{ telegram_title }}' | ||
| target: '{{ input_notification_telegram_target_id }}' | ||
| disable_notification: '{{ input_notification_telegram_disable_notification }}' | ||
| message: '{{ log_message }}' |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add error handling for Telegram notifications.
The Telegram message sending sequence should include error handling and retry logic.
alias: Send telegram message
if:
- condition: template
value_template: '{{ input_notification_telegram_enable }}'
alias: Check if telegram notifications are enabled
then:
+ - variables:
+ max_retries: 3
+ retry_delay: 5
+ - repeat:
+ sequence:
- alias: Telegram bot - Send message
action: telegram_bot.send_message
+ continue_on_error: true
data:
title: '{{ telegram_title }}'
target: '{{ input_notification_telegram_target_id }}'
disable_notification: '{{ input_notification_telegram_disable_notification }}'
message: '{{ log_message }}'
+ until: "{{ repeat.index >= max_retries or not repeat.failed }}"
+ delay:
+ seconds: "{{ retry_delay }}"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - &send_telegram_message | |
| alias: Send telegram message | |
| if: | |
| - condition: template | |
| value_template: '{{ input_notification_telegram_enable }}' | |
| alias: Check if telegram notifications are enabled | |
| then: | |
| - alias: Telegram bot - Send message | |
| action: telegram_bot.send_message | |
| data: | |
| title: '{{ telegram_title }}' | |
| target: '{{ input_notification_telegram_target_id }}' | |
| disable_notification: '{{ input_notification_telegram_disable_notification }}' | |
| message: '{{ log_message }}' | |
| - &send_telegram_message | |
| alias: Send telegram message | |
| if: | |
| - condition: template | |
| value_template: '{{ input_notification_telegram_enable }}' | |
| alias: Check if telegram notifications are enabled | |
| then: | |
| - variables: | |
| max_retries: 3 | |
| retry_delay: 5 | |
| - repeat: | |
| sequence: | |
| - alias: Telegram bot - Send message | |
| action: telegram_bot.send_message | |
| continue_on_error: true | |
| data: | |
| title: '{{ telegram_title }}' | |
| target: '{{ input_notification_telegram_target_id }}' | |
| disable_notification: '{{ input_notification_telegram_disable_notification }}' | |
| message: '{{ log_message }}' | |
| until: "{{ repeat.index >= max_retries or not repeat.failed }}" | |
| delay: | |
| seconds: "{{ retry_delay }}" |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml (3)
34-34: Consider adding a changelog section.Adding a changelog section would help users track changes between versions and understand what's new in v2025.1.0.
## v2025.1.0 + + ### Changelog + - Added Telegram notification support + - Enhanced backup functionality with timeout controls + - Added entity inclusion modes for more granular update control + - Improved update scheduling with earliest/latest day settings
283-294: Consider increasing the default backup timeout.The default backup timeout of 60 minutes might not be sufficient for systems with large amounts of data or slow storage. Consider increasing the default value to 120 minutes while keeping the range configurable.
- default: 60 + default: 120
531-555: Add a warning about core update timeouts.The update timeout description should include a warning that core updates might take longer than other updates, especially on slower systems or during major version upgrades.
The default is 1200 seconds (20 minutes). You can select any value between 10 seconds and 7200 seconds (2 hours). + Note: Core updates might take longer than other updates, especially during major version upgrades. + Consider using a higher timeout value if you experience timeout issues with core updates. + If an update times out:
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml(13 hunks)
🧰 Additional context used
📓 Learnings (1)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml (1)
Learnt from: edwardtfn
PR: edwardtfn/HomeAssistant-Config#18
File: blueprints/automation/EdwardTFN/auto_update_scheduled.yaml:391-402
Timestamp: 2025-01-21T10:50:12.444Z
Learning: Home Assistant YAML selectors do not support the `pattern` attribute for text input validation.
🔇 Additional comments (3)
blueprints/automation/EdwardTFN/auto_update_scheduled.yaml (3)
1102-1109: 🛠️ Refactor suggestionAdd retry mechanism for failed updates.
The update installation process doesn't handle transient failures. Consider adding a retry mechanism with exponential backoff.
alias: "Update - Install" continue_on_error: true + variables: + max_retries: 3 + retry_delay: 30 + repeat: + sequence: action: update.install data: {} target: entity_id: '{{ current_update_entity }}' + until: "{{ repeat.index >= max_retries or not repeat.failed }}" + delay: + seconds: "{{ retry_delay * (2 ^ (repeat.index - 1)) }}"Likely invalid or redundant comment.
847-860: 🛠️ Refactor suggestionEnhance Telegram notification error handling.
The Telegram message sending sequence should include error handling and retry logic to handle temporary network issues.
alias: Send telegram message if: - condition: template value_template: '{{ input_notification_telegram_enable }}' alias: Check if telegram notifications are enabled then: + - variables: + max_retries: 3 + retry_delay: 5 + - repeat: + sequence: - alias: Telegram bot - Send message action: telegram_bot.send_message + continue_on_error: true data: title: '{{ telegram_title }}' target: '{{ input_notification_telegram_target_id }}' disable_notification: '{{ input_notification_telegram_disable_notification }}' message: '{{ log_message }}' + until: "{{ repeat.index >= max_retries or not repeat.failed }}" + delay: + seconds: "{{ retry_delay }}"Likely invalid or redundant comment.
314-323: Add validation for backup location.The backup location input should validate that the path exists and is writable before starting the backup process.
| platform: template | ||
| value_template: > | ||
| {{ | ||
| (now().day >= input_schedule_monthday_earliest or input_schedule_monthday_earliest == 0) and | ||
| ( | ||
| now().day <= input_schedule_monthday_last or | ||
| input_schedule_monthday_last == 0 or | ||
| input_schedule_monthday_last < input_schedule_monthday_earliest | ||
| ) | ||
| }} |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Simplify the day comparison logic.
The day comparison logic is complex and could be simplified. Also, there's a potential issue with month boundaries where the logic might not work correctly when the earliest day is near the end of one month and the latest day is in the beginning of the next month.
- {{
- (now().day >= input_schedule_monthday_earliest or input_schedule_monthday_earliest == 0) and
- (
- now().day <= input_schedule_monthday_last or
- input_schedule_monthday_last == 0 or
- input_schedule_monthday_last < input_schedule_monthday_earliest
- )
- }}
+ {% set current_day = now().day %}
+ {% set earliest = input_schedule_monthday_earliest | int(0) %}
+ {% set latest = input_schedule_monthday_last | int(0) %}
+ {{
+ (earliest == 0 or current_day >= earliest) and
+ (latest == 0 or current_day <= latest or latest < earliest)
+ }}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| platform: template | |
| value_template: > | |
| {{ | |
| (now().day >= input_schedule_monthday_earliest or input_schedule_monthday_earliest == 0) and | |
| ( | |
| now().day <= input_schedule_monthday_last or | |
| input_schedule_monthday_last == 0 or | |
| input_schedule_monthday_last < input_schedule_monthday_earliest | |
| ) | |
| }} | |
| platform: template | |
| value_template: > | |
| {% set current_day = now().day %} | |
| {% set earliest = input_schedule_monthday_earliest | int(0) %} | |
| {% set latest = input_schedule_monthday_last | int(0) %} | |
| {{ | |
| (earliest == 0 or current_day >= earliest) and | |
| (latest == 0 or current_day <= latest or latest < earliest) | |
| }} |
Resolves #11
Resolves #15
Resolves #17
Summary by CodeRabbit
New Features
schedule_monthday_last,update_inclusion_mode,update_inclusion_entity_list, andupdate_inclusion_entity_searchfilter.backup_locationandupdate_timeout.Improvements
Version