Polling and commands fail due to Error 429 - Too Many Requests - Tesla rate limiting

Is there an existing issue for this?

[X] I have searched both the existing open issues & recently closed issues and did not find a duplicate of this issue.

I have read about the Fleet API and understand I may need to use it

[X] I understand issues relating to read only commands will be auto closed if not using the Fleet API.

Version of the Tesla component
3.21.0
Version of the Tesla car software
2024.14.3
Model
Model Y
Current Behavior
I setup the Fleet API via Tesla HTTP Proxy add-on a few days back. The custom integration was working at that point and I could see vehicle status and also issue commands. Today, commands stopped working but stats get updated. The integration been throwing a range of errors. Initially it was throwing UnknownException and since then I have deleted the integration, generated new Refresh Token in Tesla HTTP Proxy and set it up again. See latest log here https://pastebin.com/3R0s2Wcr - this starts from custom integration setup and until includes issue of one command.
Expected Behavior
Commands should work
Debug logs
2024-05-09 17:40:27.467 DEBUG (MainThread) [custom_components.tesla_custom.config_flow] Running in supervised environment
2024-05-09 17:40:27.499 DEBUG (MainThread) [custom_components.tesla_custom.config_flow] Found addon: c0<REDACTED>_tesla_http_proxy
2024-05-09 17:40:41.224 DEBUG (MainThread) [custom_components.tesla_custom.config_flow] Credentials successfully connected to the Tesla API
2024-05-09 17:40:41.227 DEBUG (MainThread) [custom_components.tesla_custom] Trusting CA: {'subject': ((('countryName', 'TR'),), (('localityName', 'Gebze - Kocaeli'),), (('organizationName', 'Turkiye Bilimsel ve Teknolojik Arastirma Kurumu - TUBITAK'),), (('organizationalUnitName', 'Kamu Sertifikasyon Merkezi - Kamu SM'),), (('commonName', 'TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1'),)), 'issuer': ((('countryName', 'TR'),), (('localityName', 'Gebze - Kocaeli'),), (('organizationName', 'Turkiye Bilimsel ve Teknolojik Arastirma Kurumu - TUBITAK'),), (('organizationalUnitName', 'Kamu Sertifikasyon Merkezi - Kamu SM'),), (('commonName', 'TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1'),)), 'version': 3, 'serialNumber': '01', 'notBefore': 'Nov 25 08:25:55 2013 GMT', 'notAfter': 'Oct 25 08:25:55 2043 GMT'}
2024-05-09 17:40:41.242 DEBUG (MainThread) [teslajsonpy.controller] 552 endpoints loaded
2024-05-09 17:40:41.242 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in -19853 days, 6:19:19
2024-05-09 17:40:41.242 DEBUG (MainThread) [teslajsonpy.connection] Oauth expiration detected
2024-05-09 17:40:41.242 DEBUG (MainThread) [teslajsonpy.connection] Refreshing access token with refresh_token
2024-05-09 17:40:42.061 DEBUG (MainThread) [teslajsonpy.connection] Saved new auth info {'access_token': '<REDACTED>', 'refresh_token': '<REDACTED>', 'expires_in':<PHONE_NUMBER>}
2024-05-09 17:40:42.061 DEBUG (MainThread) [teslajsonpy.connection] Successfully refreshed oauth
2024-05-09 17:40:42.061 DEBUG (MainThread) [teslajsonpy.connection] get: https://c0<REDACTED>-tesla-http-proxy/api/1/products {}
2024-05-09 17:40:42.867 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":[{"id":<REDACTED>,"user_id":<REDACTED>,"vehicle_id":<REDACTED>,"vin":"<REDACTED_VIN>","color":null,"access_type":"OWNER","display_name":"shadowfax","option_codes":null,"cached_data":"EicKAgoAEgISABoCIgAqAhIAOgwIq/vxsQYQgKeEmwPABgDQBgDgBgAatwEKAhIA+gEGCJDBybAGmgICGgDiAgwIq/vxsQYQgKeEmwPqAgIKAPICAgoA8gkICgIKABIAGgDABmTIBlDQBjLYBmToBgHwBgD9BihNSkOFB5K8KUONByhNSkOQB06YB06lB6eliT6tBwAAgD+1BwAAgD+4BwLABxDIBwDQBwDoBwDwBwD4BwCQCACoCAHACADICBDQCBCYCZELoAkAqAkQuAn0CMAJAMgJ6ALQCQDlCQAAAAD4CQAilwHyAQIKAIoCDAir+/GxBhCAp4SbA5oCAgoArQZnZqJBtQYAAIRBvQYAAKBBxQYAAKBByAYA0AYA2AYA4AYA6AYA8AYA/QYAAHBBhQcAAOBBiAcAkAcAmAcAoAcAqAcA0AcA6AcA8AcA+AcAgAgAiAgAsAgAwAgAyAgA0AgB6AgB8AgB+AgBgAkAkAkCmAkAoAkBsAkAuAkBKgAytgKyAhIKAgoAwAaMFcgGANAGAdoGASC6AgOoBgHaAgwIq/vxsQYQgKeEmwPyAgIKAPoCAhIAugMJ//f/3g//+LIS0gMLCM368bEGEMCGmW3aAwsI7PrxsQYQwIaZbeIDCwjN+vGxBhDAhplt6gMLCM368bEGEMCGmW3CBACoBkziBiJ2MTIg4oGmKDIwMjQuMTQuMyBjOTM5ZDUxZjU3YjQp4oGpsgcJc2hhZG93ZmF4wAcByAcB0AcB6AgA8AgBgAkAiAkAoAkBqAkBsAkCvQlnZiZAxQlnZiZAzQkAAChA1QlnZiZA4AkA6AkAkAoAmAoAoAoAqAoAsAoBuAoBwAoByAoB1QqamTlA3QqamTlA2AQA4AQB6AQB8AQA+AQAgAUAiAUAkAUAuAUAyAUA8AUA+AUAgAYAOpECCgIKABIDygEAOgIqAEICCgBKAnoAWgIKAGICEgBqAkoAggECEgCKAQIKAJIBAioAmgECCgC6AQIiANoBDAir+/GxBhCAp4SbA+IBAjIA6gECKgDyAQISAIICAiIAigICcgCaAgIiALgGAcAGAMgGANAGAfAGAJAHAZgHAcAHAMgHAdAHAeAHAegHAvAHAbAIAcAIAcgIAdAIANgIAegIAfAIAfgIAIAJ4OoEiAkAmAkBoAkBkgkTMjQ2LDM0LDI1NSwwLjcsMC4wNLAJAdAJA9gJAOAJAegJAfAJAPgJAIIKEUxSV1lIQ0ZTWE5DNTQ3OTQ3kAoBmAoBoAoB6AMAsAoBuAoBwAoByAoB0AoA4AoBQgBKY3oCCgCaAQIKALIBGLgGAMAGANUGAADwQt0GAABIQuUGAACqQoJ9DAir+/GxBhCAp4SbA6gGALAGALgGAMAGAMgGANAGANgGAOAGAOgGAPAGAIgHAZAHAKAHAKgHALAHAMAHAVo8CAUSGgEC5C9FaRm8DZxbAqo1kreSLczApsL8T6NaGhw2E4CvMRCompo3F3hZWNXjV612lenCXExsTqopWo4BCAgSbFeadnubD+5zwtyJHZgpxGXiz2mvJ7sl6JEVxji9JKKlDUTCv0+W9mHrI5HJH1H3E23oIwj2BbpZP9D4fdX/secTMIZGap2BF78Rdp4QMzEP++JDBESU71L0GMh50/WcRSxEfo66L556SqFC8BocBJAypCD4TqffMVpFeVhx0G7kvtBWYNZSbaLiG1pCCLgvEh9SXHa9ySnaKFGYLvnXn1bat7MXlyAbjqQwNTg6ecsdGhxxFAkN13tN5DRMlGn8nUVGtAXEAclWqWPhhfplYg5nb2luZ190b19zbGVlcKI4ngQSgAQJjnr8bQlx2T4JPulPrd1+vs7WK3R73+5n6d59T8qFtdzR46rqo4UY4SmRRU8FI1frRfrqOGXCrulF/1Az4VxS8I+xnxWnNgO3c4iMuowt3WNrpMoMKrEFy7FLcZtTE8J7qZBbbGAT9z4YrZuwZzHxjNF6hUQXYcnuLkzeENjdTdyIPHY5FShdwyQcG7E5g0uBI7NSgYy3FlZsYXjJdev9calvxZFxVZgH+SWgRLCFazNkWhvzDHg+9QtGtLKMk+XSVsKcuHQcJgewt3D5materMhHDQkofr5zq8e4vsFquKed8GzB2CKFbDthW/C2VlWnaz3CQl1FIkqbQDY1l+HvSa4nrQ8m2OXIcQICrrD4uNZdAwNDtdZ3pwk3JskQdWvo4J8JQXiKBhIAbDN2s0OrjxLXbNkQRPffmSb112VL1OII69udqPkzhPYeJuEKguMX46ILOwL5PZI2+i8iBrRq8Qr8HTawWYZ44iLp8pXkX8EN1IWTEQZ9uSZCqRp44RjUrO9j/7B/XJNickBAPiWOIPse3lIwaiH45j/3ZB/k0v97Z0jjJRA136kyxPvAcesu/DjcUewNW6bC/9NrUvHvGwZVubEyKXOiuBWEjhpyEvH3bgYMFO+4Fjf5oNvA055+WquCKQbxXsbV6mVR5G+FBGkro6Of5yrLvTrN0Ni/JRoLCLH8lLIGEMDU4kwiDAjQyI2tBhCAu8KVAqI4ngQSgAQ5mjsshBAUpHXc91MFp/qPki0hfOxC2t0uhqptUwZfzSLA4mWjO+kKjvaRwoDzZ4FU0rXD4e49+61bRithGmOsW3csnwTFlZrXKrM0suSnAcD5C0e1VlOlUoeGxQ+1Si7TSkrrJ5d1XSFan5aVDNN3bYWD69LYH3a07IKBThA1ZmDH+wQA6zW+g5YkyRN9mDshEBqb4ORK/Cu6SRz4oSne0mzj6MPF3ui/2CSthsEdyNLGYLF23axUsIcDinIgMQhQhgjxm3sSZUSopmXCJt0DR0m8dMYh7m3tvtgUFUqgGg7m+C/SyOeyuKWOIJ58KuW/entWSNfNVDmcSwSzE3nsW/Gapj8IGR7q0KrmLezdwTc6XaBtHWeFeQbnwxzSlwY66VREBJNAnAYUtkdygEwDTGpPU+VfLlnZZJIv+vkAUc6qFbbxBNyK38h7aQPyxBMzXxU3+/RTg+WXgtsER0+l/nVqvxjyrrynX/MLyg5BXqZNGJ46ost78msG426d/E3Qgd358W2M/NXcUGJ5ij8lsS0TMNM7EocJWQ/zCREA2Xy3bBxCFgjfg2tfBFiG+Vhu2fgw24gKbwZyJN19aYWEiNlmSUZorT0Sa2EBAc2Ql+LOaq5qwNJEA1GqKpo/XYlMFPW9a0I/TriZkVqR6u8VQM6YgQHEUIWq4WKo//9lThoLCLH8lLIGEMDU4kwiDAj/5futBhCAk6uyAbg+AQ==","granular_access":{"hide_private":false},"tokens":["a93e355b1a27cf80","ea98435367380ffe"],"state":"offline","in_service":false,"id_s":"<REDACTED>","calendar_enabled":true,"api_version":76,"backseat_token":null,"backseat_token_updated_at":null,"ble_autopair_enrolled":false,"command_signing":"required","release_notes_supported":true}],"count":1}
2024-05-09 17:40:42.867 DEBUG (MainThread) [teslajsonpy.controller] 47947: Changing car_online from {} to False
2024-05-09 17:40:42.867 DEBUG (MainThread) [teslajsonpy.controller] 47947: Resetting last_parked_timestamp to:<PHONE_NUMBER> shift_state None
2024-05-09 17:40:42.867 DEBUG (MainThread) [teslajsonpy.controller] 47947: Sending wake request with deadline of:<PHONE_NUMBER>
2024-05-09 17:40:42.867 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 8:00:00
2024-05-09 17:40:42.868 DEBUG (MainThread) [teslajsonpy.connection] post: https://c0<REDACTED>-tesla-http-proxy/api/1/vehicles/<REDACTED_VIN>/wake_up {}
2024-05-09 17:40:43.072 DEBUG (MainThread) [teslajsonpy.connection] 429: Retry later

