My biggest pain point getting started with Home Assistant has been the complexity of managing/organising my ever growing set of devices.
It seems that deciding on (and sticking to) a good naming convention is pretty critical to success. There’s a lot of helpful advice & opinions out there on the subject, but in practice I’ve found it takes time and continual iteration to settle on an approach that works for you and this is quite subjective. The more devices you add, the more important this becomes (if you want to avoid chaos, anyway). I think the UI sometimes makes it fairly tricky to stay organised.
There are a number of key parts of the system, e.g.
Areas (containing devices, services and entities)
Devices (containing entities)
Entities (containing attributes)
All of these get presented in huge, flat lists. The filters are helpful, but it’s still not always easy to see the relationship between these different “entities” (in the general sense of the word) or drill down to the set of things that you need.
I suggest adding a tree view which can be used to more easily “drill down” to find groups of devices / entities etc.
E.g. display a tree structure where you can expand/collapse nodes to drill down to the thing you’re looking for:
(Area) Bedroom
(Device) Bedside Lamp
(Entity) Light
(Attribute) brightness
(Attribute) color_temp
(Attribute) …
(Device) Temperature & Humidity Sensor
(Entity) Temperature
(Entity) Humidity
(Entity) Battery
(Area) Kitchen
…
As I understand it (and no doubt there’s a lot of complexity and history here) these entities are not necessarily strictly structured as a tree (there may be many-to-many relationships etc), but I think there’s still a lot of value to be had in allowing the user to choose (ad-hoc) how these get grouped into a nested hierarchy when displayed. For example, choosing to present the hierarchy grouped by area/room or by integration etc.
I think this could go hand-in-hand with the current filterable tabular lists, but provide a much more intuitive hierarchy in many situations - making things less overwhelming.
To make this truly useful, provide both a way to view information (e.g. current states) but also perform bulk actions on subtrees, such as bulk renaming of entities. For example expanding Root → Bedroom → Temperature Sensor and then being able to rename ids/friendly names etc for all entities within that part of the tree in one go based on a certain naming convention.
I’ve had similar thoughts since I switched over from ioBroker a year ago. At least the main problem and general approach is the same - if you think it’s too different from your ideas, I’m happy to open a new topic.
I too was very confused that whenever it comes to selecting entities, Home Assistant presents a huge, flat list of entities. That has a couple of implications, e.g. having to put enough information in the entity title to correctly identify it, which in turn leads to rather long and similar titles. On top of that, many devices have 10+ sensors, e.g. device tracker has 32 sensors and 85 diagnostics for my smart phone. There isn’t any order and structure between those.
While I like many things much more in Home Assistant, I miss how ioBroker organizes all “entities” into a tree structure. For example, there would be objects with IDs like shelly.0.SHSW-25#987612345678#1.Relay0.Power or worx.0.201812345678001234B4.product.features.rain_delay. This divides the big list of entities into a meaningful structure, even below device-level. The Shelly also has a Relay1 and both relays have the same properties. The name is just Power, but since the entity picker shows it as a tree, the context is very clear. That’s helpful for multi-channel devices, but it could also group e.g. all WiFi-related sensors of the phone.
That doesn’t answer the order of the entities and also doesn’t consider the area like you mentioned. I’m not saying it’s perfect, but a good start.
By the way, the IDs in ioBroker are based on the “integration” name and usually a naturally unique identifier like a MAC or serial number. They’re dictated by the integration, including the part behind the device ID, not changeable by the user. I feel like that’s a good thing because it gives some predictability, which is useful when accessing the entities programmatically (e.g. loop over a list of devices and check a certain property). If you need your own structure, it could easily be achieved with aliases, while keeping the primary ID untouched.
I’m not demanding anything here, it’s just some food for thoughts that more structure would be helpful. Maybe others feel the same and have their own ideas.
Ever wonder how your devices, entities, automations etc are related to each other? A network graph may reveal configuration inconsistancies and dependencies that isn’t easily seen in the native GUI. Such as entites not related to an area and automation triggers/conditions/actions.
Suggestion is to implement a framework for config documentation. And some of them possibly natively (such as optionally viewing groups and entities in a matrix view to toggle on/off memberships!)
I have thousands of entities and keeping consistency and leave no one behind is sometime tricky although having a strict naming scheme helped me a lot!
I did a small proof of concept some year ago but then got a small baby and no time to finish it - yet!
Many things to consider, such as most importantly:
Is this an integration, an add-on, appdeamon or something else?
Best way to read the configuration data? Parsing the raw json was easy but i assume we should use abstration layer but didnt get it to work for more than a few use cases.
Layers. There are in a big installation so many relations and nodes so showing them all at the same time doesnt make sense. Define a few common slices.
But the WTH is simply “view the configuration in new creative ways”.
(Sorry did not have any screenshots of the complex views with my configuration but can promise they revealed a lot of useful info!)
