Yes CPU utilisation does seem to be notable. Mine goes from 2-4% with the HAVNC add-on stopped to around 32% with HAVNC started.
I have no camera feeds
mine usually remains below 10% but spikes to 44% at times. tuning the VNC instance to use a lower resolution might help.
1 Like
Thanks all for the feedback, I’m really happy to see people are trying to use it.
I think the CPU utilisation is mostly from Chrome and all the javascript it runs but it’d be interesting to test if lowering the resolution would make a difference
I found a way to enable low power low-power mode which might reduce the load. The load from my dashboard on my pi4 is not high enough that I can see a difference. If someone want’s to try you will have to disable the kiosk mode on chrome and go to chrome://discards and toggle it there.
To disable the kiosk mode you can either remove the --kiosk from config/supervisor/5-chromium.conf and recompile. Or the faster way to test changes if you have enabled low level ssh debugging is to jump into the container with docker exec -ti addon_local_havnc /bin/bash , modify the file in /config/ directly and then send a kill -HUP to supervisor to make it restart chrome.
I also experimented with enabling hardware acceleration in Chrome, which was not enabled for me but it looks like it increased the cpu usage not decreased it. I believe I got that part working by apk add mesa-vulkan-broadcom inside the container but I’m not sure, have not tried to reproduce it. You can check if you have that working or not by going to chrome://gpu/ after you have disabled the kiosk mode.
Two different dashboards is a interesting use-case which had not occurred to me but makes sense. I don’t have any good ideas on how to do it with the current architecture. I think your idea on having another add-on is probably the easiest way to get it working currently.
1 Like
So to avoid to have to do the login everytime I reboot HA, I configured bypassing the login page by using trusted networks in configration.yaml
homeassistant:
auth_providers:
- type: trusted_networks
trusted_networks:
- 192.168.66.0/24
- fd00::/8
- 127.0.0.1
- ::1
allow_bypass_login: true
- type: homeassistant
This seems to work for my local logins, but not for the HAVNC browser. I’m not sure why, because from the point of view of HA, the browser accesses HA from 127.0.0.1 or ::1.
Anyone any idea why this is not working?
Cheers,
BC
It runs in a docker container and it will have a 172.30.33.0/24 IP
I have it combined with trusted_users which allows one to skip the login screen completely, but note that any add-on will have full access if you allow the whole /24
seems unlikely to be a big risk that someone or something would abuse that but you have to do your own risk-assesment
Hi gnyman,
I was just about to post that I had launched a bash instance in the docker instance and that I discovered the 172.30.33.1/23 address.
using /24 however does not work, and /23 results HA to run in recovery mode.
Also /16 does not seem to work.
BC
this is what I have in mine
auth_providers:
- type: trusted_networks
trusted_networks:
- 172.30.33.0/24
trusted_users:
172.30.33.0/24: [cut]
allow_bypass_login: true
- type: homeassistant
this works but I recall I had some issues getting it to work, might be that HA required some restarting
it’s weird, I used the same config to no avail.
what is your subnet mask in the HAVNC docker container? I have /23 and not /24 there.
cheers,
BC
Hmm, I also have a 172.30.33.6/23 in the docker container but it happens to have a IP which falls in the /24 range. I guess thats why it works. Does your container have a .32 or .33 IP?
My HA also goes into recovery mode if I change it to /23, but the documentation does not say anything about any restrictions to the netmasks, but there seems to be some interactions with the built-in containers which makes it crash. Seems like a bug.
I don’t know how stable the container IP’s are, maybe just allowing just the one for the container could work if it’s not possible to allow the whole .32 range.
I have now 172.30.33.1/23, so there’s the issue then.
I agree this seems to be a bug. I’ll report it as soon as I have time.
I wonder if it is possible to set the IP for a Docker container, that would fix things.
I reported the bug.
What is very weird is that 172.30.0.0/16 is accepted by HA and includes the IP, but I still get the login screen.
BC
So apparently the issue for the recovery mode is that the correct subnet is 172.30.32.0/23.
I changed the config to that, but I still get a login oddly enough.
BC
EDIT: OK, mystery solved: this does not work for me because the 172.30.33.0/23 network is also in trusted_proxies. I have this entry for reverse proxies to work to have external access.
BC
1 Like
Hi,
I want to have my iPad full time on and in order to keep the battery from draining, I need to use the Dark version of the default theme. however, whenever I restart the HAVNC addon and container, this setting is gone.
I removed the --guest and --data-dir options to the chromium command an rebuilt the container, but the dark theme setting is still ignored.
the weird thing is, it already switches back to light when I simply log out and log back in again. so the container doesn’t even need to be restarted for this to happen.
do I need to do anything else?
cheers,
BC
UPDATE: so I changed the google directory to /data/google-chrome in the supervisor config file and this fixed the automatic login issue and the dark theme issue at once because now cookies are stored permanently.
1 Like
thats great feedback and the idea, putting the cache into /data/ is something I have to look into, that would be probably solve issue with having to login each time also
Just wanted to ask if you have already released a version with the /data fix, or if it’s still something planned for a future update?
Hi! Trying to install the addon, but I have an error. Tried many things with chatGPT to fix it, nothing works. So I asked GPT to make you a summary of the problems and what we did try, this might help you!
Add-on Build Failure Report — “HAVNC” on Home Assistant OS (aarch64)
Environment:
• Home Assistant OS: 16.2
• Home Assistant Core: 2025.10.0
• Supervisor: 2025.10.0
• Architecture: aarch64
• Host machine: macOS (running HA OS in UTM VM)
• Add-on location: /addons/local/havnc/
• Add-on repo cloned manually (not from official store)
Issue:
The add-on appears correctly in the add-on store, but when attempting to install, I get this error:
Unknown error, see supervisor
In the Supervisor logs, I see:
[supervisor.addons.addon] No local_havnc addon Docker image local/aarch64-addon-havnc found
[supervisor.docker.addon] Invalid build environment, can’t build this add-on!
What I’ve verified:
• My config.yaml is valid and includes the correct architecture:
arch:
-
aarch64
• There is a valid Dockerfile in the root of the add-on folder.
• The directory structure is correct:
/addons/local/havnc/
├── Dockerfile
├── config.yaml
├── config/supervisord.conf
├── config/supervisor/*.conf
├── index.html
├── icon.png
└── translations/
• I tried both:
• Reloading the add-on store
• Running ha addons rebuild local_havnc → Error: “Addon is not installed”
• The add-on does not specify an image: in config.yaml, so it should be built locally.
Conclusion:
It looks like Supervisor fails to trigger the local Docker build for this add-on, even though all requirements appear to be met. The issue might be specific to how the Docker image is declared or how Home Assistant handles custom add-ons on aarch64.
Request:
Could you please confirm:
• Whether the current Dockerfile and structure supports builds on aarch64 under HA OS
• If any special step is required to support Supervisor-triggered builds
• Whether there’s a known incompatibility or workaround for HA OS running in a UTM VM
Thanks in advance!
I don’t know, the only thing I see which I’m wondering about is that you have it in a subdirectory, /addons/local/
Have you built other add-ons inside this subfolder?
Are you able to try moving it to /addons/ and try building it there?
- It does support aarch64. My pi4 is aarch64.
- There should not be.
- I don’t see why running it UTM would be different, I have not tested it there though.
I also have 172.30.33.0/24 under trusted_proxies, for use with Cloudflared external access.
So how did you solve this “conflict”?
Apart from the login hassle, I’ve got most things sorted. However, the weather-forecast card, if set to show hourly forecast, shows the time as 13:00 on my computer. But connecting to noVNC, it shows the time as 1:00 PM.
Can I modify HAVNC to use another locale?