2024-05-09 17:40:43.072 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during setup, car will still be added. 429: TOO_MANY_REQUESTS
2024-05-09 17:40:43.073 INFO (MainThread) [custom_components.tesla_custom.teslamate] Un-subbing from all MQTT Topics.
2024-05-09 17:40:43.073 INFO (MainThread) [custom_components.tesla_custom.teslamate] Un-subbed from all MQTT Topics.
2024-05-09 17:40:43.073 DEBUG (MainThread) [custom_components.tesla_custom] Connected to the Tesla API
2024-05-09 17:40:43.073 DEBUG (MainThread) [custom_components.tesla_custom] Saving new tokens in config_entry
2024-05-09 17:40:43.073 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2024-05-09 17:40:43.074 DEBUG (MainThread) [teslajsonpy.controller] Get vehicles. Force: False Time: 2 Interval 60
2024-05-09 17:40:43.074 DEBUG (MainThread) [teslajsonpy.controller] 47947: Skipping update with state offline. Polling: True. Last update:<PHONE_NUMBER> ago. Last parked: 2 ago. Last wake up<PHONE_NUMBER> ago.
2024-05-09 17:40:43.074 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.000 seconds (success: True)
2024-05-09 17:40:43.099 DEBUG (MainThread) [custom_components.tesla_custom.teslamate] Got car ID. VIN:<REDACTED_VIN> TeslamateID: None
2024-05-09 17:40:53.076 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2024-05-09 17:40:53.076 DEBUG (MainThread) [teslajsonpy.controller] Get vehicles. Force: False Time: 12 Interval 60
2024-05-09 17:40:53.076 DEBUG (MainThread) [teslajsonpy.controller] 47947: Skipping update with state offline. Polling: True. Last update:<PHONE_NUMBER> ago. Last parked: 12 ago. Last wake up<PHONE_NUMBER> ago.
2024-05-09 17:40:53.076 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.000 seconds (success: True)
2024-05-09 17:40:53.122 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2024-05-09 17:40:53.123 DEBUG (MainThread) [teslajsonpy.controller] Get vehicles. Force: False Time: 12 Interval 60
2024-05-09 17:40:53.123 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.000 seconds (success: True)
2024-05-09 17:41:03.122 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2024-05-09 17:41:03.122 DEBUG (MainThread) [teslajsonpy.controller] Get vehicles. Force: False Time: 22 Interval 60
2024-05-09 17:41:03.122 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.000 seconds (success: True)
2024-05-09 17:41:03.298 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2024-05-09 17:41:03.298 DEBUG (MainThread) [teslajsonpy.controller] Get vehicles. Force: False Time: 22 Interval 60
2024-05-09 17:41:03.298 DEBUG (MainThread) [teslajsonpy.controller] 47947: Skipping update with state offline. Polling: True. Last update:<PHONE_NUMBER> ago. Last parked: 22 ago. Last wake up<PHONE_NUMBER> ago.
2024-05-09 17:41:03.298 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.000 seconds (success: True)
2024-05-09 17:41:13.122 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2024-05-09 17:41:13.122 DEBUG (MainThread) [teslajsonpy.controller] Get vehicles. Force: False Time: 32 Interval 60
2024-05-09 17:41:13.122 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.000 seconds (success: True)
2024-05-09 17:41:13.296 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2024-05-09 17:41:13.296 DEBUG (MainThread) [teslajsonpy.controller] Get vehicles. Force: False Time: 32 Interval 60
2024-05-09 17:41:13.296 DEBUG (MainThread) [teslajsonpy.controller] 47947: Skipping update with state offline. Polling: True. Last update:<PHONE_NUMBER> ago. Last parked: 32 ago. Last wake up<PHONE_NUMBER> ago.
2024-05-09 17:41:13.296 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.000 seconds (success: True)
2024-05-09 17:41:23.124 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2024-05-09 17:41:23.124 DEBUG (MainThread) [teslajsonpy.controller] Get vehicles. Force: False Time: 42 Interval 60
2024-05-09 17:41:23.124 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.000 seconds (success: True)
2024-05-09 17:41:23.297 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2024-05-09 17:41:23.297 DEBUG (MainThread) [teslajsonpy.controller] Get vehicles. Force: False Time: 42 Interval 60
2024-05-09 17:41:23.297 DEBUG (MainThread) [teslajsonpy.controller] 47947: Skipping update with state offline. Polling: True. Last update:<PHONE_NUMBER> ago. Last parked: 42 ago. Last wake up<PHONE_NUMBER> ago.
2024-05-09 17:41:23.297 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.000 seconds (success: True)
2024-05-09 17:41:33.121 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2024-05-09 17:41:33.122 DEBUG (MainThread) [teslajsonpy.controller] Get vehicles. Force: False Time: 52 Interval 60
2024-05-09 17:41:33.122 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.000 seconds (success: True)
2024-05-09 17:41:33.296 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2024-05-09 17:41:33.296 DEBUG (MainThread) [teslajsonpy.controller] Get vehicles. Force: False Time: 52 Interval 60
2024-05-09 17:41:33.296 DEBUG (MainThread) [teslajsonpy.controller] 47947: Skipping update with state offline. Polling: True. Last update:<PHONE_NUMBER> ago. Last parked: 52 ago. Last wake up<PHONE_NUMBER> ago.
2024-05-09 17:41:33.296 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.000 seconds (success: True)
2024-05-09 17:41:43.123 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2024-05-09 17:41:43.123 DEBUG (MainThread) [teslajsonpy.controller] Get vehicles. Force: False Time: 62 Interval 60
2024-05-09 17:41:43.123 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:58:59
2024-05-09 17:41:43.123 DEBUG (MainThread) [teslajsonpy.connection] get: https://c0<REDACTED>-tesla-http-proxy/api/1/products {}
2024-05-09 17:41:43.296 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2024-05-09 17:41:43.404 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":[{"id":<REDACTED>,"user_id":<REDACTED>,"vehicle_id":<REDACTED>,"vin":"<REDACTED_VIN>","color":null,"access_type":"OWNER","display_name":"shadowfax","option_codes":null,"cached_data":"EicKAgoAEgISABoCIgAqAhIAOgwIq/vxsQYQgKeEmwPABgDQBgDgBgAatwEKAhIA+gEGCJDBybAGmgICGgDiAgwIq/vxsQYQgKeEmwPqAgIKAPICAgoA8gkICgIKABIAGgDABmTIBlDQBjLYBmToBgHwBgD9BihNSkOFB5K8KUONByhNSkOQB06YB06lB6eliT6tBwAAgD+1BwAAgD+4BwLABxDIBwDQBwDoBwDwBwD4BwCQCACoCAHACADICBDQCBCYCZELoAkAqAkQuAn0CMAJAMgJ6ALQCQDlCQAAAAD4CQAilwHyAQIKAIoCDAir+/GxBhCAp4SbA5oCAgoArQZnZqJBtQYAAIRBvQYAAKBBxQYAAKBByAYA0AYA2AYA4AYA6AYA8AYA/QYAAHBBhQcAAOBBiAcAkAcAmAcAoAcAqAcA0AcA6AcA8AcA+AcAgAgAiAgAsAgAwAgAyAgA0AgB6AgB8AgB+AgBgAkAkAkCmAkAoAkBsAkAuAkBKgAytgKyAhIKAgoAwAaMFcgGANAGAdoGASC6AgOoBgHaAgwIq/vxsQYQgKeEmwPyAgIKAPoCAhIAugMJ//f/3g//+LIS0gMLCM368bEGEMCGmW3aAwsI7PrxsQYQwIaZbeIDCwjN+vGxBhDAhplt6gMLCM368bEGEMCGmW3CBACoBkziBiJ2MTIg4oGmKDIwMjQuMTQuMyBjOTM5ZDUxZjU3YjQp4oGpsgcJc2hhZG93ZmF4wAcByAcB0AcB6AgA8AgBgAkAiAkAoAkBqAkBsAkCvQlnZiZAxQlnZiZAzQkAAChA1QlnZiZA4AkA6AkAkAoAmAoAoAoAqAoAsAoBuAoBwAoByAoB1QqamTlA3QqamTlA2AQA4AQB6AQB8AQA+AQAgAUAiAUAkAUAuAUAyAUA8AUA+AUAgAYAOpECCgIKABIDygEAOgIqAEICCgBKAnoAWgIKAGICEgBqAkoAggECEgCKAQIKAJIBAioAmgECCgC6AQIiANoBDAir+/GxBhCAp4SbA+IBAjIA6gECKgDyAQISAIICAiIAigICcgCaAgIiALgGAcAGAMgGANAGAfAGAJAHAZgHAcAHAMgHAdAHAeAHAegHAvAHAbAIAcAIAcgIAdAIANgIAegIAfAIAfgIAIAJ4OoEiAkAmAkBoAkBkgkTMjQ2LDM0LDI1NSwwLjcsMC4wNLAJAdAJA9gJAOAJAegJAfAJAPgJAIIKEUxSV1lIQ0ZTWE5DNTQ3OTQ3kAoBmAoBoAoB6AMAsAoBuAoBwAoByAoB0AoA4AoBQgBKY3oCCgCaAQIKALIBGLgGAMAGANUGAADwQt0GAABIQuUGAACqQoJ9DAir+/GxBhCAp4SbA6gGALAGALgGAMAGAMgGANAGANgGAOAGAOgGAPAGAIgHAZAHAKAHAKgHALAHAMAHAVo8CAUSGgEC5C9FaRm8DZxbAqo1kreSLczApsL8T6NaGhw2E4CvMRCompo3F3hZWNXjV612lenCXExsTqopWo4BCAgSbFeadnubD+5zwtyJHZgpxGXiz2mvJ7sl6JEVxji9JKKlDUTCv0+W9mHrI5HJH1H3E23oIwj2BbpZP9D4fdX/secTMIZGap2BF78Rdp4QMzEP++JDBESU71L0GMh50/WcRSxEfo66L556SqFC8BocBJAypCD4TqffMVpFeVhx0G7kvtBWYNZSbaLiG1pCCLgvEh9SXHa9ySnaKFGYLvnXn1bat7MXlyAbjqQwNTg6ecsdGhxxFAkN13tN5DRMlGn8nUVGtAXEAclWqWPhhfplYg5nb2luZ190b19zbGVlcKI4ngQSgAQJjnr8bQlx2T4JPulPrd1+vs7WK3R73+5n6d59T8qFtdzR46rqo4UY4SmRRU8FI1frRfrqOGXCrulF/1Az4VxS8I+xnxWnNgO3c4iMuowt3WNrpMoMKrEFy7FLcZtTE8J7qZBbbGAT9z4YrZuwZzHxjNF6hUQXYcnuLkzeENjdTdyIPHY5FShdwyQcG7E5g0uBI7NSgYy3FlZsYXjJdev9calvxZFxVZgH+SWgRLCFazNkWhvzDHg+9QtGtLKMk+XSVsKcuHQcJgewt3D5materMhHDQkofr5zq8e4vsFquKed8GzB2CKFbDthW/C2VlWnaz3CQl1FIkqbQDY1l+HvSa4nrQ8m2OXIcQICrrD4uNZdAwNDtdZ3pwk3JskQdWvo4J8JQXiKBhIAbDN2s0OrjxLXbNkQRPffmSb112VL1OII69udqPkzhPYeJuEKguMX46ILOwL5PZI2+i8iBrRq8Qr8HTawWYZ44iLp8pXkX8EN1IWTEQZ9uSZCqRp44RjUrO9j/7B/XJNickBAPiWOIPse3lIwaiH45j/3ZB/k0v97Z0jjJRA136kyxPvAcesu/DjcUewNW6bC/9NrUvHvGwZVubEyKXOiuBWEjhpyEvH3bgYMFO+4Fjf5oNvA055+WquCKQbxXsbV6mVR5G+FBGkro6Of5yrLvTrN0Ni/JRoLCLH8lLIGEMDU4kwiDAjQyI2tBhCAu8KVAqI4ngQSgAQ5mjsshBAUpHXc91MFp/qPki0hfOxC2t0uhqptUwZfzSLA4mWjO+kKjvaRwoDzZ4FU0rXD4e49+61bRithGmOsW3csnwTFlZrXKrM0suSnAcD5C0e1VlOlUoeGxQ+1Si7TSkrrJ5d1XSFan5aVDNN3bYWD69LYH3a07IKBThA1ZmDH+wQA6zW+g5YkyRN9mDshEBqb4ORK/Cu6SRz4oSne0mzj6MPF3ui/2CSthsEdyNLGYLF23axUsIcDinIgMQhQhgjxm3sSZUSopmXCJt0DR0m8dMYh7m3tvtgUFUqgGg7m+C/SyOeyuKWOIJ58KuW/entWSNfNVDmcSwSzE3nsW/Gapj8IGR7q0KrmLezdwTc6XaBtHWeFeQbnwxzSlwY66VREBJNAnAYUtkdygEwDTGpPU+VfLlnZZJIv+vkAUc6qFbbxBNyK38h7aQPyxBMzXxU3+/RTg+WXgtsER0+l/nVqvxjyrrynX/MLyg5BXqZNGJ46ost78msG426d/E3Qgd358W2M/NXcUGJ5ij8lsS0TMNM7EocJWQ/zCREA2Xy3bBxCFgjfg2tfBFiG+Vhu2fgw24gKbwZyJN19aYWEiNlmSUZorT0Sa2EBAc2Ql+LOaq5qwNJEA1GqKpo/XYlMFPW9a0I/TriZkVqR6u8VQM6YgQHEUIWq4WKo//9lThoLCLH8lLIGEMDU4kwiDAj/5futBhCAk6uyAbg+AQ==","granular_access":{"hide_private":false},"tokens":["a93e355b1a27cf80","ea98435367380ffe"],"state":"offline","in_service":false,"id_s":"<REDACTED>","calendar_enabled":true,"api_version":76,"backseat_token":null,"backseat_token_updated_at":null,"ble_autopair_enrolled":false,"command_signing":"required","release_notes_supported":true}],"count":1}
2024-05-09 17:41:43.405 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.282 seconds (success: True)
2024-05-09 17:41:43.405 DEBUG (MainThread) [teslajsonpy.controller] Get vehicles. Force: False Time: 0 Interval 60
2024-05-09 17:41:43.405 DEBUG (MainThread) [teslajsonpy.controller] 47947: Skipping update with state offline. Polling: True. Last update:<PHONE_NUMBER> ago. Last parked: 62 ago. Last wake up<PHONE_NUMBER> ago.
2024-05-09 17:41:43.405 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.108 seconds (success: True)
2024-05-09 17:41:45.830 DEBUG (MainThread) [teslajsonpy.controller] 47947: Sending wake request with deadline of:<PHONE_NUMBER>
2024-05-09 17:41:45.830 DEBUG (MainThread) [teslajsonpy.connection] Token expiration in 7:58:57
2024-05-09 17:41:45.830 DEBUG (MainThread) [teslajsonpy.connection] post: https://c0<REDACTED>-tesla-http-proxy/api/1/vehicles/<REDACTED_VIN>/wake_up {}
2024-05-09 17:41:46.039 DEBUG (MainThread) [teslajsonpy.connection] 429: Retry later

