initial implementation for Powerwall control#110
Merged
Conversation
Collaborator
|
LGTM. I'm not a big fan of embedding the client in the result, but that's what we're already doing. |
Author
|
Can we merge this @bogosj ? |
Owner
|
Released as v1.2.0. Thanks! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds a minimal implementation of the Products API, used to read Tesla Energy products data. Also, adds support for a single command against Tesla Energy Sites, allowing to control the battery reserve percentage which is usually controlled via the Tesla App.
I did not add support for the entirety of the returned JSON structures, as it is rather big and contains a lot of (uninteresting?) stuff. Also, it is not clear, how Tesla slices the data. A lot of the information specific to e.g. a Powerwall is also returned partial when just listing the products.
Either way, there's room for improvements or extensions if a specific field is missing.
Caveat: I do not own a Tesla car, so I do not know if and how the products endpoint responds if you have both a car and energy products. I tried to make the implementation pretty generic, by only requiring
idandresource_typein the JSON replies.I use the presence of
energy_site_idas an indicator that the given product is an energy site (and not a car).The included example shows how to use the implemented calls to both read information for the energy site and optionally also allows to change the battery reserve percentage.