“Hacky install methods” like… installing an official package from a package repository like every other piece of Linux software?
Bad title.
This is really disappointing. My HA Supervised install was running fine last year on an old laptop and unsupported distro. In order to move to a supported installation of HA I purchased a very efficient fanless laptop specifically sized to run Debian 12 and HA Supervised. This install has been rock solid and the opposite of “Hacky” (despite Howtogeek’s clickbait title), and I expected it to easily last 5+ years. It’s been 8 months.
Of course Home Assistant developers need to sometimes EOL specific configurations and dropping 32bit hardware support was overdue (the last 32 bit Raspberry Pi was released over 10 years ago), but 6 months is an absurdly short amount of notice to give users of supported configurations on supported hardware that they’re going to be forced to migrate to something else.
You bought a laptop to run home assistant?? Why? Why not just a random thinclient for ~50€?
Different people have different use cases. A thin client doesn’t work for video object recognition, nor does it come with a keyboard, display, SSD or battery backup.
They usually do come with SSD. If you need object recognition, there are ones with an PCIe slot for a gpu.
But I am honestly not sure why you need a keyboard and display on a server.
You can continue to used supervised, the difference is that it’s no longer officially supported. TBH, almost all supervised installations weren’t officially supported anymore, so nothing big changes
I’m aware it can still be run, but as I stated in my previous comment my platform and installation were specifically purchased and configured to be fully supported and I would like to keep it that way.
6 months is not “absurdly” short considering it won’t suddenly stop working. It’s an open source project, 6 months is fairly reasonable for such circumstances.
“Hacky?” Bullshit.
Fuck anyone who just wants to run a lightweight service on a home server, right?
If you read the Home Assistant official announcement, it basically says all the different methods were confusing to new people so they will remove them from end user support documentation and won’t take support questions from people using these methods.
However, outside the deprecation of 32bit OSs (which they point out a large portion are on 64bit capable hardware), they are still going to be documenting the other methods in the developer documentation.
I honestly think this is the right move. Their time is being wasted by confusing new users, and supporting 32 bit OSs is literally preventing the development of new functionality. If you want to use a Python environment instead of docker, the developer documentation is there to support advanced users.
I did read it, thanks. It’s not clear from their statement that they would maintain any sort of documentation for such methods.
It says
As these installation methods are used for the development of Home Assistant, it will still be technically possible to update them. We still would recommend migrating to a supported method, but that’s your choice.
And then towards the end:
Will the developer documentation on these things remain?
Yes, those will remain. The developer documentation for running Home Assistant’s Core Python application directly in a Python virtual environment will remain. This is how we develop. This proposal is about removing end-user documentation and support.How I read it is that these methods are actively used for development so will still be maintained and updated, including developer documentation because developers will continue to need to use these methods.
There’s no need for hostility, your characterization of what is happening does not reflect reality.
I stopped upgrading about 6 months ago and am very happy with the decision. I had to say goodbye to some cloud services but it’s saved me a ton of time and hassle.
I stopped upgrading about 4 years ago. Kinda terrified to update at this point. Everything just works the way it is so I don’t dare touch it anymore.
Yeah the thought of ceasing updates scares me for that reason. Better to just stay up to date imo.
Once I weighed rhe cloud services Id lose vs the amount of stuff that breaks in upgrades (which I often don’t realize until months later), I realized that I was losing a lot more from upgrading than not upgrading.
Meh, I guess I will need to find a new way to install Home Assistant on my Orange Pi.
The instructions I found apparently uses the supervised version even if it’s running in docker.
It’s been a while since I looked into installing/reinstalling HA but AFAIK using anything else than a Raspberry Pi seems discouraged, which is… discouraging.
It’s been a while since I looked into installing/reinstalling HA but AFAIK using anything else than a Raspberry Pi seems discouraged, which is… discouraging.
I don’t think that’s the case, the docker containers are still going to be officially supported, and you can run those on any hardware.
I tried on docker but couldn’t get the USB Z wave to pass through. Simpler for me to let it live on the pi (until the SD card dies and I forget how any of the HA config works and have to do it all again)
If you want a second attempt, this might help.
To get USB devices working inside a container, you need to map the device into the container, which can be tricky—especially if you’re running rootless containers.
If you’re on Linux and want to avoid complicated setups with user namespaces, groups, or messing with udev rules, the easiest way to start is by manually recreating the device node inside a folder you control (like where your config is stored) using mknod.
For example, if your USB device is /dev/ttyUSB0:
-
Run ls -l /dev/ttyUSB0 You should see output like: crw-rw---- 1 root dialout 188, 0 Jan 1 1970 /dev/ttyUSB0
-
Note the major (188) and minor (0) numbers.
-
Change directory to the folder where you want to create the “clone” device node, then run: sudo mknod -m 666 ttyUSB0 c 188 0 (Use the major/minor numbers from your device — they differ by device.) This will create a device readable and writeable by anyone on the system so perhaps consider changing the mode from 666 to 660 and/or chown the file afterwards to your user and group. As I said, this is HACKY and not a secure solution.
You will now have a device file you can then pass into your container with the Docker/PODMAN option: –device /path/to/your/folder/ttyUSB0:/dev/ttyUSB0
I realize this is a pretty hacky and insecure workaround—feel free to downvote or ignore if you want something cleaner. But it’s a quick way to get your USB device accessible inside the container to get started. Later on, you can look into proper handling with udev or other methods if security is important.
If you use Windows, you are on your own unfortunately, I do not have experience with podman/docker in Windows environments.
-
Pi 4 + USB-connected SSD with Home Assistant OS is the best way to run HA for the vast majority of people.
If you want to run other services beside HA and Add-Ons, you should be comfortable picking your own orchestration method and hardware.
That’s a good point - I think I have a USB SSD case somewhere
@pedz @cm0002 there are pre-build images for a lot of SBCs offered by #armbian .
Link for HomeAssistant:
https://forum.armbian.com/topic/33245-armbian-with-preinstalled-home-assistant-supervised
My Odroid N2/N2+ is listed under "Tested on"😁
Link to all apps:
https://github.com/armbian/distribution/tree/master
Do they still support the OVA installation method?
