at first I liked the UI configuration of integrations. But now I really start to hate it.
So I want to filter out most of the sources from the Bravia integration as I only use the Inputs and streaming apps. With a media_player configured in the configuration.yaml, this was quite esay: add sourcefilter: with the sources.
And now? There is a drop down field allowing me to click the sources to filter. Yeah. We are talking about thousands of them! Any convenient way to do that?
I don’t understand why the configuration of an UI configured device isn’t put into the configuration in YAML - so everybody could be happy. UI lovers and people who just want to edit their stuff in a convenient way. If that is not possible any more, the UI configuration should at least be complete and offer tools that make it usable and not presenting me a drop down list with 2000 checkboxes. It would be helpful already if it was possible to invert the list or “mark all”- so I could just click the few to keep.
But I hope that I am the stupid one and just missing an option to edit this.
Yeah, but unfortunately that ship has sailed. YAML config is going away.
It seems there is a disconnect between some of the developers and the users who are stuck with having to deal with half-assed and/or cumbersome UI configuration options.
What makes it worse is that the decision has been made to never allow any YAML configured integrations in the future. So even if a developer wants to maintain YAML config they aren’t even allowed.
Initially I tried OpenHAB2 and what made me really furios there was this pre-OH2 and post-OH2 world where you never knew if you can edit a config file to fix things or if there is a problem with that UI configured stuff which was a hassl to handle and you were unable to edit manually (and the UI that is awful because you have to create one for each device).
And now they start to make the same awkward decisions here, against a big part of the user base
Thre should at least be standard to offer a minimum of comfort when configuring stuff and the possibility to edit the creatd configs.
This is NOT a YAML appreciation thrad. I actually HATE YAML. It is the worst language I ever met in my ~30 years in IT.
I also did NOT participate in the flames when these changes were announced, the opposite is the case. I was open to it and even happy about the chance to reduce YAML contact.
What I do here is that I explain what is going wrong on a real example. This shouldn’t happen. It is absolutely uncommon to offer such a list to users without options to manipulate it to get stuff done. And I pointed out that an experienced user before had the possibility to get that stuff done and now this possibility is taken away.
I also offered options how this could be done better, what means I am open for future improvments and to change my mind if those improvements happen.
I think I also contributed a lot here already (and yes, got even more back) and it is also my right to express if I don’t like the direction things are going.
And if so many people don’t like that, that you have to start muting those threads…well…maybe somebody should think about this stuff again.
I think this is not a way to go. There are often big changes in HA and building my setup on outdated integrations or HA releases does not seem to be an option to maintain a stable installation.
I appreciate your afford and will check if I want to go that way, thanks for linking! However it seems to be a little odd being forced to do such an overkill for something that was possible natively before, right? I mean, I just want to filter my sources in this case
However thank you for giving these directions, I might really need them in future
To be forced to go backwards to get the same functionality as you had is truly bizarre…especially in an open source project but it’s up to the developers who make these bizarre decisions. If you don’t need to go forward then don’t. Just revert and dig in there until the weight of community opinion gets noticed by the developers I reckon.
Welcome to the club, @HorizonKane. There’s a lot of us who think that UI-only is a bit inefficient. The UI Config Flow was added in April and removed short after.
I do agree that filing a feature request is a good way to make yourself heard, but if the request is bringing YAML control, this will not happen as per ADR-0010.
In the meantime, their advise is to “do it yourself”. The custom component way is the one I’ve found lower cost at full functionality. You can even revert the full component to how it was before these changes were made.
I didn’t even ask for YAML additions but to put an usable way to the UI to configure this. I think that could be expected if the other way is taken away.
In the end this is a decision of the developers. There are often pro and cons and different sights and they have to choose the route. However I think this is a project with a very strong community and doing things against what a big part of that community likes might not be the wisest idea. Also as I said already, this is what scared me away from OpenHAB…that they had this old config file world and the new UI config world. I hope they will do it better here and that the UI configuration improves a lot. If so it might even become a success. But like it is now… meh.
I also want to point out that I don’t want to flame the Bravia component in special here, it is just an example I met on my way and it is a very good example how usability can decrease if you don’t think these things to the end.
It’s not an argument against UI-only. You should ask authors of components to make things configurable from gui. Once they understand that without yaml config their components are half-baked they will learn to make the job complete. Or not - their choice.
Yes, it requires more programming work. But nobody said otherwise.
But I also think when there is a custom integration available that is widely used and accepted you should have a look at it and try to offer same comfort / performance. I think it makes no sense to put half baked stuff in the official product when there is a full blown integration in the world that everybody loves. You should take care to keep at least the things that make huge sense before calling something else “official”.
Example mini-media-player. Yeah the new media player card in Home Assistant is kinda cool. But if you want to do REALLY cool stuff in your dashboard, you need the mini-media-player
Or for Bravia again: Just switched back to the PSK integration. It easily allows me to create direction buttons for a virtual remote in the mini-media-player. For the official integration this seems not to be possible, at least it is not document. But of course I want to be able to click left, right, ok on my virtual remote in Home Assistant. Having to request each of these features and then hoping that it might be heard while it is existing perfectly anywhere else already? meh.
Nonetheless, it’s a complain about a reduced functionality that happened because of the change to UI only and removal of YAML. Before it was fine.
Yes, a solution would be to improve the UI. Probably, the one that developers will choose. However, this would not have broken in the first place if both options were still available rather than an aggressive deprecation.
You can add UI config for basic cases; and leave YAML for advanced users; or, at least, while you build the full UI configuration flow with all the options.
Well, they did say that YAML deprecation was to reduce development efforts. This extra cost may be a one time off while you migrate everything, but I still do not see how leaving existing YAML config would have made things worse.
the problem is, that most authors of integration (at least those I know, incl officisl components) just give a f to gui… And everything, even basic things, you need to setup in yaml, of course incl dozens of system restarts if you experimenting.
I understand them: covering settings by GUI is a lot additional work (this is what I meant in previous post). it’s even harder then working with config because you need to support not only operations needed for adding integration but it should support various corner cases.
But without the decission made, those GUIs would never be improved to provide sufficient user exoerience.
BTW afaik the requirement is valid only for integrating/enablink an integration. how settings of integration are provided to the user is up to integration author. So I assume a lot of configuration will be stored in configuration files making whoke system inconsistent user experience wise. Unfortunately.
If you flick through lots of the available channels, then this is not going to help you and this is certainly not the filter solution you would like. However, rather than un-tick the channels you don’t want to keep, you can specify the ones you do want to keep in customize.yaml. On the off-chance you’re in the UK, there’s a few below to get you started: -
One caveat is it’s best to get the complete list before you save and reload cutomizations because you won’t be able to see the full list after that point. Deleting the list in customize.yaml does bring back the full list though.
This was suggested to me yesterday by another community member Nassau. Now, when I expose this media player to Google Assistant, I can instruct Google to change to one of these sources. It wouldn’t connect properly when the full list was exposed
media_player.sony_bravia_tv:
source_list:
- HDMI 1/MHL
- HDMI 2
- HDMI 3
- HDMI 4
- BBC One Wal HD
- BBC Two HD
- CBBC HD
- CBeebies HD
- ITV Wales HD
- ITV+1
- ITV2
- ITV2+1
- ITV3
- ITV4
- CITV
- Channel 4 HD
- Channel 4+1
- Channel 5 HD
- Channel 5+1
- S4C HD
- E4+1
- More4
- More4+1
- Film4
- Film4+1
- POP
- POP+1
- POP Max
- POP Max+1
- Tiny Pop
- Tiny Pop+1
- Food Network
- Food Netwrk+1
- Amazon Prime Video
- BBC iPlayer
- YouTube
- Media Player
