Yes, I understand that I have to run my own containers for things that work “automatically” as HA add-ons with Supervised or HAOS. My problem is that I don’t know how to do that.
Is there any documentation that can help me get, for example, “Home Assistant Google Drive Backup” and “TellStick” up and running in their own containers and working together with Home Assistant Container?
Google drive backup is supported in the regular backup system, no addon needed. And tellstick is an integration, not an addon. So neither of those things really pertain to this deprecation.
Then move to HAOS
Ah I see, that’s a deprecated addon and the code was deprecated 5 years ago.
So, what’s your reasoning for running supervised?
Yes, it’s old, but it still works flawlessly. I use it every day to control old Waveman 433.92 MHz switches and dimmers with a classic TellStick USB device. These switches are mounted in the walls of my building, so it’s quite a big undertaking to replace them all.
If anyone can suggest an alternative, I’m absolutely open to switching to something from this millennium.
But what about the Home Assistant Google Drive Backup add-on? It’s an add-on I use.
Maybe this integration does the job?
Fair - it works dont touch it.
BUT.
Tellstick is supported as an integration in HAOS. AND
Goog Drive backup is supported as an Addon in HAOS. (HAOS does addons)
So your system should be support-able on HAOS. Yes, sounds like you’ll have to migrate the tellstick config over from the old addon to the new integration - but…
If you go container you will be responsible for looking up those containers that provide that, then maintaining them. Its not just about someone show me how, what happens on day 2?
HAOS will be the closest to what you have now, and you can literally migrate to it by backing up and restoring into a haos install? Why not?
See this post:
I have created a new thread regarding my performance problems with HAOS. If anyone has any suggestions, please give them!
I just finished successfully my migration from Supervised HA to Container HA.
I prepared some example with docker compose (with HA, mariadb, mqtt mosquitto, zigbe2mqtt, wmbusmeters, vscode, tasmoadmin, hikvision doorbell), maybe someone will find it useful:
I also managed to integrate mariadb backups with Google Drive using just systemctl and gdrive (if someone will be interested just comment)
Would that include the addons (such as Node red, zigbee2mqtt, duckdns etc…) that im running? or i would need to manually install and configure each one of those? because that would be a huge downgrade as opposed to 1 click install and some yaml
and what about USB passthrough, for example for my zigbee stick?
You would need to manually install and configure them. If you’re running Docker and docker compose, then it’s as simple as adding a new section to your docker compose file, configuring the container, and then starting it. You mentioned you’re already running other services on the host, so maybe you’re doing this already?
USB passthrough is simple as well.
You don’t even need devices when you use privileged as per HA docs.
I’ve been using supervised installation for a few years but due to the above, decided to go to this HASSIO installation on a raspberry pi 4 - it appears that I’ve got most things working apart from 1wire devices connected directly to the raspberry pi gpio4. I have done many searches and tried various suggestions but I am unable to enable 1wire devices on the host computer like I used to with raspi-config - has anyone managed to get this working? If so, how? - I’ve tried putting the disk with the operating system in a Linux machine to access the files but could not find a boot partition, but I did find a hassos-overlay I added dtoverlay=w1-gpio to a folder called boot, but no joy - thanks
I don’t know what your 1-wire device does, but one option would be to connect it to an ESP and integrate it with HA via ESPHome.
Yeah that is one of the downside to Home Assistant OS that you are meant to workaround by moving your 1-wire setup to ESPHome or to a different computer (e.g. a separate Raspberry Pi or Raspberry Pi Zero, and preferably one that is dedicated for just the 1-wire hub solution.
One of the point is that you should not have low-level access to the local hardware from Home Assistant OS, and that includes the GPIO.
So suggest first check out ESPHome for 1-wire and then maybe look at buying a dedicated Raspberry Pi Zero 2 W to use as a 1-wire hub if do not like ESPHome for some reason. There are loads of guides online how to an ESPHome solution for 1-wire. Vegin by reading:
And
If you prefer the idea of using a Raspberry Pi as a dedicated 1-Wire hub then check out owserver (OWFS server). The owserver is a generic backend, it can be remote, and shared by several front ends. This is the recommended way of accessing your 1-Wire bus. Search for ”owserver AND home assistant” to find guides.
Benefit is that both of those solutions are more flexible and can be placed anywhere.
So, I’ll just add my disappointment here. I’m one of those people who are Linux admin types and wanted to have a more complex setup (but still have all the management benefits of supervisor).
I know my setup is not ‘supported’ (because I run custom things along side it). I also am just getting notification of this because I don’t update monthly (because I know things may break and so I spread out the pain). So, the hitch hikers guide reference rings very true.
But being told that the debian packages are going to be killed because you can’t just tell people ‘no’ to support sucks (while still building the software and not actively deleting information / documentation). Why can’t you just straight up say ‘community only support’ and keep the docs and packages.
Im very fearful this project is moving towards the android style closed ‘open source’ ecosystem… It’s open source but we are going to actively make it harder to use if you dare do it the non appliance way (I’m not going to manage all the damn addins in docker compose… I use supervisor specifically to NOT do that).
This sucks… I’ll keep using supervisor because it’s what fits my needs and hope someone picks up the debian packages. I’m very worried the debian upgrade is being setup as a hard break.
This has been repeated 100s of times. And people don’t read back on it.
People keep repeating the same misconceptions. No one is stopping you from using what you like, it’s just up to yourself to maintain it hence the warning in your install. This was already the case for many, without them realizing, it has just been made extra clear now.
People with unsupported systems request a disproportionate amount of support time from Home Assistant even saying “that’s not supported” and closing Git issues is wasting everyone’s time.
Nothing is happening with the Open Source of this project. Nothing can happen with the Open Source of this project. See how the Open Home Foundation has been setup. It cannot be sold to a third party or made Closed Source in any way.
So who is going to maintain the Debian package? I get that I’m supporting my own install I always have been.
But when you stop publishing the Debian installer and do not update it for Trixie that’s a very different place then just saying you’re not supported. That’s actively breaking my ability to do a supervised install. Unless, someone has stated somewhere that the Debian / supervisor install package is going to continue to be maintained. I have not seen that stated openly anywhere what is going to happen to that repo.
I’m specifically talking about this repo: GitHub - home-assistant/supervised-installer: Installer for a generic Linux system
Are you stating that I should fork this repo and now I need to maintain this package set?
I’m 1000% ok with no support. I’m a big boy and can maintain my systems and use developer docs to do so. But I feel like it’s talking out of both sides of your mouth to say that I can keep doing it, but you’re actively taking away the tools to do so (or at least in no way providing any guidance on what’s going to happen to those tools).
I’m assuming they’re gone just rot on the vine and at some point be broken and then supervised installs will effectively be not possible (without a silly amount of manual work).
