Flightradar24 integration for Home Assistant needs update from 2023-7.3-22 --> 2024.1.6

[Sweepr]

Software Name

Home Assistant 2024.1.6

Brief Description

Current latest version is 2023-7.3-22, newest version https://github.com/home-assistant/core/releases/tag/2024.1.6

HACS intergration "Flightradar24" complains about version 2023-7.3-22 being to old, and must install at least version 2023-9.3

Website

https://github.com/home-assistant/core/releases/tag/2024.1.6

Documentation

https://github.com/home-assistant/core/releases/tag/2024.1.6

Build/Installation documentation

https://github.com/home-assistant/core/releases/tag/2024.1.6

Source code

https://github.com/home-assistant/core/releases/tag/2024.1.6

OpenSource License

MIT

Other License

No response

[hgy59]

There are some new requirements for HA, so it we'll need some time to create an update.

• needs updated version of Python311 to build Pillow >= 10.0.x and other python modules
• needs custom build for ha_av and will depend on ffmpeg (5 or 6?) package

The homeassistant package is growing in size and we have limitted space in the synocoummunity.com repository.
This is mainly caused by including a lot of cross compiled wheels in the package.
Especially for arm 32 archs, most of the "no-arch" wheels are not available for download (at pypi).

We probably have to drop the homeassistant package for all but the Models with x64 or aarch64 CPU.
But all x64 and the newer aarch64 models have support for docker and would support hosting HA by docker.
This would lead to stop providing native HA packages.

Another approach would be to create an additional repository for the Homeassistant package to host the cross compiled wheels and remove those from the packages (spk files).
One issue will remain: I never found the reason, why Homeassistant with our package does not download most of the wheels on demand (therefore we install all wheels at package installation).
If we find a solution for this, the installation time would be seriously shortened, and dependencies for integrations would be installed on demmand.

A custom repository for cross compiled wheels would have another benefit.
Cross compiled wheels that fail to build with the spksrc dev. env. could be provided, when the build with another environment is possible. For the rare case that cross build is not possible, even native built wheels could be provided.

@th0ma7 what is your opinion on the future of the HA package?

[th0ma7]

@hgy59 this is an interesting question that fits well in the sense trying to keep spksrc relevant and figuring out how to keep (or not) older arch in a maintanable shape, and at what cost.

But, in continuation of this, in the longer term if we want to keep maintaining efficiently python packages (including HA), we definitively need to move to an online repository and redirect all wheel builds under python for instance:

python311
├── wheels/grpcio/Makefile
└── src

Taking grpcio specifically as it affect all aspects: does not build on armv5, qoriq (actually does it even build?) - i.e would require considering alternate tools than pip to generate some builds whereas framework needs to be adapted accordingly. Afterwards packages would simply refer to the URL online.

That's something I'm willing to tackle (once other framework clean-up and qoriq thingy are merged). But I'd need assistance on many areas, for once the web site would need to be adapted for this.

Long story short, I believe there are opportunities, how much effort are needed vs value is the question - and on that if @mreid-tt web changes are finally getting merge we may have an idea of how many people are really using this and confirm if there even is a real interest?

@mreid-tt is you ever can get stats on a per arch-dsmversion basis that would be more than awesome 😄

[mreid-tt]

Long story short, I believe there are opportunities, how much effort are needed vs value is the question - and on that if @mreid-tt web changes are finally getting merge we may have an idea of how many people are really using this and confirm if there even is a real interest?

@mreid-tt is you ever can get stats on a per arch-dsmversion basis that would be more than awesome 😄

@th0ma7, I've been actively advocating for the two open PRs to be merged into the spkrepo, but it's been a bit of a struggle to grab the attention of the backend administrators. I'll keep nudging where I can until we get them merged and published.

Regarding the stats, it seems like it might be a bit of a separate challenge. We'll likely need to dive into the logging on the Fastly CDN network we're using. Given the significant volume of downloads we manage, implementing this will require some clever coding since the initial approach of direct database recording posed a risk to server performance and was consequently removed from the PR. It's definitely something I'm willing to tackle with some support and insights into the backend, but let's focus on one thing at a time for now.

[hgy59]

@Sweepr while trying to build homeassistant 2024.1.6 I found further issues:

• the webrtc-noise-gain module requires ‘-std=c++17’ therefore requires DSM >= 7

In the near future we will have the homeassistant package from DSM 7 only.

[Sweepr]

@Sweepr while trying to build homeassistant 2024.1.6 I found further issues:

• the webrtc-noise-gain module requires ‘-std=c++17’ therefore requires DSM >= 7

In the near future we will have the homeassistant package from DSM 7 only.

DSM 6.2 will reach EOL by the 4th quarter this year anyway.

Thanks @hgy59 and others for the effort and quick reponse to my request!

Highly appreciated. 👌

[th0ma7]

• the webrtc-noise-gain module requires ‘-std=c++17’ therefore requires DSM >= 7

In the near future we will have the homeassistant package from DSM 7 only.

@hgy59 what if we could move to llvm/clang for DSM6? Worth investigating...

[sikysikov]

Just to understand what to expect: Is it going to be updated to 2024.1.6 (and next versions) on DSM 7 in close future? Or it is not and I need to order HA GREEN?

[Sweepr]

@hgy59 @mreid-tt

I fully understand you guys are busy, but at least tell us what the expected timeline is for the package to be updated?
There has not been any status update in over 4 month's.

More and more things are starting to break because of the outdated HA, even the simplest HACS garbage intergration can no longer can be updated.

Latest version is : 2024.5.1

Last logged: 07:25:32

[545064844432] This version requires Home Assistant 2023.11.0 or newer.

Latest version is : 2024.5.1
Have you guys looked at the possibility to update the package from within HA, similar to SabNZBD, Sonarr, Radarr?

[hgy59]

Have you guys looked at the possibility to update the package from within HA, similar to SabNZBD, Sonarr, Radarr?

This is not an option.
"Home Assistant Core" is a python application. We need to cross compile a lot of python modules and include those in the package. There is no possibility to use an other update method.

And we heavily depend on the home assistant project.

• they changed the restart procedure and the integrated restart does not work anymore (you have to restart by stopping and starting in DSM Package Center)
• some features are not available in HA Core (Addons, Updates, ...)
• they changed the recommended python to 3.12, don't know how log it will work with 3.11
• since "The year of the Voice" 2023 a mandatory dependency is the ha_av module (a home assistant specific version of the ffmpeg library bindings) and this is hard to build with spksrc framework (currently it is not supported to build python wheels that depend on ffmpeg libraries)
• It is a big effort to find all the updated dependencies of a new HA package version (and testing amount is also enormous)

probably we will have to limit future HA packages to aarch64 and x64 and to DSM 7.2 - so the supported models will also support docker and docker would be a better platform for HA...

Before #6040 is merged it is not possible to build a newer HA package.

[Sweepr]

Thank you for the status update!l, appreciate it!