esphome / esphome/feature-requests
substitution support for arrays and other data types
- Dominant language
- No language data
- Stars
- 450
- Forks
- 29
- PR merge metrics
- No merged PRs in 30d
Description
**Describe the problem you have/What new integration you would like**
Currently substitutions appear to be limited to strings. It would be very helpful if they could be any data type, particularly arrays.
**Please describe your use case for this integration and alternatives you've tried:**
I have multiple ESPHome nodes that send raw IR codes. It would be nice if I could define the IR codes in a package as a yaml variable or substitution.
**Additional context**
I don't want to have the entire service call in the package as each node will implement the service slightly differently. But they will all need the same raw codes.
With the help of some friendly users on Discord, we found a hack around this. It's possible to define the array as a string in a package as a substitution, and then in the service use a lambda to return the substitution as a C++ vector. This works, but native substitution support for arrays would be preferred.
Current hacky solution
```yaml
substitutions:
vizio_power_raw: '9103, -4475, 621, -515, '
switch:
- platform: template
name: Power
turn_on_action:
- remote_transmitter.transmit_raw:
carrier_frequency: 38kHz
code: !lambda 'return {${vizio_power_raw}};'
```
Ideal solution: (currently does not compile)
```yaml
substitutions:
vizio_power_raw: [9103, -4475, 621, -515, ]
switch:
- platform: template
name: Power
turn_on_action:
- remote_transmitter.transmit_raw:
carrier_frequency: 38kHz
code: ${vizio_power_raw}
```
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading how substitutions are parsed and expanded, then trace the remote_transmitter.transmit_raw configuration path shown in the examples. The issue provides no files or tests, so the first task is locating those entry points. Done means package substitutions can carry arrays and other data types while the existing string use cases continue to work.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- yaml
- Domain
- embedded-iot
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100