Home Assistant: add a new package

[BKPepe]

Maintainer: me
Compile tested:

• Turris MOX, cortexa53, OpenWrt master
• Turris Omnia, mvebu, OpenWrt SNAPSHOT r9420-c17a68c

Run tested:

• Turris MOX, cortexa53, OpenWrt master

Description:

• add: Home Assistant

[karlp]

linking https://github.com/openwrt/packages/pull/5701/files as related, even though this is the package itself.

[karlp]

Both the version patches look like things that should go upstream. At least pyyaml, and the other one should probably got to a >= rather than "just another" fixed point in time?

[BKPepe]

Yes, I am aware of the pull request and I would like to help @mueslo with his pull request, but it will take me a while as I want to do some things before I can look into it.

---

To be honest, I don't have a clue why some of their dependencies are pinned and others are not. I sent a few pull requests to Home Assistant and all of them were accepted. In the end, it's their decision.
You may look here home-assistant/core#22997 (comment) and I didn't get a reply, why they use it like it.

The same thing is about ruamel.yaml. On their website, there is

For production systems you should pin the version being used with ruamel.yaml<=0.15.

And in Home Assistant it's pinned to 0.15.91

However, I created 5 days ago issue for PyYAML: home-assistant/core#23195 , it doesn't seem that it will go through.

For attrs, it's a little bit complicated and if I remember correctly some test wasn't passing, but I will try it once again as what I have tested it works.
That's why I didn't send it to devs of Home Assistant yet.

//EDIT: All tests passed, sent to Home Assistant and accepted. ;-)

---

I would appreciate any feedback regarding it and what you tested as it will help me. :-) Still, we're talking about pre-release version, which I used because of some dependencies as I would need to backport a few commits.

[BKPepe]

On the other hand, I added a lot of packages for Home Assistant and it would be bad if I didn't show that I have it working. I need to start somehow. ;-)

[karlp]

You can add more descriptive commentary to the patches perhaps explaining why they are necessary here, and not upstream. They can be full "git am" patches, so you can have descriptive headers. See https://github.com/openwrt/packages/blob/master/net/net-snmp/patches/000-cross-compile.patch for example.

I've done no testing whatsoever. I don't use home assistant and don't have python running on any openwrt devices, this is just reviewing the general form :)

[jefferyto]

ruamel.yaml is changing their API, that's why they suggest pinning the version for production systems:

Starting with version 0.15.0 the way YAML files are loaded and dumped is changing. See the API doc for details. Currently existing functionality will throw a warning before being changed/removed. For production systems you should pin the version being used with ruamel.yaml<=0.15. There might be bug fixes in the 0.14 series, but new functionality is likely only to be available via the new API.

[jefferyto]

Regarding the version pinning, I would suggest removing the pin entirely, rather than changing the version numbers. Otherwise, every time a dependency (i.e. the OpenWrt package) is upgraded, you would need to change the patch. (On the other hand, you wouldn't know if an upgraded dependency breaks HA... Hopefully everyone is using semver correctly 😆)

[feckert]

@BKPepe sorry I have set this from draft to pull request!!! This was my fault. I can not undo this :-(

[BKPepe]

@jefferyto: Yes, it will be a little bit difficult to maintain it. But for now, I am ready to track the changes and maintain it here and in HA.

@feckert: No need to worry about it. :) There's no way to set PR as Draft once it is marked as review.

[BKPepe]

I've just pushed a commit, which includes a new version 0.92.0 of HA.

Currently, it doesn't work with python3-urllib3 with version 1.25.1
pkg_resources.ContextualVersionConflict: (urllib3 1.25.1 (/usr/lib/python3.7/site-packages), Requirement.parse('urllib3<1.25,>=1.21.1'), {'requests'})
//EDIT: blocked by https://github.com/kennethreitz/requests/pull/5063

For now, I have been able to test it with python3-urllib3 with version 1.24.2

Patches changes:

• Added upgrade to ruamel-yaml to 0.15.94
• Added upgrade to pyotp to 2.2.7
• Added upgrade to xmltodict 0.12.0

In all of them, I included a note in their patches about issues or pull request in Home Assistant repository.

[BKPepe]

A few minutes ago, I pushed another commit to update Home Assistant to 0.92.1.

• Added patch, which upgrades zeroconf to version 0.22.0.
  (there is no description in the patch, yet)

Home Assistant tested with Xiaomi gateway with temperature sensors and it works. :-)
So, the next steps are things in the to-do list, but it's time for that. I will wait for a new version of Home Assistant, which should have fewer patches than now.

