The stance on YAML configuration hasn’t changed in some time, you can find the ADR on it here.
I’m not sure specifically which YAML configuration you’re referring to but if an integration communicates with devices and services it should be configurable via the UI as per that ADR. If it is an existing integration that communicated with devices and services previously configurable in YAML then there’s no obligation to switch to making it UI-configurable but in many cases developers have chosen to since it makes the integration more easily discoverable and configurable for users. Once an integration like this has been made UI-configurable it is up to the developer if they want to maintain the YAML configuration option. There’s no obligation to do so and many choose to drop it since maintaining two options for configuration is more work. A big part of the reason for that ADR was to reduce the burden placed on community developers.
Integrations which do not communicate with devices or services can be made ui-configurable, yaml configurable or both. It is up to the developer.
There’s a constant flow of feature requests to make more integrations UI-configurable. Search the feature requests and wth categories to see. And judging by some of the issues and requests that pop up a lot in discord and other support channels there’s plenty of users that are only aware of integrations that are listed in the UI. And don’t care to find out about yaml-only ones since they have zero interest in messing with YAML. So I would not agree with this statement, certainly not that 100% of users are advanced users.
Are you referring to the breaking changes section of the release notes? These are all planned breaking changes for this release, hence why they are listed. And none are to custom components, those aren’t listed there. If you are using a custom component that broke on release then you should report issues there.
There were a few changes that broke custom components this release actually, specifically removal of support for providing some values as strings instead of as an enum. These changes were all announced months ago and every user of those custom components has seen warnings in their logs saying that the custom component they are using is doing something deprecated and to please report it to the custom component for the past several releases. If no one did then yes the custom component probably broke and an issue will need to be reported now.
my thoughts to, wifi devices can do that for several reason 1. no “reserved” ip, in router, phones switches from 2.4 to 5.0, or bad connection(devices looses contact with router, and shows up again, and gets new ip, due to above)
I use DHCP for my iPhone and it does not generate new devices whenever the IP address changes. Not sure what the devlopers use as the unique_id but it’s not the IP address. It’s not the mac address either as that can change (it’s a privacy feature).
You can still define a “classic” group using YAML; it hasn’t been deprecated.
The recent additions are domain-specific groups (along the lines of the Light Group integration) and, yes, they are currently only configurable via the UI. You said “I am a developer and I am happy to help out” so, if you want them to be configurable via YAML, propose it in the Architecture repo and, if approved, you can comfortably proceed to submit a PR. Already possible; see tom_l’s comment below.
i also never had problems with my android-phone, but other wifi device, that suddenly showed up as “device_2” “device_3” in HA, so i “reserved” all DHCP devices in the Router, after that i havent seen any popping up with new ID
PS: i might have done few other things, during that “session” so im actually not sure what solved what, and forgot what i did also
Yea switch as x is the only new helper that is UI only. And that’s because it is totally new so it was up to the developer which approach to take for configuration. Anyone is welcome to submit a PR adding a yaml configuration option for it though. It does not communicate with devices and services so that is fine per the ADR.
Description of 2022-04 new ‘Hide entities’ says: “Besides enabling/disabling entities, it is now also possible to hide them. You can now mark an entity as hidden in the entity settings. Hiding entities will hide them from most places in the UI, but they are still there and are still being recorded. However, they are no longer shown on auto-generated Dashboards;”
I did hide some of my media_player entities but they are still shown in list of players in Media section. I would consider the list as auto-generated. Would it be logical to not show hidden media_player entities there. Wouldn’t be?
I thought this sounded like a really great idea; however, this approach has left more unanswered questions. When I go into users to assign a device, it only offers the same two device entities
@CentralCommand Thanks for the reply, although I find it very strange how much you’re claiming this release doesn’t break anything considering how many comments in this thread say otherwise and have even reverted to previous versions, let alone all the other threads on the forum about 2022.4> issues.
Again, I have no issue with having things UI-configurable, it’s my preferred option when it works. But to now have to resort to editing the SQLite db when thing’s DON’T work - is an awful move in my opinion.
Bugs and breaking changes are not the same thing. Maybe you don’t know the lingo. Breaking changes refers to a planned change that will break the current configuration. Bugs are unexpected breakages. As someone who monitors threads threads regularly, this release has been similar to every other release. Also, we are half way through April and we are on the .4 release. We’re on par for .7 or .8, meaning roughly the same amount of issues as any other release.
Oh you were referring to the bugs. I was confused, you mentioned breaking changes and custom component devs. Breaking changes aren’t bugs, they are planned. And I wasn’t sure where custom component devs came in.
Unfortunately yes there does appear to be some bugs that are now being worked on. Not disputing that just misunderstood.
click the “clear” so you see the 251 hidden entities, and search phone
Edit: Thou it seems like it’s your automation/service that gets the tailing number, have you tried to Reboot, to secure there is not running duplicate “processes” ?
I cleared away all my filters and got the same results except now we’re also pulling back every microphone. Still only the original device entity for the iPhone:
I DID notice in the device screen that the tracker for this device is under diagnostics and not grouped with the other entities. I don’t know if that’s normal or not but it looked weird to me. I don’t have apple products and I don’t know what this typically looks like:
I’ve rebooted a half dozen times today and probably a dozen times yesterday (I’ve been doing a lot of other work). Rebooted from host and on all the newest version of everything. I AM in the beta channel. Maybe I should bow out and see if the issue remains.
