That’ll break someone’s ability to roll back an update for sure.
2 Likes
Any idea if that fact was documented anywhere to let people know there will be a problem rolling back? And more importantly how to fix it? OR did you just figure that out yourself
That is what backups are for!
1 Like
Right, but someone’s going to definitely post about it.
1 Like
Cheers @Silicon_Avatar I haven’t read the release notes for 0.110 at all so thanks for the heads up. For now I won’t be moving forward at all.
This project is moving in a bad direction for my purposes so I’m in the process of setting up testing suitable candidates for a long term solution for my needs. Once that is setup I may test some new releases as well. I’ll still be following whats going on here but atm it seems to me that problems being introduced in new releases far outway any benefit for my needs.
1 Like
This migration towards a UI-centric configuration approach creates problems that we didn’t have before, and forecloses solutions for those problems. And I’m really surprised that Nabu Casa would head down this architectural evolutionary path.
From the Nabu Casa perspective, you’d think that part of what informs architectural decisions is if they would help or hinder future revenue opportunities. Sure, having a UI-centric vision, and the infrastructure around to support that is great if the customer segment you want to address is ever only individual end-user retail customers. But this selects the customer segment that’s the most costly to market to and acquire - each unit is an individual sale/transaction. And your support load goes up linearly with the number of customers/users, because you have unique, individual customer relationships with each of them.
What you’d like to enable a wholesale distribution model, where Nabu Casa doesn’t have to manage individual customer relationships, but can work though channel partners that could manage groups of those customer relationships. They provide end-user support, and Nabu Casa supports distribution partners.
So, how do you support a million Home Assistant installations remotely, where these things are embedded appliances inside a larger “solution?” Maybe your distribution partners are home builders or AV/Home Theater system vendors or similar. They want to install and somehow manage appliances for these individual users.
The way this becomes successful is to get increasing leverage at scale. This means support/maintenance per instance must be more and more efficient as the number of instances increase. Your business sucks if you have to grow your support infrastructure at the same rate as you grow your customer base.
Enabling this scalability means less human touch and more automation. And that means you really should have abstracted the interface to the persistent state in Home Assistant so that it can be exposed and invoked by APIs. And you write your fancy retail GUI to that interface, and you build externally callable APIs for that interface. And you could imagine a local file-based versions (like in YAML or JSON) that could also be used to invoke those APIs to install/confirm the persistent state.
This is infrastructure as code as has been discussed previously in this thread.
From my point of view, it’s never been about YAML vs. JSON - that’s just a representation choice. It’s the fact that you did have a documented/relatively stable interface specified as a data structure, and implemented using YAML as the representation. It could have been JSON - they’re essentially equivalent. The JSON we have now in .storage is opaque and not a documented interface. You screw with that at your own peril.
The nightmare scenario is when you are really successful and you have 1 million devices in the fields, and you want to push out an upgrade – but “stuff” needs to be done to all 1 million of these. Or you have a remote support problem, where all the users with some commonality (like using some integration with an external thing/service) break and you have to push a configuration change to the 100,000 users with that problem. Having an API and mechanistic interface to the configuration allows you to respond to this sort of problem.
Sure, this isn’t the problem that people reading this discussion have. I would imagine that the problem of supporting a million Home Assistant appliances is a problem some would like to have… I’d think this scenario should be part of some longer term strategy. This approach is hardly new or novel…
I used to have to worry about this in my $DAYJOB when I was CTO for a large VoIP OTT operator, and by the time I left, we had 2,500,000 residential VoIP lines in service. And we learned how the user population transitions from “geek” to “early adopter” to “value-seeker”. And when your product is on the shelf at WalMart… usability and customer education is a whole other problem. I had newfound respect for Dell that innovated different colored connectors on their PCs, along with cable ends with matching colors and similar… You cannot believe the support calls I would listen in on… No, no, plug the YELLOW cable into the YELLOW hole and the other end into YOUR ROUTER. No, don’t plug your phone in the Ethernet jack; even if it fits if you push hard enough…
And so what I learned is that at some point, for a complex product/service, you can only make it so simple and to continue to expand. You (or someone) needs to figure out how to educate the potential users enough on why they need this thing to solve a problem they didn’t really know they had. And that education can be expensive – you need to find a way to get more leverage to reduce support requirements and figure a way to bring to bear both automation via APIs and growing distribution with partners that would also want tooling. The simple point-and-shoot UI will get you far enough to have a really large problem, and then you find yourself painted into a corner because you can’t have enough keyboards, mice, screens and people to drive them.
Maybe no one but Nabu Casa need worry about these problems. Maybe a few others think about how to add value by supplying an embedded solution in place of Crestron and other high-end automation/entertainment alternatives. If you can build an appliance component that is Home Assistant that’s more cost effective for a VAR to support for his end-users, you’ll get the “design-win” and integrated into those systems.
I dunno, this is probably thinking too big for an open ecosystem solution. Amazon, Google, etc. have fairly constrained environment they operate with by default, existing customer relationships and an existing ecosystem to expand from. Home Assistant/Nabu Casa comes at this from the other direction and is trying to solve a harder problem. Do you think this scales up far enough to take market share from some of the existing companies in this space? Go big, or go home?
18 Likes
I just tried 0.110 on dev environment… Seriously guys, this is not funny anymore. I lost my ability to configure ONVIF via Yaml files. I’m not going that way and will stick with 0.109
8 Likes
UI integration should be also more matured allowing a control over integration after first time install. Today a lot of integrations don’t alliw perform changes other way than removing integration and setting things up again. Such limited possibilities are not acceptable.
10 Likes
That is in train.
This, and very much this!
I’m wondering if it’s worth continuing with Home Assistant if my configuration API is disappearing…
6 Likes
Keep up the great work.
I like the new front end and cleaner yaml files.
Helpers are awesome.
Now with more tasmota auto discovery options for sensors and switches it makes things even faster to integrate new devices.
1 Like
For those of you who are frustrated by this decision:
It seems a bit hard to change the decision that has been made and the owners of the repository can (unfortunately) take such decision. There’s a bit of evil on the good, and a bit of good in the evil.
Like many of you, I have also expressed my opinion on why I do not think this is the right decision from an Open Source perspective. Although many of you have articulated the reasons for which is a bad decision much better here.
However, my question would be: when the decision is implemented, what can we do? I have some ideas and I will be sharing some of them soon both focused on users and developers. I would love to read some of your ideas too.
10 Likes
From your twatter thread
Personally, I’ve taken down 2 published components, removed HACS support for one of them and cancelled other plans for components that I was building for home_assistant and their HACS support.
Childish? Yes
And what have you got against HACS?
2 Likes
Apparently HACS is an official custom integration. 
It’s not.
My first idea was to completely remove the integrations, which I did consider and did with some of them.
I finally decided that having to copy the code was better than install it from a UI. It’s kind of the opposite of what was decided on this blog post to force people to use UI for official integrations.
Thanks for sharing your opinion. You can read my previous message on why I want things to be installed only via code rather than via UI only.
(Actually, I would prefer both, but then the official integrations only offer one of them).
Removing your custom components from HACS is unrelated to this issue. Anything on HACS is installable via command line.
Also custom components do not have to be configurable by UI. They can stick to yaml. They won’t ever make it to core, but that is not the point.
To be very clear, this thread is about the deprecation of core integrations to be configured by yaml.
1 Like
It was not me who brought it up and I agree. Let’s focus on Home-Assistant to not support YAML on new integrations.
Yes you did, you said you were removing HACS support as protest about partial yaml deprecation.
I linked Twitter with my opinion. 99% on that tweet is about why I think deprecating YAML on official integrations is a bad decision and powered by NabuCasa interests. From that tweet, you cherry picked the part about me deprecating HACS and, instead of replying on Twitter, copied that fragment to this post.
In any case, can we focus on the topic at hand around the deprecation of YAML for new integrations? (and probably in the past ones at some point, since you cannot also make changes to the YAML config and if the spec changes, YAML configuration would no longer work).
1 Like