[BKPepe]

Updated it to latest version, which is now 0.93.1.

Changes:

• removed almost all patches (right now, there is only PyYAML, I'd like to get it in next release of hass)

[Cynerd]

Just few things I noticed. I know that it is still work in progress so sorry if I dived too deep.

[Cynerd]

I would rather use filespec to include init.

[commodo]

IIRC: filespec is typically used for packages that go under /usr/lib/pythonX.Y/

[Cynerd]

Yes but it can be used to deploy generally any file or directory to package. I know that most of the time I am using it to remove stuff not to add but I don't see it as a problem and it solves problem with duplicit bin copy code.

[Cynerd]

I am not aware of how home assistant is deployed so possibly sorry for stupid question but shouldn't this be somewhere like in /etc/homeassistant?

[BKPepe]

I'm glad that you asked. I would like to see it there as well.
Unfortunately, in the config folder, there isn't only one configuration file configuration.yaml, but together 9 files and 3 directories.

For example:
Files:

• database (home-assistant_v2.db), in my small setup it writes 2 MB / per day.

Folders

• .storage (files there together has 12,9 KB)
• deps
  If you don't have some dependencies for Hass and during the startup, it put them here
  /srv/homeassistant/deps/lib/python3.7/site-packages
  In my case, there are PyQRCode, mutagen, home_assistant_frontend and so on. When the Hass managed those dependencies itself, it's fewer things to maintain.

About the location /srv. It's a question. In one case, you shouldn't do excessive writes on the internal storage and on the other hand, you don't want to lose all the data during reboot or power off. From my point of view, I can write to description that Hass has a database and if you want to install it and run it with the default configuration, which I provided you need to mount a flash drive to /srv, but who will read the description? If I put /var, I don't see it very user-friendly as users will need to edit the configuration path in CLI also I would need to patch it in Turris feeds.

[Cynerd]

Up to my knowledge respawn_threshold nor other variables in this line were defined. Drop them if you are not using them here.

[BKPepe]

If I am not mistaken according to documentation for procd, which is is still under writing those values should be as default. I rather put them here, so in the future, I don't need to look at the documentation and search what default values are and if something happens I can slightly edit them.

But I don't mind to remove it. ;)

[BKPepe]

Squashed commits, rebased on current master, this one is ready for review unfortunately with an older version of Home Assistant, which I explained in comments and it is also included in the commit message of one of my patches.

@jefferyto , @commodo would you please look at it? :)

[commodo]

curios: won't /usr/bin stuff be installed automatically?
there is some auto-magic rules that should do this; i am not recalling this 100%; but it's also fine to leave this

[BKPepe]

They are when install section is not defined.

If I define install section like this

define Py3Package/$(PKG_NAME)/install
	$(INSTALL_DIR) $(1)/etc/init.d
	$(INSTALL_BIN) ./files/hass.init $(1)/etc/init.d/hass
endef

Then in the package are

• site-packages
• init script

Nothing more.

[commodo]

oh right;
the default one does that, but you are overriding it;

thanks & sorry for the noise;
i think i did not have any coffee before i asked

[BKPepe]

That's fine. You don't need to worry about it.

[Cynerd]

The reason is that default Py3Package/$(PKG_NAME)/install features this code but when you have to include some more files then you have to define your own "define" and you loose that piece of code to move binaries. I am not sure if that code should not be rather part of python install script but that is outside of this PR scope.

[commodo]

we may want to find a better mechanism here than patching it like this;
i have no idea for one atm;
but we'll see

[BKPepe]

I wouldn't say that it is so difficult as packages in stable releases (OpenWrt 18.06 and 19.07) are not updated so often.

Right now, there are two solutions

1. Keep tracking changes here and in Hass
2. Remove the entire pinning which was suggested by @jefferyto

[commodo]

