Release 2026.1.0 withdrawn, new version 2026.1.A #219
Replies: 14 comments 34 replies
-
|
thanks Pedro, I'm happy to help test, although I've not seen the crash during charging. FWIW in my years experience coding in C++ for microcontrollers, the most common cause of crashes is manipulating character strings and arrays so it sounds like you're on the right track. Can you pls confirm the syntax to include the correct packages? substitutions:
...
tesla_ble_component: "github://PedroKTFC/esphome-tesla-ble@main"
BLE_library: "https://github.com/PedroKTFC/tesla-ble.git#main" # ????
packages:
remote_package_files:
url: https://github.com/PedroKTFC/esphome-tesla-ble/
path: packages
files: [base.yml, common.yml, project.yml, client.yml]
ref: main # ??? |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
I've created a new project branch This substitution: This packages settings (this is a simplified version of the original packages multi line files specification you might have, just replace that): Please let me know how it works for you. Many thanks for testing. |
Beta Was this translation helpful? Give feedback.
-
|
You seem to have dropped esphome-tesla-ble/packages/common.yml Line 15 in d2c9696 |
Beta Was this translation helpful? Give feedback.
-
|
HI Pedro, thank you so much for your work. I try to built a littel display base on guition . i try your repair branch , and this is the output 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Charging works ok with no crashes, and all charging related data is being displayed ok. Uptime 53 mins and counting 🎉 |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
I m really not sure the problem is on your code pedro, so until other tester repport the same behavior dont spend time on this .... my project is totally"under developemment.... and i did lot of change to fight for stabilization. probably my best version was this one : https://github.com/capof1000/guition-tesla-ble/blob/newteslalib/guition7.yaml.
As fact today i notice that the esp is stable when the car dont charge, but as soon as it is charging.... it keep crashing regulary.
|
Beta Was this translation helpful? Give feedback.
-
|
Actually, the hardware I use (Guition ESP32-S3-4848S040) is equipped with 8MB of Octal PSRAM, so I’m not limited to the internal 512KB SRAM. However, you are right about the RAM pressure. Even with PSRAM, ESPHome and BLE stacks are very demanding. To handle this, I have already implemented several optimizations in my configuration: External Memory Allocation: I've enabled CONFIG_BT_NIMBLE_MEM_ALLOC_MODE_EXTERNAL to force the Bluetooth stack to use the PSRAM. Stack Size Tuning: I've try to increased the Arduino loop and Bluetooth task stack sizes to prevent overflows. LVGL Buffering: I'm using a small 5-10% display buffer to keep some internal SRAM free for critical real-time tasks. |
Beta Was this translation helpful? Give feedback.
-
|
guys is this crashing problem as simple as you must have an ESP32-S3 with a minimum amount of PSRAM? Atom S3 lite has no PSRAM. My board never crashes and has 8MB PSRAM (QSPI). Uptime is over 25 hrs for me now! |
Beta Was this translation helpful? Give feedback.
-
|
It might be. I have a draft change that fixes the buffer overflow by expanding the protobuf buffer by only 7 bytes. I hope that the almost trivial extra use will not cause any crashes but we'll have to see. |
Beta Was this translation helpful? Give feedback.
-
|
An interesting fix in the new beta: esphome/esphome#12696 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
I've now updated main to 2026.1.B so closing this discusssion. |
Beta Was this translation helpful? Give feedback.









Uh oh!
There was an error while loading. Please reload this page.
-
I've reset the default base to the last known working version. This means the buffer overflow issue some people were seeing will be there. I intend to update over the next few days in the following order:
The .A (.B, .C etc) numbering scheme reflects the fact these versions will be catch ups to 2026.1.0.
I will only make a new release when I've had confirmation from more than one user that the last release is working as expected. That includes this release. Although it is set to the last working release, it's always possible my GitHub skills mean I have not quite got it right.
Thanks for bearing with me.
Beta Was this translation helpful? Give feedback.
All reactions