The best thing with the way it was explained/presented is, it inspire , and if people want to use it in “alternative ways” also, nothing prevent them for doing it
Oh that’s ok. You’re certainly not doing that.
This is not about long or short names. At no point do names come into it.
Nobody, ever, was suggesting that you’d have names that look like a file system path or any form of resource locator.
This is about the entity relationship model inside HA and how that is developed to infer spacial relationships - how this surfaces at the Ui is important but not as important as core structures.
I can only add, that im glad that i.e “Area” is a “Fuzzy” object, as well as “Floors” are.(Not to mention Labels).
Lets assume we have a “schematic overview” cording to common acknowledge concepts.
( ps: don’t mind my naming in parentheses i.e (Var) means “Where ?” Which could infer to “Here” when you look at the circle in the Map( a kind of “spacial relationship”) 
- My Property> Zone](Var) sorry it’s not rectangular, or in fact it’s “Pentagon”
ps: I only use 2 Zones, as it covers my purposes (what ever other people uses Zones for
- My House> Zone(Home) Also a “diffuse” circle (within Zone-Var)
- My House> Area(House) … Unassigned area, so far(meaning not in the Floor-Structor)
- Weather-service
- Moon
- Etc. ( Stuff “Devices/Services/Entities” which needs either Cloud-access, or i decide belongs here for what ever reason/purpose )
So Sorry it aint a “strict” Physical Area, Im sure Core couldn’t care less, unless Dev’s somehow are able to “stir” Core into detecting a Physical Area, Which i haven’t Defined, then the Core-Structor, like i.e floors, areas etc, will remain as “containers/objects” with various features/restrictions and dependencies etc. And Not a Locked “Concept” defined by i.e "common theoretical hierarchies "
- External> Area (Front/Back/South-East/South-West etc.) … Unassigned areas, so far !(meaning not in the Floor-Structor)
- What ever “Devices/Services/Entities” i decide belongs here
- etc.
- External> Area (Mover)( Could also be a “Floor” named Mover, or Lawn ! ) … “covering/overlapping” Front/South-East-Back(areas) Above
- Sling 1 , 2, 3 etc, Docking etc. Could be individual Areas in a “Floor” named Mover/Lawn
- Battery etc what ever is essential to this “Functional Area”
Floors:
Naa i better stop here, your “spacial relationships” seems to go split ways before with Internal/external, just to satisfy an Opinion, not because it’s needed, or improve the functions of the system
i did read the Orig Github Discussion( And ballob’s cons & pros) thou dropped out, half way, as many “commends” seemed like people believed that adding yet another “object” or several in a hierarchy is improving a system.
And im glad that “Level” was not chosen as description, as it more define up/down, where as Floors as mention can be a physical as well as functional “object”
In the end HA has to address the Entities, the less complex the structure is the better,for the system.
Now we got Floors, and beside Labels(versatile), beside we have Areas physical/functional Object
Labels btw, can define everything, without being the same, can be a shorter “path” to the Entities, which in the end is what you(HA) Addresses. it’s not like you turn_off 1st Floor, and HA “pretends” it turned of the requested entities.
It’s /Floor/Area(s)/entities , And same have to be reflected “up the ladder” (if you turn_of an entity direct), Where you btw seems it would be a good idea to have Internal/external.
It’s All possible now, basically always have been, so, the “hierarchy” is only to satisfy people various perspective/ideas upon a “common perception of spacial relationships”
Naming is in fact a part of this, Depending upon How you name your i.e Device.( Im not gonna write an essay about this now )
Domains, Entity-Globs is a also part of this , Groups and Now Labels
And how ever you or other find best in your perspective, you still have to write the Automations/Scripts/Templates( To in the end Address the Entities ), And everything happens “behind the curtain” Unless you choose to show this process in UI.
My point of view have always been and always will be " Build a System as Simple and fast as possible " often meaning the less complex, the less can go wrong, less conflicts
Sorry i just react upon seeing this “discussion” again , what ? +3 month after !
As someone mention, just don’t use Floors, if it can’t fill a purpose for you, there are Tons of Core Features, i don’t or never will use.
If it somehow was a degradation of a feature/function , i could understand (maybe, if i used it
But when there is actually huge improvements, save your “Amu” and embrace it
Did the Total Connect integration die this week or is it a “just me” event?
It started yesterday with a failed to connect error. I removed the integration to set it up again and now I’m getting an “Unknown error” (sometimes it just closes the dialog box, and other times its an “invalid flow specified” error) when I put in my credentials (which do work on the TC 2.0 app and the website).
At first I thought it was a server error on the Total Connect side, but I suspect there might be an issue with the integration as I’m seeing a long “[aiohttp.server] Error handling request” error dump on the logs whenever I try to add the integration again.
I have not been able to update to 2024.4.4 from 2024.4.3. Tried it before the weekend and I tried it again today. It all stops.
I run it through VirtualBox (Ubuntu 22.04). I cannot stop the VirtualBox container (Power off). It has to be killed.
If you have any ideas of how to fix this, I would be greatful.
Change to VMWare Player, Seriously, So many people seems to get various Issues, which you never haer reported from Users On VMWare.
Just search VirtualBox + i.e can’t update, don’t start, crashes, etc, etc. Month after Month
1 Like
New organization is awesome.
Would it be possible to make a clear filters button? It’s quite easy to hit a label while trying to scroll, and three clicks to clear the filter. Something similar to the X for check boxes would be awesome, maybe right next to the filters button, visible while selected.
What’s the etiquette, best to post here or oh GitHub?
2 Likes
I think there’s a link on this thread to another post where specific feedback can be given. Try to search for it. Maybe it was just a post to say the right people will see it here. I tried to find either post now, but I couldn’t find it.
Generally speaking though, you’d make a feature request here in the forum (there’s a category called Feature Requests, or FR for short). GitHub is only for bugs and large, architectural decisions.
How to enable this new Lock safety feature?
I have a switch (relay) that opens a door - unlatches it. If I change the switch “Show as” → Lock it creates the Lock entity but it opens the door (flips the switch) immediately when toggled. Here is what it looks like:
It’s not possible with that setup. If you show a switch as a lock, it thinks your switch is for the door lock, not the door latch.
The only way this could be implemented is if lock.template was extended to support openable locks, which it doesn’t seem like it currently does.
I see, thanks. Well the idea is sound so I guess I’ll make a helper toggle lock and some automation to replicate the behavior.
Hi everyone,
just finally found some time to work through the frontend improvements and am wondering how to use the new lock feature for one of my doors. Do I need to manually configure that entity as a lock? Right now it is a switch (in Shelly integration).
I would like to simply prevent accidental opening.
EDIT:
I am also starting to use labels but is there a way to use them for grouping? I find categories + labels a bit redundant.
Even if an automation had multiple labels, I would not mind seeing it in both labels.
Since categories are not global, it seems like a lot of additional work.
Or can cetagories be defined in yaml? Docs do not mention this option.
How can I make use of {{ issues() }} (Templating - Home Assistant) to filter for exactly those issues also shown at /config/dashboard and /config/repairs?
Like those restart reminders e. g.:
Looking at the template output I can’t find any usable attribute.
The visible repair is created by this:
{'created': '2024-09-01T18:33:02.600212+00:00', 'dismissed_version': None, 'domain': 'hacs', 'is_persistent': False, 'issue_id': 'restart_required_373845609_tags/v1.14.4'}
But it is not different to effectively any other output of {{ issues() }}. So how to differentiate (filter) the interesting ones?