2024-05-09 17:41:46.039 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [140353510598976] Unexpected exception
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 239, in handle_call_service
    response = await hass.services.async_call(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2738, in async_call
    response_data = await coro
                    ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2779, in _execute_service
    return await target(service_call)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 975, in entity_service_call
    single_response = await _handle_entity_call(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1047, in _handle_entity_call
    result = await task
             ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/button/__init__.py", line 134, in _async_press_action
    await self.async_press()
  File "/config/custom_components/tesla_custom/button.py", line 68, in async_press
    await self._car.wake_up()
  File "/usr/local/lib/python3.12/site-packages/teslajsonpy/car.py", line 1130, in wake_up
    await self._controller.wake_up(car_id=self.id)
  File "/usr/local/lib/python3.12/site-packages/teslajsonpy/controller.py", line 475, in wake_up
    result = await self.api(
             ^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/teslajsonpy/controller.py", line 1375, in api
    return await self.__post_with_retries_except_unavailable(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/tenacity/_asyncio.py", line 88, in async_wrapped
    return await fn(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/tenacity/_asyncio.py", line 47, in __call__
    do = self.iter(retry_state=retry_state)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/tenacity/__init__.py", line 314, in iter
    return fut.result()
           ^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/concurrent/futures/_base.py", line 449, in result
    return self.__get_result()
           ^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/concurrent/futures/_base.py", line 401, in __get_result
    raise self._exception
  File "/usr/local/lib/python3.12/site-packages/tenacity/_asyncio.py", line 50, in __call__
    result = await fn(*args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/teslajsonpy/controller.py", line 1407, in __post_with_retries_except_unavailable
    return await self.__connection.post(command, method=method, data=data, url=url)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/teslajsonpy/connection.py", line 166, in post
    return await self.__open(url, method=method, headers=self.head, data=data)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/teslajsonpy/connection.py", line 218, in __open
    raise TeslaException(resp.status_code)
teslajsonpy.exceptions.TeslaException
2024-05-09 17:41:53.122 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2024-05-09 17:41:53.122 DEBUG (MainThread) [teslajsonpy.controller] Get vehicles. Force: False Time: 10 Interval 60
2024-05-09 17:41:53.122 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.000 seconds (success: True)
2024-05-09 17:41:53.297 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2024-05-09 17:41:53.297 DEBUG (MainThread) [teslajsonpy.controller] Get vehicles. Force: False Time: 10 Interval 60
2024-05-09 17:41:53.297 DEBUG (MainThread) [teslajsonpy.controller] 47947: Skipping update with state offline. Polling: True. Last update:<PHONE_NUMBER> ago. Last parked: 72 ago. Last wake up<PHONE_NUMBER> ago.
2024-05-09 17:41:53.297 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.000 seconds (success: True)
2024-05-09 17:42:03.121 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2024-05-09 17:42:03.122 DEBUG (MainThread) [teslajsonpy.controller] Get vehicles. Force: False Time: 20 Interval 60
2024-05-09 17:42:03.122 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.000 seconds (success: True)
2024-05-09 17:42:03.297 DEBUG (MainThread) [custom_components.tesla_custom] Running controller.update()
2024-05-09 17:42:03.298 DEBUG (MainThread) [teslajsonpy.controller] Get vehicles. Force: False Time: 20 Interval 60
2024-05-09 17:42:03.298 DEBUG (MainThread) [teslajsonpy.controller] 47947: Skipping update with state offline. Polling: True. Last update:<PHONE_NUMBER> ago. Last parked: 82 ago. Last wake up<PHONE_NUMBER> ago.
2024-05-09 17:42:03.298 DEBUG (MainThread) [custom_components.tesla_custom] Finished fetching tesla_custom data in 0.000 seconds (success: True)

Anything else?
I can see Running controller.update() in the logs every 10 seconds or so. Not sure if that has any implications. Polling is at the default 660 seconds.

I also received the same 429 error today. It looks like Tesla are starting to implement the rate limits which have been public for a while:
https://developer.tesla.com/docs/fleet-api#membership-tiers
According to the API response header Retry-After I have been rate limited for 24 hours :|

Yikes! 50 commands per day? There goes my automation for excess solar charging.

Short term, we need a PR to identify the time period specified in Retry-After and possibly delay polling until that point. We also would need to decide if we just queue the pending command, or just fail immediately with the error.
The issue is a user really needs to do something at this point if they are getting rate limited as it's unclear if Tesla will do anything negative, including ban users who continue to try to do things while rate limited.

Short term, we need a PR to identify the time period specified in Retry-After and possibly delay polling until that point.
Maybe I misunderstand you, but just wanted to add that when I got rate-limited yesterday polling still worked fine, all my sensors like battery updated correctly. I just couldn't send any commands.

From rileymd88's link above (https://developer.tesla.com/docs/fleet-api#membership-tiers) I would guess I hit the "Command limits" of 50 reqs/day.
Looking further down in the Tesla API documentation "Vehicle Commands" are all POSTs (https://developer.tesla.com/docs/fleet-api#vehicle-commands)
For "Device data limits" at 1 reqs/5min we should mostly be fine, as default polling interval is at 10 minutes if I'm not mistaken.
I do however agree with you on the solution to verify Retry-After and delay polling if this unlikely event should occur.
For Vehicle Commands however I'm not sure what to do. It's not really an option to delay the sending of the command for 24 hours.
Perhaps exposing a sensor, Rate Limited with the number of seconds (taken from Retry-After) to wait until a command can be issued again?
That way the sensor can be used in automations as some sort of failsafe.

Yikes! 50 commands per day? There goes my automation for excess solar charging.

Same for me, automation uses data and commands every minute. Now I have to adjust manually 😕

Yikes! 50 commands per day? There goes my automation for excess solar charging.

Same for me, automation uses data and commands every minute. Now I have to adjust manually 😕

You can use BLE for commands (that are not rate-limited), as you are connecting to the car directly.
I am running a modified version of the HTTP proxy, where I try to connect via BLE first, it is not perfect solution, I will need to improve it once I have time. sometime the BLE is stuck and even using the context cancelling in go, still won't prevent from deadlock from time to time. So If I detect the deadlock, I just restart the service..

So I'm trying to understand this bug. I can no longer send commands to my car, however I'm getting data back and just as frequently as few months prior through Teslamate. Wouldn't both be hiring the same issue?

So I'm trying to understand this bug. I can no longer send commands to my car, however I'm getting data back and just as frequently as few months prior through Teslamate. Wouldn't both be hitting the same issue?

This add on uses the new Fleet APIs which have the rate limits. Teslamate still uses the old deprecated Owners API which did not have any rate limiting in place.

Yikes! 50 commands per day? There goes my automation for excess solar charging.

Same for me, automation uses data and commands every minute. Now I have to adjust manually 😕

You can use BLE for commands (that are not rate-limited), as you are connecting to the car directly. I am running a modified version of the HTTP proxy,

Any links/doco on how this works and how to set this up?

How is Teslemetry getting around this?
I thought it used the fleet api as well. And I’m not talking about the few entity’s you can stream with Teslemetry.
After getting rate limited using this custom integration, I got my old Teslemetry hacs integration up and running again I can do a “Home Assistant core integration : update entity” service call every 15s which effectively does a force update on all Teslemetry entities and not get rate limited.

We contacted Tesla regarding this, and they confirmed that they started to roll out their documented rate limits. That being said, we believe their implementation is buggy. For instance, we get a 429 with a Retry-After: 86400 when calling the wake_up endpoint, which has a documented rate limit of 5 API requests / car / hour.
This value seems odd for two reasons:

This number shouldn't be static. When you try again in 5 minutes, it should show a value around 86100. Otherwise, you might get a Retry-After: 86400 while it might work 2 minutes later again.
The number 86400 (a full day) does not make sense for an endpoint with an hourly measurement window.

We told Tesla that we'd love to adhere to their limits (even tho some limits feel extremely small) but would need a bit more guidance. The whole wake_up thing also never made sense to us in the first place. It should just be possible to set a wake car if asleep flag on any important call instead of having to make a separate call first. Also, what if the vehicle doesn't have a signal for some time? One would waste their daily budget of 5 calls a day per car quite fast.
We hope they come around soon to help their consumers with better advice. ¯_(ツ)_/¯

I also seem to be having this problem, using llamafilm's Proxy, which I only started using a few days back. I am using this for solar charging and it normally works well until sometime in the afternoon and then stops.
I would be interested in zlymeda's comment about BLE. If this works to change charging amps then that is most of the commands I issue.

the go repo for running http proxy, as well as using BLE is here: https://github.com/teslamotors/vehicle-command
you should find all the necessary information there.
then I modified the method loadVehicleAndCommandFromRequest. first I try to use BLE connection.. if that fails I will fallback to HTTP:
// try to use BLE
conn, err := ble.NewConnection(ctx, vin)
if err == nil {
	car, err = vehicle.NewVehicle(conn, p.commandKey, p.sessions)
	if err == nil {
		return car, commandToExecuteFunc, nil
	}
}

// if above fails, use HTTP
car, err = acct.GetVehicle(ctx, vin, p.commandKey, p.sessions)

When blocked, I found that the mobile app still has access to the vehicle data. This also applies if my cell phone and my server have the same IP address. By using the app, I was even able to temporarily unblock my server. Does anyone have any idea whether the cell phone app isn't blocked and how?

Thanks zlymeda.
I have just started using llamafilm's version of the proxy as I got cut off a couple of weeks back, so I might let things mature for a while and hope Tesla comes out with information about the scheme, especially how they might charge for this. That would be simplest.
I suspect that many will have the same issues as I do, my Home Assistant server is behind CGNat and out of BLE range from the car.

I've started getting the Error 429 this afternoon. Looking in the logs I notice I have the following entries:
2024-05-22 23:19:12.982 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during poll. 429: TOO_MANY_REQUESTS
2024-05-22 23:19:22.986 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during poll. 429: TOO_MANY_REQUESTS
2024-05-22 23:19:32.974 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during poll. 429: TOO_MANY_REQUESTS
2024-05-22 23:19:43.041 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during poll. 429: TOO_MANY_REQUESTS
2024-05-22 23:19:52.973 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during poll. 429: TOO_MANY_REQUESTS
2024-05-22 23:20:02.974 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during poll. 429: TOO_MANY_REQUESTS
2024-05-22 23:20:12.993 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during poll. 429: TOO_MANY_REQUESTS
2024-05-22 23:20:22.975 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during poll. 429: TOO_MANY_REQUESTS
2024-05-22 23:20:32.982 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during poll. 429: TOO_MANY_REQUESTS

Note these seem to be going on continously, this is just a selection.
It seems like something is (re?)trying a poll every 10 seconds. Since the 429 started, and reading about the 50 a day limit, I've changed my polling interval from 660 seconds to 2000, which should total less than 50. I've no idea about the underlying process but could these be swamping the Tesla servers?
In fact, might this mean I will never recover (these are continuing to spew out as I write this)?

Yes, the old API used to let you access the list of vehicles and determine basic status before connecting to the vehicle without a rate limit. This was hitting Tesla's server and not your car.  We do it every 10 secs. Apparently that is rate limited now. Happy to take a PR but this now means we can't detect wakeups as quickly so there might have to be a complete rearchitecture.

Ah, thanks for the comment and link. So it looks if I set the car's Polling switch off the car isn't polled but are the Tesla servers always polled every 10s by the integration? If so I'll raise a PR.
Also, in my automations, I use the Charger switch to start and stop the car charging. Some questions about this:

if I disable polling, will the switch ever be turned on or off?
If not, could I force it by using either of the Force data update or Wake up buttons?
If so, which one would be best? If not, is there any other way of turning charging on and off?

For my case I don't need the car's information to be always up to date, only when I want to request it.

Same problem here, and same goal: usage of excess solar...
I really like the BLE option, whether you are in range, or could setup an ESP wifi to BLE relay or other contraption...
However @zlymeda I don't really get what you have done by modifying the method. I mean, is this Go library already used by this Tesla integration? If yes, that would be a simple option to be added, or even systematic...

+1

the original HTTP proxy only connects to cars via HTTP, not BLE.  however, the repo contains a cli for executing commands via HTTP or BLE. I had to modify the method (in the proxy) so that the BLE is tried first, if BLE fails => I use HTTP.
for my "solar excess" usage it is enough. but it is not great. the better solution would be to "know" if the car is home, and so BLE is reachable. I need to find more time to improve it. the problem, I mentioned before is that the BLE sometimes gets stuck and even context cancellation does not prevent it from blocking forever. so my workaround is: if this is detected kill the app. I run the app as a service, so killing it means restarting.
even the BLE connection is issued every time there is a request. this is a proxy for multiple cars (potentially). but I think, we could build a "single car" proxy, that could re-use the ble connection and probably other things as well.
I tried monitoring the car via BLE, but once it is monitoring it can't do other things, like issue command via BLE. the BLE seems not to be able to do more things at once. so I'll need some strategy to detect if the car is home (asking HA?, checking the GPS  via HTTP?, ...) and based on that use BLE or HTTP.
also there are issues in the official repo about reading information via BLE. right now, we can issue commands via BLE, but we don't know the state of the car and we need to use HTTP for that. if they add support for reading charge limit, charging state, ... via BLE, then we could build solar excess charging solely using BLE.

Thanks.
Looking at the code from the Tesla Custom Integration, I do not see any reference to the official vehicle-command library, as the API call URLs are hardcoded.
@zlymeda Did you manage your solar charge regulator with HomeAssistant and Tesla SDK? or any other wizardry? :)
I am no fluent in Go, but happy to learn and to help to upgrade with this BLE integration... For what I need:

I get current charging amps data --> which could still be HTTP or "saved" from previous successful sent command via BLE
Then calculate few variables and send new charging order --> can be done via BLE
This every 2 or 3 minutes, so I assume the BLE session could drop in between, so just create a new one

The ideal way of working (maybe) would be for this TeslaCustomIntegration to use directly (or fork and change) the vehicle-command SDK... Again, happy to help, but the starting point is not super clear for me.

I confess to not following the comments above about BLE - is it possible to do everything through BLE that you can do through http? Also, are you trying to detect if the car is at home? This is something I'm also trying to do as I want to open my electric gate when the car gets home and when someone gets in the car to drive away. I did this in my previous car with a very simple ESP32 board that I plugged into the car's USB port. HA would ping this every second and, if it got a reply, an automation would trigger to open the gate. However, I'm finding the USB ports in the Tesla can become active almost at random, especially if the car's plugged in, with my gate then opening unexpectedly! I'm trying to add a test for if a user is present but of course this will be affected by any throttling. However, detecting the car purely through BLE might be an option although I need to understand this better.
I also thought I'd update on how I'm getting on with polling etc. After a few trial and error attempts, I think (!) it's possible to control how data is collected from the car as follows:

Have the car's Polling flag normally off
To collect data, set it on, then activate the Force data update button and then reset the Polling flag to off

I have a Lovelace page where I display some key car data. On this page I now have a button that sets a toggle helper to true, which causes an automation to trigger (I actually use NodeRed) that does what's in the second bullet above and then clears the helper. This causes the data on my page to be refreshed. I can use similar logic to run other automations. I've since seen no throttling errors.

I wonder how much carbon this change created though lost solar charging efficiency.

I thought I'd mention that I think Tesla's rate limit is over all requests to a particular vehicle, not just from a particular registered virtual key. So if you have two different integrations both trying to query the car both will fail even if one isn't polling every 10s.
This is what's happening with Octopus my Energy provider. My tariff with them enables them to charge my car when they decide. They use the fleet api.
Since Tesla changed their rate limit logic my provider has been unable to charge my car.

@i-am-shodan thanks for sharing. That’s interesting. I would be surprised if that’s true; I assumed the limits would follow the developer account, not the car.
I’m glad to know that electric companies are using this feature too; I hope they will put some resources into fixing it sooner than later. But my guess is they will try to solve it at the EVSE, so it works for all makes of car.

We have a big problem :)
https://developer.tesla.com/docs/fleet-api?javascript#membership-levels

I'm very lost with all of this. So my integration was configured with what I'm guessing was the old API route, and had sensor date provided by Teslamate locally. A few weeks ago I noticed that through HA I could no longer interact with any of the controls through HA, however my local Teslamate is still grabbing telemetry being fed into HA.
It seems like most people can still grab telemetry via Teslamate's method of talking to Tesla via the v2 API, but some no longer can.
Digging around and trying to understand (please correct me if I'm wrong), there's a new v3 Fleet API that's more websockets based and requires the "app" to be registered with them to get access to the API. There's a Tesla HTTP Proxy as an HA addon/docker image which connects with Tesla and then the HA integration through authentication with Tesla gets what it needs to talk to the proxy. And then the spice should hypothetically flow.
For the HA integration is interacting with the v2 API done, or is there some use case where it should still work? Should I get on ith getting the HTTP proxy working locally?
What's keeping this project from just using the API endpoints that Teslamate is using? At least until Tesla makes it a little more clearer as to how their rate limiting actually works.
Sorry I've I'm being a bit clueless here, I'd just like to know if there are any paths forward for my setup.

I'm very lost with all of this.
I do think it is valuable to understand the situation as it seems to vary by location.
I was on the old HA Tesla integration and was also using TelsaMate (basically the same as rubin110). Then about 3 weeks ago I lost the ability to send commands through HA Tesla integration but Teslamate still worked. That is because they are different APIs.
I then applied for a developers license and got the new "Fleet API" working with HA thanks to llamafilm's proxy addon. That license suggests that I cannot continue to use the TeslaMate api, so I am trying to use the new Fleet Telemetry api. Unfortunately this is more complex in my case as I am behind CGNat.
The new Fleet API also comes with some quite severe restrictions on the number of commands per day (50 so far). That might be bypassed by using a bluetooth connection directly to the car but I haven't go that working as I can just get my charging done under the 50 commands most days. I hope that helps.

We have a big problem :)
https://developer.tesla.com/docs/fleet-api?javascript#membership-levels

I agree not ideal but for automations in HA I should be able to manage within these limits. For example, I'm very unlikely to want to issue more than, say, 4 at max charging commands a day. I'll have to ensure my automations are very "slow"!

I just inserted a feature reuest for adding call counters (sensors).....

That license suggests that I cannot continue to use the TeslaMate api, so I am trying to use the new Fleet Telemetry api.

@abreingan I think I'm reading that wrong. When applied for new keys with the Fleet API, did that kill Teslamate's ability to grab data?

That license suggests that I cannot continue to use the TeslaMate api, so I am trying to use the new Fleet Telemetry api.

@abreingan I think I'm reading that wrong. When you applied for new keys with the Fleet API, did that kill Teslamate's ability to grab data?

No I can still get data via TeslaMate but I am unsure if this will continue and there is a clause (below) that suggests fleet may be revoked if the old APIs are used.
Fleet API is Tesla's official 3rd party API and the only supported API for vehicle interactions. The list of available endpoints can be found at Endpoints and Regional Requirements. Starting April 2024, any vehicle APIs not part of this list will be phased out. Per the Fleet API policies, continued usage of unsupported APIs will result in the revocation of Fleet API access privileges.

After a few hours last of banging my head against something hard trying to troubleshoot local DNS, I have the Tesla HTTP Proxy Docker image running. I configured the custom integration to grab details from MQTT and to only poll once every 3600 seconds. 12 hours later I can still flip my sentry mode off and on from HA.

@rubin110 are you changing const.py? If so to what values?

I have not changed any code, at least nothing outside of configs like for docker compose. I only have a model 3, no solar/power wall. What I have going on:

Teslamate running locally publishing over MQTT
Tesla HTTP Proxy
HACS Tesla integration set to talk to the proxy, grab whatever data from MQTT, and polling interval set to 1 hour

As of right now (3 days later), I can still flip sentry on/off through HA and see that change reflected in the Tesla app.
Not sure how much this may matter, but for these three days my car has been sitting idle out next to the curb on the street, not on wifi, not charging, sentry mode on.

Hi all,
I spent quite some time fiddling around... Main target for me is excess solar charging regulation, for which I refresh the charging amps every 2 minutes. I was seeing generic "TeslaException", and well, I assumed I was rate limited, but in fact I was using the old API.
1st action is to setup FleetAPI. The "howto" in the Tesla HTTP Proxy Add-On is sufficient, but be very focused, especially if you are not a specialist.
Then re-create your Tesla in HA with FleetAPI. Please be aware that you need some sort of business credentials (probably not mandatory though).
--> It restored the possibility to send commands. However, I am now clearly rate limited mainly on commands
This way if you set limits (as above posts) on polling rate, you should be ok for now if you don't abuse.
2nd action / hack is to use the official Tesla Vehicle Command SDK, which contains cli tools to send commands via BLE to your Tesla. This package is already part of the proxy deployed in step one, but only for the HTTP proxy. @zlymeda managed to directly integrate BLE calls within the Tesla HTTP calls (in the proxy) as a hack, but not working for me...
To make it short: I installed tesla-control on a spare machine and used shell/ssh commands from HA to send commands via BLE to the Tesla.
Steps taken:

Install basic raspbian on an old RPi 3B laying around (but any linux / mac machine with BLE should work). ~30-60min
Clone and compile (with golang >1.21) the cli tools from the Tesla SDK. The one I am interested in is tesla-control ~10min
Follow this tutorial from Shankar Kumarasamy to:

Generate a new keypair to send ble commands to your Tesla (the tesla-keygen cli tool did not work for me) ~10min
Push the public key to your Tesla with tesla-control ~5min
Successfully send commands to your Tesla with BLE, then stop the tutorial there

Be happy
Generate SSH keypair to allow HA to connect to your spare machine on which you installed tesla-control ~5min
Create a shell script in HA with the command below, and make it executable ~5min
ssh -i /config/ssh/id_rsa -o StrictHostKeyChecking=no -q [login]@[ip of ble machine] /path/to/tesla-control/tesla-control -ble -vin [your VIN] -key-name /path/to/teslakeypair/private.pem -key-file /path/to/teslakeypair/private.pem $@
Create a "shell_command" as per guide ~5min
Then instead of calling the commands from the Tesla Custom Integration objects, you use the shell command created, with the arguments you need (see example below) depends on you
Be more happy
Finetune the delays as the BLE command may sometimes timeout or fail (busy device)
I also adapted my solar regulation to "assume" Tesla state based on sent commands, instead of polling data. Maybe useless, but not tested.

To make things sustainable for solar charge regulators, I would see:

Easy option: buy a wall charger with is controllable........ $$$
Create a custom integration to implement only the BLE tesla-control, and then remove the need for third party beacon. Something like "Tesla local commands" --> I will try...
Nicely integrate BLE commands in the existing integration. Maybe in teslajsonpy...

Thanks for the write up. I don't know why I thought that getting local BLE access was going to be as easy as tossing an ESP32 in the garage and then seeing some auto discovered Tesla BLE integration pop up in HA.
Anyhow I drove around a bit today and car is now in the garage plugged in. While out I was successful 3 times with my hack of yelling "turn on the car AC" at Google assistant and that flipping on the Tesla climate control in HA,. And my automation of turn off sentry mode if parked in the garage worked. Other than some stale telemetry with the integration (from the 1 hour poll time), everything looks correct. Teslamate is still kicking in and my app works.

Hi all,
I spent quite some time fiddling around...
Thank you raphmur for some very productive fiddling. A few questions if I may.
You say - Generate a new keypair to send ble commands to your Tesla.
I assume this is a new key rather than the one generated by the Tesla HTTP Proxy Add-On. Did you have to create another app in the Tesla Developers site?
I was afraid this might disable the proxy and have been trying, without success, to get the private key out of the proxy addon container. Not helped by the fact that its my first time playing with large slabs of this technology.
I also want to try and get the Fleet Telemetry working and it seems over the top to have three different keys. It does seem as if one key would work for all.

As for a long term solution, I am happy with the separate pi solution as my HA instance is out of BLE range from the car. Obviously good to have it all integrated and as much visible from HA as possible. Would the BLE proxy work for this?

Indeed, I did not mention. I tried also to recover the keypair from the proxy, but no success.
So I created a new (local) keypair using openssl as per the tutorial here (the one from Shankar K). It has no link with your Tesla Dav account, it is recognized by the car as a BLE key, and that's it. More or less the same way of working (I assume) as with pairing your phone as a key.
For BLE proxy, I did not read through enough.

Thank you - I will go fiddle with that.

Indeed, I did not mention. I tried also to recover the keypair from the proxy, but no success. So I created a new (local) keypair using openssl as per the tutorial here (the one from Shankar K). It has no link with your Tesla Dav account, it is recognized by the car as a BLE key, and that's it. More or less the same way of working (I assume) as with pairing your phone as a key.
/!\ Please be aware that getting your Pi stolen or hacked will compromize your car (but you can delete the key from the car).
For BLE proxy, I did not read through enough.

Thanks a lot for your work. It's most welcome and useful for charging our cars with excess solar power.

Hi all,
I spent quite some time fiddling around... Main target for me is excess solar charging regulation, for which I refresh the charging amps every 2 minutes. I was seeing generic "TeslaException", and well, I assumed I was rate limited, but in fact I was using the old API.
1st action is to setup FleetAPI. The "howto" in the Tesla HTTP Proxy Add-On is sufficient, but be very focused, especially if you are not a specialist. Then re-create your Tesla in HA with FleetAPI. Please be aware that you need some sort of business credentials (probably not mandatory though). --> It restored the possibility to send commands. However, I am now clearly rate limited mainly on commands This way if you set limits (as above posts) on polling rate, you should be ok for now if you don't abuse.
2nd action / hack is to use the official Tesla Vehicle Command SDK, which contains cli tools to send commands via BLE to your Tesla. This package is already part of the proxy deployed in step one, but only for the HTTP proxy. @zlymeda managed to directly integrate BLE calls within the Tesla HTTP calls (in the proxy) as a hack, but not working for me... To make it short: I installed tesla-control on a spare machine and used shell/ssh commands from HA to send commands via BLE to the Tesla. Steps taken:

Install basic raspbian on an old RPi 3B laying around (but any linux / mac machine with BLE should work). ~30-60min
Clone and compile (with golang >1.21) the cli tools from the Tesla SDK. The one I am interested in is tesla-control ~10min
Follow this tutorial from Shankar Kumarasamy to:

Generate a new keypair to send ble commands to your Tesla (the tesla-keygen cli tool did not work for me) ~10min
Push the public key to your Tesla with tesla-control ~5min
Successfully send commands to your Tesla with BLE, then stop the tutorial there

Be happy
Generate SSH keypair to allow HA to connect to your spare machine on which you installed tesla-control ~5min
Create a shell script in HA with the command below, and make it executable ~5min
ssh -i /config/ssh/id_rsa -o StrictHostKeyChecking=no -q [login]@[ip of ble machine] /path/to/tesla-control/tesla-control -ble -vin [your VIN] -key-name /path/to/teslakeypair/private.pem -key-file /path/to/teslakeypair/private.pem $@
Create a "shell_command" as per guide ~5min
Then instead of calling the commands from the Tesla Custom Integration objects, you use the shell command created, with the arguments you need (see example below) depends on you
Be more happy
Finetune the delays as the BLE command may sometimes timeout or fail (busy device)
I also adapted my solar regulation to "assume" Tesla state based on sent commands, instead of polling data. Maybe useless, but not tested.

To make things sustainable for solar charge regulators, I would see:

Easy option: buy a wall charger with is controllable........ $$$
Create a custom integration to implement only the BLE tesla-control, and then remove the need for third party beacon. Something like "Tesla local commands" --> I will try...
Nicely integrate BLE commands in the existing integration. Maybe in teslajsonpy...

Hi ,
Thanks for your incredible job.
Do you think that this can run in the same raspberry where I’m running by-Matt-gateway to scan continuosl ble trackers ?
Thanks

Hi all,
I spent quite some time fiddling around... Main target for me is excess solar charging regulation, for which I refresh the charging amps every 2 minutes. I was seeing generic "TeslaException", and well, I assumed I was rate limited, but in fact I was using the old API.
1st action is to setup FleetAPI. The "howto" in the Tesla HTTP Proxy Add-On is sufficient, but be very focused, especially if you are not a specialist. Then re-create your Tesla in HA with FleetAPI. Please be aware that you need some sort of business credentials (probably not mandatory though). --> It restored the possibility to send commands. However, I am now clearly rate limited mainly on commands This way if you set limits (as above posts) on polling rate, you should be ok for now if you don't abuse.
2nd action / hack is to use the official Tesla Vehicle Command SDK, which contains cli tools to send commands via BLE to your Tesla. This package is already part of the proxy deployed in step one, but only for the HTTP proxy. @zlymeda managed to directly integrate BLE calls within the Tesla HTTP calls (in the proxy) as a hack, but not working for me... To make it short: I installed tesla-control on a spare machine and used shell/ssh commands from HA to send commands via BLE to the Tesla. Steps taken:

Install basic raspbian on an old RPi 3B laying around (but any linux / mac machine with BLE should work). ~30-60min
Clone and compile (with golang >1.21) the cli tools from the Tesla SDK. The one I am interested in is tesla-control ~10min
Follow this tutorial from Shankar Kumarasamy to:

Generate a new keypair to send ble commands to your Tesla (the tesla-keygen cli tool did not work for me) ~10min
Push the public key to your Tesla with tesla-control ~5min
Successfully send commands to your Tesla with BLE, then stop the tutorial there

Be happy
Generate SSH keypair to allow HA to connect to your spare machine on which you installed tesla-control ~5min
Create a shell script in HA with the command below, and make it executable ~5min
ssh -i /config/ssh/id_rsa -o StrictHostKeyChecking=no -q [login]@[ip of ble machine] /path/to/tesla-control/tesla-control -ble -vin [your VIN] -key-name /path/to/teslakeypair/private.pem -key-file /path/to/teslakeypair/private.pem $@
Create a "shell_command" as per guide ~5min
Then instead of calling the commands from the Tesla Custom Integration objects, you use the shell command created, with the arguments you need (see example below) depends on you
Be more happy
Finetune the delays as the BLE command may sometimes timeout or fail (busy device)
I also adapted my solar regulation to "assume" Tesla state based on sent commands, instead of polling data. Maybe useless, but not tested.

To make things sustainable for solar charge regulators, I would see:

Easy option: buy a wall charger with is controllable........ $$$
Create a custom integration to implement only the BLE tesla-control, and then remove the need for third party beacon. Something like "Tesla local commands" --> I will try...
Nicely integrate BLE commands in the existing integration. Maybe in teslajsonpy...

Hi,
thank you for the little guide.
I was able to deploy and use the raspberry toghether with home assistant to control my car via BLE.
The only problem is that, when i send commands to the car, i receive very ofter the error:
Error: ble: failed to enumerate device services: ATT request failed: input channel closed: io: read/write on closed pipe
Did you know how to solve this?
Due to this issue i had to create a script that check if the command is successful or not, and in this case it retry it for 5 time, maybe this can be useful for someone:
script:   tesla_ble_charger_setpoint:     mode: restart     sequence:       - repeat:           sequence:             - if: "{{ repeat['first'] == false}}"               then:                 - delay:                     seconds: 10             - service: shell_command.tesla_ble_set_charging_amps               data:                 vin: "{{vin}}"                 command: charging-set-amps                 number: "{{amps}}"               response_variable: response           until:             - or:                 - condition: template                   value_template: "{{ response['returncode'] == 0 }}"                 - condition: template                   value_template: "{{ repeat['index'] >= 5 }}"

Hi all,
I was searching the github issues list to find some info as yesterday my v2 API access seized to work. I did install the HTTP proxy and followed all the gory details to make FleetAPI working. So now FleetAPI works.
However, BLE seemed from the beginning a better solution for charging from solar excess. I will write here what I've done so far.

BLE commands worked from day 1 of Tesla publishing the FleetAPI in 2023. I initially installed the software on a rpi3 and it worked fine although there was a bit slow like 1-2 seconds from the command until the car reacts to it.
From a previous project where I tested the relay attack for the BLE connection between the phone and the car (which worked really well) I understood something important. Specifically that on rpi3 the BLE works very poorly when WiFi is used. That is because BLE and WiFi share the same 2.4Ghz band and the wifi signal drowns the BLE receiver. So, going further, I tried a rpi5 that has the 5Ghz wifi band. This allowed a huge improvement for the BLE connection between the rpi5 and the car. Improvement is both in longer distance and stability of connection.
I'm not a big fan of golang but I did some research on how to convert the code to a pure C, C++ so I can run the BLE code on an ESP32. There are some code converters but even with just a single file from the golang library it failed. So this is still some work in progress as ESP32 should be quite nice to have in this project.
detecting if the car is home I've done with an ESP32 by receiving the iBeacons sent by the car. There are 4x BLE transceivers (center, rear, left, right). They are used by the car to detect where the phone is physically located by comparing the RSSI received from each of the transceivers. The transceivers emit iBeacons at a high rate so multiplied by 4x it gives a very fast presence detection and this is why I use it for turning the lights on when I reach at my home's gate. The 4x transceivers are also used for detecting the location of each of the wheels so that's why there is no need to pair each of the wheels to the car.
the BLE FleetAPI from Tesla does not provide status from the car if one wants to get e.g. SoC or batt charge limit or other data. We can send only commands and the only feedback is a sort to communication error in case something is not working so it is like shooting in the dark. We asked Tesla on github to improve the API with status commands but so far there is nothing changed in the API.

BTW, just as info, this is one example of the BLE measurements (of the phone signal) done by the car and sent to the phone during the authentication phase when the user tries to open the driver's door but it is too far so the car will not unlock:
alert {
alertHandlePulledWithoutAuth {
timeSinceAlertSet_ms: 858
connectionCount: 1
deviceSpecificPayload {
keyChannel: 3
RSSILeft: -78
RSSIRight: -92
RSSIRear: 127
RSSICenter: -88
}
}
}
All in all, I think the BLE will be good for communication with the car for charging and not only because there will be no rate limiting and no need for internet access.
Hope this helps.

Super
Thanks @BogdanDIA for clarification! For BLE performance, I assume using a ethernet RPi3 and leaving the full antenna for BLE should improve...? Or using an external bluetooth dongle maybe....
@andreaconfa, I like your tweak, though it just becomes specific for one command (set charge amps), which should not be a big issue as this is one of the main goals...
I did not see this exact error but some similar on busy channel or pipe.... I just retried the command and it worked. What I have found relevant:

don't spam commands too often: leave at lease 15sec between calls
when it fails: retry and usually it works. I use this in a loop anyways so it is not a major concern if 1 loop fails.
I though of implementing this failsafe version but your code is useful now! Be careful, I have found that the "wake" command, with "-domain vcsec wake" is not usually successful even if no error is thrown.

I really used this "BLE trial & error spamming technique" as a last option :) So it could probably be done smartly with and integration, failsafe solutions, ... Oh well

Thanks @BogdanDIA for clarification! For BLE performance, I assume using a ethernet RPi3 and leaving the full antenna for BLE should improve...? Or using an external bluetooth dongle maybe....

@raphmur  yes, the ethernet shoud work while having wifi disabled.

Your post is super interesting, thanks a lot.

I tried a rpi5 that has the 5Ghz wifi band. This allowed a huge improvement for the BLE connection between the rpi5 and the car. Improvement is both in longer distance and stability of connection.

From what I've read, there is some kind of unicorn out there in the form of ESP32-C5 which is able to connect to 5Ghz wifi networks. However I don't think it's available yet.
Based on your experience, without interference from Wi-Fi and Bluetooth (using either an RPi 5 or an Ethernet connection), what is the maximum distance at which we can place the device from the car? I am trying to decide whether I should run an Ethernet cable to my garage and use an old RPi 3, or buy a new RPi 5 (which costs at least $60 where I live) and utilize the 5 GHz Wi-Fi.

detecting if the car is home I've done with an ESP32 by receiving the iBeacons sent by the car.

Can you expand on that :

Are you using esphome with BLE beacons ?
How reliable is this ? For now I'm using a proximity sensor in HA with a few device trackers, it works most of the time but I'm wondering if it could be improved.

ESP32 should be quite nice to have in this project.

I'm pretty confident in telling you I'm not the only one that'd be very interested in such a solution. In this case however, could we have issues between Wi-Fi and Bluetooth ?

Your post is super interesting, thanks a lot.

I tried a rpi5 that has the 5Ghz wifi band. This allowed a huge improvement for the BLE connection between the rpi5 and the car. Improvement is both in longer distance and stability of connection.

From what I've read, there is some kind of unicorn out there in the form of ESP32-C5 which is able to connect to 5Ghz wifi networks. However I don't think it's available yet.
Based on your experience, without interference from Wi-Fi and Bluetooth (using either an RPi 5 or an Ethernet connection), what is the maximum distance at which we can place the device from the car? I am trying to decide whether I should run an Ethernet cable to my garage and use an old RPi 3, or buy a new RPi 5 (which costs at least $60 where I live) and utilize the 5 GHz Wi-Fi.

detecting if the car is home I've done with an ESP32 by receiving the iBeacons sent by the car.

Can you expand on that :
* Are you using [esphome with BLE beacons](https://esphome.io/components/text_sensor/ble_scanner.html) ?

* How reliable is this ? For now I'm using a [proximity](https://www.home-assistant.io/integrations/proximity/) sensor in HA with a few device trackers, it works _most_ of the time but I'm wondering if it could be improved.

ESP32 should be quite nice to have in this project.

I'm pretty confident in telling you I'm not the only one that'd be very interested in such a solution. In this case however, could we have issues between Wi-Fi and Bluetooth ?

I've checked the ESP32 C5 few months ago but as you said it was not ready. The major work would be porting the golang to the ESP. Encrypting the FW in ESP should give a good level of protection for the car's keys.
I think you need to experiment with the maximum distance you can obtain as it depends on many variables like LOS(line of sight) or not, number of other networks in the area, existing walls, etc. A for myself, I started with having a laptop at 5 meters from the car and making the BLE FleetAPI working on it I switched to rpi3 by placing it in the same spot as the laptop. It did not work as there were a lot of comm errors  so that is why I switched to rpi5 on 5Ghz band. Did not check max distance, though.
For car presence I started with the iBeacon HA integration which was awfully slow especially when departing from home so I decided to use ESPHome with my own implementation. Instead of using the RSSI in calculating the distance, I used the count of the iBeacon messages received from the car. This works very well in this case where the car sends tens of messages per second. When there is no message received for e.g. 3 seconds it is clear the car is not close. This worked flawlessly for more than 6 mo now.
One thing to note is that during car's software update there is a period of 15-20 seconds when iBeacons are not sent and this needs to be taken in consideration e.g in HA automation that will not trigger the action while updating the car.
But there are other ways to change the charging parameters for the experimenters, one of them being with CAN commands. Been fiddling with CAN for sometime with an rpi/ESP32 and a OBD2 dongle, no keys needed, just 8byte messages. I don't recommend it though as I've seen Tesla changing some of the CAN commands format from time to time during the years. And also that some people say that Tesla logs strange CAN messages that do not come from MCU but from other busses of the car. On the flip side, the S3EXY buttons from enhance do the same thing by sending CAN messages instead of MCU or other devices on the buses.

I'd check out https://github.com/pmdroid/tesla-ble and see if the API is the same.

Hi,
This is awesome.
Unfortunately I already see an issue for my use-case.
I have two car (and this mean two different vins).
Maybe you can make the VIN number as a setting in home assistant instead of passing it directly to the docker container….
Do you think is possible ?
Thanks
Inviato da iPhone
Il giorno 10 giu 2024, alle ore 16:14, Iain Bullock @.***> ha scritto:

Thanks for everyone's contribution to this.
I have created a docker container which will send commands via MQTT to a car using BLE. It is useful to run on a remote device e.g. Raspberry Pi located close to where the car is parked. MQTT will auto-populate the various entities in Home Assistant, such that Buttons can be pressed (and Services called from Automations) to send commands. There is a Number entity to set the charging current. It's a first release so will need further work no doubt
https://github.com/iainbullock/tesla_ble_mqtt_docker
—
Reply to this email directly, view it on GitHubhttps://github.com/alandtse/tesla/issues/961#issuecomment-2158489968, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKUNNLKY6G2SJMB7LJUXC2LZGWYDFAVCNFSM6AAAAABHOLPIF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJYGQ4DSOJWHA.
You are receiving this because you were mentioned.Message ID: @.***>

Thanks @iainbullock! Looking great.
You mention in your docs that the wake command does not work. I managed to get it to work with the -domain vcsec parameter. I will try to contribute directly then.
Are you familiar with HA integrations? It seems that with this, we are not too far from deriving your project to make the integration work locally on the HA host 😀. It should be feasible, but so far I do not know how to access the BLE device in HAOS...
Anyways, this thread is getting very long and it seems that most of us have a workaround with FleetAPI (with increased polling intervals) + BLE for frequent commands when close to the car.
I suggest to close this issue as solved, marking Ian's repo as solution... @alandtse? At least until a more packaged solution raises with the full bundle HA extension: Fleet API + local BLE (on HA host) + remote BLE (on ESP or RPi), including some proximity/location sensors...
Maybe switch this discussion to Discord or anything less verbose on the Internet? I just initialized this channel

I'd check out https://github.com/pmdroid/tesla-ble and see if the API is the same.

Seems to be the old one that has been reverse engineered form the Android phone.
But I think the old one and the new one are still coexisting in the latest version of the car's SW.

I'd check out https://github.com/pmdroid/tesla-ble and see if the API is the same.

Thanks for the suggestion. I'm going to be away for two weeks soon, so might not get chance until i get back. It will be interesting to see what develops in the meantime

Hi, This is awesome. Unfortunately I already see an issue for my use-case. I have two car (and this mean two different vins). Maybe you can make the VIN number as a setting in home assistant instead of passing it directly to the docker container…. Do you think is possible ? Thanks

Definately possible, I thought about it but decided to get this simple version released to see what comments / contributions it gets

I can try to contribute to this but I’m not sure what is the best way to do it.
Using the vin as parameter in home assistant (sent via Mqtt) means that people with only one car need to also use it when not needed.
Maybe a combination of fixed vin in docker (as a default one) and mqtt paremeter to override the default vin can be the way to do it.

Hi, This is awesome. Unfortunately I already see an issue for my use-case. I have two car (and this mean two different vins). Maybe you can make the VIN number as a setting in home assistant instead of passing it directly to the docker container…. Do you think is possible ? Thanks

Definately possible, I thought about it but decided to get this simple version released to see what comments / contributions it gets

I can try to contribute to this but I’m not sure what is the best way to do it.
Using the vin as parameter in home assistant (sent via Mqtt) means that people with only one car need to also use it when not needed.
Maybe a combination of fixed vin in docker (as a default one) and mqtt paremeter to override the default vin can be the way to do it.

I think you opened an issue on my project page. Please can you repeat the question there and we can discuss it there thanks
https://github.com/iainbullock/tesla_ble_mqtt_docker/issues/1

edited

It's been over a week with connecting to my model 3 through the http proxy, setting HA to only poll once an hour, getting most of the my data through Teslamate/MQTT, I haven't had any issues with occasionally interact with the vehicle.
I'm interesting in messing with the BT proxy, but I think that's a winter time project.

Do you speak German?
I have just discovered this project: https://evcc.io/en/
... with this issue: Tesla fleet API error 429 Too Many Requests
and this package to implement a BLE proxy.
Anyone has got elements of context?
As for now @iainbullock has bundled a set of commands in a self running docker image, that connects to MQTT: https://github.com/iainbullock/tesla_ble_mqtt_docker
And I bundled it in an Add on (still very early beta): https://github.com/raphmur/tesla-local-control-addon
We will probably work around these two to increase the stability and usability over BLE.

I made https://github.com/yoziru/esphome-tesla-ble to get around this. Set up on an ESP32 and it shows up as an ESPHome device. Bonus: it works locally and offline

What is the suggestion to not get rate limited then? Changing the polling interval from 660s/30s to something else? :)

I only poll on demand now. For example, when I want to see my car's current stats, I use a binary helper that triggers a NodeRed routine that enables polling, updates data and then disables polling (and resets the binary helper).

I trigger an update through an automation (in my case in NodeRed). Another example is I have free electricity from Octopus Energy so I have an automation that starts charging when the free power starts and stops when it ends.


fix: get rid of prop-types error

Removes the missing key error

Coverage remained the same at 87.276% when pulling 3d2d456c9fd0dc5b11537163620080a0e7c72bfe on lbirch/table-header-fix into b2cfe53ae1a904190c52bfa143c719b332746166 on master.

:tada: This PR is included in version 13.3.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


real-world example of use needed.

Stock price, weather, something to do with TODO-lists?

@paul-hammant I do agree that the README should be updated to reflect real-world use cases. However, SimpleNet is simply a client/server framework that allows users to send data back and forth using TCP. For stock prices and weather, I'd imagine that would involve HTTP GET requests, which is something that SimpleNet doesn't currently offer (I'd normally delegate that to Java's HttpClient).
A simple, real-world use case for SimpleNet could be a chat server, network backend for a multiplayer game, etc.
Personally, I think a chat server would suffice. What do you think?

Yes, chat server.  Then go on to talk about the nature of the wire messages. Example of client and example of server - both standalone main() method demos.

I implemented a basic chat server in README which I'll probably move to their own example files. I think I should also take advantage of the GitHub Wiki for something like this.

Nice work. You'd get lots of press if you were to have a branch that demonstrated Loom/Fibers ahead of the release. Maybe even conference speaking opportunites for the experience report.


update aerospike image

Codecov Report

Merging #166 into develop will increase coverage by 2.88%.
The diff coverage is 100%.

@@              Coverage Diff              @@
##             develop     #166      +/-   ##
=============================================
+ Coverage      81.34%   84.22%   +2.88%
- Complexity       281      378      +97
=============================================
  Files             76      103      +27
  Lines            938     1249     +311
  Branches          12       13       +1
=============================================
+ Hits             763     1052     +289
- Misses           170      190      +20
- Partials           5        7       +2

Impacted Files
Coverage Δ
Complexity Δ

...m/playtika/test/aerospike/AerospikeProperties.java
57.14% <100%> (ø)
1 <0> (ø)
:arrow_down:

.../playtika/test/minio/DefaultMinioWaitStrategy.java
100% <0%> (ø)
1% <0%> (?)

...h/EmbeddedElasticSearchBootstrapConfiguration.java
100% <0%> (ø)
4% <0%> (?)

...t/pubsub/EmbeddedPubsubBootstrapConfiguration.java
100% <0%> (ø)
6% <0%> (?)

...playtika/test/pubsub/PubSubResourcesGenerator.java
78.57% <0%> (ø)
9% <0%> (?)

...b/EmbeddedPubsubDependenciesAutoConfiguration.java
100% <0%> (ø)
2% <0%> (?)

.../EmbeddedMinioTestOperationsAutoConfiguration.java
100% <0%> (ø)
4% <0%> (?)

...om/playtika/test/rabbitmq/RabbitMQStatusCheck.java
66.66% <0%> (ø)
2% <0%> (?)

...est/minio/EmbeddedMinioBootstrapConfiguration.java
100% <0%> (ø)
7% <0%> (?)

...t/voltdb/EmbeddedVoltDBBootstrapConfiguration.java
100% <0%> (ø)
5% <0%> (?)

... and 18 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 79f89a7...1a52982. Read the comment docs.


[SPARK-44868][SQL][FOLLOWUP] Invoke the to_varchar function in Scala API

What changes were proposed in this pull request?
In the PR, I propose to invoke the to_varchar function instead of to_char in to_varchar of Scala/Java API.
Why are the changes needed?

To show correct function name in error messages and in explain.
To be consistent to other API: PySpark and the previous Spark SQL version 3.5.0.

Does this PR introduce any user-facing change?
Yes.
How was this patch tested?
By running the modified test:
$ build/sbt "test:testOnly *.StringFunctionsSuite"

Was this patch authored or co-authored using generative AI tooling?
No.

Merging to master. Thank you, @dongjoon-hyun @peter-toth @cloud-fan for review.


REST API

This issue will be used to track the status of the REST API.

[ ] GET /gateway

Below are end points that still need to be fully wrapped:

[ ] POST/channels/{channel.id}/messages (needs embed/file implementation)

[ ] PATCH/guilds/{guild.id}/members/@me/nick

[ ] GET/guilds/{guild.id}/prune

[ ] POST/guilds/{guild.id}/prune

[ ] GET/guilds/{guild.id}/regions

[ ] PATCH/users/@me

once https://github.com/FiniteReality/disccord/pull/27 is merged this issue can be closed

As of 659f676, all REST endpoints have been wrapped. If Discord makes changes to their REST api in the future, please create new issues for each affected endpoint.


Default doc links to Spark 3/Scala 2.12

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/3119/
Test PASSed.


charger_phases incorrectly showing 2 phases on 3-phase charger

It should be 3 phases.
Running v3.9.1
Not sure what other info to attach.

We're reporting what Tesla is reporting. You can try looking at teslajsonpy logs to see what data is there. If it's wrong, you need to talk to Tesla.

Ok, thanks. I turned on debug logging in HA but it doesn't print enough info to show what's going on.
Teslamate is showing the correct number of phases:

This is what Tesla are reporting from upstream.
Here is my work around.
    ev_phases:
      friendly_name: "EV Charger Phases (adjusted)"
      value_template: "{{ max(1,(state_attr('sensor.duka_charger_power','charger_phases')|int(0)*3/2)|int(0))}}"

FWIW: metering consumption in IT net - barely used in Europe but quite common in Norway - is done by the Aron-circuit and this measures only 2 phases which is sufficient for a precise consumption metering. If you live in Norway this might be the reason but I do not know why Teslamate shows something else.


Toolbar improvements

This PR gets rid of cart dropdown and fixes appearance of errors.

Current coverage is 48.19%

Merging #413 into master will increase coverage by +0.05% as of 4a04168

@@            master    #413   diff @@
======================================
  Files           84      84
  Stmts         3404    3401     -3
  Branches       322     321     -1
  Methods          0       0
======================================
  Hit           1639    1639
  Partial         29      29
+ Missed        1736    1733     -3

Review entire Coverage Diff as of 4a04168

Powered by Codecov. Updated on successful CI builds.


am i missing something? (missing text and player controls)

Describe the bug
For basically all themes I try, the side text is missing for the most part, and the player controls aren't there.
To Reproduce
Steps to reproduce the behavior:

Use Pop-Dark
See no player controls or text

Expected behavior
Things to be there? lmao
Screenshots
https://i.imgur.com/ARDYvib.png
Logs
Add logs from console. To do that

Run spicetify enable-devtools in terminal
Spotify will be restarted
Hit Ctrl + Shift + I to open DevTools window
Navigate to tab Console
Copy console window content.

webnowplaying.js:106 WebSocket connection to 'ws://<IP_ADDRESS>:8974/' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
init @ webnowplaying.js:106
DevTools failed to load SourceMap: Could not load content for https://zlink.app.spotify.com/zlink.bundle.js.map: Connection error: net::ERR_NAME_NOT_RESOLVED
DevTools failed to load SourceMap: Could not load content for https://playlist.app.spotify.com/playlist.bundle.js.map: Connection error: net::ERR_NAME_NOT_RESOLVED
DevTools failed to load SourceMap: Could not load content for https://buddy-list.app.spotify.com/buddy-list.bundle.js.map: Connection error: net::ERR_NAME_NOT_RESOLVED
DevTools failed to load SourceMap: Could not load content for https://zlink.app.spotify.com/css/zlink.css.map: Connection error: net::ERR_NAME_NOT_RESOLVED
DevTools failed to load SourceMap: Could not load content for https://buddy-list.app.spotify.com/css/buddy-list.css.map: Connection error: net::ERR_NAME_NOT_RESOLVED
DevTools failed to load SourceMap: Could not load content for https://playlist.app.spotify.com/css/playlist.css.map: Connection error: net::ERR_NAME_NOT_RESOLVED
4webnowplaying.js:106 WebSocket connection to 'ws://<IP_ADDRESS>:8974/' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED

Specifics (please complete the following information):

OS: Windows
Spotify version Can't find it, but its latest version
Spicetify version 1.1.0
Theme name Pop-Dark

spicetify config extensions dribbblish.js-
spicetify apply

spicetify config extensions dribbblish.js-
spicetify apply

@khanhas Pop-Dark isn't part of dribbblish? I do have the extension installed tho and it doesn't help

@khanhas Pop-Dark isn't part of dribbblish? I do have the extension installed tho and it doesn't help

You should UNINSTALL the dribbblish extension when not using Dribbblish theme, that's what khanhas's commands do

You should UNINSTALL the dribbblish extension when not using Dribbblish theme, that's what khanhas's commands do

I understand that now. The pop-dark still isnt working properly tho.

I understand that now. The pop-dark still isnt working properly tho.

Dribbblish themes also don't work properly even with the extension still

Dribbblish themes also don't work properly even with the extension still

the common issue between the two seem to be missing icons, does this mean something?

the common issue between the two seem to be missing icons, does this mean something?

Please uninstall your Spotify and reinstall with latest installler from website. Then run spicetify backup apply

Please uninstall your Spotify and reinstall with latest installler from website. Then run spicetify backup apply

alright, that seemed to work. thank you!

alright, that seemed to work. thank you!


⚠ ClamAV has degraded performance

In 9fb41fc, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 78 ms

Resolved: ClamAV performance has improved in bdccb88.


Removes product update

Missed this in #31.

Talked with Stephen (Eval's PM, who was in at the time) and he's going to do this in a few weeks time, so lets keep it in for now


Option to read the output state of the IO expander at boot

When rebooting, the state of the outputs are lost. An option to read the output state of the IO expander during init would prevent weird behaviours when for certain reason the main controller reboots.

If I get your issue right, I changed the begin functions so that all IOs will be configured as inputs and all output and input registers get cleared. Mode register will be configured as default if not changed in optional function argument. If I missunderstood something please tell me.


iced_wgpu: query wayland

I am quite tired of weird workarounds in libcosmic regarding chassis-detection, power_pref and accidentally inheriting environment variables, cosmic-workspaces accidentally turning on the dgpu by using anti-aliasing... the list goes on.
Lets patch iced_wgpu instead and query the compositor for the device to use.
(untested, because I don't have the full libcosmic dev setup with me during the hackfest, please somebody test this with applets and apps before merging.)

FYI: This breaks the build on macos as smithay-client-toolkit doesn't compile.


aarch64 fixed

@volovyk-s should we merge this?

@ailisp not 59, #159
We need to improve our CI release jobs.


Replace generic exits with specific enumerated exit codes

Replaced by https://github.com/felt/tippecanoe/pull/9


Added alerting, ISM, and security analytics front and backend plugins to 2.5 manifests.

Signed-off-by: AWSHurneyt<EMAIL_ADDRESS>Description
Added alerting, ISM, and security analytics front and backend plugins to 2.5 manifests.
Issues Resolved
https://github.com/opensearch-project/alerting/issues/732
https://github.com/opensearch-project/alerting-dashboards-plugin/issues/434
https://github.com/opensearch-project/index-management/issues/641
https://github.com/opensearch-project/index-management-dashboards-plugin/issues/536
https://github.com/opensearch-project/security-analytics-dashboards-plugin/issues/283
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #3077 (907eca8) into main (11b5990) will decrease coverage by 0.30%.
The diff coverage is n/a.

:exclamation: Current head 907eca8 differs from pull request most recent head 661d8da. Consider uploading reports for the commit 661d8da to get more accurate results

@@            Coverage Diff             @@
##             main    #3077      +/-   ##
==========================================
- Coverage   93.17%   92.87%   -0.31%
==========================================
  Files         167      167
  Lines        4602     4602
==========================================
- Hits         4288     4274      -14
- Misses        314      328      +14

Impacted Files
Coverage Δ

src/system/temporary_directory.py
64.44% <0.00%> (-28.89%)
:arrow_down:

src/system/os.py
94.73% <0.00%> (-5.27%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Added new comparison topic

Added some additional detail around end-to-end typesafety.
@nikolasburk can you pls also take a look?

made a suggestion but overall looks good to me!
to be fair, I generally am not super sure about the difference between "gives you the impression of type safety" and "full type safety".

made a suggestion but overall looks good to me!
to be fair, I generally am not super sure about the difference between "gives you the impression of type safety" and "full type safety".

Since that's a quote from a 3rd party, we can't/shouldn't change it.
I think it looks good now with your suggestion.


Standardize UG

Fixes #31

Codecov Report

Merging #32 (9f2ad69) into master (a8c68a8) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #32   +/-   ##
=========================================
  Coverage     72.15%   72.15%
  Complexity      399      399
=========================================
  Files            70       70
  Lines          1232     1232
  Branches        125      125
=========================================
  Hits            889      889
  Misses          311      311
  Partials         32       32

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a8c68a8...9f2ad69. Read the comment docs.


Further Resolver enhancement

This one is #645 evolution based (mostly) on @JeneaVranceanu comments.
Closes #640

Speaking about .withMargin is one that @mloit brings in here, and actually I have no idea about it's propose, so we're just passing it around for a month, like it's something very important. I'd vote to reduce whole that resolver enum to 2-3 values e.g.

automatic
manual

Even limited is a question to me, is it worth it.
At the beginning of work on this bit (resolver) I’ve wonder should I just strip them down to only two values, and made it one universal type for every gas price property. I even tried that, but failed — it did comes because of my lack of deeply understanding what way you should handle transaction to make it work.
So I’m myself a both hands on to make this one as simple and as universal as possible. Is there any proposal how made it in appropriate way, folks?

Also @JeneaVranceanu I've didn't get your point about Oracle initializations. Could you please elaborate it.

Hah, @JeneaVranceanu, making that function to throw an error broke a couple of tests. Seems that those were fake one till now.

Also @JeneaVranceanu I've didn't get your point about Oracle initializations. Could you please elaborate it.

@yaroslavyaroslav I meant that the inialization of Oracle(provider) should happen in the switch-case where it's used.
It's a minor improvement but why not since there's only one case in these resolve... functions that use an oracle.
Codewise I suggest to change this:
public func resolveGasBaseFee(for policy: FeePerGasPolicy) async -> BigUInt {
    let oracle = Oracle(provider)
    switch policy {
    case .automatic:
        return await oracle.baseFeePercentiles().max() ?? 0
    case .manual(let value):
        return value
    }
}

to this:
public func resolveGasBaseFee(for policy: FeePerGasPolicy) async -> BigUInt {
    switch policy {
    case .automatic:
        return await Oracle(provider).baseFeePercentiles().max() ?? 0
    case .manual(let value):
        return value
    }
}

I meant that the inialization of Oracle(provider) should happen in the switch-case where it's used.

Though I haven't any objections to this, but why?

 Should we leave them or should we strip them out to something more universal?

I meant that the inialization of Oracle(provider) should happen in the switch-case where it's used.

Though I haven't any objections to this, but why?

The memory is allocated and not used in the second case of the switch statement. Even though it's not really noticeable, I'd prefer allocating memory only when it's needed.

 Should we leave them or should we strip them out to something more universal?

Regarding the enum cases I thought about having an enum like this one:
/// Policies for resolving values like:
/// - nonce
/// - gas required for transaction execution
/// - gas price
/// - maximum fee per gas
/// - maximum priority fee per gas
public enum ValueResolutionPolicy {
    /// What ever value will be resolved is the one to be applied
    case automatic
    /// Specific value to be applied
    case manual(BigUInt)
    /// The resolved value is evaluated against given limit. The lower one is used.
    /// Note: has the same effect as `manual` for resolution prices and fees.
    case limited(BigUInt)
}

But while writing the documentation for case limited realised that I'm not sure if this case will ever be really used.
So the final suggestion from is would be this:
/// Policies for resolving values like:
/// - nonce
/// - gas required for transaction execution
/// - gas price
/// - maximum fee per gas
/// - maximum priority fee per gas
public enum ValueResolutionPolicy {
    /// What ever value will be resolved is the one to be applied
    case automatic
    /// Specific value to be applied
    case manual(BigUInt)
}

I'd thought the same way back there. So I'll implement it shortly to let merge this one and to release 3.1 to close up this issue with broken changes asap.

/// - nonce
@JeneaVranceanu Are you sure about nonce? Now it's just a type alias for BlockNumber which is perfectly fits there.

@JeneaVranceanu I've pushed fixes just yet, take a look

So it's up to you @JeneaVranceanu, and please merge it whenever you'll approve it.

/// - nonce

@JeneaVranceanu Are you sure about nonce? Now it's just a type alias for BlockNumber which is perfectly fits there.

Correct, it's unrelated. Thanks!

@yaroslavyaroslav I've added a minor convenience documentation update so it's easy for readers to find the source explaining what max fee per gas and max priority fee per gas is.
Besides that, all seems good. Waiting for CI to complete the tests and will approve the PR.

While I'm totally ok with that, I just wonder how you did that?) like how you updated my pr?

@janndriessen now it's your turn to reapprove review, I've made it that way that it declined every time push to the branch have been made.

While I'm totally ok with that, I just wonder how you did that?) like how you updated my pr?

@yaroslavyaroslav @janndriessen There is an option to edit a file right here on GitHub. And it looks like I've rights to do so in other people's PRs now.

Also a few nice shortcuts when you are located at "home" page of this repository:

press button T to start searching by filename
press button . to start online IDE


Bounty Account Refill Request - 19/09/2021 - FrontEnd

1000 TNBC for https://github.com/thenewboston-developers/Website/issues/2045
To 38a99b8f1916eab0471ca1df26e7fe5e71d845e6ea5b233cd3d93a75097ea2d6

Should it be 1002?

@tspearing No, we are paying directly to the contributors. So 1000 is correct.


Bug/devtooling 606 - Managed sites data source

Due to https://inindca.atlassian.net/browse/DEVTOOLING-606, this PR:

Removes managed attribute from sites data source
Automatically sets managed sites to data on export
Searches both managed and unmanaged sites on getSiteByName function call
Due to import cycles, the genesyscloud_resource_exporter will read the DataSourceManagedSites on export to determine which resources should be exported as data

New PR created due to issues