Created attachment 226109 [details] patch Open source home automation that puts local control and privacy first. Powered by a worldwide community of tinkerers and DIY enthusiasts. Perfect to run on a Raspberry Pi or a local server. WWW: https://www.home-assistant.io/ patch contains also few dep ports
This port uses Virtual Environment and will download and install via pip all required python packets.
A quick review: - # $FreeBSD$ is deprecated and no longer needed. - Please rewrite some of the pkg-descr files as per porters-handbook [1], which states "the content of pkg-descr must be longer than the COMMENT line from the Makefile. It must explain in more depth what the port is all about." - USES=python:3.{5,6}+ can be rewritten as USES=python [1]: https://docs.freebsd.org/en/books/porters-handbook/quick-porting/#porting-desc Thanks!
@Reporter Can you detail how this works with respect to standard modes of port installation and dependencies, the virtualenv process and behaviour, particularly with respect to dependency versions as they get updated by pip over time, versus whats installed by ports/pkg.
Thanks for creating this port! I'd like to make a request; Given that this is a new port proposal. Can this pr's title be prefaced as such? [NEW PORT] www/py-homeassistant: Open-source home automation platform running on Python 3 or just [NEW PORT] www/py-homeassistant: Open-source home automation platform running on Python as Python 2 is no longer available. :-)
(In reply to Kubilay Kocak from comment #3) This port (py-homeassistant only) does not respect FreeBSD ports deps, I suppose. First attempt was to make standard port that installs all deps during installation from ports tree. I success with this, but HA is useless/unsupportable in this mode: it starts and you can configure it. But then you try to add some integration - HA report that you have missed deps. (There is an app argument to disable pip auto installer) There is 1800 "integrations" (plugins): https://www.home-assistant.io/integrations/ this mean that complete port will all features will require to install more than 2000 ports. We have no most of these ports in ports tree. And I can not do this work. In current state port installs all requirements to allow it to bootstrap. And some ports that auto loaded at bootstrap by pip. I'am force to downgrade some pip packets versions to use python packets from system. Probably better will be remove all additional ports and let pip install it. As far as I understand HA install via pip all packets that missed or version mismatch. Original HA deps mostly have fixed versions (== x.y.z), and I replace it to >= for some ports from ports tree. Bootstrap is in homeassistant_precmd(). Without this HA will require more ports to start first time and produce some errors at first 1-2 attempt to start. First port version was done in time of python 3.7. After update python to 3.8 and reinstall HA it bootstrap and download all 3.8 pip packets into /var/db/homeassistant/deps/lib/python3.8/site-packages. I remove by hands /var/db/homeassistant/deps/lib/python3.7 to clean up space. Current port state: it is installs and work, but have some non critical issues: 1. on info page /config/info it does not show that it is Virtual Environment 2. chromium does not work with web ui, some error in script 3. ff some times glitches in web ui, refresh page fix this Probably all these issues may be fixed if more ports will have version that HA requires instead of that I force to use from ports tree. I run it few days and have few integrations: IPP, MQTT+tasmota (mosquitto, 1 device: ESP8266+BME680), mobile app (4 devices), weather - all works fine. "recorder" configured to use mariadb (db_url: mysql+pymysql://...).
Created attachment 226148 [details] patch
Currently don't have the capacity to test this - back to pool.
Created attachment 230957 [details] patch update to 2021.11.5
(In reply to Guangyuan Yang from comment #7) If you have time, than this can be tested as web app, no extra or special h/w required. After install and start it can be accessed via web browser, some things work out of box, like weather widget. Some "integrations" requires only internet access, like speedtest.net. Some UPnP/DLNA/zeroconf devices can be found in network, it can monitor cups printers and work with soundbars and TVs.
I have a need Home Assistant, especially if it can run natively on FreeBSD.
(In reply to Ivan Rozhuk from comment #5) After reading that comment, it seems to me that it might be easiest to accept that HomeAssistant is not easily ported. I may take a different approach. I plan to jail it and let it use pip. Doing otherwise seems like a wild and never-ending project.
(In reply to Dan Langille from comment #11) Try patch before :) Now it installs things that required to bootstrap venv and after that it automatic installs inside venv all that required for work.
(In reply to Ivan Rozhuk from comment #12) I tried the patch first. It asked me many questions.
(In reply to Dan Langille from comment #13) By "asked me many questions", I mean the patch did not apply cleanly.
Created attachment 236352 [details] patch Update to latest release. Work as clean install and may update existing installation. Manual actions required only if python version changed.
Currently 2 additional patches required: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266213 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266211
Created attachment 236955 [details] patch 2022.9.7
Created attachment 237209 [details] 2022.9.7 Remove unsupported ble from esphome.
Created attachment 237210 [details] 2022.9.7
I've compiled the whole stuff, installs flawlessly and runs fine However homeassistant listen only on 127.0.0.1 instead of 0.0.0.0, which makes it less useful on a server without a GUI grep -r 127.0.0.1 returns o a bunch of occurrences, so I don't know how to fix this Thanks for the port ! Xavier
(In reply to Xavier Humbert from comment #20) Digging in HA docs, II found the variable server_host : default_config: server_host: 0.0.0.0 Another glitch : PID file cannot be created directly under /var/run, user homeassistant does not have appropriate rights. # mkdir /var/run/homeassistant && chown 570:570 /var/run/homeassistant and patching rc file accordingly fixes the problem
I was skimming the HA docs the other day and noticed that it did seem to have support for installing it's dependencies at runtime in a local lib directory in the data folder. It appeared to support this only if it didn't detect it was installed in a virtual env. It made me think maybe one doesn't need to package it as a venv at all! That'd bring the dependencies down to just the core ones which strikes me as a possibility. I'm hoping to fiddle with it this weekend and see if that's possible. I'll also need to dig up links too, sorry for the lackluster comment!
Is anyone still working on this? Is there a current list of blockers?
(In reply to Patrick Donnelly from comment #23) It is work at my home.
I was working on this and updating it, and frankly it's pretty gnarly. I'm not entirely sure it's feasible. I also went a bit further than the OP for better or worse as I'd really prefer not to have to include all the build-time dependencies in my jail. They've become a pain to manage. In no particular order, issues I ran into: 1. Upgraded to 2024.1.3 (monthly release cycle) 2. Required Python 3.11 (it would be a port only) 3. Project pins to exact versions at aggressively updates (making it churny to keep in sync) 4. HA installs packages at runtime with the `default_config` via pip (not listed directly in requirements) Ideally, I'd like to see the default install not need to reach for pip (which means a fair amount of ports). Even better if I could also support common major integrations. So I got through most of this into #4 before I hit the blocker. It ended up pulling in python-matter-server which uses the https://github.com/project-chip/connectedhomeip SDK. The SDK implements the Matter protocol and doesn't support being built on FreeBSD at the moment. I'm sure there could be interested dev's on that, it's out of my league. This is where I hit my 'crap.' point, as that's writing C interfaces to the FreeBSD networking stack. It's possible and I think there would be interest by that community, but it made me pause. I'll work on cleaning up what I did get up to and putting it on GH to share. I took the poudriere+portshaker approach to this because of how many ports were necessary. P.S. I also ended up heavily hacking up pytoport heavily to support modern python packaging requirements and recursively follow dependencies to facilitate the process. But that project seems inactive, so I'm not sure I could get any of the useful behaviors cleaned up and upstreamed. Unfortunately, at the end of the day I'm not sure if a port could be maintained without a significant and ongoing effort. At this time the project is focused on their currently supported platforms and hasn't been interested in porters. I'm not sure how much interest/engagement it'd take on the FreeBSD side to move that needle. Even if it's as a "Tier 2" target in FreeBSD's parlance.
For myself, I came to the conclusion that HA is not suitable for long-term use as an automation tool, as it is too difficult to maintain and unpredictable. A huge number of dependencies is a road to nowhere. At the moment it works for me, but I will not automate my housing with its help. I would love to continue using ESPHome, but it is difficult to support under FreeBSD due to compilers. Most likely I'll just create a virtual machine with Linux for it. In general, I see automation as: ESPHome based devices + zigbee->thread + matter. Possible MQTT, DALI/DMX. BLE, and all sorts of vendor protocols are a waste of time and money. Instead of HA, I want to write it in C+LUA+PHP, all I have to do is write it :)
FYI, I am running Home Assistant under byhve, backing it up using zfs - snapshots. Upgrades are smooth. I can use all the add-ons and extensions. It is what I recommend, despite my past efforts to get it working via ports. Some systems are monoliths, not just a single port. That describes Home Assistant to me. * https://dan.langille.org/2023/02/27/home-assistant-running-natively-on-freebsd-via-bhyve/ * https://dan.langille.org/2022/12/27/using-syncoid-to-backup-zfs-snapshots-home-assistant/
(In reply to Dan Langille from comment #27) Yes, I also came to the conclusion that it’s easier to stick it in a virtual machine and hope that the authors don’t break it. If we look at the question more broadly, then HA is more of a universal control panel for a zoo of equipment. I mean, it’s good to try at first, but I’m scared if it breaks in 10 years, which is a very short time for a house. From an administration point of view, it turns out to be very expensive and unreliable to have a huge amount of different equipment. Perhaps my point of view is too conservative :)
Created attachment 251160 [details] 2024.1.3 in venv This is rc.d script that bootstrap venv with HA. Most deps required to allow pip run build commands inside venv. ffmpeg binary is used directly by HA. py-sqlite3 copied inside venv, I fail to find another way to not use "pip venv --system-site-packages". 2024.1.3 - last version with python 3.11 support. camera and stream components probably broken due to pip fail build PyTurboJPEG. assist_pipeline probably broken due to pip fail build webrtc-noise-gain - FreeBSD unsupported.
(In reply to Ivan Rozhuk from comment #29) webrtc-noise-gain does work on FreeBSD; simply install a more recent version in the venv: pip install git+https://github.com/rhasspy/webrtc-noise-gain.git Reference: https://github.com/rhasspy/webrtc-noise-gain/issues/6#issuecomment-1836810982 Furthermore, 2024.3.3 is the last version compatible with Python 3.11 (see: https://github.com/home-assistant/core/blob/2024.3.3/mypy.ini). There's also a workaround for installing py-numpy if needed. Regarding Bluetooth support, one can simply nuke it by overriding the module locally (~/.homeassistant/custom_components/bluetooth/) with a dummy one. I can supply a diff if you are interested. Even though the HA Core developers go out of their way to unsupport FreeBSD, I've been running HA (via py-venv) for 3+ years without a hiccup.
Hello I am trying to make this port working on FreeBSD
My current work so far : https://framagit.org/kiwi/freebsd-ports/-/tree/master/www/py-homeassistant Poudriere is ok with it but still have some issues to populate venv for now.
I have tested and make happy portlint and portclippy. Fixed the starting script that need /usr/local/bin in the venv path to find rust to compile some module. Git dependcy was missing to create the venv (mostly for zlib-ng). Port has been tested on a jail, and it detect successfully some of my stuff on the network. The Mysql/PGsql part has not been tested on my side.
If it works for you - than ok, I do not see any critical for me changes :)
Home assistant dropped support this installation method. It is intended to be run either as an docker image or virtual machine. https://www.home-assistant.io/blog/2025/05/22/deprecating-core-and-supervised-installation-methods-and-32-bit-systems/
Hello, Unfortunatly this is sad. This port was even faster than a bare machine with Hassio. I have never feedback from freebsd-ports about this controversial way to install HomeAssistant. @Ivan, what should we do? Push it anyway or drop it?
(In reply to Paavo-Einari Kaipila from comment #35) I am not sure if that changes much for FreeBSD. They stopped supporting those methods as in they do not provide support for issues with such installations. The methods still work, e.g., for developers. But they didn't provide support for FreeBSD anyway. Quoting the announcement: However, after those six months have elapsed, these methods will become unsupported, which means issue reports will no longer be accepted. As these installation methods are used for the development of Home Assistant, it will still be technically possible to update them.
(In reply to Andriy Gapon from comment #37) Since we have more recent python I will try to update the port. Maybe if I can get some feedback on my https://reviews.freebsd.org/D48458 this should be appreciated.
Created attachment 265788 [details] 2025.11.3 This port is experimental for enthusiasts. If you want to use HA - better to use in bhybe and have "standard issues" that can be googled. ============== There is less disabled components since last time. Probably I will remove broken Bluetooth later. It requires python 3.13+. Update will require a lot of time to compile deps and run migrations (depend on DB size). Also note that modern ESPHome does not work any more with old HA: https://github.com/esphome/esphome/issues/11371.
(In reply to Ivan Rozhuk from comment #39) Don't remove the Bluetooth component unless you absolutely don't want Bluetooth support. I discovered a few months ago that once you get ESPHome running, you can setup a Bluetooth Proxy node and use it as the main Bluetooth controller. In other words, you can have Home Assistant running in a FreeBSD venv with Bluetooth 100% working, even if you don't have a BT adapter in the system. If you nuke the Bluetooth component, then the ESPHome BT Proxy doesn't work. I'm currently running 2025.11.3 in a venv with zero issues. Furthermore, I'm preparing to test a customized 2025.12 instance with some "deprecated" changes reverted (e.g. stuff removed by the HA devs that aren't "supported" in their OS). Changes done so far: https://github.com/home-assistant/core/compare/dev...HA-Libre:core:main There's a few other "deprecated" commits I have reverted but not pushed yet as I wish to test HA in its current form. As Andriy pointed out, "supported" and "deprecated" are just fluff words that basically mean "we don't want anyone using these advanced installation methods that still work, so we're removing public-facing docs about it". IMHO, it also feels like the HA devs are trying to lock things down to boost sales of their embedded devices, but I digress.
(In reply to Saro from comment #40) Yes, HA Bluetooth staff can work entirely through ESPHome API (using a device as a proxy). But I think that there was some error in bleak initialization when BlueZ or something could not be found locally. Someone reported that to HA or bleak devs (I don't recall), but they brushed off the report as being for a non-supported configuration.
Ok, I will leave bluetooth as is :) Another thing that I do not like is rc.d script that build and manage venv. Probably I should move most of code to Makefile and let port system do dirty work to build+pack+install/uninstall that venv.
Created attachment 265931 [details] 2025.11.3_2 It is same 2025.11.3 but with breaking changes: - /var/db/homeassistant/conf and /var/db/homeassistant/venv is used, so you need to move configs to /conf and remove other files after service stop and port uninstall - /var/db/homeassistant/.cache is used to cache python pip crap, hope this have some checks that python version changed and etc and will not require manual remove - py-uv-build may be removed, it was wrong dep - some how on FIRST start after install/reinstall ESPHome devices not work, restarting service fix it Changes: - now building as usual ports: make build do most work - ccache is used during build - rc.d script minimized to only start/stop HA - sqlite3 and py-uv is packed into venv during build - uv now used from system, this dramatically reduce build time. (but making plist is new time waster : ) - on port uninstall - service stopped before files deleted - on port install it will remove /var/db/homeassistant/venv dir before install files: this is hack, since @postunexec is called before files deleted and a lot of warnings that file missed is generated, and I want to minimize hand job while maintain HA. It is still not classical FBSD port that pre download all files by ports framework using fetch before build, but if some one want - it can be done. PS: I do report to asyncinotify that FBSD now have inotify, hope in next year we will see -1 warning in HA :) https://github.com/ProCern/asyncinotify/issues/20
Hello, Thanks for the update, but it seems I have another issue with poudriere : [00:00:31] Ignoring devel/py-uv-build@py313 | py313-uv-build-0.9.15: Unknown flavor 'py313', possible flavors: py311 [00:00:31] Skipping www/py-homeassistant | py313-homeassistant-2024.12.1: Dependent port devel/py-uv-build@py313 | py313-uv-build-0.9.15 ignored This is quite strange :( Trying to look deeper...
(In reply to Xavier Beaudouin from comment #44) But I do remove uv-build in last update...
(In reply to Ivan Rozhuk from comment #45) uv-build is not the only one affected on my side. Working on it :)
(In reply to Xavier Beaudouin from comment #46) Well it seems it is looking for uv as well: http://pkg.oav.net/data/143x64-default/2025-12-09_12h53m22s/logs/errors/py313-homeassistant-2025.11.3.log