There’s a reason people use third party firmware for Sonoff that integrates directly and easily with Home Assistant.
1 Like
This should be on the wall in big letters.
3 Likes
Yeah, but that requires flashing. And I read that didn’t go smoothly either for a lot of users. Again, it’s a solution, but not a great one. Hence the solution I was using that promised me none of that shit. Unfortunately, dev is not up to date so I’ve to wait and see if it’s coming. I think by the way HA should be more clear on those integrations, they need a star system. Work great, might work if you’re lucky (fitbit), don’t work (yet or anymore). I wouldn’t have started on this work yesterday if I knew before both had problems. Wasted a few hours on this and ended up with nothing.
1 Like
It is a great solution. There is no official support for those third party integrations for Sonoff!!! You are dependent of third party devs anyway. This thread is really only about official devs and official integrations.
Flashing Tasmota is pretty much foolproof.
3 Likes
I think someone made a similar comment in the thread about the new naming scheme/s (Hass.io —> HA supervised, etc). This point is so key as everyone uses HA differently.
It increasingly appears that the devs don’t want to involve the broader community in open discussion, before making changes. There will be a large majority of comments in any sort of open discussion that are not useful or relevant, but, there will be a small fraction that will provide a perspective that perhaps hadn’t been considered and give pause. Start a thread, like this one, with ideas to gain feedback. Bring people along for the ride, make people feel involved - like they got a chance to have their say.
It’s a slippery slope when paid employees go from 1 to 2, to 4 and so on. The motivation changes, it becomes about appeasing those who are paying for the service to keep those on the payroll, being paid.
If removing YAML and and converting as much as possible to integration style on-boarding makes things easier for those newer/novice users who pay for Nabu Casa, then that is the direction the project will take because if the users paying stops paying, then paid staff will lose their jobs.
7 Likes
(I’m posting this as a user of HA, not as a mod)
Those of you who know me know I’m a long term supporter of YAML and manual config. I don’t hate the UI setup, but I do have an aversion to it. There’s a variety of reasons for that, some of which are about my background and experience, some of which are about wanting to be able more easily configure a new install that’s the same as my current one.
That said, there are a number of integrations I’ve set up that would be a nightmare to do manually. Things like GPSLogger… how do you get the webhook? Adding a new integration through the UI also doesn’t require a restart, which is more than a little nice.
So… I don’t love this shift in course, but I understand it and I do like it a little. I’m sure it’ll grow on me over time. I’m also not surprised it happened, I’m actually surprised it hasn’t happened sooner, and I’m happy that (at least for now) YAML is still being kept for as much as it is.
8 Likes
And there’s the rub. I don’t strongly disagree with you but the, ‘at least for now’, is I think the sticking point. No one knows what the (paid) powers that be will do in the future.
1 Like
Clear answer… Do you think when this will happen, you still can use YAML to make complicated automation using still all integrations by using their entity_ids?
Again something that I don’t really believe was intended to communicate. With it’s international base of users it just makes sense to add translations instead of forcing everything to be in english. and I don’t get why this even would be a problem
i dont know why. it was in the early days. a lot of people were for it and presenting arguments.
also presenting ways how it could be adchieved, but balloob himself said explicitly: no way!.
it took quite a while before it finally changed.
same with a frontend managed GUI. even after there was already a third party frontend GUI.
Shouldn’t you keep such data within a password manager? At least to me, using your secrets-file to organize the passwords seems like a really bad abuse. That’s not what the file is meant to do.
In general such information should be kept in a separate documentation. Or at least in the company I work for we do this, and it kinda makes sense to me.
i dont even use a secrets file. its just part of the config. (i dont share my config, so no reason to keep it in a seperate file) a password manager is a horror.
there is no other program changing anything in my home automation, and thats how it should be.
Just so I get this correct: in some, for this discussion irrelevant, interval you change the IPs or passwords of your cameras (I assume you do this manually by browsing to the cameras web interface, one by one), and therefore have to adjust the configuration in Home Assistant to keep the cameras working? I use ZoneMinder for my cameras. And if I were to change passwords / IPs, I’d have to change them there one by one as well. And I guess pretty much any other recording-software as well. So the possibility of doing this in a text file seems to be more like a historical convenience, cause by a lack of UI configuration. I’d argue that if it just was configurable via UI from the beginning, then you wouldn’t even miss the possibilities yaml gave to you
i wasnt talking about changing passwords, but looking them up. for example when i want to use them in a different program.
I image it to be totally horrible to manage 600 entities in yaml. I’d much more prefer sortable tables with options to filter so I can quickly find what I’m looking for. The devices dashboard for devices coming from UI integrations for example is great to get an overview of devices.
its not horrible at all if you organise it in the correct way.
its the same with my automations (way over 500) if you dont organise it correctly it is a horror, but if you organise it correct then its a bless.
and the advantage from yaml is that i can organise it MY WAY. any other way of organising chosen by someone else is always worse. because it doesnt comply to my way of thinking.
the devices dashboard is exactly a good example for that. its useless!
if i am looking for temp sensors (in mysensors, foscam cams, broadlink devices, etc.) then i really have no use for looking at cams, broadlinks, etc.
i really cant think of any reason why i would want sensors organised by the device they come from. same with actuators.
And even if they did, Home Assistant does progress
i wouldnt say it progresses, it evolves. and thats a complete other thing.
personally i have chosen HA for certain reasons years ago. if HA would have been what it is right now, i would never have chosen it.
i hardly come to the forum anymore, and wouldnt have reacted when i wouldnt have seen it on FB.
but when i then come accross these kind of things, i understand why others feel what i already feel for a long time.
i am busy stepping away from HA for over a year now, but i guess you can understand that with so much entities and so much automations its not that easy done. (dont want to lose my WAF by breaking everything)
4 Likes
Because yaml is human readable, human editable and it is also readable for machines. Getting away from it will it make harder tasks like:
- Trace down when a change happened
- Make git diffs and understand what happened
- Back to a previous version of a particular yaml file. Everything is now in the same file, and going back to a previous version means rolling back everything
And those are just 3 things that comes out from my mind, if I think about it I will find more, I promise you.
9 Likes
I understand the Reason to take this way. A lot of user there are not geek don t use hass because need to modify text file. But a good compromise will be to could modify configuration in yaml directly in the UI as same way than Lovelace yaml edit but with a better editor 
. what do you think of that?
1 Like
What are you talking about? I can copy paste that and all that I have to do is add my credentials on my secret file, which is clearly declared on this same piece of yaml you pasted. This answer in favour of the UI doesn’t make sense. I don’t want to manually setup things on the UI every time I upgrade my hardware
3 Likes
There comes a time in any project where everyone will have had their say but ultimately a decision has been made. At that point the whole team HAS to accept the decision and align with it. In the years to come, if it doesn’t end up as planned, you can have the smug moment of thinking “I told you so” but it doesn’t change the inevitable. To constantly spend a huge amount of time and effort telling everyone why the decision is wrong will just cause bad feeling in that team. We are the Home Assistant team and the decisions have been made and there’s at least be some effort to explain those decisions.
We’ve all seen comments from developers saying how demoralising it can be to have their hard work slated for not conforming to an individuals desires. Requesting changes is fine but trying to change the way in which they want to work isn’t fair. Surely we need to get on board with what is happening? We’re massively lucky to have Home Assistant. Remember trying to write python scripts on RPi’s connected to various components and then finding Cayene and thinking it was amazing? I can’t live without Home Assistant but if you can’t live WITH it, you have to find an alternative solution.
6 Likes
I think this is a bad decision. It is OK to go with UI, but UI will never replace YAML (/JSON) files. UI will always leg behind the capabilities the user wants / need, and as the requirements increases, UI is very difficult to maintain and develop.
I assume that most of HA users are DIY guys and have the capability to handle configuration via YAML files.
I really hope that HA will reconsider and keep the YAML configuration for all integrations and will not encourage going in one path.
5 Likes
it should never touch the configuration file?
i dont want to break your bubble, but all the files in the .storage directory are nothing more and nothing less then configuration files!!
they are filled by the system and even in the blog its stated that that should be saved.
those configuration files could be in yaml instead of in json (and not hidden) and it would be identical.
but i personally agree with you. the configuration should never be touched by the system. that is exactly why i dislike the fact that its done through GUI.
i add my new integrations in yaml in appdaemon. doesnt require a restart either.
and like i stated before, saving it in a hidden json file doesnt change opposed to saving it in a visible yaml file.
Oh yes, manually adding screenshots or copy-pasting stuff on every change you made is way better than just having everything easily readable from just the configuration. What a bland argument.
4 Likes
I think that answers your question, as best as I understand it anyway
As a hater of YAML in the beginning, after getting used to it - it seemed ok for me.
Since some time, I’ve been migrating all my stuff to new config flow solution and I really don’t want to go back to the times of restarts after every change.
Things are changing, but what is generating the frustration for newcomers is YAML for sure.
I can’t wait to see where it will get back in future tho.
You and @aidbish are the kind of people that, at the minimum requirement of agreement and debate say: “It’s my way, or the road”, “take it or leave it”, and it is not like that.
Home assistant is big because it’s community, and they should listen to the community that made the project grow. Forking a project and divide the community just because people like you don’t want to have some discussion is absurd.
4 Likes
My point of view is: checking whether it gets the job done. If it does, the way is fine/irrelevant to me. (though I can’t see the integration list grow even more from the way it is now, to a list with 1574 integrations in the future…surely that’s all easily solved when the need arises)
UI config is immediate, and requires no more restarts. Which is an absolute blessing. Please do keep that, and expand, as much as possible.
Where issues arise is when UI config limits the functionality we can have with the same integration in yaml (Philips Hue can only set allow_groups, and allow_unreachable in yaml, so we need both UI and Yaml config). Or forces us to use sensor.names with our gps data in the names (and yes, we can change that in the editor, clicking here and there a couple of times)
Or even worse, when (because of the) modernization of the integration (it) stops offering the functionality we had before (Asuswrt seems one of these, where no more consider_home, track_new_devices, or interval_seconds are allowed, from the days this was still a device_tracker…)btw, only noticed that because I had to replace the Nmap tracker which all of a sudden is broken, without being acknowledged by the dev team, or by any known breaking change…
Seems that in modernizing integrations, necessary (to some) functionality is thrown overboard, because (most) people wont need it. I find that disappointing tbh.
Also, I do see a lot of people contribute their free and unpaid time to the development of this beta software, and quite often they are simply ‘told’ their request/suggestion/experience is against guidelines or what have you.
Please listen to the folks that help build this software in their way, spending many fee (pun intended) hours in tinkering, and trying to follow guidelines on posting Issues on GitHub (which when done incorrectly is not always met with the same courtesy…) Think end-users are of prime concern. What/who else make a product for?
So, I’d like to repost that its not ‘us’ simple folk that should uncomplainingly accept free software that comes with no guarantee whatsoever because it’s open software, but that its ‘us’ simple folk that help making this great product even better.
Having said all that, I’ve just updated to 108.4, and my HA setup has never been so quick and multifunctional. I do mourn the further demise of custom-ui which is still most dearly missed, but other than that. Hurray for HA!
further reading: