You are mistaken. selectattr is a filter and only produces results that are actually accessed.
The states object accesses all objects and forces updates on all state changes. I believe this is what you’re getting confused by. The template itself is not accessing all that memory.
Using expand() limits your template to only be updated based on what’s found in the template. So, it would update less, unless you have a very chatty entity in your expand. Then it would be no different.
i.e. using states is the problem, not select, selectattr, reject, and rejectattr. Using expand limits your initial set of entities before using something to filter the list down.
the database will not keep values “xxxxxxxxxxxxxxxxxxxxxxxxxx” & “yyyyyyyyyyyyyyyyyyyyyyyyyy” for EACH sensor’s change?
I.e. these static values are stored once for this sensor and do not repeat for each state change?
And how is that confirms or disprove my post? Could you elaborate?
Yes, I understand that the “states” stores all entities. But where is my confusion? Unclear…
Sorry, again unclear.
Assume I have a group - and I believe that this group already have all needed entities.
Expanding this group gives me a list of these entities.
Surely I need to manage my groups, update them periodically - and I mentioned this a possible problem (a not updated in time group may contain a wrong list of entities).
It’s not a database. It’s the state machine. It’s a collection of state objects that house the current state object for all entities. This is persistent at all times. State objects do not magically gain attributes when you ask for an attribute that doesn’t exist in the state object.
Generator’s only give you what you asked for. If you didn’t ask for it, it doesn’t give it to you. When you say “I only want entities with xyz”, you’re only going to get entities with ‘xyz’. Nothing else is altered or presented on entities that do not have ‘xyz’.
No, it does not store anything. It accesses. Store means “makes new memory”. Accessing means, “Uses the already existing memory”.
FYI the state machine with all state objects exists at all times. That’s how everything is displayed in home assistant. When you use states, you’re accessing them all. When you use expand you’re accessing a subset of the entities that are in states. That’s all you really need to understand.
That was about using attributes like “attr_x” to select needed entities.
You answered:
So I concluded that your answer is regarding my assumption above - and asked about database again.
And you finally wrote “it’s not a database”, I am confused.
Yes, but why are you saying this? I see a misunderstanding.
And regarding all the rest - I totally do not understand how is this related to my 1st post.
Probably I am missing something.
Or may be you understood my question in a wrong way.
Because it’s not a database. A database is very specific in software. This is not that. This is an object that is holding the current state of all entities in HA. It’s a collection. A list. A lookup. It’s not a database.
You asked:
Nothing is stored. When you use selectattr('attributes.attr_1','defined'), nothing is stored. It’s simply looking to see if a state object has that attribute. I.e. Nothing is added or stored, it’s simply looked at.
Imagine you’re in a room with 10 people in a line. You quickly glance at all 10 peoples shoes and you ask the people wearing red shoes to step forward. So only 3 people with red shoes step forward. Did the people without red shoes do anything? Or did they just sit there doing nothing? The only “work” being done is the 3 people stepping forward.
That’s how selectattr, select, reject, and rejectattr work. Except it’s like that with state objects. You only get & use what you ask for. So all that matters is the initial set that you start with.
Sorry, you misunderstood my answer.
Info which you are providing is definitely valuable - but this is not what I asked for.
Once again: sometimes we need to list a set of entities - to do smth with them, to list in auto-entities card etc.
I posted 4 known methods to select (“filter”) needed entities:
List entities which have a defined entity_id: “sensor.voltage_1”, “sensor.voltage_2”, “sensor.voltage_xyz”. So here we need to follow some “naming conventions”.
List entities by expanding a group - and this group must contain needed entities (and we again need to create these groups based on some filters).
List entities based on area, integration, device_class etc. This way may be used as a PART of a desired filter.
List entities based on previously added attributes. And here I have an assumption (possibly wrong): if some entity has an attribute used ONLY for filtering - it occupies a place in DB which is not good (same static value in each record).
A question was - what method of filtering do you recommend?
Sorry, but maybe this is a language barrier thing, but your original question is not as clear as this post.
Personally, I use 2 only. I pair that with an automation that runs periodically to automatically generate group so that I don’t have to maintain any lists of entities.
I still place random attributes on all my template sensors because I filter my recorded database to only things that I care about.
If you’re worried about CPU and ‘heavy’ templates, using 2, or 3 are the most optimized.
Here’s an example of an autogenerated list and template it’s using:
alias: Create Group
trigger:
- platform: event
event_type: event_template_reloaded
- platform: homeassistant
event: start
action:
- service: group.set
data:
object_id: my_group
entities: >
{{ filter to a list of entities that you want using method 1, 3, or 4 }}
This will automatically update your group whenever you reload your template entities or when HA starts.
EDIT: I’m super lazy with my configuration, I do not like maintaining lists of things. So this method will get you the ‘most hands off’ approach to lists of entities. It’s also optimized to only perform the heavy templating on restarts or reloads. And all the lightweight templates are performed regularly when entities update.
really a bit puzzled by your post here Ildar. What is the purpose of your quest? you mention auto-entities, and then only a very select set of the available filter options, which Thomas has listed here
so, yeah, those can be useful, depending on the output you desire, there’s no preference other than the requirement set by the user.
additional to those, you have the template option. with the available (de)selectors. Based on the collection of entities we startup with.
As that last aspect in fact your actual question? how to define the base set of entities, to work with ?
No problem, we are all intelligent people and should always find a way to understand each other.
I do it for some cases, and here is a risk: sometimes a group may contain an outdated list…
Your solution with “template_reloaded” may not sufficient enough in cases like “I need entities with some desired state”; so it may be used as a PART of filtering (as all other 3 methods) - expand a group then analyse each entity.
As for using “attributes for filtering”: it was not my idea, probably I heard it from you or Taras.
I find this method rather good in some situations when you do not want to deal with groups or entity names.
What do you mean by “random”?
Is it some kind of random unique value?
Could you describe a use-case for this?
Also, I am still worried about my assumption -
surely it is an off-topic here - but do you know smth about this, do these static user-defined attributes occupy a place for every entity’s state change?
yes, but the beauty of an automation like that is you can make it update whenever you want by adding additional triggers.
So, when I create a template entity, I always add a template: ... attribute that basically describes where it came from so I can quickly filter it in developer tools → states page.
e.g.
template:
- sensor:
- name: Outside Temperature
state: "{{ ... }}"
attributes:
template: temperature
Yes, but from what I can tell, the most recent database changes only store them when they change. bdraco might know better.