Argon ONE V2 - Fan always on after reinstalling RPi OS

I wanted to start fresh so I just re-installed RPi OS on my RPi 4 and now the fan is running constantly.

Just before the fresh install it was silent and acted predictably according to my argonone-config setup.

Has anything changed in the that now makes it behave weirdly with Argon ONE V2 cases?

I have the same issue: After executing

curl | bash

and then running


the fan on the Pi is always on and doesn’t turn off anymore. At 55 degrees it should run at 30%, and I checked the temperature, which was at 39 degrees and the fan still was at 30%, but wasn’t turned off.

Glad to hear that I’m not alone with this issue.
I did the same as you, I monitored the temperature of the Pi and it was idling at only around 32°C and the fan was still running and not cutting off as it did reliably before.
I’m quite convinced that they’ve changed something in their install bash script .

I assume that you also have your jumper set to ‘always on’ inside the Argon ONE case so that it’ll automatically turn on again in case of power failure?

I actually went ahead and turned off the fan manually with the following command:
i2cset -y 1 0x01a 0x00

According to the Argon-ONE-i2c-Codes readme page on Argon40s github they say that you’re supposed to set

i2cset -y 1 0x01a 0xfe

for the case to be in ‘Always On’ mode.

I maybe naively thought it was enough to set the hardware jumper to ‘always on’ and the would take care of the correct installation accordingly. I mean it used to work reliably, which I find strange.

Am I missing something here?

If you think about it twice, this command can’t work for you. Also if the MCU reacts on this command, the state is lost after you unplug the power. This must be a documentation error or was for a special revision without the jumper available - maybe there is a 3rd behavior if the jumper is complete removed - but this is currently not worth to try.

Can you locate the script at your installation and post the content of it here please?

Important: Additionally, you should be aware that the newer scripts also monitor the temperature of the SSD/NVMe. So it could be that this threshold has been exceeded and not for the CPU. The default values are 30% dutycycle at 30° celsius - so it looks like triggered by HDD temp.

Thank you for your reply HarryH, I’m using the regular V2 case and I’m booting from an SSD connected with a USB 3.0 to SATA cable.

I tried searching for to see if the bash script had left it as a residual file after I used the classic:
curl | bash
but it’s nowhere to be found on my RPi, I guess it pulled and used the one from on the 4th of May. Unfortunately I don’t have the residual file left…

The usual behavior would be that upon first boot after a fresh installation of RPi OS Lite (the jumper set to always on) the fan would start running immediately on a slow speed making quite an annoying high pitched noise.
The fan would stop running and start to behave as intended and reliably after having run the classic bash script with the string I mention above.

What could be different this time?

I’m having the same issue. I just installed the Raspberry Pi OS Lite (64-bit) 2024-03-15 release on my Raspberry Pi 4B in an Argon One V1 upgraded with the M.2 bottom. I don’t know if there’s a meaningful difference between the V1 and V2 besides the full size HDMI ports, but it’s exhibiting the same behavior that you are describing.

I tried modifying the fan control temp values, even though the core temps were well below the default 55C threshold, yet the fan was still running at full speed. I was able to turn off the fan with the i2cset line your provided, so thank you for that, but hopefully the script gets updated to remedy this issue. Having to execute that command on each reboot is not a long term solution, automated or otherwise.

Initially I thought it might be related to updates to the script to accommodate the new RPi5 V3 case, but I ran an archive of the older version of the script someone had uploaded to GitHub and it still had the same issues.

Could it possibly have something to do with the bump in Debian version (bullseye to bookworm)? I was previously running on the bullseye version of RPiOS (64-bit) without issue, but once I did a full reinstall to bookworm, this issue began to occur. Just a thought.

The should be here:

You can check the service state with systemctl
sudo systemctl status argononed.service
There you should be able to locate the service file assumed here:
Within that file your should find the reference to too.

Like I wrote:

Important: Additionally, you should be aware that the newer scripts also monitor the temperature of the SSD/NVMe. So it could be that this threshold has been exceeded and not for the CPU. The default values are 30% dutycycle at 30° celsius - so it looks like triggered by HDD temp.

The old script observe the CPU temperature only. With the new script, it tries to monitor the “HDD” temperature too. It makes no different if you have USB device or internal NVMe for that, as long its reported as /dev/sdX or /dev/nvme*. Mostly the temperature of this devices is fastently upper 30° celsius, so the fan will start to spin all the time. To prevent this, you must change the default values for the HDD temp fan curve to more realistic values.

Additional the script use another library to control the GPIO pins now. Also the fan control commands have been updated to support the Argon ONE V3 case. But this mostly can make a stupid fan speed up/speed down behavior during speed regulation, but not that the fan never starts or running all the time.
I can imagine, that the script can fail with an exception if the HDD temp process run into trouble, because the underlying commands hddtemp or smartctl deliver an unexpected return value. To identify such things, I would need more detailed feedback from a affected user.

Currently I think, most users overseen, that there is a second fan curve active which overwrites the CPU fan control curve.

It looks like that you can set HDD fan curve with:
sudo /etc/ hdd
or directly via
sudo nano /etc/argononed-hdd.conf
Don’t forget to restart the fan control service to apply the new settings.
sudo systemctl restart argononed.service

Some weeks ago I had feedback of another user, that his Argon ONE V1 was only usable with the ancient version of the script.

Yes, to fall back to the old script was a solution/workaround for him, but the root cause must be a other little detail in the change history, like the switch of the library to control GPIO pins or the HDD temp fan curve. I’m expect that the V1 should behave like V2, and the different to V3 is not as much that it makes the script unusable for V1/V2.

If you already corrected the HDD fan curve and the issue remains + you are in the mood to isolate the root cause, please check the current state of the service and look for warning/error messages in the journatctl file:
sudo journalctl -u argononed.service

Harry, thanks a bunch for your reply!

I just realized that I am talking about an Argon ONE V1, at least I assume it’s a V1 because the daughter-board has the mini HDMI ports instead of the full size ones.
(I have a V2 too with a M.2 board and full size HDMI ports. I got it confused and thought both of my Argon ONEs were V2s.)

However it remains true that the script has been changed quite recently. I wish there was a good changelog that made it possible to “downgrade” to an earlier version of the script.

Ideally the current script would be updated to repair the compatibility and this annoying bug.

To be honest, now It‘s up to you. As long no affected user with an Argon ONE V1 helps to bisect that issue, maybe there will never be a change back to the old behavior.

Yes, the behavior is unexpected for a user if he only used the old script until now. But from the point of view of a programmer this is not a bug, if there is attached a USB drive or something like that and that drive reports a temperature of 30° celsius or more.
Whether the function of additionally monitoring the temperature of the hard drive (SSD/NVMe) and thus controlling the fan should be selectable during setup with the script is a different discussion.

I‘m missing some feedback, if you already tried to correct the threshold for HDD temp or not.
If you want to find a working solution with newer script version for the future, this should be the first thing to clarify…