fix: ESPBTUUID::to_str() requires a buffer argument, not zero - #315
Merged
Conversation
The previous to_string() -> to_str() migration compiled fine in our own tests because none of them declared a logger: component, which silently strips ESP_LOGCONFIG/ESP_LOGW down to no-ops and skips type-checking their arguments entirely. Real device configs run with logger: level: DEBUG or higher, where ESPHome 2026.7.4 fails to build: error: no matching function for call to 'ESPBTUUID::to_str()' candidate: 'const char *to_str(std::span<char, 37> output) const' Fix both call sites to pass a stack buffer instead of chaining .c_str() on a call that no longer returns std::string. Also fixes a second, pre-existing bug in divoom_display.cpp that the same missing-logger gap was hiding: address_str() already returns const char*, so .c_str() on it doesn't compile either. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
1 task
eigger
added a commit
that referenced
this pull request
Aug 18, 2026
) None of the component test configs declared a logger: component, which makes ESPHome silently compile ESP_LOGCONFIG/ESP_LOGW down to no-ops and skip type-checking their arguments entirely (see #315, where this exact gap let a broken ESPBTUUID::to_str() call through CI). Add logger: level: VERY_VERBOSE to every component's test config (via the shared common.yaml where one exists) so dump_config() and warning-log code paths actually get compiled and type-checked. Recompiled every component's esp32-idf/esp32-ard test config with this change and fixed the one warning it caught: a %u format specifier vs. uint32_t argument mismatch in divoom_display.cpp's dump_config(), the same class of bug already fixed in ble_elm327. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
esphome compileon a real device config (logger: level: DEBUG) fails witherror: no matching function for call to 'ESPBTUUID::to_str()'—to_str()takes astd::span<char, 37>output buffer, it doesn't returnstd::string.to_string()→to_str()migration, which passed our own component tests only because none of them declare alogger:component — ESPHome silently stripsESP_LOGCONFIG/ESP_LOGWto no-ops in that case and never type-checks their arguments. Root-caused via the user's actual build log.divoom_display.cppthe same gap was masking:address_str()already returnsconst char*, so chaining.c_str()on it doesn't compile either.Test plan
esphome compileforble_elm327anddivoom(esp32-idf) withlogger: level: DEBUG/VERY_VERBOSEexplicitly added — zero errors, zero warnings in our code.logger:to every component's test config so this class of bug can't hide again) is a separate PR, since it's orthogonal to this fix.🤖 Generated with Claude Code