zabuldon / teslajsonpy

Apache License 2.0
56 stars 62 forks source link

Generalize API and remove home-assistant specific architecture #24

Closed alandtse closed 2 years ago

alandtse commented 5 years ago

Right now, this library creates entities specifically for HA to consume. This has two downsides that I can see.

  1. Many functions are not intuitive as they assume some knowledge of the HA architecture. It took me a while to figure out that controller.list_vehicles() returned a list of objects for HA and not just a list of vehicles. It also means people not using HA likely won't use this library which runs against the philosophy from HA requiring the library be put in pypi to allow others to reuse.
  2. Feature updates to HA for Tesla require changes to both teslajsonpy and HA. For example, if someone wants to make an additional sensor for charging rate, they will need to modify the sensor in this library and then make an equivalent edit to process the new data. This impacted my ability to make changes in HA and probably is impacting others who want to tweak it. If this library is just intended to allow access to the Tesla API, then teslajsonpy changes will only be needed if new endpoints/commands are created.

I think we should move the HA related architecture into the HA component. I'd be happy to take that project on.

From an initial review, controller, connection, and exception make sense to me in this library. Everything based on vehicle probably should go into HA.

@zabuldon, this is your project to start, do you have any objections to this rearchitecture? I'll plan to start on doing that unless you object.

alandtse commented 2 years ago

All, please take the PR specific comments to the PR. This issue should only be for discussions about the issue and not an implementation to resolve that issue.