To use the changes from this PR as an external component, add the following to your ESPHome configuration YAML file:

external_components:
  - source: github://pr#14180
    components: [dsmr]
    refresh: 1h

(Added by the PR bot)

👋 Hi there! This PR modifies 1 file(s) with codeowners.

@glmnet, @PolarGoose, @zuidwijk - As codeowner(s) of the affected files, your review would be appreciated! 🙏

Note: Automatic review request may have failed, but you're still welcome to review.

Memory Impact Analysis

Components: dsmr
Platform: esp8266-ard

Note: This analysis measures static RAM and Flash usage only (compile-time allocation).
Dynamic memory (heap) cannot be measured automatically.
⚠️ You must test this PR on a real device to measure free heap and ensure no runtime memory issues.

This analysis runs automatically when components change. Memory usage is measured from a representative test configuration.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.09%. Comparing base (6ecb01d) to head (cd0c4a6).
⚠️ Report is 8 commits behind head on dev.

@@            Coverage Diff             @@
##              dev   #14180      +/-   ##
==========================================
- Coverage   74.11%   74.09%   -0.03%     
==========================================
  Files          55       55              
  Lines       11591    11591              
  Branches     1578     1578              
==========================================
- Hits         8591     8588       -3     
- Misses       2598     2600       +2     
- Partials      402      403       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I already asked this question in the previous pull request when the void set_decryption_key(const char *decryption_key) was introduced, sorry for asking it again, but given the circumstances maybe it worth to look at it again:

Are you sure you don't want to use std::string_view? Then the existing client's lambdas will still compile, and you get your performance benefits.

Thanks for the suggestion! We intentionally avoid std::string_view in this codebase; it pulls in a significant amount of STL template machinery that bloats flash on these resource-constrained embedded targets. Where we need a view type, we use our own lightweight StringRef instead. const char * is the right fit here since all callers pass either string literals (from codegen) or null-terminated strings from std::string::c_str(). Additionally, set_decryption_key() isn't documented at esphome.io and isn't public API per our policy; this deprecated overload is a courtesy to ease the transition, not a commitment to support the std::string signature long-term.

That said, as a codeowner of this component, if you'd like to keep the std::string overload permanently and document set_decryption_key() as a supported API in a follow-up PR, that's fine too. We don't disallow allocating patterns when users explicitly opt into them; we just don't want to force them into that pattern by default. However, it's better to document and push users toward the non-allocating pattern. This particular case isn't one where it makes a big difference, but the effect is cumulative and that's how we end up with heap fragmentation and crashing devices.

We intentionally avoid std::string_view in this codebase; it pulls in a significant amount of STL template machinery

Ok. Agreed.
Also, I agree with your other points.
I'm fine with deprecating the std::string overload. The less code, the better.

thanks