Bug 256885 - [NEW PORT] www/py-homeassistant: Open-source home automation platform
Summary: [NEW PORT] www/py-homeassistant: Open-source home automation platform
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords: feature, needs-qa
Depends on: 254853 252072 252073 252078 252081 256883 256884 266213
Blocks:
  Show dependency treegraph
 
Reported: 2021-06-29 12:43 UTC by Ivan Rozhuk
Modified: 2024-02-24 12:04 UTC (History)
15 users (show)

See Also:


Attachments
patch (19.67 KB, patch)
2021-06-29 12:43 UTC, Ivan Rozhuk
no flags Details | Diff
patch (17.92 KB, patch)
2021-07-01 04:36 UTC, Ivan Rozhuk
no flags Details | Diff
patch (18.07 KB, patch)
2022-01-12 17:10 UTC, Ivan Rozhuk
no flags Details | Diff
patch (21.16 KB, patch)
2022-09-04 04:13 UTC, Ivan Rozhuk
no flags Details | Diff
patch 2022.9.7 (21.08 KB, patch)
2022-09-29 22:08 UTC, Ivan Rozhuk
no flags Details | Diff
2022.9.7 (22.79 KB, patch)
2022-10-11 12:25 UTC, Ivan Rozhuk
no flags Details | Diff
2022.9.7 (22.80 KB, patch)
2022-10-11 12:42 UTC, Ivan Rozhuk
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan Rozhuk 2021-06-29 12:43:56 UTC
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
Comment 1 Ivan Rozhuk 2021-06-29 12:46:45 UTC
This port uses Virtual Environment and will download and install via pip all required python packets.
Comment 2 Guangyuan Yang freebsd_committer freebsd_triage 2021-06-29 20:25:38 UTC
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!
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2021-06-30 00:08:32 UTC
@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.
Comment 4 Chris Hutchinson 2021-06-30 00:22:27 UTC
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. :-)
Comment 5 Ivan Rozhuk 2021-06-30 01:12:11 UTC
(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://...).
Comment 6 Ivan Rozhuk 2021-07-01 04:36:45 UTC
Created attachment 226148 [details]
patch
Comment 7 Guangyuan Yang freebsd_committer freebsd_triage 2021-07-31 09:52:40 UTC
Currently don't have the capacity to test this - back to pool.
Comment 8 Ivan Rozhuk 2022-01-12 17:10:08 UTC
Created attachment 230957 [details]
patch

update to 2021.11.5
Comment 9 Ivan Rozhuk 2022-01-13 00:22:33 UTC
(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.
Comment 10 Dan Langille freebsd_committer freebsd_triage 2022-06-21 15:45:55 UTC
I have a need Home Assistant, especially if it can run natively on FreeBSD.
Comment 11 Dan Langille freebsd_committer freebsd_triage 2022-06-21 15:59:02 UTC
(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.
Comment 12 Ivan Rozhuk 2022-06-23 01:27:46 UTC
(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.
Comment 13 Dan Langille freebsd_committer freebsd_triage 2022-06-23 14:25:01 UTC
(In reply to Ivan Rozhuk from comment #12)
I tried the patch first. It asked me many questions.
Comment 14 Dan Langille freebsd_committer freebsd_triage 2022-06-30 16:58:55 UTC
(In reply to Dan Langille from comment #13)

By "asked me many questions", I mean the patch did not apply cleanly.
Comment 15 Ivan Rozhuk 2022-09-04 04:13:32 UTC
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.
Comment 17 Ivan Rozhuk 2022-09-29 22:08:31 UTC
Created attachment 236955 [details]
patch 2022.9.7
Comment 18 Ivan Rozhuk 2022-10-11 12:25:53 UTC
Created attachment 237209 [details]
2022.9.7

Remove unsupported ble from esphome.
Comment 19 Ivan Rozhuk 2022-10-11 12:42:09 UTC
Created attachment 237210 [details]
2022.9.7
Comment 20 Xavier Humbert 2023-01-29 20:18:13 UTC
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
Comment 21 Xavier Humbert 2023-01-29 20:41:02 UTC
(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
Comment 22 Daniel Kimsey 2024-01-10 06:12:17 UTC
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!
Comment 23 Patrick Donnelly 2024-02-23 16:11:29 UTC
Is anyone still working on this? Is there a current list of blockers?
Comment 24 Ivan Rozhuk 2024-02-23 17:05:31 UTC
(In reply to Patrick Donnelly from comment #23)
It is work at my home.
Comment 25 Daniel Kimsey 2024-02-24 03:24:49 UTC
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.
Comment 26 Ivan Rozhuk 2024-02-24 10:04:38 UTC
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 :)
Comment 27 Dan Langille freebsd_committer freebsd_triage 2024-02-24 11:17:49 UTC
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/
Comment 28 Ivan Rozhuk 2024-02-24 12:04:52 UTC
(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 :)