Releases: timdorr/tesla-api
v3.1.0
This release handles the new auth process (see #260). It does not yet handle MFA users.
When upgrading, any previously stored refresh_token
s will no longer function, as they are being generated by a new system. While existing Owner API access_token
s will continue to work until they expire, a full login will be needed to obtain new refresh_tokens.
Changes
- Update for new authentication process
v3.0.7
v3.0.6
v3.0.5
This release is sponsored by RedAlert, a smart alerting platform for Tesla vehicles.
Changes
- Retry request on timeouts (#159 by @MarkusHarmsen)
- Charge limit only allows integers (#209 by @jankeesvw)
- Add client_options param to pass to API client (#218 by @cyu)
v3.0.4
v3.0.3
v3.0.2
v3.0.1
v3.0.0
This release is sponsored by RedAlert, a smart alerting platform for Tesla vehicles.
Sorry for the quick major bump again, but this is warranted. The internal HTTP client I was using (HTTParty) was entirely thread-unsafe, so things like Sidekiq jobs or other multi-user systems would be impossible to implement safely.
As a bonus, I've updated the streaming API to use the new WebSocket endpoint. The old HTTP streaming endpoint is completely defunct now.
Changes
- Replace HTTParty with Faraday. This ensures instances stay separate from each other.
- Update
Vehicle.stream
to use the WebSocket endpoint. - Add a
Client.vehicle(id)
endpoint for getting a single vehicle from the API.
v2.0.0
Changes
- Revamped
TeslaApi::Client
.new
now uses keyword arguments:email:
,access_token:
,access_token_expires_at:
,refresh_token:
,client_id:
, andclient_secret:
. Note:access_token_expires_at
should be a DateTime.- Methods
.token=
,.expires_in=
,.created_at=
have been removed. You can set these when creating the client. - Added a
refresh_access_token
method to obtain a new access token using a refresh token. Note: Tesla invalidates the previous refresh token when obtaining the new access token.