You’ve been around in this thread for over a 1000 comments. You’re ignoring all the things that have been said and just keep repeating your claim about an evil plan, completely ignoring all our remarks about our work load and burn out. Even going as far as saying it’s silliness. We’re real people, please treat us like that.
All I am asking @balloob is that the conditions for the Debian 10 installation are softened up so it becomes usefull.
I should be able to install sshd on it so I can login remotely to administrate it.
I should be able to install samba and reuse the machine as a fileshare.
I am OK that HA anything installed in Docker is limited to Home Assistant and Addons managed by the supervisor. That is reasonable.
And I would like to have a gentlemans word that you will not deliberately code the supervisor so it will not run or upgrade just because the host OS is a Debian derivative of the same generation. That is I ask. And it should not cost you a minute extra work.
I do both of these things with debian & supervised. No one is stopping you and no red text
I installed Realvnc with no problem and no red text.
This is part of the definition of Home Assistant Supervised in ADR-0014:
Add checks to Home Assistant to warn (but not forbid) when not all requirements are met for this installation method.
We’ll not going out of our way to break things on purpose. Software that we depend on will change over time, and so requirements will also evolve over time as we adopt those new versions.
We are moving in circles and getting nowhere. It is ADR-0014 that I do not accept.
It says that I cannot install any packages. There goes secure shell remote login and Samba
And it says the computer must be dedicated to Home Assistant.
With these limitations any reason to install Supervised on Debian is gone. You may as well install the Home Assistant operating system. The supervised installation method has no purpose under these conditions. I and others raised it when you created ADR-0014. And the protests continues here. And if you close the discussion then someone will soon start it elsewhere.
So install them. They won’t cause any problem or error.
Yes. I know. I already do. And I want to know I can continue to
You’re making way too much out of this!
That ship has sailed, time to move on
I’ll refer you to my comment from a few days ago because this is becoming painful.
Hi All,
I have to admit I was quite sadden to read this whole thread, I thought this was a platform for enthusiasts yet the enthusiasm seem to have disappeared. I am also running Home Assistant Supervised on a generic debian 10 linux machine and if the way to install it changes then I will adapt. I agree with Sparkydave there.
So I’d like to take this as an opportunity to say thank you to Frenck, Paulus and the rest of the team as well as all others who have created scripts, collaborated and created wiki to help me. Please remember there is always an opportunity to learn something new and to improve things.
Love!
M
Wow, just WOW! I am a new user to HA, but seriously thinking I made such a bad mistake to (try to) use HA. This thread shows everything that is wrong with HA. Going on since May! There is clearly so much discontent here, it can hardly be called a community. As a new user, I find it SUPER frustrating to try to figure out all the possible combinations of docker/venv/VM/Supervisor/linux/debian/ubuntu/…
No clear installation documentation, no upfront support matrix, no dev feedback. Not really what I signed up for.
I honestly don’t care how I install HA, I just want it to run on my platform (RPi 4) efficiently and most importantly reliably and supportable. I want to concentrate on building stuff on top of HA, without having to worry about installation/updates/support - or lack of it.
It’s really not that hard. Go to https://www.home-assistant.io/, click on “Getting Started”, scroll down to Installation and follow the (rather simple) 9 steps just as it lays out.
Is that not clear documentation?
As for “no upfront support matrix”, on the Getting Started page there’s links for:
For advanced users (or if you don’t have a device that is supported by this guide), check out our alternative installation methods.
If you click on the first link, you can see the 11 devices supported for the basic installation method. An additional 5 supported VM images, and instructions on how to install it as a VM (these instructions don’t cover all possible contingencies, but as this is an “advanced” install method, the user is expected to have some assumed knowledge).
The second link has additional hardware requirements and performance expectations.
The rest of the stuff (“docker/venv/VM/Supervisor/linux/debian/ubuntu/”) probably isnt for you if you’re just looking to run it on a Pi and don’t understand what the other options are. Those are considered “advanced” methods, and again assume some existing level of knowledge of the user. However the community forum has plenty of threads to read through to get an idea of what each ones is and how it works.
There are additional community guides available for these install methods, including one that has a nice matrix of what you get/loose with each install method.
Then open source projects might not be the best fit; and one that’s still in a beta phase before a 1.0 release (like HA is) especially.
HA is great software, but if you don’t want to worry about updates I fear that you may not enjoy yourself. HA is on a 3(ish) week release cycle, and while the devs do their best to avoid it, there are typically breaking updates in each and every update. That’s something that’s going to be on you to manage and deal with (with the support of the community, obviously), since there’s no tech support phone number to call if/when it stops working.
HA isnt a “fully mature” software product yet. There is a lot of individual learning and maintenance that the users will have to do themselves. Many new features of HA in the past year have worked to cut down on that but we’re not yet at a 1.0 release for a reason, however home automation is inherently a technically complex venture.
On the contrary. This is the first time I read so much discontent. There is a community of people ready to help and assist. I have tried other solutions out there and Home Assistant is by far the best (subjective view)
Documentation is extensive albeit at times late in catching up with developments, the users are friendly (with the exception of the above exchanges) and the solution works.
I encourage you to read the blog and the vision of the founder it helps understanding what home assistant is for and where it is going.
Not sure what you signed for, I cannot remember having agreed to anything other than gaining new skills, discovering new technologies and having fun!
It is true that this thread is not a great advertisement for HA, but it is not typical.
@Silicon_Avatar - thank you for the very thoughtful response, really appreciate it! I consider myself a power user, I am using docker/python/venv on my day to day job, so I do understand the concepts. I don’t really understand HA yet, I will check the links you mentioned. When I said I don’t want to learn all the inner workings of HA, it is because I don’t want to spend the time in doing that, but concentrate on building on top of it.
To give an very recent example: I was trying to follow this guide to install an add-on (I’d say a pretty basic thing to do). However, there’s no Supervisor panel in my (venv based) direct on rasbian install. Now, to do a simple task, I need to understand what to do (that’s how I came to see this thread), as there is no link to any documentation: “If you installed Home Assistant using any other method then you cannot use add-ons (but you can achieve the same result manually).” - very helpful, I’d like to see a link to how to “achieve the same result manually”.
This is just the latest in a set of issues I ran into and I had a really hard time finding any documentation. It might be me, but trust me, I used dozens (hundreds?) of open source projects. Some are better, some are worse. HA might have been well documented at some point, but given the super messy installation options snafu, I think documentation needs some love.
Meanwhile, I’ll go searching for answers in some other place, but frustrated by having to go through this process every few days.
Understood. That’s definitely the goal! I think at this point in the project, that’s true except when you get into troubleshooting why things don’t work (which can unfortunately be often, depending on the complexity of what you’re trying to achieve).
Thankfully a lot of really great content/information exists on the forum, just be careful when searching that the information isnt too outdated. HA development moves at a fast pace so information can become outdated quickly.
This is the reason most of us don’t recommend blindly following guides online (outside of the official website) or youtube tutorials, since all too often they lead people down the wrong path when things don’t work.
The Community Guides section of the forum is a great place to learn more about the install methods, and has (usually) up-to-date information.
Good example. The short answer would be to install the software/program on the bare metal of your machine or as docker containers if you have the option.
For example I run some non-addon containers in docker with the image obtained from somewhere generic like LinuxServer, some of which (like ombi) have HA integrations to talk to it.
So if, for example, you didnt or couldn’t use the deCONZ addon, you could run the marthoc container (avilable on docker hub), or install it right on your server, and then you could configure HA to talk to it (getting the same end result as running the addon version).
HOWEVER if you run things like this, you loose some addon specific things like ingress. That’s just not available unless you run it as an addon.
What's ingress?
Introduced in 0.92 (?), ingress is a way of accessing the web based configurations, or webpages, hosted by addons. It used to be that the supervisor would let you re-map the addon’s port 80 to a new port, then you would use the new port to access the addon’s web page. For example you’re HomeAssistant interface may be http://My.IP:8123
and the deCONZ config page would be http://My.IP:8951
.
Ingress acts as a nginx proxy server to let those pages be hosted as subdomains. This is great for external access, since you no longer need to forward all those other ports as well in your router. And the ingress pages are protected via your HA authentication, so you can only access them after logging in.
You can acomplish a similar thing running your own nginx proxy server, and their might even be a way to leverage the HA auth system (maybe?), but it would be all manual work you have to do and research. Running supervised HA means ingress is built in and enabled with 1 button press.
One of the main struggles in documentation is the dev cycle. It sounds like an excuse (and pretty much is) but keeping up with all the scattered documentation when things can change very dramatically very quickly is a weak spot here that pretty much all users and devs agree needs some love. All of the documentation is hosted from github though, so every page has an “edit” button. ALL community members are encouraged to use this to submit PRs to fix documentation problems when found.
I hope you can stick with it without too much more frustration, as the platform is super powerful already, and only getting better every 3(ish) weeks.
TBH the community guides are not of major consolation to me. I’m sitting on Ubuntu waiting to migrate to Debian, but waiting for the new installer and documentation about it as teased by Frenck. If I’m going to go through all the work to migrate, I’m going to do it the official-official way…