Skip to content

Vehicle HA: add position support via device_tracker entities#28113

Draft
Turbo87 wants to merge 2 commits intoevcc-io:masterfrom
Turbo87:ha-vehicle-position
Draft

Vehicle HA: add position support via device_tracker entities#28113
Turbo87 wants to merge 2 commits intoevcc-io:masterfrom
Turbo87:ha-vehicle-position

Conversation

@Turbo87
Copy link
Contributor

@Turbo87 Turbo87 commented Mar 11, 2026

I'm currently using a HomeAssistant vehicle with the vehicle API charger. The latter supports geofencing, but the HA vehicle so far did not. This PR is my attempt to fix that.

I've tried this change locally and it appears to work as expected, but I'm new to the codebase and my Go knowledge is also fairly limited, so thorough review might be appropriate... 😅

Copy link
Contributor

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry @Turbo87, your pull request is larger than the review limit of 150000 diff characters

Add position tracking to the Home Assistant vehicle by reading
`latitude`/`longitude` attributes from `device_tracker.*` entities.
This enables geofencing for the `vehicle-api` charger.
@Turbo87 Turbo87 force-pushed the ha-vehicle-position branch from fb314bb to 2140426 Compare March 11, 2026 11:50
@Turbo87
Copy link
Contributor Author

Turbo87 commented Mar 11, 2026

your pull request is larger than the review limit of 150000 diff characters

yeah... I had to regenerate the vehicle decorator file with the new position field, which is causing the diff to be quite huge. is there a way to avoid that?

@andig
Copy link
Member

andig commented Mar 11, 2026

This adds 14k lines of code due to the way the code generation works. Imho that is not a good tradeoff, more so since evcc does not have geofencing atm.

@andig andig marked this pull request as draft March 11, 2026 12:14
@andig andig added the vehicles Specific vehicle support label Mar 11, 2026
@Turbo87
Copy link
Contributor Author

Turbo87 commented Mar 11, 2026

This adds 14k lines of code due to the way the code generation works. Imho that is not a good tradeoff

yeah, I would tend to agree.

is all of the code gen really necessary though? as mentioned above, my Go knowledge is limited :D

@andig
Copy link
Member

andig commented Mar 11, 2026

It's what we've decided to do for "optional" interfaces. May not have been the best choice :O. Sometimes we can group them like "read phases" being dependent on "set phases". For vehicle unfortunately I couldn't find any logical grouping to reduce combinatoric complexity and not better technical approach to reduce the LoC.

@Turbo87
Copy link
Contributor Author

Turbo87 commented Mar 11, 2026

It's what we've decided to do for "optional" interfaces. May not have been the best choice :O

I had Claude Code take a look at alternatives and it came up with #28116. As the PR description mentions, feel free to tell me that this is completely wrong and I should stop opening such PRs :)

@github-actions github-actions bot added the stale Outdated and ready to close label Mar 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

stale Outdated and ready to close vehicles Specific vehicle support

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants