Closed TobiasLaross closed 7 months ago
This update introduces significant enhancements to the LynkCo custom component, focusing on data fetching and state monitoring. Key changes include renaming the manual update service to emphasize forced updates, adding new asynchronous data fetching functions, and integrating a new ExpectedStateMonitor
for real-time state tracking. The version has been bumped to 1.1.0 to reflect these improvements.
Files | Change Summary |
---|---|
.gitignore |
Added venv/ to exclude virtual environment directory. |
README.md , services.yaml |
Renamed manual_update_data service to force_update_data . |
.../lynkco/__init__.py , .../remote_control_manager.py |
Added new imports, constants, and functions for enhanced state monitoring and data fetching. Renamed key service. |
.../lynkco/const.py , .../services.yaml |
Added new constants and updated service keys. |
.../lynkco/data_fetcher.py |
Expanded with new async functions for fetching vehicle data. |
.../lynkco/expected_state_monitor.py |
Introduced ExpectedStateMonitor class for state management. |
.../lynkco/login_flow.py |
Changed logging level for authorization steps. |
.../lynkco/manifest.json |
Updated version number to "1.1.0". |
🐰✨ In the code's garden, updates bloom, New functions grow, old errors doom. With every line, the rabbits hop, Ensuring LynkCo stays atop. Cheers to v1.1, with a hop and a skip! 🎉🌟 🐰✨
README.md (39)
Near line 1: Possible spelling mistake found. Context: # Lynk & Co Home Assistant Custom Component #... --- Near line 4: Possible spelling mistake found. Context: ...nt users to integrate and control their Lynk & Co vehicles directly from Home Assist... --- Near line 8: Possible spelling mistake found. Context: ...cle management. This has been tested on european models only. ## Table of Contents - [W... --- Near line 15: Possible spelling mistake found. Context: ...s) - [Adding the Custom Repository to HACS](#adding-the-custom-repository-to-hacs)... --- Near line 32: Possible spelling mistake found. Context: ...ome Assistant running. - Access to your Lynk & Co account credentials. - Your vehicl... --- Near line 35: Possible spelling mistake found. Context: ...N. ### Adding the Custom Repository to HACS 1. Navigate to HACS in Home Assistant. ... --- Near line 36: Possible spelling mistake found. Context: ...ustom Repository to HACS 1. Navigate to HACS in Home Assistant. 2. Go to "Integratio... --- Near line 38: Consider adding a hyphen. Context: ...ons". 3. Click on the three dots in the top right corner and select "Custom repositories"... --- Near line 44: Possible spelling mistake found. Context: ... Installing the Integration 1. Find the Lynk & Co integration in the HACS Integratio... --- Near line 44: Possible spelling mistake found. Context: .... Find the Lynk & Co integration in the HACS Integrations section and click "Install... --- Near line 52: Possible spelling mistake found. Context: ...ck on "Add Integration" and search for "Lynk & Co". 3. Follow the on-screen instruct... --- Near line 62: Possible spelling mistake found. Context: ...ure is experimental and undocumented by Lynk & Co.) - `force_update_data`: Forcing u... --- Near line 63: Loose punctuation mark. Context: ...ted by Lynk & Co.) - `force_update_data`: Forcing update data from the vehicle, b... --- Near line 64: Loose punctuation mark. Context: ...ypassing night limit. - `refresh_tokens`: Refreshes authentication tokens, this s... --- Near line 68: This sentence does not start with an uppercase letter. Context: ... #### Detailed Service Information - **start_engine / stop_engine**: This service al... --- Near line 68: Possible spelling mistake found. Context: ...feature not officially supported by the Lynk & Co app. Use with caution, as it may n... --- Near line 69: “Service” is a singular noun. It appears that the verb form is incorrect. Context: ...climate will be set to HI, this service have not been tested without sufficient EV b... --- Near line 72: Possible spelling mistake found. Context: ...rehensive monitoring and control of the Lynk & Co vehicle, including both sensors an... --- Near line 74: Possible typo: you repeated a word Context: ... both sensors and binary sensors. #### Sensors Sensors provide detailed information about vari... --- Near line 77: Possible spelling mistake found. Context: ...us and environment. These include: - **Lynk & Co Odometer**: Measures the total dis... --- Near line 78: Possible spelling mistake found. Context: ...vehicle has traveled in kilometers. - **Lynk & Co Battery**: Shows the current batte... --- Near line 79: Possible spelling mistake found. Context: ...ttery charge level as a percentage. - **Lynk & Co Fuel Level**: Displays the current... --- Near line 80: Possible spelling mistake found. Context: ...s the current fuel level in liters. - **Lynk & Co Fuel Level Status**: Indicates the... --- Near line 81: Possible spelling mistake found. Context: ...cates the status of the fuel level. - **Lynk & Co Fuel Distance**: Reports the estim... --- Near line 82: Possible spelling mistake found. Context: ...e traveled with the remaining fuel. - **Lynk & Co Time Until Charged**: Provides the... --- Near line 83: Possible spelling mistake found. Context: ...until the battery is fully charged. - **Lynk & Co Battery Distance**: Shows the esti... --- Near line 84: Possible spelling mistake found. Context: ...be traveled on battery power alone. - **Lynk & Co Interior Temperature**: Reports th... --- Near line 85: Possible spelling mistake found. Context: ...ide the vehicle in degrees Celsius. - **Lynk & Co Exterior Temperature**: Displays t... --- Near line 86: Possible spelling mistake found. Context: ...ide the vehicle in degrees Celsius. - **Lynk & Co Charger Connection Status**: Indic... --- Near line 87: Possible spelling mistake found. Context: ...arger is connected or disconnected. - **Lynk & Co Charge State**: Shows the current ... --- Near line 88: Possible spelling mistake found. Context: ...rent charging state of the vehicle. - **Lynk & Co Address**: Displays the vehicle's ... --- Near line 89: Possible spelling mistake found. Context: ...address in a human-readable format. - **Lynk & Co Address Raw**: Provides the vehicl... --- Near line 90: Possible spelling mistake found. Context: ... integration with mapping services. - **Lynk & Co Door Lock Status**: Indicates the ... --- Near line 91: Possible spelling mistake found. Context: ...lock status of the vehicle's doors. - **Lynk & Co Last Updated by Car**: Timestamp o... --- Near line 93: This phrase is duplicated. You should probably use “Binary Sensors” only once. Context: ...update received from the vehicle. #### Binary Sensors Binary sensors indicate specific vehicle states that h... --- Near line 96: Possible spelling mistake found. Context: ...ture before you enter. It uses the icon `mdi:air-conditioner` to visually represent ... --- Near line 97: Only proper nouns start with an uppercase character (there are exceptions for headlines). Context: ...n the Home Assistant UI. - **Vehicle is Running**: Shows if the vehicle's engine is cur... --- Near line 97: Possible spelling mistake found. Context: ...onal state of your vehicle and uses the `mdi:engine` icon for easy identification. ... --- Near line 104: Possible spelling mistake found. Context: ...h good cellular reception and that your Lynk & Co account is active and not facing a...
release-notes (1)
`1-2`: Ensure the version number and summary accurately reflect the changes described in the PR.custom_components/lynkco/const.py (2)
`19-22`: Ensure the new constants `DATA_EXPECTED_STATE` and `DATA_IS_FORCE_UPDATE` are used consistently across the codebase.Verification successful
--- The constants `DATA_EXPECTED_STATE` and `DATA_IS_FORCE_UPDATE` are used consistently across the codebase in the files where they are referenced. They are correctly utilized to manage state and control flow within the Home Assistant component, aligning with typical usage patterns for such constants. Based on the information provided by the script output, there are no discrepancies or issues with their usage. - `custom_components/lynkco/remote_control_manager.py` - `custom_components/lynkco/__init__.py`--- `31-41`: Confirm that the renaming of `SERVICE_MANUAL_UPDATE_KEY` to `SERVICE_FORCE_UPDATE_KEY` and the addition of new expected state constants are reflected wherever these constants are used.Scripts Executed
The following scripts were executed for the analysis: --- Script: ```shell #!/bin/bash # Search for usage of DATA_EXPECTED_STATE and DATA_IS_FORCE_UPDATE across the codebase. rg --type py 'DATA_EXPECTED_STATE|DATA_IS_FORCE_UPDATE' ``` Length of output: 982Verification successful
--- The verification process confirms that the renaming of `SERVICE_MANUAL_UPDATE_KEY` to `SERVICE_FORCE_UPDATE_KEY` has been successfully implemented throughout the codebase. Additionally, the new expected state constants are correctly defined and utilized in various parts of the system. No issues were found regarding these changes. - `SERVICE_FORCE_UPDATE_KEY` is used in `custom_components/lynkco/__init__.py` and defined in `custom_components/lynkco/const.py`. - New expected state constants like `EXPECTED_STATE_CLIMATE_ON`, `EXPECTED_STATE_CLIMATE_OFF`, etc., are defined in `custom_components/lynkco/const.py` and used in both `custom_components/lynkco/__init__.py` and `custom_components/lynkco/expected_state_monitor.py`.Scripts Executed
The following scripts were executed for the analysis: --- Script: ```shell #!/bin/bash # Search for old and new service keys to ensure correct renaming. rg --type py 'SERVICE_MANUAL_UPDATE_KEY|SERVICE_FORCE_UPDATE_KEY' # Search for usage of new expected state constants. rg --type py 'EXPECTED_STATE_CLIMATE_ON|EXPECTED_STATE_CLIMATE_OFF|EXPECTED_STATE_ENGINE_ON|EXPECTED_STATE_ENGINE_OFF|EXPECTED_STATE_UNLOCKED|EXPECTED_STATE_LOCKED' ``` Length of output: 3754custom_components/lynkco/services.yaml (1)
`43-44`: Confirm that the renaming of the service to `force_update_data` is consistently applied across all configuration and documentation files.Verification successful
--- The renaming of the service to `force_update_data` appears to be consistently applied across all relevant configuration and documentation files within the codebase. The search results confirm that the new service name is used in both `services.yaml` and `README.md`, and there is no occurrence of the old service name `manual_update_data`. - `custom_components/lynkco/services.yaml`: Contains the new service name `force_update_data`. - `README.md`: Mentions the new service name `force_update_data` in the context of forcing update data from the vehicle.Scripts Executed
The following scripts were executed for the analysis: --- Script: ```shell #!/bin/bash # Search for old and new service names in configuration and documentation files. rg --type yaml 'manual_update_data|force_update_data' rg --type md 'manual_update_data|force_update_data' ``` Length of output: 261custom_components/lynkco/data_fetcher.py (1)
`12-24`: Ensure that the new asynchronous functions for fetching vehicle data handle errors appropriately and use the correct URLs and parameters.Verification successful
--- The new asynchronous functions for fetching vehicle data delegate to a central function, `async_fetch_vehicle_data`, which includes error handling for token retrieval issues. This design ensures that error handling is consistent and centralized, which is a good practice. The error is logged, and `None` is returned if the CCC token cannot be retrieved, which is an appropriate way to handle this potential error. - `async_fetch_vehicle_data` logs an error and returns `None` if the CCC token is not available.Scripts Executed
The following scripts were executed for the analysis: --- Script: ```shell #!/bin/bash # Search for error handling patterns in the new asynchronous functions. rg --type py 'async_fetch_vehicle_address_data|async_fetch_vehicle_shadow_data|async_fetch_vehicle_record_data' ``` Length of output: 920 --- --- Script: ```shell #!/bin/bash # Extract the bodies of the new asynchronous functions to check for error handling mechanisms. rg --type py --context 10 'async def async_fetch_vehicle_address_data|async def async_fetch_vehicle_shadow_data|async def async_fetch_vehicle_record_data' custom_components/lynkco/data_fetcher.py ``` Length of output: 1236custom_components/lynkco/expected_state_monitor.py (1)
`22-109`: Review the `ExpectedStateMonitor` class to ensure it correctly manages state expectations, handles concurrency safely with locks, and integrates properly with the data update coordinator.Verification successful
--- The `ExpectedStateMonitor` class is correctly integrated and used within the codebase. The method `expect_state` is appropriately called in various scenarios in `__init__.py`. Other methods (`remove_opposite`, `monitor_states`, `check_and_update_states`) are likely called internally within the class, which is a common practice for encapsulating functionality and maintaining class responsibilities. Therefore, the class manages state expectations, handles concurrency safely with locks, and integrates properly with the data update coordinator as intended.Scripts Executed
The following scripts were executed for the analysis: --- Script: ```shell #!/bin/bash # Search for usage of ExpectedStateMonitor across the codebase to ensure proper integration. rg --type py 'ExpectedStateMonitor' ``` Length of output: 420 --- --- Script: ```shell #!/bin/bash # Search for method calls from the ExpectedStateMonitor class to ensure they are used correctly. rg --type py 'expected_state_monitor\.(expect_state|remove_opposite|monitor_states|check_and_update_states)' ``` Length of output: 748custom_components/lynkco/remote_control_manager.py (2)
`65-69`: Verify that the new parameters added to the `stop_climate` function are used correctly and consistently across the codebase. --- `175-179`: Ensure the `force_update_data` function correctly triggers a data update and integrates properly with the data coordinator.Verification successful
--- The `force_update_data` function appears to be correctly integrated within the codebase. It is used directly in `expected_state_monitor.py` to trigger updates and is also wrapped in a service within `__init__.py`, which allows it to be called as part of the Home Assistant service infrastructure. This setup ensures that the function can be invoked both programmatically and via user interactions in Home Assistant, aligning with the intended functionality of forcing data updates bypassing the nightly check. - `custom_components/lynkco/expected_state_monitor.py`: Direct usage in async function to trigger updates. - `custom_components/lynkco/__init__.py`: Wrapped in a service for user-invoked updates.Scripts Executed
The following scripts were executed for the analysis: --- Script: ```shell #!/bin/bash # Search for usage of force_update_data function to ensure it is integrated correctly. rg --type py 'force_update_data' ``` Length of output: 770README.md (1)
`63-63`: Confirm that the service renaming in the README matches the actual implementation in the code.Verification successful
--- The verification process confirms that the service `force_update_data` mentioned in the README is consistently implemented across various Python files in the `custom_components/lynkco` directory. This includes its definition, usage in function calls, and registration as a service. Therefore, the README accurately reflects the current code implementation. - `custom_components/lynkco/remote_control_manager.py`: Definition of `force_update_data` function. - `custom_components/lynkco/const.py`: Constant `SERVICE_FORCE_UPDATE_KEY` set to `"force_update_data"`. - `custom_components/lynkco/__init__.py`: Usage and registration of the `force_update_data` service.Scripts Executed
The following scripts were executed for the analysis: --- Script: ```shell #!/bin/bash # Search for the renamed service in the code to ensure consistency with the README. rg --type py 'force_update_data' ``` Length of output: 770custom_components/lynkco/login_flow.py (1)
`34-34`: Ensure that the change in logging level to `debug` is appropriate for the context and does not hide important information that could be useful for troubleshooting.custom_components/lynkco/__init__.py (17)
`8-8`: Added import for `Debouncer`. This import is necessary for the new debouncing functionality introduced in the `setup_data_coordinator` function. --- `10-10`: Added import for `ExpectedStateMonitor`. This import is essential for the new functionality related to state monitoring, which is used extensively in the service functions. --- `17-27`: Added multiple constants related to expected states and force update functionality. These constants are well-defined and are used appropriately throughout the updated and new functions to manage state expectations and data fetching processes. --- `38-40`: Added functions for fetching vehicle data. These functions are crucial for the new data polling mechanism and are used in the `update_data` function to fetch different types of vehicle data. --- `66-70`: Updated `async_setup_entry` to initialize `ExpectedStateMonitor` and use new constants. This update is necessary to integrate the `ExpectedStateMonitor` into the system and utilize the new constants for managing state and force update flags. --- `98-100`: Updated `register_services` to use `ExpectedStateMonitor`. This change ensures that the state monitoring functionality is incorporated into the service registration process, enhancing the system's ability to manage state expectations. --- `115-117`: Updated `start_climate_service` to use `ExpectedStateMonitor`. This update is crucial for managing the expected state when the climate control is started, aligning with the new state monitoring functionality. --- `121-123`: Updated `stop_climate_service` to use `ExpectedStateMonitor`. Similar to the start service, this update ensures that the expected state is managed when the climate control is stopped. --- `127-127`: Updated `lock_doors_service` to use `ExpectedStateMonitor`. This change integrates state monitoring into the door locking functionality, enhancing security and state management. --- `131-131`: Updated `unlock_doors_service` to use `ExpectedStateMonitor`. This update ensures that the door unlocking process is aligned with the expected state, maintaining consistency in state management. --- `140-141`: Added `force_update_data_service` function. This addition is necessary to expose the new `force_update_data` functionality as a service, allowing for immediate data updates as described in the PR objectives. --- `144-144`: Updated `start_engine_service` to use `ExpectedStateMonitor`. This update is essential for managing the expected state when the engine start functionality is triggered, aligning with the new state monitoring features. --- `148-150`: Updated `stop_engine_service` to use `ExpectedStateMonitor`. This change ensures that the engine stop functionality is integrated with state monitoring, enhancing the system's ability to manage state expectations accurately. --- `170-170`: Updated service registration to use `SERVICE_FORCE_UPDATE_KEY`. This update is necessary to reflect the renaming of the service key, aligning with the changes made across various files as mentioned in the PR objectives. --- `207-207`: Updated `setup_data_coordinator` to include `request_refresh_debouncer`. This update introduces debouncing to the data update process, which can help prevent excessive updates and enhance system performance. --- `223-224`: Updated `update_data` to use `is_force_update` instead of `is_manual_update`. This change aligns the function with the new naming convention and functionality for force updates, ensuring consistency across the component. --- `262-264`: Updated `update_data` to use `async_fetch_vehicle_address_data`. This update is crucial for fetching address data based on vehicle location, enhancing the data richness and accuracy for the vehicle management system.
…ual_update_data to force_update_data
Summary by CodeRabbit
New Features
force_update_data
function for immediate data updates without time restrictions.ExpectedStateMonitor
for continuous state monitoring in home automation systems.Enhancements
.gitignore
to exclude thevenv
directory.Documentation
README.md
andservices.yaml
to reflect renaming of data update services.Version Updates