[RPi] Argon ONE Control Add-on (Support Thread)

    Hello this is nice work, thank you.

    I have a question however as I'm seeing intermittent problems with shutdown. Maybe I missed some important part on the shutdown and red LED discussion.

    I have an RPI4 with a Argon v2 m2.sata case and I'm using the Argon remote with LE12 booting/running from sata ssd.

    Good case: When I press the remote's power button it brings up Kodi's shutdown/reboot dialog but the shutdown proceeds without dialog confirmation needed. After the tv screen going dark (CEC) the red LED stays on for a few seconds then blinks a few times then turns off. The RPI4 is shut down and can be turned back with the remote power button.

    Bad case: When I press the remote's power button it brings up Kodi's shutdown/reboot dialog and the shutdown does NOT proceed on its own from here. I need to confirm 'Power off system' (OK) with the remote and Kodi will now shut down. After the tv screen going dark (CEC) the red LED will stay on forever and the RPI4 cannot be turned back on with the remote. Also the RPI4 will not react to the power button at the back. I will need to make the device powerless pulling the power supply cable.

    With me this happens intermittently but frequently. I say about 80% good case vs 20% bad case. I have so far not found any hint why the bad case happens.

    Any ideas what log files I should be looking at or what debug settings I should turn on?

    thx R

    The bad case matches to: „Known Issues“ and „Workaround after improperly shutdown“

    GitHub - HungerHa/libreelec_package_argonforty-device: ArgonForty Device Configuration Add-On for LibreELEC
    ArgonForty Device Configuration Add-On for LibreELEC - HungerHa/libreelec_package_argonforty-device
    github.com

    Because the remote control sends „KEY_POWER“ command, sometimes this key is passthrough fast enough, to open the power menu of KODI, before the background service signals the KODI shutdown. But the shutdown should already initiated. KODI 21 takes time…

    If without your confirmation, the system doesn‘t shutdown hard (power cut) after 10+ seconds, then it‘s a „new“ behavior of the MCU firmware to me.

    Do you have the SD card removed? I‘m asking to exclude that the system sometimes was accidentally booted from SD card with the settings/add-ons from there.

    If you enable debug logging you should find Argon40 messages in the kodi.log (kodi.old.log after next boot). If you find an exception message instead of the Argon40 debug messages there, then possibly an bug exists.

    Edited 2 times, last by HarryH (July 29, 2024 at 1:28 PM).

    This is whats confusing me. The symptoms described under known issue is nothing like what I am experiencing.

    Whats described in the known issue is the board powerdown outracing the Kodi shutdown leaving potential inconsistencies - I don't know maybe uncommitted db transactions or maybe filesystems not unmounted cleanly or whatever. But in my bad case Kodi and LE arent shutting down at all using the hardware trigger. I have to use the soft shutdown from Kodi.

    So I think yes its a 'new behaviour'.

    I can’t imagine that the firmware has been corrected by Argon40. Also the shutdown should work, after you has confirmed via power menu. If there is no power cut after you triggered the shutdown via remote control, could also be an indication that the MCU is stuck.

    I know such behavior if there was send some (un)specific I2C messages for example with i2cdump command to the MCU before. If the MCU is stuck, mostly the fan runs permanently and long press (<= 5 seconds) of the power button doesn‘t work, only unplug of the PSU. <- this matches more to your description.

    Do you have some kind of overclocking active? Also other I2C devices/drivers maybe trigger this.

    Edited once, last by HarryH (July 29, 2024 at 8:59 PM).

    Thank you for engaging with me on this first of all.

    No I dont have any overclocking and no third party software installed, very standard, very vanilla: RPI4 model b 4GB ram in argonone.v2.m2.sata case and 256GB sata ssd. Also I have the argon remote.

    Very basic LE installation using ssh starting with SD boot. After that...

    • 'dd' LE12 image to argon.m2.sata drive.
    • remove SD card
    • 2 boots & minimal/network configuration
    • install rpi tools & system tools kodi add-ons
    • boot
    • install 'libreelec_argondevice_1.1.1.zip', default config
    • install media library via shared 'mariadb' on other RPI4 server (advancedsettings.xml)
    • some kodi customization
    • finished

    I have a couple of good case kodi.logs collected with debug log setting on. Now I am waiting for the bad case to happen again to collect another kodi.log. But since then the bad case didn't happen again. :)

    I will report back when it does with any findings from the kodi logs.

    For the parameter „enable_uart=1“ is documented that this locks the clock rate as fixed, but as far as I know this is not true.

    enable_uart=1 NOT fixing core_freq to 250MHz · Issue #4123 · raspberrypi/linux
    Is this the right place for my bug report? I hope so, apologies if that's not the case. I've also posted on the RPi forum (See…
    github.com


    So since beginning I expected that the I2C speed could make trouble too, because of dynamic clocking. Perhaps this is unfounded for the I2C and only the RPi clock-stretching bug is an issue. Until now I couldn‘t verify that case.

    If you can catch a bad case again, please provide the full log, not only snippets. If my suspicion is right, then we will doesn‘t find a difference in the logs, because the issue exists only during transfer of the message at the I2C bus.

    To rule out this possible trouble maker we can try to set the clock rate manually. This will have some restrictions like:

    • higher power consumption, no clock down during idle
    • maybe shortening lifespan of the RPi4, because the clock should be set to 550Mhz to be fast enough for 4K

    By the way: I have also been trying out a different configuration without "enable_uart=1" for several months in order to use a different UART and not restrict dynamic clocking (if it after an kernel/firmware update accidentally works like designed ;)). This works too, if you can live without the integrated bluetooth adapter.

    I doesn‘t have a oscilloscope to see what happens at the I2C bus so I‘m not 💯 sure that could be the solution for the bad case scenario. For the I2C clock stretching bug, maybe slow down the I2C speed helps to mitigate the issue.

    Edited 3 times, last by HarryH (August 1, 2024 at 7:09 PM).

    Thanks for this addon. I have installed that on LE12 on my Rpi4B. But the fan does not spin up. The power off / restart function of the button does not work as well. It seems to me, that there is no service running for controlling that. Should there be a service? I am not sure.

    What I see in the journal are a lot of these messages:

    Dec 13 12:38:11 LibreELEC kernel: i2c-bcm2835 fe804000.i2c: i2c transfer timed out
    Dec 13 12:39:13 LibreELEC kernel: i2c-bcm2835 fe804000.i2c: i2c transfer timed out
    Dec 13 12:40:14 LibreELEC kernel: i2c-bcm2835 fe804000.i2c: i2c transfer timed out
    Dec 13 12:41:15 LibreELEC kernel: i2c-bcm2835 fe804000.i2c: i2c transfer timed out

    Any help is appreciated.

    Cheers

    Thomas

    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:

    Code
    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.

    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 firefox ,

    that was really fast. To get a feedback before publishing the release package. :D

    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.

    Edited once, last by HarryH (December 21, 2024 at 12:55 PM).

    Tested on pi5 8g argon v3 nvme. really great. button works perfect.

    tested on rpi4 8g argon v2 sata nvme . was running 1.1.2 before. fan ok . button fantastic. no delay on reboot or shutdown.

    I cant say much more on curves or so because argon cases and LE will never pass 40 celsius.

    With thermal paste instead of thermal pad you get some points less. no way to go over 39.

    Thanks, really a good job. believe nothing else is needed, it's very well done....