Thank you one more time for testing!
So far I got 3 observations for 2023.7:
- Demo integration became inconsistent.
- “Image” entity does not accept “/local/…” path.
- A simple card may hang a page.
Thank you one more time for testing!
So far I got 3 observations for 2023.7:
Is there a way to look at my dashboard YAML without opening it? I want to see if I am using grid in those instances.
I managed to bypass a hanging page using this:
http://192.168.0.100:8123/NAME_OF_DASHBOARD/ADDRESS_OF_PAGE?edit=1
Can’t even get that far. As soon as the dashboard opens, even in edit mode, it’s unresponsive.
Because the page you trying to open contains “bad code”.
Is it a graph inside grid?
You need to open a page w/o these things.
Seems I just shared a virus and soon it will capture all smart homes…
I am, but I need to see the code on the “bad” page to confirm that it has these grids. I can’t see the code because I can’t open the page, even in edit mode. Where is the code stored? Can I get to it from the terminal?
My 1st method was “open a raw yaml file, scroll to a hanging view, edit the code”.
Here is a 2nd method:
There is a json file in “.storage” folder, it is called “lovelace.NAME_OF_DASHBOARD”, you can edit it.
OK, I got it. Looks like my history cards are in “vertical-stack” and “horizontal-stack” types, not grids. But maybe these are just specialized instances of grid?
What I also did with my “virus” is:
type: vertical-stack
cards:
- type: history-graph
hours_to_show: 12
entities:
- entity: zone.home
There is one more issue, seems to be same origin:
Hmm, this is also causing hanging:
OK, more info (but probably more confusing):
On Linux Firefox:
On Windows 10 Firefox:
On Android app:
Well, let’s see if any feedback comes from Dev.
Actually, even a detailed description of a bug sometimes does not matter.
Different priorities, no mood to revise a code, etc…
For me, the most desired update will be “2023.8: Solving ancient bugs”.
Who decided on those lock colors of green for locked and red for unlocked?
This seems the opposite of most physical lock and alarm devices I have interacted with, where green normally is for open/ready/authorized and red is for secured/armed/rejected?
There were some discussions about colors - if a “discussion” is a proper word for a process when some users are discussing colors, other users trying to shut them up & devs are mainly keeping silence.
You are probably correct, but I can see how red=unsafe=open and green=safe=closed would be understood. Ideally a way to change this would have been preferred.
Ditto.
Using an ELK M1 for 15 years and its keypads indicate ‘ready to arm’ in green and ‘armed’ in red.
Oh well, I can get used to Home Assistant’s inverse version.
There are some more examples of controversial default color choices. Anyway there is a possibility to redefine them by a theme.
P.S. only zones are still only blue or grey.
I’m not familiar with themes, but at least on the dashboard its lucky just the same old blue padlock icons.
what is it with people posting this, that makes them think
it helps the general atmosphere in this community
it helps their challenge see a solution
it helps, well, anything really
why ask for names and back numbers, if all you feel is some simple design was not as you expected it to be? why feel so mistreated, if you don’t always get what you want, or if others don’t immediately respond and fix you personal challenge?
please let us all work towards a friendly ambiance in this community where we invite others to think along, and not be thrown off by the tone of voice, or personification of your ‘issue’.
end rant
On the matter at hand: if you check the docs that have been added as a result of some serious And fruitful interaction between this community and the Frontend dev team, more specifically on the state-color: Home Assistant frontend - Home Assistant
it will help out on any colorization you might want (well, almost, we have to accept we live in a world where we just cant always get what we want…)
You have to add the repository first to HACS (Go to HACS → Integrations → 3 dot menu → custom repository). Add briancmpbll/home_assistant_custom_envoy (github.com)
Also, check this thread for more information on this issue: Enphase Envoy stopped - Energy - Home Assistant Community (home-assistant.io)
just found another way of showing snapshots in the Frontend, and still have them served from our protected /media share (opposed to what I had to do above in the /www folder using the new image template):
see: 2023.7 image entity local image - #17 by Mariusthvdb
bottom line is I used the Local File technique on that snapshot:
camera:
- platform: local_file
name: Snapshot Oprit
file_path: /media/snapshots/camera_oprit.jpg
and show it with:
- type: picture-entity
entity: camera.snapshot_oprit
only minor gripe is it does not show the time the snapshot is taken in the footer of the picture-entity, but the state of the camera being idle.
I dont really get that, since at the time the snapshot was taken the cam was active (obviously ) and there would be no connection to the current state of the cam, since this is a file/image not cam feed anymore?
add:
show_state: false
Anyways, for me it’s the best go between now, as the snapshot itself has the timestamp in the image. best of both worlds now: secure/ auto-updated in Dashboard/simpler config(no extra script actions)
it might be an older integration (no unique_id, no frontend config) but it does the job nicely