Posts by HarryH

There are 2 different settings which are related to your case:

• Remote button press repeat rate (ms)
  At this interval, the button is automatically repeated as soon as you press the
  for longer than the following setting
• Remote button press delay before repeating (ms)

So play a bit with the second setting first. For my TV this combination works better than the default values:

• Remote button press repeat rate (ms): 100ms
• Remote button press delay before repeating (ms): 200

Regarding the xml file, please install a recent nightly build of LE12. There was an attempt to support CEC at both HDMI ports of the RPi4/5 at the same time. But this had some culprits and was reverted after release of 12.0.1. This patch wasn't restricted to the RPis.
In addition, KODI must be stopped before changing such settings files via CLI, otherwise the values may be overwritten by the running process.

In case of the Argon40 addon it is used to observe the shutdown pin GPIO4 for an incoming pulse. This pulse will be generated by the MCU at the pcb of the Argon ONE if:

- Remote control power off command signal has been detected
- The power button at the back side of the case has been double tapped
- The power button at the back side of the case has been hold for 3 seconds at least, but shorter than 5 seconds

The pulse time for double tap is 20-30ms, for the other ones is 40-50ms. If one of these is detected by the addon, KODI and therefore the operating system will be informed by the addon immediately to initiate a reboot or a shutdown, depending of the mapped event to the pulse time. The shutdown signal is the more critical moment and cannot be skipped, as the MCU starts an internal timeout of approx. 10 seconds until it switches off the power - regardless of whether KODI/the operating system is ready or not. Additionally, KODI has an internal timeout until it tries to kill running threads after 5 seconds during process stopping. But this seems counterproductive in the case of the default Python modules lgpio and gpiozero (due to some bugs) and leads to a fixed timeout of 30 seconds for the KODI process.

That is the reason to have a library which is able to fast release the resources (below the KODI 5 seconds limit) to have mostly a properly shutdown.

EDIT:
Okay, after reading again. If you're thinking in terms of extending functionality using the GPIOs, it's up to you to find some real-world applications. Like rolling or unrolling canvases, triggering an actuator for a fire extinguisher above the housing or something like that.

During the review phase It were decided to provide the Python bindings with system-tools addon instead of rpi-tools addon to immediately make it available for all platforms, not only RPi. The PRs were applied today.

Thanks a lot for the friendly and helpful support of the LE maintainers.

The system-tools addon PRs (libgpiod) were applied today and currently building, so it could be available in the next days. Many thanks to the kindly and helpful support of the LE maintainers.

Because I was asked several times for that and I think now it's time for, some minutes ago I opened 2 pull request to possibly add the argonforty-device addon to the LibreELEC repo.

argonforty-device: add package (support for the Argon ONE cases) by HungerHa · Pull Request #9662 · LibreELEC/LibreELEC.tv

During the continuous development of the ArgonForty Device Configuration add-on I was asked several times, like: “Why is the addon not installable…

github.com

[le12] argonforty-device: add package (backport of PR9662) by HungerHa · Pull Request #9663 · LibreELEC/LibreELEC.tv

Backport of #9662 During the continuous development of the ArgonForty Device Configuration add-on I was asked several times, like: “Why is the addon not…

github.com

In preparation of the official support of gpiod with the system-tools addon...

Version 1.1.5 released:

• also supports gpiod in the system tools

Maybe this dirty hack is the only option:

https://eu.community.samsung.com/t5/tv/turn-off-pc-mode-on-hdmi-input/td-p/7626071

Do you have already checked, if you maybe can disable the auto detection and preset/force the mode to "Standard" (non PC mode) of the HDMI port before you connect the HDMI cable? Some Samsung TVs are said to have this option.

ARC is only necessary for the connection TV -> AVR/soundbar, to provide the sound from TV back to the sound system via HDMI. So reserve that port for your AVR, if it also supports ARC. Your RPi doesn't use that kind of connection, so you could use another HDMI as well.

If your PC is not housed in a shielding enclosure and/or to near the TV, it can radiate into your antenna cable and block the TV signal. Please check the isolation of your antenna cable and the used HDMI cable, sometime also another power supply for the PC.
I had encountered a similar problem with a friend who had a Bluetooth transmitter for headphones attached directly to the back of her new TV. The SAT tuner was unable to find a transponder until I found and removed this construction.

I have not yet made the release package for 1.1.5 available, as I am still busy converting the PRs to integrate gpiod into the official system-tools addon instead of the rpi-tools addon. Until their merge, I saw no technical necessity to use 1.1.5.

Please can you check if that happens too when:

• move the cabeling to the primary HDMI port of your RPi4
• use a recent LE 12 nightly
• without additional USB devices like keyboard and so on ...
• connected directly to the TV set (bypassing the DENON AVR)

Do you have an alternative power supply available for a cross check?

Quote from ApexDE

Thanks! Will the updated rpi-tools come to LibreElec Updates?

Maybe I was to ambigous or you just overlooked the known issue part of the documentation at my GitHub repo. Some days ago I started this thread and provided the required changes, which are the base of my updated rpi-tools packages.

