Add the possibility to transform strings for LCD displays

[numo68]

Description:

The LCD displays are produced with several ROM variants defining different character sets. On the other hand the native character encoding of the yaml configuration and most of code editors is UTF-8. An it.printf("Temp %4.1f °C", id(temp).state); lambda cannot be used as is.

The transform lambda allows the user to define a transformation function run immediately before the string is output to the LCD.

Pull request in esphome with YAML changes (if applicable): esphome/esphome#3563

Checklist:

• [X] Branch: next is for changes and new documentation that will go public with the next ESPHome release. Fixes, changes and adjustments for the current release should be created against current.
• [ ] Link added in /index.rst when creating new documents for new components or cookbook.

[netlify[bot]]

✅ Deploy Preview for esphome ready!

Name	Link
🔨 Latest commit	592f863ed6a4f0e4cc08409362b9f5191817c725
🔍 Latest deploy log	https://app.netlify.com/sites/esphome/deploys/62a98ad22d737700097f7baa
😎 Deploy Preview	https://deploy-preview-2134--esphome.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[glmnet]

You should add the transform to the formal parameter list. And add a link to the explanation.

Also, did you try that the code (with the sample) fixes the original issue? I mean, since the issue is specifically with the character given in the issue: https://github.com/esphome/feature-requests/issues/1766#issuecomment-1154191530 providing an example for those will be good (I had issues as some of those characters are multi byte so could not be stored in char or something like that and had to use a string), may be you can have @nagyrobi test it for you.

[numo68]

You should add the transform to the formal parameter list. And add a link to the explanation.

Done, also added one for user_characters that was missed as well.

Also, did you try that the code (with the sample) fixes the original issue? I mean, since the issue is specifically with the character given in the issue: esphome/feature-requests#1766 (comment) providing an example for those will be good (I had issues as some of those characters are multi byte so could not be stored in char or something like that and had to use a string), may be you can have @nagyrobi test it for you.

Here I would like to ask @nagyrobi to test as he has a real project for this. The code I have tested and is provided in the documentation example at https://deploy-preview-2134--esphome.netlify.app/components/display/lcd_display#display-transformation-lambda is however IMO close enough to what was done in that comment. The degree character used is a multi-byte one (\xc2\xb0) so that part is tested.

Thanks

[numo68]

@glmnet Well.. there is an effect identified by @nagyrobi's testing limiting the usability for the intended purpose somehow and that is that one cannot easily calculate the actual length of the string anymore, meaning any naive attempt to computationally right-align things fails if there is a multi-byte character involved. I added a note of this to the documentation.

I still find this PR usable, YMMV.

[github-actions[bot]]

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions.