It would be really cool if the template entity had an attribute named provenance with the path and line number where it is defined.
Really cool.
I get literally none of that when the config is passed to me from core. I can only do so much with what Iâm given. I get a large dictionary of a fully combined configuration for all integrations after packages and includes are fully processed. I.e. just data, no sources.
3 Likes
I am having trouble with the following template. It used to work by splitting the attribute for BOM weather at a 230 character limit. I then recombine the states as shown below. This is to overcome the 255 character limit for sensors.
Now it is only outputting Conditions are none of the rest of the state (weather report attribute) is shown if it exceeds 255 characters.
# Template Weather Report Text - BOM Current Conditions - TTS Input (split over 2 sensors)
- default_entity_id: sensor.weather_report_conditions
name: "Weather Report Conditions"
unique_id: ed7a9c4f-ae78-495d-bc42-b6e23f7c6f1e
state: >-
{{ 'Conditions are' -}}
{%- set details = state_attr('sensor.devonport_extended_text_0', 'state') %}
{{ details[:230] if details | length < 230 else '' -}}
- default_entity_id: sensor.weather_report_conditions_2
name: "Weather Report Conditions_2"
unique_id: b38fdba1-19d1-4193-a590-aa85ea9694cf
state: >-
{%- set details = state_attr('sensor.devonport_extended_text_0', 'state') %}
{{ details[230:] if details | length < 230 else '' }}
This is the current state of the two sensors that should contain the information of the attribute below
This is the attribute that is meant to be split into the two sensors.
Where I recombine the state of the sensors to form a full weather report in NodeRed
Where I recombine the sensors to create a weather report using mushroom template card.
type: custom:mushroom-legacy-template-card
primary: >-
{{ states('sensor.devonport_short_text_0') | upper }} | {{
states('sensor.weather_report_warnings') }}
secondary: >-
{{ states('sensor.weather_report_temperature') }} {{
states('sensor.weather_report_conditions') }} {{
states('sensor.weather_report_conditions_2') }} {{
states('sensor.weather_report_rain') }} {{
states('sensor.weather_report_fire_uv') }}
icon: null
entity: button.weather_report
multiline_secondary: true
multiline_primary: true
tap_action:
action: toggle
fill_container: true
icon_color: ''
card_mod:
style: |
{% from 'macros.jinja' import warning_bg %}
ha-card {
--card-primary-font-size: 20px !important;
--card-secondary-font-color: white !important;
--card-primary-line-height: 1.2;
--card-secondary-font-size: 20px !important;
--card-secondary-line-height: 1.2;
background: {{ warning_bg() }};
}
I cannot say for sure thatâs your issue, but using state_attr to get the state seems odd (even if it worked before for you). Perhaps try using the states function in your templates like you do in your card config.
Itâs not odd, itâs just not correct in most situations. There is no way to get the state using state_attr. state_attr only gets attributes. However, his entity has a state attribute.
Meaning, his if statement is likely working properly.
{{ details[:230] if details | length < 230 else '' -}}
If the length is over 230 characters, the result will return nothing. Thatâs exactly whatâs happening here.
He doesnât need to have that if statement, he can just output {{ details[:230] }} and it will always output 230 characters or less.
The : in splicing means âEverythingâ. when you use [:230] this says "output everything before the 230th item. If you donât have 230 items, then you will simply just get a list of all the items that you do have. With strings, items are characters.
If you use [230:] this means output everything after the 230th item. If you donât have 230 items, you will get an emtpy list. In the case of a string, you will get an empty string.
Classical shadowing of names. This is what caught me here and thanks for pointing that out. If it was the regular state, I just meant Iâve never seen it done this way, because, like you say, itâs only for attributes.
As for the rest, I know all that: I just didnât consider any of that, since I got stuck on the state thing. He says it was working before, so I donât know what the issue is then, because itâs working as programmed. 
I donât believe there is an issue, just a template that happened to produce unexpected results after moving to the new style configuration. Under the hood, the behavior of template entities is identical with legacy configuration in comparison to new configuration. So any behavior change people report is always a âfalse correlationâ.
To put this into perspective, template entities will never change the behavior of anything inside the template (jinja). Everything inside templates are controlled by jinja. Template entities just use the results jinja creates and they do not alter jinja behavior.
3 Likes
Managed to fix the solar edge template which was having the error. Took me a while to get things lined up since I had not realised that the hyphen at the beginning does not count. Its the text lining up that matters.
However although I have no errors, I do have other templates bits in the file that are not causing issues. So I have left them alone.
average_soc:
friendly_name: "Average soc"
value_template: "{{ ((( states('sensor.GIVTCP_CE2232G255_soc') | float) + (states('sensor.GIVTCP2_CE2232G271_soc') | float)) / 2) | round(1)}}"
unit_of_measurement: '%'
saving_session_required_soc:
etc
Is this OK or do I need to change those even if they are not causing an error?
All legacy Template entities need to be converted to the current configuration syntax. Petro has provided a custom integration tool, linked in the top post, that will find them and perform the conversion, requiring only a few small, manual, config edits.
Iâve been confronted with 119 deprecation warnings, all switch and sensor templates. HA offers a solution for each, but how can I address these efficiently? Do I have to go through all of these and make the suggested changes, or is there a simpler way to it in batch? Also, if HA recognizes something is broken and knows what the fix is, why doesnât offer to fix it itself?
Read the first post of this thread the moderator just moved your post toâŚ