no strong preference from my side;
a proper mechanism [that works for all/most cases] would be a bit of work anyway [at this point in time];

it's not one of those battles that's worth picking right now;
there are more important things to do until that;

[commodo]

if you run this with procd_set_param command "$PROG" -c "$CONF" --daemon would it work to remove

procd_set_param stdout 1
procd_set_param stderr 1`

?

[Cynerd]

Why do you want to remove standard output redirection to syslog? I think that it is a good approach. I don't see reason why we should avoid it.

Also parameters you posted are not good idea as well. Using --daemon with procd service is bad. Procd looses track of service if it does double fork (which is what --daemon instructs it to do). This means that there is effectively no way to kill service trough procd. It is something I encountered with syslog-ng recently so I am clearly aware that it is not a good idea.

[commodo]

oh right;
i forgot that procd requires services in foreground [been a while since i used it more thoroughly]
the --daemon arg is stupid to use now; so, my bad

regarding:

Why do you want to remove standard output redirection to syslog? I think that it is a good approach. I don't see reason why we should avoid it.

things may have changed in a while;
but, personally, i liked it when services would use syslog directly, so that procd would not need to do any output redirection to syslog;

i sometimes found that procd's output redirection was sometimes buggy [but that probably isn't the case anymore];

some services, do allow the program to stay in foreground, while output-ing directly to syslog
[ i was looking for this when i suggested --daemon ]

[neheb]

I'd use procd_append_param. Although that's just a style thing.

[jefferyto]

Comparing the list of dependencies here and the ones in setup.py, it looks like you added a few (aiohttp-cors, ifaddr, netdisco, pyotp, sqlalchemy, zeroconf) that are required by different components but not core? (Actually I couldn't find any direct requirements for ifaddr.)

If this is the case, I think it would be better to require only core's dependencies and let users decide which components they want to use and then install those component's dependencies individually?

[jefferyto]

A further thought on components (though I know nothing about Home Assistant and haven't really looked into it yet): If there are a large number of optional components (I would guess that different users will have different hardware they want to control), perhaps it would help to have separate packages for each component (or related components, again I don't know the specifics)? This would keep the core package smaller, and component packages can have their own dependencies. (You could also have meta-packages that installs all components, a recommended minimum set, or for different setups, etc.)

[jefferyto]

Also a wild guess for home-assistant/core#24982: In 0.94.0 they added importlib-metadata as a new dependency (home-assistant/core#24114), not sure if you were aware.

I have no idea if the error messages you got were because this package was missing, but I thought I would mention it 😆

[aparcar]

Friendly ping

[BKPepe]

I started looking at it since yesterday. I can not use the version which was released yesterday (2021.1.1) as I have some issues with that. Version, which I pushed seems to be working at least for me, but it requires an additional one package, which is missing in OpenWrt but that package requires additional 2-3 dependencies. I packaged it and will send a PR within a few hours. They can be installed via pip if you want to test it right now.

[juanesf]

Debería requerir compilar Home Assistant solo en mvebu, aarch64 y x84_x64. Es muy probable que otras plataformas no sean compatibles debido a la limitación de HW, ya que haas requiere al menos 1 GB de RAM. Se ejecuta potencialmente con 512 MB, pero eso no es compatible ya que pueden suceder algunas cosas inesperadas.

I should require to compile Home Assistant just on mvebu, aarch64 and x84_x64. Other platforms won't be most likely supported due to HW limitation as haas require at least 1 GB RAM. It runs potentially with 512 MB, but that's not supported as some unexpected things may happen.

most allwinner (sunxi) boards have at least 512 ram and several cores although they are arm, I'm sure it runs on bpi-m2-ultra

[wulfy23]

not sure if suggested... too many comments to catch up on...: utilities > automation?

[BKPepe]

Unfortunately, because of https://www.home-assistant.io/blog/2025/05/22/deprecating-core-and-supervised-installation-methods-and-32-bit-systems/ I need to close this pull request as it is not going to be supported anymore.

[aparcar]

I'm still interested in HA on OpenWrt, specifically the One since it supports Zigbee via the MicroBus. Should we look into getting those containers ready with APK? We tried that before and Debian would work fine in an APK container.

@dangowrt wwdd?