There is an open PR that fixes lot of similar issues. That should be fixed once it’s merged Use body scroll with ha-drawer by piitaya · Pull Request #16137 · home-assistant/frontend · GitHub
6 Likes
Since 2023.4.3 scroll doesn’t work on any of my dashboards.
Is it system-wide issue, or should i revise my HACS UI stuff?
Literally one post above yours…
1 Like
Also, can I have a virtual cover entity, as I have with switch?
Just putting cover in the YAML configuration file didn’t succeed.
Awesome!! Nice work!
When are you going to fix conditions tests and traces so they actually show how much “For Time” is remaining ? The lack of votes is not an indication of unimportance. It’s a fundamental information gap which needs to be rectified.
2 Likes
Just curious how many slip up with the states function for jinja? I always question myself everytime I write it whether it’s meant to be state('some.entity') or states('some.entity'). Of course I immediately think of the former as we are not checking more than 1 state. I also understand that this is stamped in and too many people use it for it to be changed but maybe an alias?
I also came across Selectors - Home Assistant who also used the term state and not states which just added to my confusion again.
1 Like
Home Assistant app cant be loaded and fail at start after Reolink integration. (Enable main camera entity)
Probably it is an issue with internal link. I use duckdns. App doesnt work but i can reach HA via local ip.
Seems cameras cant get data over duckdns link
If anybody was wondering what the various ways of importing macros are (and didn’t check the HA docs carefully where it’s linked), it’s all in the Jinja docs.
TL;DR: You can use all the same variations as you can in Python, with one exception (if you know Python).
Quick reference
Import the whole file:
{% import 'tools.jinja' as foo %}
{% foo.bar() %}
As per the example in the HA docs/blog, import one macro (or variable) from the file:
{% from 'tools.jinja' import bar %}
{% bar() %}
Multiple macros (or variables) from the same file:
{% from 'tools.jinja' import bar, bas %}
{% bar() %}
{% bas() %}
You can use aliases too:
{% from 'tools.jinja' import bar as qux, bas %}
{% qux() %}
{% bas() %}
But the one exception (which is different from Python) that won’t work is just doing:
{% import 'tools.jinja' %}
7 Likes
Off topic in this thread.
Also don’t be demanding.
Before this release, it was possible to hide the border/separator between sidebar und main area. Think its color was defined via theme variable divider-color.
Which is still in use for the other separators there
But for the line on the right, here set in blue
now everything there is either hard-coded, like right border width and style or you can see with 1px set border the general background color variable, which is used everywhere.
So currently no way to set border-color or background color which is shining through or border wdth to 0 or … anymore.
Any idea how to set it on my own or who can bring back a separate variable or non hard-coded values there again?
1 Like
My entity names have gone crazy after the latest update to 2023.4.4. Lights have gone hidden, friendly names have been replaced by their internal ids…
I noticed that devices that have “Switch as X” are the affected devices only. What I see that happened was like this:
-
imagine a device with one named ‘Relay 1’
-
‘Relay 1’ was set up to be seen as a light named ‘Desk lamp’, thus making ‘Relay 1’ hidden
-
when doing so, Home Assistant uses ‘light.desk_lamp’ as the entity name for the ‘Desk lamp’
After the upgrade to 2023.4.4 the situation is this:
-
‘Relay 1’ is being shown as lamp, and it’s entity name is ‘light.desk_lamp’
-
‘Desk lamp’ is being shown as a relay, and it’s entity name is the original device entity name.
The problem affects all devices in Home Assistant. I have over 100 devices. This is a headache to go and fix manually by myself.
Did anyone come across the same issue? thoughts?
So if I understand well - majority of users will have, speaking about polymers, two options - either be dependant on flexibility of custom cards developers or rework their UI ( some views at least in the better case).
Please correct me if I am wrong.
This is not related to Polymer only - in general many people do not want depend on custom plugins at all.
In some Russian forum which I used to visit (more than 1 year ago, until this forum became too “rashist”) there was a tendency to talk about ANY custom lovelace cards disparagingly (hope this is a correct word); this “rule” was made by the forum’s admin and most users (at least openly) followed this “rule” (probably due to “herd mentality”, if an English translation is correct).
1 Like
Sure. As always.
Use of custom components comes with risks. They can break anytime and you are in the hands of their devs.
Or your own of course…
2 Likes
looks like there is a problem with the Enviroment Canada service, when changed to 2.4.4. the entitiy values go to zero, althouhg some of the forecast entitites seem to come through. If I rollback to 2.4.2 all is good.
1 Like
Dev is aware of this issue
When exactly does it supposed to happen on this Sunday? I have a feeling that my db is even bigger than before…
You don’t need to wait for the second Sunday of the month, you can just repack the database whenever you want using:
service: recorder.purge
data:
repack: true
You can also use e.g. keep_days: 7 to purge history and only keep the last 7 days, at the same time as repacking.
It was my bad. This is the 3rd Sunday of the month. And actually my db is bigger than ever.
My question really was about the new size reduction. Is it really working?