I am currently working on version 1.2.0 of the Argon ONE Control add-on, which optionally supports the ONE V5 fan or any RPi5 with a fan installed on the official fan connector. I need a little feedback before the general release in the LE add-ons repo, if possible. If anyone is interested in testing this with an RPi5, please send me a message or leave a comment.
Posts by HarryH
-
-
Version 1.1.13 released:
* new GUI language: Bosnian (Bosnia and Herzegovina)
* Disabling the HDD temperature curve prevents unwanted hard drive wake-ups -> [RPi4] Constant access on external drives -
Thinking a little further: Have you also considered that the counterpart to the Wi-Fi connection: the router/repeater, might not be "enthusiastic" about this type of connection interruption by the Broadcom client and block the reconnection?
-
Usualy you should fill the mode whitelist with the resolutions/refresh rate combinations you want that KODI switches to if the media format matches. The available combinations depend on the EDID data provided. Maybe there are some limitations which combinations are supported by RPi4/5 hardware.
It should be enough to set: "Settings \ Player \ Videos \ Adjust display refresh rate = Start/Stop". This prevents that KODI switches back to the default if OSD is open during playback and ensures the best match of your whitelist is used.
EDIT:
race condition, HiassofT was faster...
-
Are the external drives powered by case only or do they have an own power supply? The kernel does not expect drives to be removed without first being unmounted. Does this problem also occur if you unmount the external drives beforehand?
-
not needed at all, because with V5
- IR receiver is not available
- FAN is controlled by kernel (connected to RPi5 fan connector) https://forums.raspberrypi.com/viewtopic.php?t=359778
- RPi5 power button is in use (no external MCU)
-
The Argon ONE Control add-on is not required for the ONE V5 case, so you can skip this step. To enable the I2C bus, this line in the config.txt file is sufficient:
dtparam=i2c=on
-
Hi guys, please remain relaxed. There is no reason to curse the case itself, this time.
ajne
I will look into this, but I need some time to simulate your configuration in order to find a more practical solution. In the meantime (untested), you can change line 432 in this file:nano /storage/.kodi/addons/service.argononecontrol/resources/lib/argon.py
from val = argonsysinfo_getmaxhddtemp()to val = 0
Restart KODI afterwards or disable/enable the addon to activate the changes.
systemctl restart kodi -
Do you have already tried to disable the "Argon ONE Control" add-on? This could rule out if the integrated support for catching the HDD/SSD temperature triggers the spin up.
-
Your TV set switches to the ‘active source’, which is normally intended. How it reacts on simultaneous "active sources" depends on your TV. As a rule, the active source that is reported last wins. This could lead to the situation that you have to wait until the satellite receiver reports itself as an active source after startup. You could also start this satellite receiver only and patiently wait until this activates the TV.
With some TVs, you can set a specific external input as the standard for watching television.
Maybe a mitigation is possible if you disable "Switch source to this device on startup" and/or "Wake devices when deactivating the screensaver" in the "CEC Adapter" settings of LibreELEC: Settings -> System -> Input -> Peripherals -> CEC Adapter
However, this could also lead to some problems, e.g. that the remote control via CEC not working properly or partially only because another CEC device is being controlled or similar. -
Stuntel ,
You should make sure that you use the HDMI port that is closest to the USB-C port. Then CEC will work again. 12.0.1 temporarily supported CEC on both ports, but there were too many unresolved issues, so support was limited to the first HDMI port. -
It's not currently on the ToDo list as the V5 has nothing in common with the previous ONE enclosures other than the name and the manufacturer. In addition, I don't have an OLED device to test the function, and I would need capable testers with the ONE V5 case to get useful feedback in a timely manner during the development/debugging phase.
As far as I can see in Argon40's implementation with their scripts, the OLED requires additional Python modules like Luma.OLED and some binaries provided by Argon40. The latter without licence information. This hinders an integration, not only the additional abundant effort.
What expectations would you have regarding OLED support? Only the few cyclically repeated system information as with the argon1v5.sh script?
-
Please keep in mind that LE is reduced to just the required components for KODI and hosted in a readonly root filesystem. All additional things (more than a simple script), which are not already available in the base image or as add-on, you want to install should be a package. This can be an add-on package or directly included in a self build image. Many things are documented in the Wiki, at GitHub and also in the code itself.
As for your example with the Python background process, you can set it up manually as you have already done, or create an KODI add-on (script or service) that does the same. Adding new additional Python libraries can be significantly more difficult and depends heavily on how experienced you already are with compiling and packaging Linux packages.
Maybe I'm just misunderstanding you. But your wishes/goals sound very ambitious and require a good understanding of hardware/specialised knowledge in some areas. There is no such thing as a simple all-in-one guide. You should also not ignore the fact that not everything can be realised or is necessary on every hardware platform.Some starting points:
-
You are welcome. It was just a guess on my part that you also moved the fan_control.sh shell script to the subfolder called ‘scripts’. You are right that it makes no difference where it is located as long as the path in the autostart.sh script matches.
If you set FAN_OFF = 0, the fan should be stopped until the CPU temp value cross the threshold of MIN_TEMP. So you could lower the value MIN_TEMP near to the idle temperature for testing purposes, to trigger ON/OFF earlier and check the functionality of the script. -
Because it relies on gpiozero you could be affected by this (RPi gpiozero): https://libreelec.tv/2025/01/22/libreelec-nexus-12-0-2/
To find out where the problem comes from, what is the output of python3 /storage/scripts/fan_control.py ? Are there any exceptions/error messages? Or is this what you mean by?QuoteI was able to control my fan just fine from the interactive python so I know I have everything hooked up correctly.
If this works, the next step should be to test the wrapper script:
sh /storage/scripts/fan_control.sh start and sh /storage/scripts/fan_control.sh stop -
Version 1.1.12 released:
- new GUI languages: Korean, Chinese (Simplified Han script)
- missing Dutch addon description and summary added
-
Sounds to me like the issue which was already discussed here: RE: Nightly Builds
-
Sounds promising. I think they mean some kind of speed ramp (the longer you hold a button down, the shorter the distance to the next repetition) and I'm keeping my fingers crossed.
PS: Regarding the mouse mode, where I was wrong: As I didn't know the model you have, I chose it at random: 65RTS4K