I am in the process of developing addons for this which would work for HAOS. I already have a VPN addon which provides DMZ and isolated networks. The next addon I am looking developing (or extending an existing one) would be for IOT wireless radio managment via iptables, hostapd, wpa_supplicant, dhcpd, and dnsmasq.
In that scenario, you need an addon with NET_ADMIN capabilities and you can manage that stuff from userland via docker container.
It seems to work fine and just the way I want it toâŚ
Updates to HA also work fine.
The HA service (port 8123) listens on any address, so although I never access HA from the sensor vlan, I guess that would be possible.
I guess Iâll find out when it breaks for some reasonâŚ
Ok, after reading the latest I feel better about core. I personally like it as I can hack the python code directly to see what is happening and troubleshoot my own problems. This allows me to use the opower integration to handle both of my home energy meters that are on a single account, and also allowed me to figure out why the octoprint extension was spamming my systemâs logs after an upgrade (change in logging blows it up if the octoprint server is disconnected).
Plus itâs a lot more fun and exercises my mind. Learned a lot about python and environments and wheels with HA, will continue to do so into the future.
Long live Core!
Ditto, Iâve been running Core multi-homed since about 0.4xx builds.
I found a lot of issues (early on at least), where HA not being in the IoT VLAN breaks stuff. So mine is both inside and outside, with appropriate F/W rules in place.
Maybe its better these days, but Iâve had no reason to change the setup.
Iâm running supervised on an OrangePi4, in an unsupported fashion - the only way I could make it work. The only drawback Iâve seen is I have to dismiss a warning message from time to time, which states that it is unsupported. Itâs not clear to me if I will be able to do this in the future (after the deprecation date) or not.
I keep seeing responses that say âall theyâre doing is dropping documentation and official supportâ, but the above two quoted lines mention code and release artifacts. I canât tell if the reference to code/artifacts is just âin generalâ or if this is implying code and artifacts for supervised will cease to be published after deprecation. Can you clarify this?
Thanks
Keith
I donât quite understand what you are saying here. If you want to develop HA without any involvement from Nabu Casa or other commercial companies, you can. Fork it. Change whatever you want to change. Publish the code. Let anyone else who wants to change stuff do that. Integrate their changes into yours. You can do all this today. Your heaven is here on earth.
I use a optical usb reader together with EDL21. Is that supported in HaOS? Right now running supervised. Thanks
Itâs very confusing for many people. The point is: it works. It will probably continue to work. BUt itâs not supported. Meaning that if you do some stuff in the host and it doesnât work together with HA like you want it to, you canât file an issue in the HA Github to have people work on a solution. Youâll get to hear that you will have to fix it yourself. If such a thing had turned up in the past (which I understand it hasnât), you would have gotten a reply along the same lines. Because it wasnât supported before.
The weird thing about Supervised, to me, is that it was a supported install method, but it seemed to me that all the reasons to install it immediately invalidated the support. I would be interested to hear from Supervised users that run a completely vanilla Debian with no other processes running except what is needed for the OS and HA. Because I understand that that is the only supported method for Supervisor. But I donât know what that really offers over HAOS or Container.
I did until beginning last year. Zotac mini pc with Atom 64bit processor and max 2 Gb ram. Did not support UEFI, so could not install HA OS. Moved it over to a N100 under proxmox jan '24.
yeah, it is!
If you click impactâs link, then you will see the requirements are among others:
No additional software, outside of the Home Assistant ecosystem, is installed.
Ah yeah, that sounds logical. Non-uefi hardware is getting more and more rare though.
I run a supported version of HA supervised. Iâm gonna swap to haos whenever I feel like it. Probably sometime in the next few years
A general summary of other comments in this thread for âwhy vanilla debian with supervisedâ:
IMO the general announcement could add a little more information:
It seems to me that âjust documentation and supportâ is not just documentation and support. When dropping a CPU architecture it generally means maintainers plan to stop building base docker images in those CPU architectures.
I gave this feedback in the original âfeedback for dropping supportâ but it seems neither the original support thread was updated nor this announcement thread includes this clarification.
Dropping specific artifacts from being built/provided is more than documentation and support. It would be nice to know if the base images would continue or not; as a developer of addons myself.
The thing about updating addons the way you mention is that it lacks integration!
The current way, addons update via the HA interface. All things in one place. Same for the addon âmarketplaceâ, itâs accessible through the HA interface.
The mentions of running a command or using dockge are workarounds, not solutions.
They arenât workarounds if youâre running container installation. Thatâs how you update containers.
Here also to express my frustration with this. I have a larger server set up and container and VM lifecycle is managed with tools (getting into Ansible. Itâs fun!) and Supervised Install allowed me to have this and also use and Add-Ons/Ingress access to them.
This feels like an attempt to close the ecosystem up, which IMHO is not a good look for homeassistant.
i run supervised on my NUC for so many years, i do not really know why I choose this method, but once in a while i have to update my debian in order to keep with the HA compatibility. pretty happy with it and i do not have any issue in switching to HA OS if it works out of the box on my NUC.
is it possible to use PXE to install HA OS? i have my netboot.xyz setup connected to my pfsense dhcp that allows me to install easily a classic debian, or ubuntu, or whatever iso i want, can it also do it or i need to install through a liveusbkey ?
also, i do not see what i would loose by switching to HA OS compared to Supervised. Is it only the ability to ssh to the machine and apt install some custom packages?
Normally with PXE boot you have an installer built within a live distro of Linux packaged within squashfs. Linux is initially booted via memdisk.
Home Assistant OS doesnât come with any installers. Itâs just a raw image that you dd/write to an sdcard or drive (even on x86 machines).
To install via PXE I would:
To ensure integrity I would checksum the image before writing; and then checksum the disk after writing.
Other than above post what you would lose is any other functionality youâre using your NUC which isnât covered by home assistant addons. It would also have a little less security because from what I read in docs you get passwordless boot; meaning hooked up to a monitor you have direct access to HA without a login. I donât think you get SSH out of the box but you can modify the image with a loopback mount and chroot (create a local account and add ssh keys). That being said thereâs a common theme where if you do anything to HAOS internals other than just writing the image to disk you are no longer supported. So take my advice with a grain of salt. Thereâs SSH addons but it gives you ssh into a container which isnât useful when I tried it.
In my case, I would need to modify HAOS to get it to work on my SBC (drivers) and so I am just going to keep running supervised. Thereâs no supported path forward for my hardware (OrangePi 5 plus 8-core 32GB RAM aarch64).
