I am currently running ESX6.7 on a Intel NUC i3 with passtrough configured for 3 devices:
Aeotec Zwave, IR-reader for reading out district and a EU P1-cable for my energymeter.
These are al serial devices so I don’t think that should be a problem? Not sure if it matters if I “connect” them with the /dev/tty device or the /devserial/by-id/xxxxxxx ? I do remember I had some issued by using tty so used by-id… but I guess this is not the came as PCI device ID’s right? For me pssstrough is ot needed for GPU or whataver other devices, USB serial only!
What is the benefit of the USB hub btw still in this case?
Hi Tom,
Yes, this setup works great. I have zero problems. It was trivial to pass through my HUSZB-1 USB device. That’s the only device I need, but it would seem others would work the same. I love this setup. I only average about 4% CPU usage and love the Proxmox setup. I gave the HA VM 4 cores and 4GB ram. It never uses more than 2 though, and usually only about 1.2. I can backup the entire VM in about 30 seconds. I also like the templates you can create. I can crank out a fully installed server or HA VM in just a few clicks. Great for testing and thrashing about. If they decide not to deprecate I will use Supervised, in a Proxmox VM.
the benefit is that you pass it ALL to the VM, so you can then attach anything you want and the VM detects it: for some HW, like external HDD, pass only the port or device id is not enough.
You generally don’t have to worry about ids, find them all etc etc.
But pass usb to serial is not a problem, i did the same for a solar system, just passed the port.
I don’t know on esxi, but proxmox has a limit to 5 usb devices per VM, you have to edit a file to extend it, but then you have to manually edit the VM conf, just for let you know that in case you need more than 5 usb devices. And even in that case, if you pass an USB hub you are fine
Great thanks for the insights!! Really helpful, will still dig around Google to get the details.
Only played around a little with Proxmox running on ESX running on the NUC.
Since there seem to be so many Proxmox gurus here…
I used to run HA on NUC/Proxmox for a while but moved to Ubuntu supervised (oh boy, I hope I got that terminology right ) because I couldn’t get HA to use the Bluetooth.
Is that something that can be done now because I really like it for presence detection?
I am planning on going back to Proxmox. I’m more comfortable with VMs than I am with Linux and at least if I screw up a Linux VM it won’t affect anything else.
Silly question but I’m driving myselft crazy. I installed previous version of supervised and I see several containers running. But going to raspberry-ip-address:8121 is not opening anything. I had HA before running on a docker container and it was working.
@francisp Can I ask you one more question? In this setup (Supervised) where in my debian filesystem I should file the config? The developer tools say Path to configuration.yaml: /config
But I don’t have that folder on my root directory so I’m assuming it must be somewhere else.
@balloob and @frenck thanks for keeping that install method going. It provides the greatest flexibility and we truly appreciate your extra effort it takes in keeping Supervised around. Best news I heard all day… stay safe folks!
Sorry i confused, i used a raspberry pi 3 b+ with raspbian light version, And i have many separately services on it,so i used hassio generic installation because i dont like to overkill to have one raspberry for only one service, And now i see that the installation stopped support is there any way to install my hassio via docker such the previous installation or something else?
I am using Hass.io (Supervised) on Docker now for over a year on my x86_64 Ubuntu machine. I am very comfortable with it and it’s working like a charm!
Updating, installing addons etc. is super easy. Yes I can understand that one person is not enough, but supporting generic Linux with Docker I think is a pretty valuable feature especially for people like me running several webservices on one machine besides HA. Also regarding that raspis can run Docker for quite a time now… I think there are a lot of people out there like me using their HA-machine also for other stuff. Yes, VM may be an alternative but as I see it Containers are much more popular these days…
IMHO it maybe is even worth to drop another installation method instead and putting more force to this solution(?). Maybe you should start a poll on that matter…
At least I hope this masterpiece comes back alive some time. So far I now have to research how I’m getting VM to work…
just adding my two cents…
edit: Ok deprication is on hold, sorry did not get it. But I don’t find the installation instructions any more…
That’s nice, but I still think there are many people out there not willing to throw away there already existing installation of Raspian/Raspberry Pi OS or whatever with already running services just to add a new service like HA. Especially Pi 4 can definitely handle a lot more than “just” HA.
So I think a step by step installation guide/script is still very helpful to many people. I found the installation guide in the community guide section and I hope it’ll become more “official” again in future.
I feel that it is exactly what I said. It is getting rid of the supervisor on one specific type of the installation is it not? What did I misunderstand here?
That’s because I run HA in a NAS which has its own OS on which I cannot run VMs but not Home Assistant. What works for you may not work for others. Actually it is the only reason why I am running it within a VM. Running it this ways gives me the same benefits you get from a container, backup, snapshots etc…
The same logic you mention applies to containers. You seem to assume that a container is not a virtualization layer… it is! It is just a stripped down VM with a stripped down OS to minimize resource usage. The only reason why a container would be needed, just like a VM should be because the applications cannot be run on the host OS. The thing you don’t understand regarding what I said applies to the same way whether it is a VM or a container. We are basically saying the same thing: If you can run it on a host OS why run it in a VM? Why run any containers at all?
We are saying the same thing here. Again the only reason why I don’t run HA on the host OS is because the host OS runs a customized distribution on linux which cannot run HA and I would not do it for security reasons. I therefore have the choice of running a 2 dozen of nearly identical mini OS each with its application called containers or one single VM running one OS running all of these applications. Which one is more simple and efficient? I am advocating that it is the latter and by very far.
I did not say you can’t do the same thing with a container…
Why does HA run multiple containers and felt the need to add an additional supervisor? The only reason why containers should multiply is if an application cannot run in the same container. If they could, and for HA I am convinced that most can, then there is no reason for having a supervisor to manage all these containers. However by the time all the dependencies are added and if you want to run other things in that container, the container has pretty much become a full VM. You should be able to run HA and all of the add ons within a single container. A VM can do that easily. I am sure HA can too as I said but as designed, the nonsense is to put every single integration and add on within its own container. It ads complication and overhead. That’s all I am saying. I understand a large number of people here love docker. I tried it, used it for various other applications outside of HA and I really don’t understand why it is even implemented for HA since its benefits don’t really apply here: Give the ability to create a multiple environments separate and distinct from the host and from one another can be run with minimum overhead, much less than for a VM. The key benefit is if these environments are different from the host and from one another which is not the case for HA.
So one can either run HA on the host OS as an additional application alongside all others, or as its own OS on a dedicated machine or within a VM/container if the host OS can’t run it for one reason or another. There is just no justification for adding the complexity of the spawning of a bunch of side components in their individual identical mini OS and a supervisor on top of it to manage them. Maybe there are add ons and components requiring an environment incompatible with the HA core or with other components but I have not seen one yet. It seems to be a case of “We do it because we can and it looks cool” without serious though about whether it is really needed and underestimating the resulting complications it comes with. The cost to benefit ratio is just not there. Gaining a bit of convenience and adding a whole environment along with all the overhead, maintenance and support… There are much simpler ways to do the same thing.
) because I couldn’t get HA to use the Bluetooth.