Architecture discussion

[alandtse]

@shred86 thought it might make sense to discuss here.

This is a continuation of zabuldon/teslajsonpy#357 (comment).

I've been thinking more about the architecture for these JSON based apis. And at least when it comes to HA, we should be able to write a very simple data driven entity. Many of the entities are purely read only. For example:
https://github.com/zabuldon/teslajsonpy/blob/dev/teslajsonpy/car.py#L142-L145

    @property
    def charge_energy_added(self) -> float:
        """Return charge energy added."""
        return self._vehicle_data.get("charge_state", {}).get("charge_energy_added")

Is simply a HA sensor which needs pull data from charge_state/charge_energy_added. The Tesla component would basically just be a reference to the data source, and some basic meta data that helps fill in other required properties.

Other entities have both a state component and a command component. Anything with a command component would basically just use the _send_command and process the response to update the state or just refresh the known state from Tesla (although we've seen issues with late refreshes).

So we could basically build all sensors with a template entity that takes various metadata to set it up. I did something similar to that with alexa_media where specific sensors were subclass of another base sensor that took different meta data.

So in the Tesla case, we'd do something like.

class Sensor():
    """Representation of a Tesla sensor."""

    def __init__(self, teslajsonpy_controller, state_key, meta_data) :

class Switch():
    """Representation of a Tesla switch."""
    def __init__(self, teslajsonpy_controller, api_command, state_key, meta_data) :

We could use dictionary keys to match the type of HA expected commands against the specific HA API command and parameters.

{ "turn_on" : {"path_vars, ... "}

Again, we could have the base class handle the actual teslajsonpy_controller.

Let me know what you think.

[alandtse]

Also, thinking about this more, we may be able to simplify it further by taking the JSON response and then creating a map to auto create stuff.

For example, here's the standard response.

{
  "response": {
    "api_version": 10,
    "autopark_state_v2": "standby",
    "autopark_style": "standard",
    "calendar_supported": true,
    "car_version": "2020.36.16 3e9e4e8dd287",
    "center_display_state": 0,
    "df": 0,
    "dr": 0,
    "ft": 0,

We could do something using the structure:

{
  "response": {
    "autopark_state_v2": AUTOPARK_SENSOR,
    "autopark_style": AUTOPARK_SENSOR.STYLE,
    "car_version": DEVICE_INFO.VERSION,

Keys that are missing or None don't create anything. The values could be a class or function or something else that scales well. I haven't fully thought it through implementation wise though.

The advantage of using the existing JSON structure is we don't have to do any jsonpath parsing, and we can easily adjust to new values from the API. It also makes it very data driven.

[shred86]

This all sounds great to me, but does seem like another rewrite to the rewrite. 😂 Like I mentioned in the pull request, I’m by no means a programmer so I’m always looking for feedback. I kind of wish this discussion would have happened before we published the changes I made. Either way, I’m happy to help where I can.