Some similar method of search imho was added several releases ago. There is a corresponding issue or discussion for this.
In my tests more “close matches” are listed first, then “less close” (and mainly useless) matches.
Do not find this method useful.
Yes, mentioned it above as well, that this change was already there once but removed more than soon
Not here. Hits with the exakt phrase are not even in the top 5 of most of examples. Here e.g. only number 4. But many cases are even worse.
E.g. I have 10-15 entities with “laut” in the name. But the search is now showing over 300 entities with the relevant ones randomly distributed. More or less no chance to find the right one.
I like wildcard searches and enable them is good as well, bit then only with entering wildcards or ar switch. But returning more or less all entities in my environment in a search when I put popular letters in the search field … ?
Found it: 2022.5 (o.k. was .5 and not .1 as I remembered
and
If “everyone” 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?
1 Like
to give some counter weight, I really like the search method. If you understand how it works, it’s very very practical to not have to remember the complete object id or name of an entity you are looking for, but only a small string. Simply jot in a few characters in the correct order, and it doesnt matter what’s in between, as long as that ordere exists.
ota wont find automation, ato will
if you want an exact phrase, just add an extra character if it doesnt return the correct entities yet, its super fast
I find it especially productive in the dev states, hadnt even realized it to work like this in the /config/entities. even better !
No more need to remember exact substrings, which is an extraordinarily useful concept having over 4000 entities… if you do remember, it’s easy enough to enter sufficient chars to return what you are after.
1 Like
For this wildcards are common (optional!) and known approach. * O
There it is implemented good. If I search for “laut” it will only give wntities with exact containing “laut”. If I search “l*a*u*t” it finds more. Wildcards is the way here. But not automatic wildcards.
No. Why do you think this. See my laut example. It returns >300 entities and I cannot find the right 10-15 ones ins this huge list. Not at all. I wonder if you have already tested the search now. I’m talking about the e seach and the add entities to card search, etc.
If I have a card where I want to ad entities with “counter” in its name, I want to see the result with “counter” in its name and not entries named “could be another entity”. Has nothing to do with “just put more characters there to find the right one”. Esp. with the removal of already added entities some releases ago.
As said. 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.
…
sure, ofc I did (…!) , but I confess having reopened that exact same search now, it only finds exact strings, and I can not enter a random set of chars in the correct order. I dont know what happened.
still, I can seem to run into your problem, maybe even less so than before. Sure, we can not use wildcards here (/config/entities) but that seems better suited to let’s say a mobile device where we would need to change keyboards for that.
maybe you just need to help the system understand you. what I meant with add another character:
if you are looking for counter, add a . and you’ll only see domain counter entities sure you dont have hundreds of those?
I believe we were talking about different search bars… It now dawns on me you are talking about the card-editors in the UI?
and I see what you mean…
adding the . helps here too, though there seems to be another issue going on, check the red error on the right. huh?:
sorry about that, I figured you were referring to /config/entities, which uses another search altogether, making that 3 different versions 
Yes. Behavior there is different as well. This is fine. Dev tools state table seach as well (but ofc not dev tools state change entities search box). Dev tools state table search is the best. Exact matches with wildcard support - the way every search should work.
But not the central search (press key e) or the card entities search.
Regarding additional characters. counter was only an example. Here didn’t mean the domain but entities with e.g. energy counter in its name. Same for the “laut” example which is English “loud”. Some entities have _laut, some laut_. So, to find now exact matches with laut I must search twice and must remember if and where the position in the name is. For me, the opposite of a benefit where I was able to put laut in the search and got entities with exact matches before and not hidden and distributed in a >300 entities long result list.
1 Like
yes, I have to +1 to that, sorry for me taking so long to get your point…
the card editor seems a bit odd. I practically never use that, only in my testing dashboard, so dont hit the ‘issue’ too often.
However, I suppose the editor is written for users that dont do yaml too much, and for those I figure the behavior is even more undesirable …
I like the look of the new climate entity.
How do I get it to show min and max in the thermostat card?
And can I use a second entity as source for current temp? My thermostat does not have a built-in thermometer but there is one in each room.
Removing the forecast attribute will make it way more complex and specific for custom card creators to display this data.
Also the forecast data will not be able to be used with any automation/template entity/etc…
Building a chart for the future temperature using apexcharts-card for example will not be possible anymore.
This is sad 
Have you read the many posts above? I have already migrated my automations to use the new weather forecast service and it is working without issues
example:
action:
- service: weather.get_forecast
data:
type: hourly
target:
entity_id: weather.home
response_variable: forecast
- choose:
- conditions:
- condition: template
value_template: >-
{{( forecast['forecast'][:3] | map(attribute="temperature") | max)
< 60 }}
alias: Temp in 3 hours < 60 F
sequence:
- device_id: 1a139557a01ed2084b4db6e4c0c47fd6
domain: climate
entity_id: climate.thermostat
type: set_hvac_mode
hvac_mode: heat
2 Likes
Right, I missed that. Forgot about the response_variable feature 
Thanks
1 Like
this one still works fine:
most likely because this field is only deprecated, and has not been removed
was looking for that, thanks!
but just to make sure:
this updates the seonsor every 10 seconds right?
why is the 7 in the state? like, what does it do?
Yes it updates every 10s, it was just an example.
Set the update as you need.
The number 7 is again an example and it is the value of the eighth hour because the first hour is 0.
1 Like
Just as a canary in the mine note that may have nothing to do with the release. 2023.9.3 update. Installed the 2023.9.3 update this morning on a working 2023.9.2 system and it is now unusable. The system came up unable to find config or automations. Tried to reload autobackup made prior to install and issue remains. Visual file editor seems unable to find the directory structure where .yaml config files exist. Was on 2023.9.2 prior to update and all was well…
Trying to install a full backup from last week now…
1 Like
Just installed the .9.3 and I’m “locked out”. Can’t login to the interface anymore, but the system is alive (it replyes on telegram).
EDIT: powercycled raspberry and everything up and running again.
2023.9.3 working fine here.
1 Like
2023.9.3 working fine here too though did have to reboot Host after update as the Core reboot as part of update did not allow everything start for some reason…have encountered this before and rebooting Host gets the system back fully working…
Not sure if its related, but installed the update this morning and no sensors/integration seem to work, everything is unavailable. Neither “check config” nor “restart” option seem to be working. A lot of errors in the log from each of the integrations, but this particularly may be related as it started immediatelly after the update:
Logger: homeassistant
Source: runner.py:186
First occurred: 10:36:17 AM (420 occurrences)
Last logged: 6:36:58 PM
Error doing job: Unclosed client session