argonforty-device: add package (support for the Argon ONE cases)

[HungerHa]

During the continuous development of the ArgonForty Device Configuration add-on I was asked several times, like: “Why is the addon not installable out-of-the-box”. I think now it is in a state where that is possible...

The addon is required for the RPi4/5 Argon ONE cases. It provides the fan control and ensures that the shutdown works properly and power button events working as well. Additional it enables the IR receiver and provides support for the Argon Remote.

https://github.com/HungerHa/libreelec_package_argonforty-device

It would be nice, if it could be part of the LibreELEC addon repo.

[HiassofT]

Please change the depends and the addon projects settings.

[HiassofT]

@CvH @heitbaum please have a look at the package config, you are more familiar with that stuff than I am, not sure if the file should better be moved to packages/addons/service to match the PKG_ADDON_TYPE

[HungerHa]

@HiassofT ,

the current type script.service was inherit from the initial version 0.0.1 of that addon. According this it looks right:
https://kodi.wiki/view/Add-on_structure#Directory_Name
https://kodi.wiki/view/Service_add-ons

Moving to service looks wrong because:

Service add-ons will be automatically started when a user profile logs in or on Kodi startup, and stopped when the user profile logs out.

EDIT:
That would break functionality when the thread is stopped after the user profile logs out and multiple profiles in KODI are in use. Or does "script.service" and "service" behaves the same and I just wasn't aware of the possible issue? If I were to change “script.service” to “service”, I might need some sort of announcement or migration strategy for the current user base. The addon settings can be done again quickly or mostly left at default. But the parallel installation could be a problem.

First wiki link corrected. If I'm wrong and only the directory in the build system changes, that would of course only be a cosmetic change. ;-)

The package.mk files have been updated.

[HiassofT]

The package.mk changes look fine but I'm still confused regarding the addon type.

PKG_ADDON_TYPE likely doesn't matter as you ship your own addon.xml but in your addon.xml you define the addon to be a service type one:
https://github.com/HungerHa/libreelec_package_argonforty-device/blob/master/source/addon.xml#L11

So I'd say the package should be moved to the service directory, PKG_SECTION should be changed to service and you should set the addon id to service.argonforty-device

This is also how we do it in our LibreELEC settings addon - see https://github.com/LibreELEC/service.libreelec.settings/blob/master/addon.xml

I'll let my colleagues comment on this, kodi addons isn't excatly my area of expertise

[HungerHa]

When I started to improve and stabilize the addon, I came to the same point as you. However, I found the KODI documentation on the differences of addon types in detail rather irritating than a clear advice. After finding some other addons with “script.service” and the linked table in the wiki entry from above - I had stopped researching to change the addon type.

Some months ago I made the first steps to adopt the current addon to the LibreELEC build system. I started with the existing package.mk delivered by Argon40 and tried to understand what was going wrong with it. I tried to ensure that the generated addon.xml in the target matches to the existing one. This ensures also, that new installation are cross compatible to existing ones - because the addon id doesn't changes.

I appreciate getting some light on this as I feel lost in the documentation on this point.

[HungerHa]

For testing purposes I moved the package.mk from script to service directory and ended with that situation:

• the target has been build "script.service.argonforty-device-1.1.5.0.zip"
• the path inside matches to the addon id and should work

Afterwards I changed PKG_SECTION to "service" as well:

• the target has been build "service.argonforty-device-1.1.5.0.zip"
• the path inside has changed to "service.argonforty-device" and mismatches to the addon id.

I can't remember all the details, but that might have been the reason for my decision to place it below the script directory.

If it should be better to place it below 'service' directory and 'PKG_SECTION="service"' it need some little changes in the sources. Maybe as a patch or in general. This will trigger the migration problem mentioned above, but I guess it would only be a temporary problem.

I will await the comments from your colleagues, to get some more clarity about the best practice if possible. :-)

[HiassofT]

Looking at the kodi addon repo https://mirrors.kodi.tv/addons/omega/addons.xml.gz I count 7 addons using a script.service..xxx addon-id and 32 addons using a service..xxx addon id.

As service.example is used as addon-id in Kodi's service addon wiki page https://kodi.wiki/view/Service_add-ons and the majority of current kodi addons and all our addons use service.xxx I'd prefer to align the argon40 name and sectiion before adding it to the LE repo.

It will be a one-time action for your current users (removing the old addon) when switching to the one from our repo, but after that everything should be fine

[HungerHa]

I will rename it to “service.argonforty-device” to match the section. Or did you also think I should rename the addon from argonforty to argon40? It was Argon40's decision to use 2 different spellings for their company, depending on which logo/imprint you look at.

By the way: It's not just the users from my repo. I can inform them via the GitHub page and maybe in the existing discussion thread in the LE forum. I think there are also many others out there who are being misled by the Argon40 remote control user guide and its recommendation to install the outdated 0.0.1 version.

[HiassofT]

service.argonforty-device is of course fine as addon id.

And as you have created a fork / new version of the old argon addon it's also a good idea to use a different addon id, in case argon update their addon at some point in the future. If you'd keep using the same id you'd have a clash

[chewitt]

Can I suggest service.argonforty or service.argon40 instead of service.argonforty-device .. are we expecting any other non-device addon(s) for Argon40 things in the future? or what does device indicate/mean? - probably not IMHO so we can be more concise, and users will be swapping addons now so we don't need name continuity.

[HungerHa]

I'm open to suggestions if we're going to start again anyway. The previous ID was purely historical (and due my lack of knowledge). I don't know anything about Argon40's idea behind it. In the past I had stumbled across other Argon40 accessories/enclosures that use the same I2C command set for fan control and might be compatible with it.