-
Notifications
You must be signed in to change notification settings - Fork 34
Add execute_action_group method and remove other command execution methods.
#1862
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
I am not a huge fan of how we serialize the models to JSON (and vice-versa) with attrs and humps. We might need to see if moving to pydantic is a cleaner option here. |
9b2bc1e to
7ee723f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR refactors command execution to use a new execute_action_group() method that replaces the existing execute_command() and execute_commands() methods. The refactoring improves type safety, enables concurrent execution across multiple devices, and introduces support for command execution modes (high priority, geolocated, internal).
Key changes:
- Introduced a new serializers module to centralize payload formatting (snake_case to camelCase conversion)
- Refactored the Command class from a dict-based model to an attrs-based class with proper typing and a
to_payload()method - Added
execute_action_group()method with support for CommandMode options
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| pyoverkiz/serializers.py | New module that handles JSON key formatting (snake_case to camelCase) and special abbreviation fixes like deviceURL |
| pyoverkiz/models.py | Refactored Command class to use attrs with typed parameters supporting OverkizCommandParam enums; updated Action class to accept Command objects and added to_payload methods |
| pyoverkiz/client.py | Replaced execute_command/execute_commands with execute_action_group that supports multiple CommandMode options (high priority, geolocated, internal) |
| tests/test_serializers.py | Added comprehensive tests for payload serialization including nested structures and device URL handling |
| tests/test_models.py | Added tests for Command and Action to_payload methods including None field omission and enum conversion |
| tests/test_client.py | Added test to verify execute_action_group correctly omits None fields and applies proper serialization |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…h camelCase conversion and omission of None fields
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
78fedac to
d205616
Compare
…ersion to 2.0.0 in uv.lock
Breaking changes
client.execute_command()andclient.execute_commands()are replaced byclient.execute_action_group()Enhancements
client.execute_action_group()now supports multiple execution modes (high priority, internal, geolocated)client.execute_action_group()now supports multiple device actions in the same requestProposal
The current execution methods are poorly typed and do not support concurrent execution across multiple devices, which makes it impossible to properly work around TooManyExecutionsException and TooManyConcurrentRequestsException.
The main change is the move from
client.execute_command()andclient.execute_commands()to a singleclient.execute_action_group(). An action group takes a list of actions, each of which can include multiple device actions, including multiple commands per action.Method examples
New (mode) options like high priority will be possible now:
Next steps
This could serve as a foundation for grouping commands that are executed within a short time window, for example when triggered by a scene or automation in Home Assistant. Requests issued close together could be batched and sent as a single action group, reducing the impact of current Overkiz limitations.
The open question is where this queue should live: inside this integration itself, or as part of the Home Assistant core implementation.