the template is so short… I system searched for ‘label-multiple’ and only have that mentioned as a fixed icon on a template sensor… In the core.entity_registry, I can find is as ‘original_icon’, but that’s not a template either
is this a bug in the profiler, or do those icons also count as templates, simply because they are configured in a template sensor?
- unique_id: switches_total_device_power
name: Switches total device power
state: >
{{(expand('group.switches_total_device_power')
|rejectattr('state','in',['unknown','unavailable'])
|map(attribute='state')
|map('float')|sum)|round(2,none)}}
unit_of_measurement: W
icon: mdi:label-multiple
device_class: power
state_class: measurement
These get treated differently and the render path short circuits when is_static=True so they take multiple orders of magnitude less processing time. You can effectively ignore anything with is_static=True for the purposes of trying to optimize for performance.
@parautenbach:
Have a few TTS automations which are sending the same message (few sentences with some inline jinja code).
Moved the message to a file /config/custom_templates/tts_message_weather_forecast.jinja and
tried to replace the automation message with {% include 'tts_message_weather_forecast.jinja' %} but receiving an error “Template not found”.
Is it possible to use the new templating feature for definition of dynamic strings for messages?
Even if they are the same every one of them will be rendered every time since they don’t know about each other. So if you have 1000 templates doing the exact same thing you still have to pay for 1000 renders whenever something changes in the template.
Unfortunately you’re being given misinformation, in 99% of cases this is actually false. Even more so with this situation as Home Assistant is Proxying the Polymer calls to give the warning. Considering they’re hooking in Polymer, they can actually get more information on the calling card etc. Why they chose to omit this is at their discretion (granted it is more lines of code and work).
If you want a hint on the culprit card, you can open the dev console in your browser and turn on warning logs. Next you can view the stack trace which will list the calls and files leading to the message. The file should help determine which card or module is still using Polymer.
This could be shown in the Home Assistant logs if they chose to include the stack track in the write_log event but again, that’s up to the Home Assistant dev’s.
I’m not being given miss information. I’m a developer in my day job. I’m sorry I upset you the other day, that doesn’t mean you need to try to prove me wrong at every post I make. Posting stack traces in the logs would mislead everyone because it’s not an exception. And traversing stack traces to make guesses on what element is loading it would be a massive amount of work that could potentially point to the wrong thing.
Since the 2023.4 upgrade (and 2023.4.1), the iOS app appears to have lost some functionality and reliability.
First I noticed the missing gesture pulling out the menu on the left, but this was quickly fixed with an iOS app update.
Now it appears I’ve lost the ability to tap on the top of the screen to have it scroll all the way up to the top of the page (general function across iOS that works in all other apps).
And also, I’m now frequently opening the app to find various icons in my main glance cards blank. The data appears to be accurate, but some of the icons are missing. The workaround is I have to pull down so the app refreshes. This happens after I’ve navigated to other apps for a bit and come back to the HA app.
Is anyone else seeing these issues with the iOS app and the latest HA build?
Yh for some reason when I initially started my reply then went to reply to yours but realised I was still replying to someone else it changed the target
I’ve been using MariaDB without a problem but then was getting the warnings about my MariaDB version from Home Assistant (using Synology)… I then explored other options and decided to give InfluxDB a go, initially I thought it was highly redundant but alas I started to see the benefits.
First benefit is that the DB and entries won’t change, it also doesn’t hold unwanted “junk” like events and so forth which keeps the DB size optimised. You’re also less likely to run the risk of corruption and won’t face issues on migration updates etc.
Secondly, you will have the full history of your sensors and so forth and can manage what to keep and what to remove after a certain period.
From there on, I’ve set MariaDB to purge every 30 days to keep it optimised.
The real issue is that the data isn’t directly accessible from Home Assistant and their cards or history components etc. But I’ve overcome this by using iframes and Grafana.
I can reply to myself here. For some reason or the other, this helped: go to each Grafana chart and for each query turn visual editor mode on, save query. Rinse and repeat.
Pretty painless update for me. Thanks to all custom card developers that have updated their cards. And some help here on the forum to update my SQL sensor.
DB migration took very little time (1.6GB repacked to 1.1GB).
This is new and appears after a start up:
Logger: homeassistant.components.utility_meter.sensor
Source: components/utility_meter/sensor.py:438
Integration: Utility Meter (documentation, issues)
First occurred: 15:06:46 (8 occurrences)
Last logged: 15:06:46
Invalid state (unknown > 5910.58)
Invalid state (unknown > 234.0)
Invalid state (unknown > 64.21)
Invalid state (unknown > 132.73)
Invalid state (unknown > 125.44)
Not sure of the usefulness of logging this. That transition is actually good. The bad transition is from 0 -> some total, that sort of transition causes endless issues for energy dashboard users.