Post

RPi-Tools with official Python bindings for libgpiod

Are there a chance that the Python bindings for libgpiod are official included into the virtual rpi-tools addon? libgpiod is already part of the system-tools addon, only the python bindings are currently missing.

https://github.com/brgl/libgpiod/tree/v2.2.x/bindings/python
https://pypi.org/project/gpiod/#description

Why?

Since LibreELEC 12 gpiozero is the main module intented to interact with the GPIO pins. But there are some ugly problems:

• gpiozero takes to long to terminate (killed by KODI after 5

…

HarryH

December 10, 2024 at 8:45 PM

The workflow is started, and the 2 open pull request were already tagged. As it depends on the available time of the LE maintainers, it may take some time until someone is in the mood to review and finally merge them. Afterwards it should be general available via LE addon updates and its not required anymore to download/install the rpi-tools additional from my repo to use gpiod.

Version 1.1.4 released:

• added gpiod support
• use gpiod if available, as workaround against the 30 seconds delay on restart/stop of KODI with LE12+ -> reduced to 5-6 seconds
• regression with LE12/13: properly shutdown via power button of remote control possible again
  

This change will only take effect if rpi-tools are updated as well. Please read the known issue part, if you can't wait...

Hi mister_he1merD0ng3r ,

It is a known issue as the package provided by Argon40 is very outdated and was only intended for LibreELEC 9. The problem was already discussed by others here: RE: [RPi4B] Argon One Case Shutdown

Please use the current release 1.1.4 from here: https://github.com/HungerHa/libre…gonforty-device

Hi chewitt ,

thanks for the review and the helpful comments. I have created another PR9592 for the master branch and updated the existing PR9591 to be able to use it as a backport for LE12.

I have created a pull request with the needed changes. It's my first one, so please be kind if I made some mistakes and need to correct some things to make it acceptable.

Hi QBJack ,

please can you provide the current content of your config.txt

cat /flash/config.txt

and try if the MCU of the case is detected?

i2cdetect -y 1

The output should look as follows, where 0x1a is the address assigned by the MCU:

LibreELEC:~ # i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- 1a -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

If the MCU is not detected but the I2C working without error messages, please power cycle the case (unplug the power supply for some seconds) and try again afterwards.

A separate service shouldn't be running, The addon is running as a thread of the KODI process. You can/should enable the debug logging to get more insights what happens with the addon and please provide a link to the log:

https://wiki.libreelec.tv/support/log-files

If you have previously experimented with other solutions (argon1.sh /argonone.service ...) on your current LibreELEC installation, you should make sure that there are no fragments left that could conflict with the addon.

Are there a chance that the Python bindings for libgpiod are official included into the virtual rpi-tools addon? libgpiod is already part of the system-tools addon, only the python bindings are currently missing.

libgpiod/bindings/python at v2.2.x · brgl/libgpiod

This is a mirror of the original repository over at kernel.org. This github page is for discussions and issue reporting only. PRs can be discussed here but the…

github.com

gpiod

Python bindings for libgpiod

pypi.org

Why?

Since LibreELEC 12 gpiozero is the main module intented to interact with the GPIO pins. But there are some ugly problems:

• gpiozero takes to long to terminate (killed by KODI after 5 seconds during shutdown, may be related to the lgpio issue explained below) and doesn't frees the used GPIO ressources, so it's need to reboot instead of disable/enable the addon to get it work again
• gpiozero is slower than libgpiod because of additional abstraction layers: https://adafruit-playground.com/u/MakerMelissa…-raspberry-pi-5
• lgpio can be used without gpiozero to workaround the blocked ressource issue of gpiozero, but it seems to start some kind of threading as soon the Python module lgpio is imported. The thread with the imported lgpio module doesn't stop within 5 seconds (the hard limit for the CPythonInvoker of KODI) and prevents KODI to restart/shutdown in usual time. It takes 30 seconds to "systemctl restart kodi" or to shutdown LibreELEC if lgpio is directly or indirectly via gpiozero imported in a script addon. Therefore I think rpi-lgpio (RPi.GPIO replacement) will do have the same restriction.

For a cross-check, I compiled the rpi-tools addon for testing so that it also contains these bindings. If I use gpiod instead of gpiozero / lgpio for Argon40 Device Configuration addon the "systemctl restart kodi" takes only 4 - 6 seconds (not 30 seconds), depending how much background tasks are currently running. This will enable again an ordered shutdown, if the remote control power button is used for the case shutdown instead of the KODI menu. Another story with a firmware restriction (10 seconds limit) of the Argon40 case...

Yes, I can include the bindings in the Argon40 addon, but I would prefer a globally available gpiod Python module so that others also have the advantage of choosing the best working module for their use case.

Theoretical it's possible, but seems depends on your existing equipment and cabeling. Within the CEC adapter settings you can configure what should happen on power on/off/standby events of KODI. The issue could be if you need to signal KODI as "active source at startup" to get the TV remote control working for CEC or to switch to the right input, this triggers some TVs to power on.