My fan curve is not detected properly (Min, Start, Max = 0)

[WildPenquin]

Describe the bug

Fan curve is not detected properly. Fan2go does draw a curve, but at zero the fan is running. Hence it decides stop=min=max=0.

To Reproduce
Steps to reproduce the behavior:

run: `fan2go fan init -i [afanname]

Expected behavior

Fan curve should be detected correctly.

In case the fan is slow to stop, there should be some sanity check. The whole process should not require a longer -e parameter just because a slow to stop fan. There should be a sanity check (wait longer at 0).

I've yet to test with a larger -e value to see if the problem goes away. I believe this is caused by fan2go setting pwm to 255, then to 0, but the fan does not stop in 2 seconds.

Screenshots

❯ sudo fan2go fan init -i "Intake_pull"
 INFO  Using configuration file at: /etc/fan2go/fan2go.yaml
 INFO  Using persistence at: /etc/fan2go/fan2go.db
 INFO  Deleting existing data for fan 'Intake_pull'...
 INFO  Computing pwm map...
 INFO  Measuring RPM curve...
 SUCCESS  Done!
 INFO  Using configuration file at: /etc/fan2go/fan2go.yaml


Intake_pull
              
  Min PWM    0
  Start PWM  0
  Max PWM    0

 1729 ┼╮                                                                                             ╭────
 1614 ┤│                                                                                     ╭───────╯
 1498 ┤│                                                                             ╭───────╯
 1383 ┤│                                                                     ╭───────╯
 1268 ┤│                                                              ╭──────╯
 1153 ┤│                                                       ╭──────╯
 1037 ┤│                                                 ╭─────╯
  922 ┤│                                          ╭──────╯
  807 ┤╰╮                                   ╭─────╯
  692 ┤ │                             ╭─────╯
  576 ┤ │                        ╭────╯
  461 ┤ │                   ╭────╯
  346 ┤ │       ╭╮    ╭─────╯
  231 ┤ │       │╰────╯
  115 ┤ │       │
    0 ┤ ╰───────╯
                                                    RPM / PWM

• Distro: Arch Linux
• uname -a: Linux ArkkiVille 6.10.10-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Thu, 12 Sep 2024 17:17:51 +0000 x86_64 GNU/Linux
• sensors -v: sensors version 3.6.0+git with libsensors version 3.6.0+git
• fan2go version: 0.8.1

Other info
On my setup, things may be exacerbated by the fact there are fans on a rad in push-pull configuration. While I've tried multiple times to initialize all fans at the same time with fan2go, case may be their momentum is such that it maintains some airflow and the fans are more slow to stop than usually.

[markusressel]

Hi @WildPenquin, thx for reporting!

Yes, the automatic curve detection algorithm is not exactly great at the moment.
The easy fix for this is to set the minPwm, startPwm and maxPwm yourself, since the curve is currently not (yet) used to control the fan speed.

Of course that't not a solution for the automatic detection, which should also work for your case, so I will leave this issue open for now.

[WildPenquin]

I've set the minPwm, startPwm and maxPwm to work around the issue.

However I did some more testing. I'm using a Corsair Commander Pro. It's either the fans or the Commander Pro acting up. I believe it's a combination of two things:

• The fans in question do not stop at pwm setting 0 (some other fans do, but these don't)
• The Corsair Commander Pro can not be set to pwm value 1 (or 2, but it get's rounded to 3).

I.e., I can reproduce this weird behavior of the fans manually (without fan2go) by these steps:

• set pwm to anything between 25 (this will start the fans) to 255
• set pwm to 0, or 1 (fans stay at their previous speed)
• set pwm to 2 (or 3 ... ~20) -> fans stop (2 get's interpreted as 3 by the Corsair Commander Pro Kernel driver or the device??)

I also get a really, really slow startup every time I start fan2go. I believe I'm experiencing issue #132 although it seems like it has been fixed. The persistent PWM mapping is not working, as I can see by enabling verbose on fan2go (but perhaps I should open a separate issue or comment in #132).

[markusressel]

Yeah there were multiple issues already regarding the Corsair Commander Pro, see:
https://github.com/markusressel/fan2go/issues?q=is%3Aissue+Corsair+Commander+Pro+is%3Aclosed
I am afraid there is only so much we can do about the weird behavior of this device.

There was an issue fixed very recently regarding the pwmMap, see #311 .

Also, there have been lots of improvements in #267 but I am still trying to find the time to test it thoroughly. If you are comfortable with it, maybe checkout the branch in #267 and run

cd fan2go
make build
./bin/fan2go --your --config --params

to test it out. Would be awesome to have some third party testing info on it :)

GitHub

Issues · markusressel/fan2go

A simple daemon providing dynamic fan speed control based on temperature sensors. - Issues · markusressel/fan2go

[WildPenquin]

The Corsair Commander Pro is a bit special hardware, indeed.

I don't know it's internals nor how the Kernel driver works, but it doesn't have any pwmX_enable as "real" sensor chips. Instead it has the fanX_[input/label/target], and setting via the _target actually gives more fine-grained control and works fine. I've been using this in a custom program for controlling my fan speeds (and AFAIK liquidctl also uses these nodes?) and it works fine. However fan2go core logic and configuration relying on PWM values (AFAICT, I've just now found this software) it would be quite difficult to write an implementation to use the fan?_target nodes instead....

But you probably know all of this already.

I'll see the mentioned branch later and report back :-)

[markusressel]

But you probably know all of this already.

Not really, since I don't use this hardware 😄

However fan2go core logic and configuration relying on PWM values (AFAICT, I've just now found this software) it would be quite difficult to write an implementation to use the fan?_target nodes instead....

Well, fan2go was initially created with a 0..255 range in mind, yes. However, it is already possible to map this internal range to something different (like 0..100). fan2go also already supports different types of fans and sensors, like hwmon based ones and file based ones. So I don't think it would be far fetched or very difficult to support something slightly different as well, especially with the improvements made in the mentioned branch.

However, the biggest issues is the one I wrote at the top: I don't own this hardware. It doesn't make much sense for me to add support for something I don't own or use and cannot test on a regular basis - even though I would like to.