Closed jofleck closed 8 months ago
Looks like that API is very much built around cloud to cloud integration. Their page has an email address for API support. I suggest someone, perhaps the developer of this integration (and probably other similar things like TeslaMate) should reach out to them and point out that the current requirements are not friendly for customers who wish to host their own system. As such, there should be a way for a customer to generate an API key without needing a developer account or domain name. That would of course be bound to only that customer's account.
Tesla ignored us when we were a part of HA. This why we had to go custom. I don't think they care.
There is some good discussion and solutions coming out over here: https://github.com/timdorr/tesla-api/issues/763
Does this mean no longer have control of car from Home Assistant :(
One of the main reasons I bought a Tesla so I could automatically defrost heat or AC car based on my irregular shifts.
Will be so annoyed if Tesla joins Mazda in screwing this all up.
HA may be willing to put it back in core. Or Nabu Casa could provide an integration and charge for it. If its official and supported the new API should meet HA criteria for official inclusion again.
ChargeHQ have now migrated to the Tesla Fleet API, so there is a migration path available for 3rd party apps: https://www.tesla.com/_ak/tesla.chargehq.net
Well, me and a lot of users wonder about the future of this integration.
What changes is not just the way that credentials are enrolled. The current integration accesses old APIs, and can no longer control the cars that are delivered since december. It will also not control older cars at some point in the near future.
Will there be a new version that uses the new Tesla API, or should we all look for alternative ways to control our cars? I found the Tesla integration a very seamless solution, and even if it is more awkward to enroll keys or cost a few(!) bucks for someone who acts as a "partner" for Tesla, I would be happy to stick to it.
I built a pv surplus charging solution that charges my car via HA, the PV integration and the Tesla integration. It works well for me, and it works well for several people whom I support in the German Tesla forum. But I can't tell them if this solution will still work in the future.
What changes is not just the way that credentials are enrolled. The current integration accesses old APIs, and can no longer control the cars that are delivered since december. It will also not control older cars at some point in the near future.
It won't control any car in January 2024.
ChargeHQ have now migrated to the Tesla Fleet API, so there is a migration path available for 3rd party apps: https://www.tesla.com/_ak/tesla.chargehq.net
So did Tesla Solar Charger, it does now include the option to use the new API instead. The owner needs to register a partner account with Tesla, though.
Hi all - so come January 1st this integration will stop? If so, that's very sad as I'm not aware of any alternative. Is there any initiative at hand that I could help with or contribute to? What can I otherwise do to manage my tesla charging in HA?
Follow up on Peter's comment, also quite disappointed. I'm proud of my automations for hourly pricing and don't know what other 3rd party apps would be able to integrate into their API as easily as HA is. Does anyone know any 3rd party apps that integrate with known hourly price programs?
On Thu, Dec 21, 2023 at 3:58 PM PeterH24x7 @.***> wrote:
Hi all - so come January 1st this integration will stop? If so, that's very sad as I'm not aware of any alternative. Is there any initiative at hand that I could help with or contribute to? What can I otherwise do to manage my tesla charging in HA?
— Reply to this email directly, view it on GitHub https://github.com/alandtse/tesla/issues/743#issuecomment-1866981055, or unsubscribe https://github.com/notifications/unsubscribe-auth/AR2XH23SMRBDRGRRPEK5SF3YKSWHFAVCNFSM6AAAAAA57VL7ZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRWHE4DCMBVGU . You are receiving this because you are subscribed to this thread.Message ID: @.***>
this may or may not be good news for us... Teslascope is working on a JSON API to connect different things like home assistant: https://x.com/teslascope/status/1738083967545561377?s=20
Also they talk about something that may be announced in Q1 2024 for independent developers.
Follow up on Peter's comment, also quite disappointed. I'm proud of my automations for hourly pricing and don't know what other 3rd party apps would be able to integrate into their API as easily as HA is. Does anyone know any 3rd party apps that integrate with known hourly price programs?
Just get OCPP charger and use OCPP integration.
Hi all - so come January 1st this integration will stop? If so, that's very sad as I'm not aware of any alternative. Is there any initiative at hand that I could help with or contribute to? What can I otherwise do to manage my tesla charging in HA?
https://github.com/pkuehnel/TeslaSolarCharger
Tesla Solar Charger is pretty popular.
Follow up on Peter's comment, also quite disappointed. I'm proud of my automations for hourly pricing and don't know what other 3rd party apps would be able to integrate into their API as easily as HA is. Does anyone know any 3rd party apps that integrate with known hourly price programs?
Just get OCPP charger and use OCPP integration.
OCPP is generic and not as granular as what you can do with the Tesla API.
OCPP is generic and not as granular as what you can do with the Tesla API. So what exactly is missing in OCPP? AFAIK other than minimum which is 6A while Tesla offers 5A, PWM can be set to anything. Also Zappi has embedded ToU tariffs and by setting tariff plus time when car is expected to be ready you can have charge at minimum cost.
OCPP is generic and not as granular as what you can do with the Tesla API.
I forgot to add - if you really want to have anything, get any charger and replace PWM by generated by ESP chip, it will be anything. Juts need to understand cars limitations but that is separate story, OCPP should do enough.
So what exactly is missing in OCPP?
OCPP doesn't provide real time monitoring of my home battery nor let me charge and discharge my home battery
AFAIK other than minimum which is 6A while Tesla offers 5A, PWM can be set to anything.
Whilst OCPP is nice, I already have the Tesla hardware and it goes below 5A in 1A steps to 0A. 5A @ 3 phase @ 240V (3.6 kW) is still quite a bit of power.
Also Zappi has embedded ToU tariffs and by setting tariff plus time when car is expected to be ready you can have charge at minimum cost.
Zappi whilst also nice is a hardware solution which doesn't work for my tariff which changes every 5 minutes.
Anyway this is a Tesla integration which we would like to see functional into the future.
Tesla Solar Charger is pretty popular.
Great work they are working with the new Fleet API!
I'm wondering how well TeslaSolarCharger works with Home Assistant?
OCPP is generic and not as granular as what you can do with the Tesla API.
I forgot to add - if you really want to have anything, get any charger and replace PWM by generated by ESP chip, it will be anything. Juts need to understand cars limitations but that is separate story, OCPP should do enough.
"Any charger" can charge in the range of 6-16A@230V, 3 phase. The Tesla API can charge at 1-16A@230V, 3 phase. That makes a huge difference when you charge with PV surplus, as you can really adjust the charging power to the current PV output. For those who are not familiar: Solar energy will vary wildly within seconds with every cloud on the sky. You want the most flexibility possible to achieve a good effectiveness.
TezLab might also help in the future… https://x.com/tezlabapp/status/1739368035301892173?s=46&t=W2PQnE3QoCk5bTFgtOt7kg
One thing I tried from the new API is the BLE commands that can be sent with tesla-control app. I needed to build it first from the golang sources. There are several commands that can be sent over BLE, mostly related to the charging but not only. For executing those commands one needs only a private key and a public key registered in the car, no tokens at all. As I am using the HA Tesla integration for automation of charging based on solar panel production, BLE commands can be a good replacement of the server endpoints, for me at least. I like the fact that they don't require interaction with the server. Basically I can run the app on an rpi placed in the car so it will receive the commands remotely. Or I can translate those golang sources into C and run on ESP32. Below is the list of supported commands:
add-key Add PUBLIC_KEY to vehicle whitelist with ROLE and FORM_FACTOR add-key-request Requset NFC-card approval for a enrolling PUBLIC_KEY with ROLE and FORM_FACTOR auto-seat-and-climate Turn on automatic seat heating and HVAC autosecure-modelx Close falcon-wing doors and lock vehicle. Model X only. charge-port-close Close charge port charge-port-open Open charge port charging-amps Set charging amps charging-set-limit Set charge limit to PERCENT charging-start Start charging charging-stop Stop charging climate-off Turn off climate control climate-on Turn on climate control climate-set-temp Set temperature (Celsius) drive Remote start vehicle flash-lights Flash lights frunk-open Open vehicle frunk. Note that there's no frunk-close command! get GET an owner API http ENDPOINT. Hostname will be taken from -config. honk Honk horn list-keys List public keys enrolled on vehicle lock Lock vehicle media-set-volume Set volume ping Ping vehicle post POST to ENDPOINT the contents of FILE. Hostname will be taken from -config. product-info Print JSON product info remove-key Remove PUBLIC_KEY from vehicle whitelist rename-key Change the human-readable metadata of PUBLIC_KEY to NAME, MODEL, KIND seat-heater Set seat heater at POSITION to LEVEL sentry-mode Set sentry mode to STATE ('on' or 'off') session-info Retrieve session info for PUBLIC_KEY from DOMAIN software-update-cancel Cancel a pending software update software-update-start Start software update after DELAY steering-wheel-heater Set steering wheel mode to STATE ('on' or 'off') trunk-close Closes vehicle trunk. Only available on certain vehicle types. trunk-move Toggle trunk open/closed. Closing is only available on certain vehicle types. trunk-open Open vehicle trunk. Note that trunk-close only works on certain vehicle types. unlock Unlock vehicle wake Wake up vehicle
One interesting command is: get GET an owner API http ENDPOINT. Hostname will be taken from -config. Maybe this can be used to access more commands that can be sent also locally.
A Tessie integration is included in the Home Assistant release 2024.1, which uses the official FleetAPI and is thus officially supported now by both Tesla and Home Assistant.
The Tessie integration is currently available in RC testing and supports charging_amps for vehicles, no support for energy/ solar products and looks quite feature comparable for vehicles with this Tesla integration. https://rc.home-assistant.io/integrations/tessie
Thanks for the hint about Tessie. Hopefully others like TezLab will follow shortly (I’m a TezLab user).
A Tessie integration is included in the Home Assistant release 2024.1, which uses the official FleetAPI and is thus officially supported now by both Tesla and Home Assistant.
The Tessie integration is currently available in RC testing and supports charging_amps for vehicles, no support for energy/ solar products and looks quite feature comparable for vehicles with this Tesla integration. https://rc.home-assistant.io/integrations/tessie
As of now am not using Tessie or other third party app as HA was enough for my needs. I am still looking for a true open source solution. How much does Tessie ask for an account that can be used with HA? As I've seen in the FleetAPI docs there are some limitations on the number of commands.
A Tessie integration is included in the Home Assistant release 2024.1, which uses the official FleetAPI and is thus officially supported now by both Tesla and Home Assistant. The Tessie integration is currently available in RC testing and supports charging_amps for vehicles, no support for energy/ solar products and looks quite feature comparable for vehicles with this Tesla integration. https://rc.home-assistant.io/integrations/tessie
As of now am not using Tessie or other third party app as HA was enough for my needs. I am still looking for a true open source solution. How much does Tessie ask for an account that can be used with HA? As I've seen in the FleetAPI docs there are some limitations on the number of commands.
I checked and they charge 4.99 per month. I found that Teslascope is cheaper and offers a free basic account that is sufficient for sending charge control commands 1-2 times per minute. There is no HA integration, but the API is reasonably simple. It's a web service, and you issue a http get or post statement with credentials and the usual command syntax. They are just moving from a simple and developer-friendly key-in-paramater system to http authentication, but HA can handle that.
Why is it that HA (or an external integration) can't make the same calls as those cloud apps, and we need to go through one of them? (Sorry if this comment/question does not belong in here.)
On Fri, Dec 29, 2023 at 10:31 AM top-gun @.***> wrote:
A Tessie integration is included in the Home Assistant release 2024.1, which uses the official FleetAPI and is thus officially supported now by both Tesla and Home Assistant. The Tessie integration is currently available in RC testing and supports charging_amps for vehicles, no support for energy/ solar products and looks quite feature comparable for vehicles with this Tesla integration. https://rc.home-assistant.io/integrations/tessie
As of now am not using Tessie or other third party app as HA was enough for my needs. I am still looking for a true open source solution. How much does Tessie ask for an account that can be used with HA? As I've seen in the FleetAPI docs there are some limitations on the number of commands.
I checked and they charge 4.99 per month. I found that Teslascope is cheaper and offers a free basic account that is sufficient for sending charge control commands 1-2 times per minute. There is no HA integration, but the API is reasonably simple. It's a web service, and you issue a http get or post statement with credentials and the usual command syntax. They are just moving from a simple and developer-friendly key-in-paramater system to http authentication, but HA can handle that.
— Reply to this email directly, view it on GitHub https://github.com/alandtse/tesla/issues/743#issuecomment-1871875203, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFR224JFODJJHXAPGILTERDYL2EXBAVCNFSM6AAAAAA57VL7ZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZRHA3TKMRQGM . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Why is it that HA (or an external integration) can't make the same calls as those cloud apps, and we need to go through one of them? (Sorry if this comment/question does not belong in here.) … On Fri, Dec 29, 2023 at 10:31 AM top-gun @.> wrote: A Tessie integration is included in the Home Assistant release 2024.1, which uses the official FleetAPI and is thus officially supported now by both Tesla and Home Assistant. The Tessie integration is currently available in RC testing and supports charging_amps for vehicles, no support for energy/ solar products and looks quite feature comparable for vehicles with this Tesla integration. https://rc.home-assistant.io/integrations/tessie As of now am not using Tessie or other third party app as HA was enough for my needs. I am still looking for a true open source solution. How much does Tessie ask for an account that can be used with HA? As I've seen in the FleetAPI docs there are some limitations on the number of commands. I checked and they charge 4.99 per month. I found that Teslascope is cheaper and offers a free basic account that is sufficient for sending charge control commands 1-2 times per minute. There is no HA integration, but the API is reasonably simple. It's a web service, and you issue a http get or post statement with credentials and the usual command syntax. They are just moving from a simple and developer-friendly key-in-paramater system to http authentication, but HA can handle that. — Reply to this email directly, view it on GitHub <#743 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFR224JFODJJHXAPGILTERDYL2EXBAVCNFSM6AAAAAA57VL7ZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZRHA3TKMRQGM . You are receiving this because you are subscribed to this thread.Message ID: @.>
Because Musk wants to get money from the API calls. And for that a third party needs to register to Tesla and be between a user and the Tesla server. Otherwise the calls will not work. That is the short version.
Why is it that HA (or an external integration) can't make the same calls as those cloud apps, and we need to go through one of them? (Sorry if this comment/question does not belong in here.) … On Fri, Dec 29, 2023 at 10:31 AM top-gun @._> wrote: A Tessie integration is included in the Home Assistant release 2024.1, which uses the official FleetAPI and is thus officially supported now by both Tesla and Home Assistant. The Tessie integration is currently available in RC testing and supports chargingamps for vehicles, no support for energy/ solar products and looks quite feature comparable for vehicles with this Tesla integration. https://rc.home-assistant.io/integrations/tessie As of now am not using Tessie or other third party app as HA was enough for my needs. I am still looking for a true open source solution. How much does Tessie ask for an account that can be used with HA? As I've seen in the FleetAPI docs there are some limitations on the number of commands. I checked and they charge 4.99 per month. I found that Teslascope is cheaper and offers a free basic account that is sufficient for sending charge control commands 1-2 times per minute. There is no HA integration, but the API is reasonably simple. It's a web service, and you issue a http get or post statement with credentials and the usual command syntax. They are just moving from a simple and developer-friendly key-in-paramater system to http authentication, but HA can handle that. — Reply to this email directly, view it on GitHub <#743 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFR224JFODJJHXAPGILTERDYL2EXBAVCNFSM6AAAAAA57VL7ZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZRHA3TKMRQGM . You are receiving this because you are subscribed to this thread.Message ID: @_._>
Because Musk wants to get money from the API calls. And for that a third party needs to register to Tesla and be between a user and the Tesla server. Otherwise the calls will not work. That is the short version.
Well, first of all, that's not true. Tesla has been in contact with several of the Logger services and stated that they will support rate plans that will be free to allow noncommercial single-user applications. Mr Musk wants money from commercial API users, but they don't plan to charge for light non-commercial usage.
Second, Teslascope has to give money to Tesla just like Tessie, and yet they offer the service at a fraction of the cost.
As I wrote, you can use the free Teslascope service plan to perform charge control. You will also eventually be able to register a non-commercial plan directly with Tesla. Or you can give 3 USD to Teslascope instead of 5 USD to Tessie. Unfortunately, the most expensive solution is the only one that is integrated into HomeAssistant.
Fwiw, personally, I opted for a different solution: As of now, it is possible to perform charge-control via Bluetooth. There is a reference application from Tesla that is written in Golang. I put that reference application onto a spare Pi that I put into my garage, and my automations send MQTT messages for start, stop and amperage control. There is a simple Bash-script on the pi that subscribes to the MQTT topic and sends the commands to the car.
Caveat: This means you need another Pi, and it's not as simple as calling an integration.
Why is it that HA (or an external integration) can't make the same calls as those cloud apps, and we need to go through one of them? (Sorry if this comment/question does not belong in here.)
There is no reason HA cannot do the same, what is required is the ability to do the coding.
The new official FleetAPI only requires a level of authentication which should be possible to build with HA, so there is no technical limitation.
The more options there are, Tessie and this custom integration (which actually uses 3rd party cloud services under the bonnet) the better things are with fall backs.
I'm excited with Tessie as it now provides official support from Tesla and Home Assistant for a functional solution. The existing Tesla API was always unofficial and subject to change/ breakage on a regular basis. Home Assistant didn't like the authentication methods required for this custom integration so it got dropped from core.
The great opportunity is if Tessie can get a functional model, than so can the other integration providers and if they are happy to directly support Home Assistant, then I am happy to support them as well.
Why is it that HA (or an external integration) can't make the same calls as those cloud apps, and we need to go through one of them? (Sorry if this comment/question does not belong in here.) … On Fri, Dec 29, 2023 at 10:31 AM top-gun @._> wrote: A Tessie integration is included in the Home Assistant release 2024.1, which uses the official FleetAPI and is thus officially supported now by both Tesla and Home Assistant. The Tessie integration is currently available in RC testing and supports chargingamps for vehicles, no support for energy/ solar products and looks quite feature comparable for vehicles with this Tesla integration. https://rc.home-assistant.io/integrations/tessie As of now am not using Tessie or other third party app as HA was enough for my needs. I am still looking for a true open source solution. How much does Tessie ask for an account that can be used with HA? As I've seen in the FleetAPI docs there are some limitations on the number of commands. I checked and they charge 4.99 per month. I found that Teslascope is cheaper and offers a free basic account that is sufficient for sending charge control commands 1-2 times per minute. There is no HA integration, but the API is reasonably simple. It's a web service, and you issue a http get or post statement with credentials and the usual command syntax. They are just moving from a simple and developer-friendly key-in-paramater system to http authentication, but HA can handle that. — Reply to this email directly, view it on GitHub <#743 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFR224JFODJJHXAPGILTERDYL2EXBAVCNFSM6AAAAAA57VL7ZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZRHA3TKMRQGM . You are receiving this because you are subscribed to this thread.Message ID: @_._>
Because Musk wants to get money from the API calls. And for that a third party needs to register to Tesla and be between a user and the Tesla server. Otherwise the calls will not work. That is the short version.
Well, first of all, that's not true. Tesla has been in contact with several of the Logger services and stated that they will support rate plans that will be free to allow noncommercial single-user applications. Mr Musk wants money from commercial API users, but they don't plan to charge for light non-commercial usage.
Second, Teslascope has to give money to Tesla just like Tessie, and yet they offer the service at a fraction of the cost.
As I wrote, you can use the free Teslascope service plan to perform charge control. You will also eventually be able to register a non-commercial plan directly with Tesla. Or you can give 3 USD to Teslascope instead of 5 USD to Tessie. Unfortunately, the most expensive solution is the only one that is integrated into HomeAssistant.
Fwiw, personally, I opted for a different solution: As of now, it is possible to perform charge-control via Bluetooth. There is a reference application from Tesla that is written in Golang. I put that reference application onto a spare Pi that I put into my garage, and my automations send MQTT messages for start, stop and amperage control. There is a simple Bash-script on the pi that subscribes to the MQTT topic and sends the commands to the car.
Caveat: This means you need another Pi, and it's not as simple as calling an integration.
Even for a noncommercial user, one needs to register a domain with Tesla and get approvals. And you are not sure it will be approved. I've seen people getting rejected using their own domains. So for the regular noncommercial HA user this is a burden and close to impossible. Therefore a third party like Tessie, Teslascope, etc still needs to be used. To me I would prefer not to have a third party in between.
For now I am also using the BLE on a rpi as I wrote in a post above. It works but is has limited number of commands and hard to get feedback. For charging it works okish though.
Why is it that HA (or an external integration) can't make the same calls as those cloud apps, and we need to go through one of them? (Sorry if this comment/question does not belong in here.) … On Fri, Dec 29, 2023 at 10:31 AM top-gun @._> wrote: A Tessie integration is included in the Home Assistant release 2024.1, which uses the official FleetAPI and is thus officially supported now by both Tesla and Home Assistant. The Tessie integration is currently available in RC testing and supports chargingamps for vehicles, no support for energy/ solar products and looks quite feature comparable for vehicles with this Tesla integration. https://rc.home-assistant.io/integrations/tessie As of now am not using Tessie or other third party app as HA was enough for my needs. I am still looking for a true open source solution. How much does Tessie ask for an account that can be used with HA? As I've seen in the FleetAPI docs there are some limitations on the number of commands. I checked and they charge 4.99 per month. I found that Teslascope is cheaper and offers a free basic account that is sufficient for sending charge control commands 1-2 times per minute. There is no HA integration, but the API is reasonably simple. It's a web service, and you issue a http get or post statement with credentials and the usual command syntax. They are just moving from a simple and developer-friendly key-in-paramater system to http authentication, but HA can handle that. — Reply to this email directly, view it on GitHub <#743 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFR224JFODJJHXAPGILTERDYL2EXBAVCNFSM6AAAAAA57VL7ZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZRHA3TKMRQGM . You are receiving this because you are subscribed to this thread.Message ID: @_._>
Because Musk wants to get money from the API calls. And for that a third party needs to register to Tesla and be between a user and the Tesla server. Otherwise the calls will not work. That is the short version.
Well, first of all, that's not true. Tesla has been in contact with several of the Logger services and stated that they will support rate plans that will be free to allow noncommercial single-user applications. Mr Musk wants money from commercial API users, but they don't plan to charge for light non-commercial usage. Second, Teslascope has to give money to Tesla just like Tessie, and yet they offer the service at a fraction of the cost. As I wrote, you can use the free Teslascope service plan to perform charge control. You will also eventually be able to register a non-commercial plan directly with Tesla. Or you can give 3 USD to Teslascope instead of 5 USD to Tessie. Unfortunately, the most expensive solution is the only one that is integrated into HomeAssistant. Fwiw, personally, I opted for a different solution: As of now, it is possible to perform charge-control via Bluetooth. There is a reference application from Tesla that is written in Golang. I put that reference application onto a spare Pi that I put into my garage, and my automations send MQTT messages for start, stop and amperage control. There is a simple Bash-script on the pi that subscribes to the MQTT topic and sends the commands to the car. Caveat: This means you need another Pi, and it's not as simple as calling an integration.
Even for a noncommercial user, one needs to register a domain with Tesla and get approvals. And you are not sure it will be approved. I've seen people getting rejected using their own domains. So for the regular noncommercial HA user this is a burden and close to impossible. Therefore a third party like Tessie, Teslascope, etc still needs to be used. To me I would prefer not to have a third party in between.
For now I am also using the BLE on a rpi as I wrote in a post above. It works but is has limited number of commands and hard to get feedback. For charging it works okish though.
Well, that's an observation based on past development. Tesla acknowledging the needs of non-commercial users is a very new development, and they haven't yet said how this will be accomplished. I expect modifications to the registration process in the weeks and months to come.
Anyway, it's a pity that the new integration uses a more expensive provider. I hope someone adapts the old integration to either directly use the yet-to-be-accnounced solution from Tesla or the cheaper providers like Teslascope.
Why is it that HA (or an external integration) can't make the same calls as those cloud apps, and we need to go through one of them? (Sorry if this comment/question does not belong in here.) … On Fri, Dec 29, 2023 at 10:31 AM top-gun @._> wrote: A Tessie integration is included in the Home Assistant release 2024.1, which uses the official FleetAPI and is thus officially supported now by both Tesla and Home Assistant. The Tessie integration is currently available in RC testing and supports chargingamps for vehicles, no support for energy/ solar products and looks quite feature comparable for vehicles with this Tesla integration. https://rc.home-assistant.io/integrations/tessie As of now am not using Tessie or other third party app as HA was enough for my needs. I am still looking for a true open source solution. How much does Tessie ask for an account that can be used with HA? As I've seen in the FleetAPI docs there are some limitations on the number of commands. I checked and they charge 4.99 per month. I found that Teslascope is cheaper and offers a free basic account that is sufficient for sending charge control commands 1-2 times per minute. There is no HA integration, but the API is reasonably simple. It's a web service, and you issue a http get or post statement with credentials and the usual command syntax. They are just moving from a simple and developer-friendly key-in-paramater system to http authentication, but HA can handle that. — Reply to this email directly, view it on GitHub <#743 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFR224JFODJJHXAPGILTERDYL2EXBAVCNFSM6AAAAAA57VL7ZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZRHA3TKMRQGM . You are receiving this because you are subscribed to this thread.Message ID: @_._>
Because Musk wants to get money from the API calls. And for that a third party needs to register to Tesla and be between a user and the Tesla server. Otherwise the calls will not work. That is the short version.
Well, first of all, that's not true. Tesla has been in contact with several of the Logger services and stated that they will support rate plans that will be free to allow noncommercial single-user applications. Mr Musk wants money from commercial API users, but they don't plan to charge for light non-commercial usage. Second, Teslascope has to give money to Tesla just like Tessie, and yet they offer the service at a fraction of the cost. As I wrote, you can use the free Teslascope service plan to perform charge control. You will also eventually be able to register a non-commercial plan directly with Tesla. Or you can give 3 USD to Teslascope instead of 5 USD to Tessie. Unfortunately, the most expensive solution is the only one that is integrated into HomeAssistant. Fwiw, personally, I opted for a different solution: As of now, it is possible to perform charge-control via Bluetooth. There is a reference application from Tesla that is written in Golang. I put that reference application onto a spare Pi that I put into my garage, and my automations send MQTT messages for start, stop and amperage control. There is a simple Bash-script on the pi that subscribes to the MQTT topic and sends the commands to the car. Caveat: This means you need another Pi, and it's not as simple as calling an integration.
Even for a noncommercial user, one needs to register a domain with Tesla and get approvals. And you are not sure it will be approved. I've seen people getting rejected using their own domains. So for the regular noncommercial HA user this is a burden and close to impossible. Therefore a third party like Tessie, Teslascope, etc still needs to be used. To me I would prefer not to have a third party in between. For now I am also using the BLE on a rpi as I wrote in a post above. It works but is has limited number of commands and hard to get feedback. For charging it works okish though.
Well, that's an observation based on past development. Tesla acknowledging the needs of non-commercial users is a very new development, and they haven't yet said how this will be accomplished. I expect modifications to the registration process in the weeks and months to come.
Anyway, it's a pity that the new integration uses a more expensive provider. I hope someone adapts the old integration to either directly use the yet-to-be-accnounced solution from Tesla or the cheaper providers like Teslascope.
Can you please provide a link where to read about Tesla ack the noncommercial users?
I am reading this and wondering why is such API needed in first place, regarding charging. It is great, mostly for reading car feedback. I may see sort of need to unlock frunk via API but with no serious use case. However, most common way to talk to the car to adjust charging and/or start/stop is by PWM. So, why hassle with API, why build BT? Why not to send PWM? I bought charger which does it by PWM as I saw it as good enough but I also transplanted countless chips in power points, fans, lights, etc. I I ever wanted charger which I could not buy, I would make one using some cheap charger and ESP as PWM generator. I see many people (including myself) doing everything for HA to work without involving any sort of cloud service, here however, everyone wants cloud instead?
I am reading this and wondering why is such API needed in first place, regarding charging. It is great, mostly for reading car feedback. I may see sort of need to unlock frunk via API but with no serious use case. However, most common way to talk to the car to adjust charging and/or start/stop is by PWM. So, why hassle with API, why build BT? Why not to send PWM? I bought charger which does it by PWM as I saw it as good enough but I also transplanted countless chips in power points, fans, lights, etc. I I ever wanted charger which I could not buy, I would make one using some cheap charger and ESP as PWM generator. I see many people (including myself) doing everything for HA to work without involving any sort of cloud service, here however, everyone wants cloud instead?
Because the Tesla-API can control the charging current from 0-16 Amps, while the generic wallbox-control allows 6-16A. If you use PV-energy to charge your car, you want that whole range. I run a 8.5kWp-system, and the real-world output goes 2kW-7kW-2.5kW-8kW-3kW-6kW all day long. With a wallbox-control system, you have the option to go three-phase 4.6-11kW or one-phase 1.4-4kW. You can't cover the full range. Some wall-boxes have the ability to switch from single-phase to three-phase and back, but that means you stop charging, turn on/off two phases, then restart charging. In the long run, this will wear down the charger module in the car, as the large switches will fail after some thousand clicks. And: For a "smart" wallbox with phase-switching, you spend 1,000+ Euro/USD, while a simple 3-phase-wallbox is 250-500 Euro/USD.
Because the Tesla-API can control the charging current from 0-16 Amps, while the generic wallbox-control allows 6-16A. If you use PV-energy to charge your car, you want that whole range. I run a 8.5kWp-system, and the real-world output goes 2kW-7kW-2.5kW-8kW-3kW-6kW all day long. With a wallbox-control system, you have the option to go three-phase 4.6-11kW or one-phase 1.4-4kW. You can't cover the full range. Some wall-boxes have the ability to switch from single-phase to three-phase and back, but that means you stop charging, turn on/off two phases, then restart charging. In the long run, this will wear down the charger module in the car, as the large switches will fail after some thousand clicks. And: For a "smart" wallbox with phase-switching, you spend 1,000+ Euro/USD, while a simple 3-phase-wallbox is 250-500 Euro/USD.
That's incorrect. PWM is fluent while API is by 1A and PWM does go beyond standard just car has to be able to obey. The reason for chargers to limit PWM is to comply with cars and standard. All chargers do 0A and for 1A-5A, I believe Tesla will do it via PWM too. Self made PWM generator to upgrade simple EVSE won't cost over $100. That is similar to any BT gateway implementation and same difficult (or easy).
Because the Tesla-API can control the charging current from 0-16 Amps, while the generic wallbox-control allows 6-16A. If you use PV-energy to charge your car, you want that whole range. I run a 8.5kWp-system, and the real-world output goes 2kW-7kW-2.5kW-8kW-3kW-6kW all day long. With a wallbox-control system, you have the option to go three-phase 4.6-11kW or one-phase 1.4-4kW. You can't cover the full range. Some wall-boxes have the ability to switch from single-phase to three-phase and back, but that means you stop charging, turn on/off two phases, then restart charging. In the long run, this will wear down the charger module in the car, as the large switches will fail after some thousand clicks. And: For a "smart" wallbox with phase-switching, you spend 1,000+ Euro/USD, while a simple 3-phase-wallbox is 250-500 Euro/USD.
That's incorrect. PWM is fluent while API is by 1A and PWM does go beyond standard just car has to be able to obey. The reason for chargers to limit PWM is to comply with cars and standard. All chargers do 0A and for 1A-5A, I believe Tesla will do it via PWM too. Self made PWM generator to upgrade simple EVSE won't cost over $100. That is similar to any BT gateway implementation and same difficult (or easy).
Well, that's simply illegal in my country. You are not allowed to install a homebrew wallbox, and the industrial ones work with the normal pilot signal to communicate with the car.
AC current is dangerous, don't mess with it. I can kill or injure you, it can damage the car, and it can burn the house.
Because the Tesla-API can control the charging current from 0-16 Amps, while the generic wallbox-control allows 6-16A. If you use PV-energy to charge your car, you want that whole range. I run a 8.5kWp-system, and the real-world output goes 2kW-7kW-2.5kW-8kW-3kW-6kW all day long. With a wallbox-control system, you have the option to go three-phase 4.6-11kW or one-phase 1.4-4kW. You can't cover the full range. Some wall-boxes have the ability to switch from single-phase to three-phase and back, but that means you stop charging, turn on/off two phases, then restart charging. In the long run, this will wear down the charger module in the car, as the large switches will fail after some thousand clicks. And: For a "smart" wallbox with phase-switching, you spend 1,000+ Euro/USD, while a simple 3-phase-wallbox is 250-500 Euro/USD.
That's incorrect. PWM is fluent while API is by 1A and PWM does go beyond standard just car has to be able to obey. The reason for chargers to limit PWM is to comply with cars and standard. All chargers do 0A and for 1A-5A, I believe Tesla will do it via PWM too. Self made PWM generator to upgrade simple EVSE won't cost over $100. That is similar to any BT gateway implementation and same difficult (or easy).
PWM could work but I have to check it by myself if Tesla OBC supports going low current by PWM duty cycle. As I know the duty cycles at the lower and higher ends are used for other purposes. But Indeed it will be quite easy and cheap with an ESP32 to do this if Tesla supports it. I have an ongoing bigger project in which I want to check this but also record and decipher the CCS communication between the car and a DC charger.
On another side, the BLE code is already published and just needs to be compiled and installed on the rpi. Not much effort needed and provides other commands beside charging. I wanted to put it on ESP32 but the golang to C conversion takes some time and doing wifi and BLE in the same time does not work very well on ESP. Still plan to do it with maybe some light golang library for ESP.
API access through Tesla server would be better because I can read the line voltage from the car and calculate properly when power from PV excess can be increased/decreased. This is how I'm doing now and works great.
Because the Tesla-API can control the charging current from 0-16 Amps, while the generic wallbox-control allows 6-16A. If you use PV-energy to charge your car, you want that whole range. I run a 8.5kWp-system, and the real-world output goes 2kW-7kW-2.5kW-8kW-3kW-6kW all day long. With a wallbox-control system, you have the option to go three-phase 4.6-11kW or one-phase 1.4-4kW. You can't cover the full range. Some wall-boxes have the ability to switch from single-phase to three-phase and back, but that means you stop charging, turn on/off two phases, then restart charging. In the long run, this will wear down the charger module in the car, as the large switches will fail after some thousand clicks. And: For a "smart" wallbox with phase-switching, you spend 1,000+ Euro/USD, while a simple 3-phase-wallbox is 250-500 Euro/USD.
That's incorrect. PWM is fluent while API is by 1A and PWM does go beyond standard just car has to be able to obey. The reason for chargers to limit PWM is to comply with cars and standard. All chargers do 0A and for 1A-5A, I believe Tesla will do it via PWM too. Self made PWM generator to upgrade simple EVSE won't cost over $100. That is similar to any BT gateway implementation and same difficult (or easy).
PWM could work but I have to check it by myself if Tesla OBC supports going low current by PWM duty cycle. As I know the duty cycles at the lower and higher ends are used for other purposes. But Indeed it will be quite easy and cheap with an ESP32 to do this if Tesla supports it. I have an ongoing bigger project in which I want to check this but also record and decipher the CCS communication between the car and a DC charger.
On another side, the BLE code is already published and just needs to be compiled and installed on the rpi. Not much effort needed and provides other commands beside charging. I wanted to put it on ESP32 but the golang to C conversion takes some time and doing wifi and BLE in the same time does not work very well on ESP. Still plan to do it with maybe some light golang library for ESP.
API access through Tesla server would be better because I can read the line voltage from the car and calculate properly when power from PV excess can be increased/decreased. This is how I'm doing now and works great.
I don't believe that people who used a finished car monitoring and management API are waiting for a homebrew-solution that works with 400V DC and self-built hardware. Stock household wallboxes work with 3-phase 230V AC or 2-phase 120V AC.
Because the Tesla-API can control the charging current from 0-16 Amps, while the generic wallbox-control allows 6-16A. If you use PV-energy to charge your car, you want that whole range. I run a 8.5kWp-system, and the real-world output goes 2kW-7kW-2.5kW-8kW-3kW-6kW all day long. With a wallbox-control system, you have the option to go three-phase 4.6-11kW or one-phase 1.4-4kW. You can't cover the full range. Some wall-boxes have the ability to switch from single-phase to three-phase and back, but that means you stop charging, turn on/off two phases, then restart charging. In the long run, this will wear down the charger module in the car, as the large switches will fail after some thousand clicks. And: For a "smart" wallbox with phase-switching, you spend 1,000+ Euro/USD, while a simple 3-phase-wallbox is 250-500 Euro/USD.
That's incorrect. PWM is fluent while API is by 1A and PWM does go beyond standard just car has to be able to obey. The reason for chargers to limit PWM is to comply with cars and standard. All chargers do 0A and for 1A-5A, I believe Tesla will do it via PWM too. Self made PWM generator to upgrade simple EVSE won't cost over $100. That is similar to any BT gateway implementation and same difficult (or easy).
PWM could work but I have to check it by myself if Tesla OBC supports going low current by PWM duty cycle. As I know the duty cycles at the lower and higher ends are used for other purposes. But Indeed it will be quite easy and cheap with an ESP32 to do this if Tesla supports it. I have an ongoing bigger project in which I want to check this but also record and decipher the CCS communication between the car and a DC charger. On another side, the BLE code is already published and just needs to be compiled and installed on the rpi. Not much effort needed and provides other commands beside charging. I wanted to put it on ESP32 but the golang to C conversion takes some time and doing wifi and BLE in the same time does not work very well on ESP. Still plan to do it with maybe some light golang library for ESP. API access through Tesla server would be better because I can read the line voltage from the car and calculate properly when power from PV excess can be increased/decreased. This is how I'm doing now and works great.
I don't believe that people who used a finished car monitoring and management API are waiting for a homebrew-solution that works with 400V DC and self-built hardware. Stock household wallboxes work with 3-phase 230V AC or 2-phase 120V AC.
:) Giving the fear of HV you show, I would bet you are a SW only person. I am a HW and Firmware eng who designed and build HV inverters, so please relax, everybody is doing experiments it on it's own.
It's great there is a healthy discussion, but please remember that people are subscribed to this issue and for its resolution from this repositories point of view.
It's great there is a healthy discussion, but please remember that people are subscribed to this issue and for its resolution from this repositories point of view.
Well, I sort of agree with you as this is why people came here, however, isn't it a bit wider question too, such as "what can be done to control charging from Home Assistant?". It is HA extension.
Well, that's simply illegal in my country. You are not allowed to install a homebrew wallbox, and the industrial ones work with the normal pilot signal to communicate with the car.
AC current is dangerous, don't mess with it. I can kill or injure you, it can damage the car, and it can burn the house.
Well, the PWM is actually 24V AC. Control wire starts with positive 12V when disconnected and once connected does square AC 1kHz with 10% duty for 6A and 53% duty for 32A. All the rest, including power delivery and even driver for PWM is already there and possibly can be reused. No power circuit has to be modified.
I don't believe that people who used a finished car monitoring and management API are waiting for a homebrew-solution that works with 400V DC and self-built hardware. Stock household wallboxes work with 3-phase 230V AC or 2-phase 120V AC.
I believe depends on who. There is nice but irrelevant now project showing how to modify Tesla EVSE by adding PI inside to get it to follow PV surplus and charge solar only. It is irrelevant as it works with Gen2, now EoL product.
@darek-margas Could you post the link to that project, might be useful for others.
[edit] Found this project -> https://github.com/dracoventions/TWCManager
@darek-margas Could you post the link to that project, might be useful for others.
[edit] Found this project -> https://github.com/dracoventions/TWCManager
Yeah, that's the one!
Hello,
This comment from a Tesla employee : https://github.com/teslamotors/vehicle-command/issues/111#issuecomment-1867243463 is confirming that they are aware of the need (as said on teslascope twitter), and even allow personal usage of the API.
I confirm that i was able to register, and get credientials immediately (with a fake tax id matching the regex on the input field, and a company name starting by "Personal Use" so they can't miss it.
I'm confident that if they do something specific for open-source users, that will probably only affect the authentication part, not the API endpoints.
Currently i'm using Tessie integration on Home Assistant, and it works really great (and i planned to do this temporarily untill this integration is fixed, but again, it works realy great...).
Hi all - so come January 1st this integration will stop? If so, that's very sad as I'm not aware of any alternative. Is there any initiative at hand that I could help with or contribute to? What can I otherwise do to manage my tesla charging in HA?
Hi all - the new Tessie integration w/ HA 24.1 is working well for me. I disabled my "Tesla Custom Integration" and installed Tessie without any issues. Tessie needs an API key (with a Tessie account subscription) as part of the install. To issue commands to the car (e.g. open charge port, change charger amps) required the set-up of a virtual key via my phone with the Tesla App installed (won't work via PC) - see Tessie instructions as follows. In all pretty painless and glad to have it all working on the new Tesla API. https://help.tessie.com/article/117-virtual-key
Hi all - so come January 1st this integration will stop? If so, that's very sad as I'm not aware of any alternative. Is there any initiative at hand that I could help with or contribute to? What can I otherwise do to manage my tesla charging in HA?
Hi all - the new Tessie integration w/ HA 24.1 is working well for me. I disabled my "Tesla Custom Integration" and installed Tessie without any issues. Tessie needs an API key (with a Tessie account subscription) as part of the install. To issue commands to the car (e.g. open charge port, change charger amps) required the set-up of a virtual key via my phone with the Tesla App installed (won't work via PC) - see Tessie instructions as follows. In all pretty painless and glad to have it all working on the new Tesla API. https://help.tessie.com/article/117-virtual-key
Oh. I bought my M3, but in Germany, many Teslas are leased, so that's going to be a challenge for many owners. Thanks for mentioning it, I didn't know about that.
Oh. I bought my M3, but in Germany, many Teslas are leased, so that's going to be a challenge for many owners. Thanks for mentioning it, I didn't know about that.
There is a ticket about that : https://github.com/teslamotors/vehicle-command/issues/45 For sure, given the number of companies that are leasing the cars for their employes, tesla will have to be more flexible on that if they want to sell their fleet services (unless they want the leasing companies to sell that service for the cars they provide... ? but for sure that will reduce the market potential)
Is your feature request related to a problem? Please describe. Starting 2024 Tesla will shutdown the existing vehicle command REST-API and requires end to end signed commands through a new API
https://developer.tesla.com/docs/fleet-api#2023-10-09-rest-api-vehicle-commands-endpoint-deprecation-warning
Describe the solution you'd like Maybe a possible migration strategy should be discussed. It may will be more difficult for end users with no IT experience to install this integration, because Tesla requires a public accessible domain with a hosted public certificate for each application.
Describe alternatives you've considered To be discussed.