It looks like since one of the 2024 releases the entity search longer requires you to type the full entity name!
Whoever it was, thank you for this!
Edit: I think it was @breakthestatic .
3 Likes
Well it’s nice to see that someone apprecaites the change
opened 06:09AM - 22 Sep 23 UTC
### Checklist
- [X] I have updated to the latest available Home Assistant ver… sion.
- [X] I have cleared the cache of my browser.
- [X] I have tried a different browser to see if it is related to my browser.
### Describe the issue you are experiencing
With another recent change, the entity search (keypress e, or add entity to card search list, dev tools entity state change entity picker, etc.) is now again a fuzzy search with not good prioritizations.
Early in 2022.5 this was introduced already once, but according to core team, user feedback, etc. reverted directly again.
See:
https://github.com/home-assistant/frontend/discussions/12590#discussioncomment-2722057
https://community.home-assistant.io/t/2022-5-streamlining-settings/418477/376
Now this is back again. Perhaps the fuzzy order is better (cannot test it) but it is not good at all or still the problem that was the reason to revert it directly in 2022.5.3 again.
If search for "cla" the first exact match in search result item 34 (!):
If I search for "counter" I get first some cover entries and then the first exact match counter
If I search vor "laut" the first result I want to see is on position 4 and the rest of the exact matches containing "laut" is then randomly distributed in a list result list with >300 entries. So not even on result position 5, 6, 7. With this I cannot find the entities anymore containing "laut" at all. BTW I would doubt that a >300 random result list would help any user to find what he is searching for.
If and only if the complete hits/exact containing matches would be shown on top or with manual * or a fuzzy-checkbox it make sense for me. But not when I don’t find exact matches anymore in the list.
I would agree to see such result lists if I would be able to enter "l\*a\*u\*t". But wildcards are not supported here. But without wildcards the results have to show exact matches results only or every (!) exact matches results on top of the result list. Loop again over current result list and put exact containing matches on top of the current list. Then we would have perhaps both worlds, the old exact results and and wildcard results afterwards.
If “everyone” in the linked history agreed that it wasn’t a good idea and reverted is back, why should this now a better idea to re-do the same mistake again. Who is why re-putting already reverted “features” back?
### Describe the behavior you expected
Either:
a. Option without wildcards:
- show only exact matches
- show all (!) exact matches in result list on top of the list and then the rest of the fuzzy
- Have a checkbox (fuzzy-non-fuzzy) in the search
Option 2 is bar minimum. Loop again over current result list and put exact containing matches on top of the current list. Then we would have perhaps both worlds, the old exact results and and wildcard results afterwards.
b. Option with wildcard:
- Show only exact matches (with respecting the wildcards), so "cla" woud find only entities with existing "cla" and "c\*l\*a" would find everything accoding to the pattern,
### Steps to reproduce the issue
Search for exact matches entity search (keypress e, or add entity to card search list, dev tools entity state change entity picker, etc.) and see that exact matches are not on top on the result list.
### What version of Home Assistant Core has the issue?
2023.9.2
### What was the last working version of Home Assistant Core?
2023.8
### In which browser are you experiencing the issue with?
all
### Which operating system are you using to run this browser?
Win
### State of relevant entities
_No response_
### Problem-relevant frontend configuration
_No response_
### Javascript errors shown in your browser console/inspector
_No response_
### Additional information
_No response_
Definitely agree that some tightening of the fuzzy criteria is needed, but that’s more a part of the parent fuzzy search logic, not the expansion of the fuzzy searcher to additional fields.
3 Likes
Yeah, ok, I see, the space in my example wouldn’t have been necessary, it splits the search term into characters, which leads to some spurious results.
CaptTom
April 2, 2024, 12:27am
4
Yes! Every time I use the search function I remember how bad it used to be, scrolling.
Thank you!!
This is very much a “function over form” change, the opposite of some of the UI changes that “designers” love to make and which are almost universally unwelcome by users.
We could use a lot more of this sort of thing; making systems work better for existing users, rather than more fashionable or enticing for new users. Yeah, I know. Those mundane usability improvements don’t make headlines or look good on a résumé. Still, some of us appreciate them!
tom_l
April 2, 2024, 10:14am
5
I just had a play with it. It’s weird but I like it. e.g looking for script.lounge_close_blinds I used:
sclocl
It wasn’t the first result (that was script.lounge_clean_kodi_library) but it was second.
The order of the words seems to be important when searching like that so if you don’t know the name of what you are looking for just be less specific. e.g. what is my mailbox lid binary sensor called?
bisema-> binary_sensor.mailbox_lid_contact (3rd result after the mailbox door contact and mailbox full binary sensors).
