The reduction from 768 to 512 was overly aggressive - the stack
overflow was caused by the 1400+ byte multipart parser, not the
serialization buffer. 640 bytes covers climate DETAIL_ALL payloads
(~520 bytes) on the stack without heap fallback.
Payloads exceeding 1024 bytes are not known to exist in real
configurations. One doubling iteration covers all known entity types.
Cap at 4096 as a safety limit.
Avoids instantiating DummyWriter templates (~736 bytes flash) by
doubling the heap buffer until the payload fits. The temporary
over-allocation (at most 2x) is acceptable since payloads exceeding
the 512-byte stack buffer are rare.
ArduinoJson's serializeJson() with a bounded buffer returns the actual
bytes written (truncated count), NOT the would-be size like snprintf().
When the payload exceeded the 512-byte stack buffer, the return value
was used as the exact size for heap reallocation, but this was only the
truncated count. The heap buffer was allocated too small, the second
serialization was also truncated, and no NUL terminator was written.
This caused corrupted JSON in SSE streams for entities with payloads
exceeding 512 bytes (e.g., climate DETAIL_ALL with many features).
Fix: use measureJson() in the heap fallback path to get the exact
untruncated size before allocating. Also add the missing set_size_()
call after the second serialization to ensure proper NUL termination.
768 bytes on the httpd task stack contributes to stack overflow when
combined with other stack-allocated buffers (query string parsing, etc.).
512 bytes still covers all typical JSON payloads (sensors ~200B, lights
~170B, climate ~500-700B). Only extreme edge cases with 40+ options
trigger heap fallback.
## Description:
Move esphome-core codebase into esphome (and a bunch of other refactors). See https://github.com/esphome/feature-requests/issues/97
Yes this is a shit ton of work and no there's no way to automate it :( But it will be worth it 👍
Progress:
- Core support (file copy etc): 80%
- Base Abstractions (light, switch): ~50%
- Integrations: ~10%
- Working? Yes, (but only with ported components).
Other refactors:
- Moves all codegen related stuff into a single class: `esphome.codegen` (imported as `cg`)
- Rework coroutine syntax
- Move from `component/platform.py` to `domain/component.py` structure as with HA
- Move all defaults out of C++ and into config validation.
- Remove `make_...` helpers from Application class. Reason: Merge conflicts with every single new integration.
- Pointer Variables are stored globally instead of locally in setup(). Reason: stack size limit.
Future work:
- Rework const.py - Move all `CONF_...` into a conf class (usage `conf.UPDATE_INTERVAL` vs `CONF_UPDATE_INTERVAL`). Reason: Less convoluted import block
- Enable loading from `custom_components` folder.
**Related issue (if applicable):** https://github.com/esphome/feature-requests/issues/97
**Pull request in [esphome-docs](https://github.com/esphome/esphome-docs) with documentation (if applicable):** esphome/esphome-docs#<esphome-docs PR number goes here>
## Checklist:
- [ ] The code change is tested and works locally.
- [ ] Tests have been added to verify that the new code works (under `tests/` folder).
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated in [esphomedocs](https://github.com/OttoWinter/esphomedocs).
