Posts by HarryH

It appears what you mix up/create a theoretical issue, which do not exist if you would follow the advice of chewitt and also doesn't exist in practice (especially if the advices in the README at GitHub are not skipped, or those from above).

Because 1.1.7 and 1.1.7.0 use the same add-on id "service.argononecontrol", you will never have installed both version simultaneous. The last installed package version wins and overwrites the other. On that way you could switch between both, if would a different in code. Use case: a newer version is available at GitHub and you can't wait until it's released via the LibreELEC repo.

By the way: If something in the README is unclear documentated, please direct to the paragraph and ask straight forward. Maybe my wording is wrong (I'm not a native English speaker) and can misinterpreted or an information is missing. Sometimes it seems as if only headings are read or entire paragraphs in which the answer has already been given are skipped. The latter is frustrating because I can't fix the behaviour of the readers and it makes additional effort.

For LE13 nightlies the add-on is availabe now via the "LibreELEC Add-ons" repo. I have installed the add-on from there with a recent nightly from scratch and it's working right. It's also offered as an possible update if you manually installed v1.1.7 from GitHub before, but then will not automatically overwritten. Locations to change to the repo version:

* Add-ons / Add-on browser/ Available updates -> Argon ONE Control
* Add-ons / Program add-ons / Argon ONE Control -> context menu -> Information -> Versions -> Version 1.1.7.0

ApexDE ,

the behavior was not changed (also not planned) with regard to the edge use case with the file argon40_rc.lock. Also the naming is left the same because it remains an Argon40 device, and I like short file names for locks.

Regarding your feature request, I have already explained the related caveats/restrictions in the past of this thread. Can you please open an issue on GitHub so that it is tracked and not forgotten.

It should be updated automatically when a newer version is available in the repo. But without a version of the add-on available via the repo, I could not verify this yet. Normally this works if the last digit is increased by at least 1. But currently the count of digits in the version string differs 1.1.7 (GitHub) vs. 1.1.7.0 (Repo). So the final answer is outstanding, or the behaviour must simulated with another installed plugin.

Version 1.1.7 released:

• add-on id has changed, as a prerequisite for the upcoming integration into the LibreELEC add-ons repository
• because the id change was required, also the name has changed to distinguish better from the outdated official add-on variations 0.0.1 from Argon40

• icon changed
  
  New name: Argon ONE Control
  
  For more details please read the documentation at GitHub entirely.
  
  The add-on has been under review for approx. 2 months because, among other things, the ID had to be changed. One consequence of this is that an existing older version must be removed before a newer version than 1.1.5 is installed. However, the current customised settings are lost in the process. This is only necessary once.

  The release process is not yet complete. Only then will it become available in the LE add-ons repo. I hope that no further adjustments are necessary so that it can be included.

Hi Alex,

all available resolutions in KODI, including those you want to select for the whitelist, are based on the EDID information. If the EDID information is incomplete/incorrect, then the GUI settings may change with each restart. Details confirming this are only visible if you provide a link to a debug log. -> https://wiki.libreelec.tv/support/log-files

If the HDMI handshake fails after a successful start with the same resolution, it indicates more for hardware issue like cheap/bad HDMI cabeling or firmware issues of devices. One of known trouble maker could be the Argon ONE case as well. If you use such case, please try again without that.

Maybe your HDMI cabeling makes additional issues (use certified cables with "Premium High Speed HDMI Cable with Ethernet" label at least to reach stable 18Gbps for 3840x2160@60Hz), because it appears the HDMI handshake is below of that - this could end with 30Hz like you described.

For troubleshooting purposes and your use case it could be better to capture the EDID data during a successfully working connection RPi5 + AVR + Beamer and save into a file to make it permanently.

getedid create https://wiki.libreelec.tv/configuration/edid#getedid-create

The created dump with the EDID data of your AVR + Beamer HDMI chain will be used at every boot instead of dynamic collecting this data. This way you avoid that the HDMI sink (Beamer) must be powered on during boot. The RPi5 relies on this information for proper display support. If something is changed on your cabeling ,like buying a new AVR/Beamer, afterwards you must delete the dump file with getedid delete and repeat this process. This also required if you change the used HDMI port at the AVR or Beamer.

PS: Please also make sure to use the preferred HDMI0/HDMI-A-1 port (nearest to the USB-C power connector).

Hi antonvier ,

it may not be directly related to your problem, but your power supply seems to be insufficient. You should try to fix that as the first step.

RPi throttled=0x50000
Feb 27 17:26:08.897568 LibreELEC kernel: hwmon hwmon0: Undervoltage detected!

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

The HDMI0 port is the preferred one to also support 4K@60Hz (AFAIK: HDMI1 of the RPi4 supports max 4K@30Hz). With LE 12.0.1 there was an attempt to support CEC on both HDMI ports at the same time, but this caused more problems than it helped. This temporary function was dropped with LE 12.0.2.

Quote from hugosboss

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.

dtparam=pciex1_gen=3

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

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

That's just a shot in the dark: Do you have some kind of special characters in your passphrase? Or maybe only a 'Y' <-> 'Z' issue from the difference between German (GUI) vs. English keyboard setting?

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.