Posts by HarryH

    Unfortunately, you have not yet answered whether this worked before.

    It is to be expected that WAKE_ON_GPIO=2 consumes more power because a part must be active in order to monitor the GPIO. Have you tried WAKE_ON_GPIO=1 to see if it works? Is there any information about the purpose of the blue fan cable? Maybe you can use it to control/stop the fan just before shutdown. Because if the guys in the linked thread are right, the 5V rail stays on after shutdown.

    EDIT:

    There is different information about the GPIO pin to be used. GPIO14 may conflict with the serial console. Which pin are you currently using for the blue cable? And what does the content of your config.txt currently look like?

    dtoverlay=gpio-fan,gpiopin=14,temp=80000

    Did the fan function work before? I stumbled across this discussion:

    How to boot and safely shutdown with a button when WAKE_ON_GPIO=0
    1. Description To boot and shutdown my pi I have been using a button shorting GPIO 3 an GND. However after shutting down the pi, the fan shim and HDD keep on…
    raspberrypi.stackexchange.com


    It seems to depend on how the fan is connected and getting its power. What type of fan/HAT do you have? Can you give more details?

    The behavior is expected, after some policy changes in new kernel version that only one consumer is allowed at the same time. GPIO3 seems to be blocked by your own script that you have started via autostart.sh, by another script/addon or an activated overlay in the config.txt that has been identified as ‘shutdown’. So you must terminate the process to free the resources in forehand. For debugging purposes of your running script you should be able to use the pinctrl command instead of gpioset to circiumstand the restriction.

    pinctrl -p set GPIO3 pd

    Regarding the switch-on issue, you should check and maybe change the current EEPROM settings. There could be some changes with recent firmware updates.

    Quote
    • Update halt behavior on Pi 400 to re-enable 'power on' button if the OS did a reset rather than using the standard mailbox shutdown commands. This overrides WAKE_ON_GPIO / POWER_OFF_ON_HALT settings on Pi 400 because it has a dedicated power button. If a button on GPIO3 really is requried then it can be re-enabled by setting WAKE_ON_GPIO=2 but that will consume more power.

    Show current EEPROM settings:
    vcgencmd bootloader_config

    Edit EEPROM settings:
    rpi-eeprom-config --edit

    Off-topic: This CEC issue also occurs with my stock Fire TV 4K stick.

    Then it directs to an issue of your TV/Remote control/Cabling/AVR ... - not to KODI itself.

    Background: The remote control signal is received by your TV and translated to CEC. If the translation is faulty, then it occurs at all devices do you trying to control. Sometimes a firmware update of the TV or AVR is required to fix that.

    Common solution for typical CEC hiccups: Make all involved devices powerless at the same time for some minutes. This helps to reset the CEC settings.

    I can see some possible culprits in your config.txt. But it could be, that you have a general issue with I2C currently.

    It's a typo in the documentation of Argon40. If you want to force the PCIe speed to Gen 3, the line should show like this.

    Code
    dtparam=pciex1_gen=3

    For the troubleshooting purposes, please comment out the last 3 lines via a hashtag in your config.txt first:

    Code
    #dtparam=i2c_arm=on
    #dtparam=i2c_vc=on
    #dtoverlay=i2c-bcm2708

    Please don't forget to reboot after that changes, connect to LE via SSH and try the following:

    • Stop KODI service
      systemctl stop kodi
    • Check the current I2C state.
      i2cdetect -y 1

    Please post the output of the i2cdetect command. If the address 0x1a isn't populated, make the case some seconds powerless (unplug the power supply) and try again afterwards.

    EDIT: Your log looks like, that you have installed some banned components which are in conflict with the forum rules. Please do not expect any further support until you come back with a fresh install without such things.

    A big distance between different RF transmitters is always better. Some also reported poor WiFi signal from the RPi5. As HiassofT and Da Flex have already tried to point in this direction.

    2.4 GHz is a free usable frequency range worldwide (surely with some exceptions). Nearly all modern RF devices flooding the air with their signals. Bluetooth and DECT is also there. So you must try it to find if you run into issues. For example if you near of a microwave oven (maybe on backside of the kitchen wall with your RPi5) you have another potential issuer in that frequency range.

    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. ;)

    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

    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.