Tesla: allow customizing the command proxy to use

[FraBoCH]

Add support of custom http proxy like https://github.com/wimaha/TeslaBleHttpProxy for sending commands to the standard tesla vehicle template as discussed in #14252.

The corresponding yaml configuration would be:

vehicles:
- name: tesla
  type: template
  template: tesla
  title: Y not?
  accessToken: XXXX
  refreshToken: XXX
  vin: XXXXX
  capacity: 74
  commandProxy: http://192.168.X.XX:8080

[wimaha]

I didn't see, that there is another pull request like mine (#14620).

But I really think you have to remove the polling of the tesla server each time the current is changed. Otherwise you will hit the API Limit ...

[FraBoCH]

I didn't see, that there is another pull request like mine (#14620).

But I really think you have to remove the polling of the tesla server each time the current is changed. Otherwise you will hit the API Limit ...

We indeed need to verify that. My understanding is that the limit of « read » requests is higher and sufficient for our use case.

[andig]

According to docs there's an API limit, not a write limit.

[wimaha]

I didn't see, that there is another pull request like mine (#14620).
But I really think you have to remove the polling of the tesla server each time the current is changed. Otherwise you will hit the API Limit ...

We indeed need to verify that. My understanding is that the limit of « read » requests is higher and sufficient for our use case.

The Limit of Read-Requests ist 200. So it‘s up to the weather, of thats enough or not.

[FraBoCH]

<> > > I didn't see, that there is another pull request like mine (#14620).

But I really think you have to remove the polling of the tesla server each time the current is changed. Otherwise you will hit the API Limit ...

We indeed need to verify that. My understanding is that the limit of « read » requests is higher and sufficient for our use case.

The Limit of Read-Requests ist 200. So it‘s up to the weather, of thats enough or not.

I see what you mean. On the other hand, this data is cached (and not fetched above 6A) so I wonder how many real API call this trigger in a one day. IMHO we should keep the existing logic to avoid issue #13007 coming back, and think of a further fix if we reach the API limits in practice and if that prevent evcc from doing its job properly.

[wimaha]

<> > > I didn't see, that there is another pull request like mine (#14620).

But I really think you have to remove the polling of the tesla server each time the current is changed. Otherwise you will hit the API Limit ...

We indeed need to verify that. My understanding is that the limit of « read » requests is higher and sufficient for our use case.

The Limit of Read-Requests ist 200. So it‘s up to the weather, of thats enough or not.

I see what you mean. On the other hand, this data is cached (and not fetched above 6A) so I wonder how many real API call this trigger in a one day. IMHO we should keep the existing logic to avoid issue #13007 coming back, and think of a further fix if we reach the API limits in practice and if that prevent evcc from doing its job properly.

The Cache is resetted every time current is changing. So in my use case the limit will be reached very fast. 😕

[FraBoCH]

Adding a parameter to disable « cleanly » the current check loop. So that we can let the (advanced) user decide.

[FraBoCH]

@andig what about updating the :tesla docker image with this PR for testing ?

[andig]

I would suggest that we separate using a different proxy from limiting API requests. The latter could (maybe) be done using without additional config. I'll try to file a PR for that.

Could you limit this one to proxy only?

[andig]

what about updating the :tesla docker image with this PR for testing ?

done

[andig]

Regarding the api.CurrentGetter lets see if this doesn't already work. It will only trigger a read <6A and it will only do so due to caching if the current below 6A was changed. The last improvement (though it would need to be tested) would be to only update when the current goes below 6A for the first time, assuming following requests will all work immediately.

[Raudi1]

Hopefully getting vehicle info should be possible over BLE as well. teslamotors/vehicle-command#229

[andig]

Maybe, but it should not be necessary. The API limits should be fine once you start sending the commands via BLE.

[Raudi1]

Maybe, but it should not be necessary. The API limits should be fine once you start sending the commands via BLE.

Yes, but while it isn't an issue for me, there's people without cellular reception at their charging spots. I think I read somewhere Wifi only doesn't work for the API. Could be wrong though.
But it's always a good thing to have local access without any cloud stuff, as this whole debacle with API limits shows alongside many examples of other cloud services changing, not working, or shutting down completely.

[wimaha]

Regarding the api.CurrentGetter lets see if this doesn't already work. It will only trigger a read <6A and it will only do so due to caching if the current below 6A was changed. The last improvement (though it would need to be tested) would be to only update when the current goes below 6A for the first time, assuming following requests will all work immediately.

As described above this is an issue for my use case. I always charge with < 6A and when there is changing weather the API Limit is reached. Maybe we can try your proposed solution. Perhaps I can file a PR for that.

[andig]

Could you check the logs why that happens? We're caching the result and should only call the API if current is updated. That is 2, 3, 4, 5 Amps. Do we even need to call it if the change remains below 6A or only when going from 6A to below? Needs to be tested.

[FraBoCH]

Another approach would be to check from the charger meter if the actual current consumption match the expected value. Le lun. 1 juil. 2024 à 16:50, andig ***@***.***(mailto:Le lun. 1 juil. 2024 à 16:50, andig <<a href=)> a écrit :

…

Could you check the logs why that happens? We're caching the result and should only call the API if current is updated. That is 2, 3, 4, 5 Amps. Do we even need to call it if the change remains below 6A or only when going from 6A to below? Needs to be tested. — Reply to this email directly, [view it on GitHub](#14616 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AET5P3NVMWOHKG4NWN7IQRTZKFUEXAVCNFSM6AAAAABKCQA7RSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBQGM3DSOJXGQ). You are receiving this because you authored the thread.Message ID: ***@***.***>

[andig]

Actually, we've just added this in #14622. Since the TWC has phase currents, this should work if you remove the api.CurrentGetter from the vehicle. Could you give it a try?

[FraBoCH]

Mmmmh. Any change needed or is it suppose to already work with twc in latest nightly ?
I am testing with a custom vehicle getting data from TeslaMate (without GetMaxCurrent obviously), but it doesn’t detect the phase mismatch when switching from 13A to 1A. The Tesla gets stuck at 5A instead of 1A in that case.

[andig]

Ahhh, I see. Need to check the error return code, too. Change coming.

[andig]

@FraBoCH see #14659. It is a bit subtle but should work. Remaining drawback is that we'll only recognize if current is too high by at least 1A, so it might not detect not switching to 5A, but should detect on 4A due to https://github.com/evcc-io/evcc/pull/14622/files#diff-c456526d4bd9022a488ce32de208b40d86016e2c40b0c81a2dffe557c186377dR723. Seems this is the best we can currently do. Ymmv.