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.
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=01. 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.
-
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.
For the troubleshooting purposes, please comment out the last 3 lines via a hashtag in your config.txt first:
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. - Stop KODI service
-
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. - Remote button press repeat rate (ms)
-
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 secondsThe 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.tvDuring 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.tvBackport 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.