I think I've found a small bug in the logging for the fan speed updates.

 

Oct  9 09:10:20 Morpheus autofan: Highest disk temp is 40C, adjusting fan speed from: 112 (43% @ 1011rpm) to: 125 (49% @ 1105rpm)
Oct  9 09:10:20 Morpheus autofan: Highest disk temp is 40C, adjusting fan speed from: 134 (52% @ 1011rpm) to: 145 (56% @ 1105rpm)

 

The first line there is correct, but the second line is reporting the same RPM value, though that fan is different and is reporting over 2400.

 

It's all working just fine, both fans are adjusting as they should based on my settings, but the log always reports the same RPM values for each autofan process.

 

Unraid 7 beta 2, with Autofan 2023.02.05a

 

In both 6.12.13 and 7.0.0-beta.3, it seems the Autofan plugin only starts working after I pretend to change something and click "Apply".

Even ensuring the service is running by calling the following in /boot/config/go does not seem to be enough to make the fan control kick in.
 

# Start “Dynamix Auto Fan Control” plugin`
/usr/local/emhttp/plugins/dynamix.system.autofan/scripts/rc.autofan start &>/dev/null

My entire array overheated this morning during a backup operation due to that.

EDIT: I've moved on to using this fan control script, which works like a charm every time

 

https://github.com/IDmedia/fan-control-script

Edited October 13, 20241 yr by andrebrait

On 10/12/2024 at 12:15 AM, andrebrait said:

In both 6.12.13 and 7.0.0-beta.3, it seems the Autofan plugin only starts working after I pretend to change something and click "Apply".

Even ensuring the service is running by calling the following in /boot/config/go does not seem to be enough to make the fan control kick in.
 

# Start “Dynamix Auto Fan Control” plugin`
/usr/local/emhttp/plugins/dynamix.system.autofan/scripts/rc.autofan start &>/dev/null

My entire array overheated this morning during a backup operation due to that.

EDIT: I've moved on to using this fan control script, which works like a charm every time

 

https://github.com/IDmedia/fan-control-script

 

I found the same problem.. however wouldn't you have to use the 'nohup' command in /boot/config/go for that line to work? That way when the script exits the command would keep running.

 

 

33 minutes ago, zardoz1138 said:

 

I found the same problem.. however wouldn't you have to use the 'nohup' command in /boot/config/go for that line to work? That way when the script exits the command would keep running.

 

 

My guess is that the script is already running like that, from whatever is calling it, if that's the case.

 

Adding that line is what made the service go from Stopped to Running when I reboot my machine (without it, it only goes to Running if the first PWM controller is enabled), so I always assumed it works.

Edited October 18, 20241 yr by andrebrait

The S3 sleep plugin keeps shutting down my server backup while there is a backup running and the parity drive is active. 

What am I doing wrong?

Settings:

 

Hey, first of all thank you for your awesome plugins. Do you know when we will get systems temperature on X670e mobos. Thank you in advance. I am on Unraid 7.0.0 beta 4

On 12/12/2022 at 7:33 PM, Phoenix Down said:

Is there anyone actively maintaining the Autofan plug-in? I've already presented the fix. Just need the maintainer to merge in the one-line code change.

@bonienl does not seem to be active here anymore. Can someone finally merge the changes that Phoenix Down suggested?

I also have a Problem with this Plugin. I described it here: https://github.com/bergware/dynamix/issues/95

Edited October 23, 20241 yr by Daniel22

Hi,

I am running the Auto Fan Control plugin and want to achive that the fans of the array stop spinning if the hard disk are spin down(not running).

The used array fans are "2 x Noctua NF-A9 PWM" and connected to my minisforum AR900i. Plugin and dirver (Nuvoton NCT6687 Driver) is installed. Tried several settings but I cant get it running. As example I have written my settings down:

 

nct6798 - pwm1 —> left Noctua NF-A9 Disk 5,6,7,8 Minimum PWM: 130 Low temp: 40 High Temp: 50 Exclude drives: all 4 nvme drives (/sys/devices/platform/nct6775.2592/hwmon/hwmon6/fan1_input)

nct6798 - pwm2 —> Noctua CPU Cooler (/sys/devices/platform/nct6775.2592/hwmon/hwmon6/fan2_input)

nct6798 - pwm3 —> right Noctua NF-A9 Disk 1,2,3,4 Minimum PWM: 130 Low temp: 40 High Temp: 50 Exclude drives: all 4 nvme drives(/sys/devices/platform/nct6775.2592/hwmon/hwmon6/fan3_input)

nct6798 - pwm4 —> Minimum PWM: 130 Low temp: 35 High Temp:40 Exclude drives: all hard disk(/sys/devices/platform/nct6775.2592/hwmon/hwmon6/fan2_input)

nct6798 - pwm5 —> Minimum PWM: 130 Low temp: 35 High Temp:40 Exclude drives: nvme1+2 (/sys/devices/platform/nct6775.2592/hwmon/hwmon6/fan6_input)

nct6798 - pwm6 —> Minimum PWM: 130 Low temp: 35 High Temp:40 Exclude drives: nvme1+2 (/sys/devices/platform/nct6775.2592/hwmon/hwmon6/fan2_input)

nct6798 - pwm7 —> Samsung NVMe 980Pro Heatsink Minimum PWM: 130 Low temp: 35 High Temp:40 Exclude drives: nvme3+4 + all hard disk (/sys/devices/platform/nct6775.2592/hwmon/hwmon6/fan7_input)

 

Maybe someone has a idea or instruction how to realize this?

tia

 

Update: Okay I found out that this plugin is not maintained any more and has a lot of bugs (this thread and reddit). Is there an alternative maybe? 

Edited October 28, 20241 yr by PsYcRo
additional info

Seems like system stats not installing correctly? Is this something I did wrong or known issue? Thanks...

 

plugin: skipping: sysstat-12.7.5.txz - Unraid version too high, requires at most version 6.11.9 ----------------------------------------------------------- Plugin dynamix.system.stats is installed. This plugin requires Dynamix webGui to operate Copyright 2024, Bergware International Version: 2024.01.05 ----------------------------------------------------------- plugin: dynamix.system.stats.plg installed Executing hook script: post_plugin_checks Updating support link

 

Unnraid 7.Beta4

 

Would it be possible to control fan speed depending on CPU temp, not a disks' temp using System AutoFan plugin?

I have two fans in the case, one is for the array and one is the CPU fan, and the speed of this one I want to control depends on the CPU temp.

14 minutes ago, Vitek said:

Would it be possible to control fan speed depending on CPU temp, not a disks' temp using System AutoFan plugin?

I have two fans in the case, one is for the array and one is the CPU fan, and the speed of this one I want to control depends on the CPU temp.

CPU Fan should ONLY be controlled by the BIOS! controlling your cpu fan from a plugin is insane!

 

CPU Fan = Bios

Array Fan = Plugin

2 minutes ago, spl147 said:

CPU Fan should ONLY be controlled by the BIOS! controlling your cpu fan from a plugin is insane!

Why is that?

Just now, Vitek said:

Why is that?

because if the plugin fails, or system crashes you fry the CPU!

1 minute ago, spl147 said:

because if the plugin fails, or system crashes you fry the CPU!

Hmm, makes sense.

On 11/27/2022 at 6:53 AM, Phoenix Down said:

Hi @bonienl, is this the right channel to report a bug? If not, please point me in the right direction  

 

I've been noticing an issue with Autofan in the last couple of months. It seems like whenever all of my HDDs are spun down and only my NVME cache drives are still active, Autofan gets confused and thinks there is no active drives, and shuts down all of my case fans. This causes my NVME drives to get pretty hot. After digging through the Autofan code, I discovered the issue in function_get_highest_hd_temp():

 

My cache drives consists of 2x Silicon Power P34A80 1TB m.2 NVME drives. Apparently hdparm cannot get their power state, and because sdspin is looking for the word "standby", it never finds it. More importantly, the middle (sdspin) condition always sets $SLEEPING to sdspin's exit code, which is 25 in this case. And because 25 is not zero, this causes the script to think all disks are in standby mode (even though my NVME drives are still active), thus causing Autofan to shut off all case fans.

 

My fix is simple: remove the middle condition:

 

[[ -n $HDD ]] && SLEEPING=`hdparm -C ${DISK} |& grep -c standby`

 

Because the last condition is looking specifically for the word "standby" and not just taking the exit code, it works. This is because hdparm says my NVME drive's state is in "unknown", which is not "standby". That means the script correctly considers the NVME drive as NOT in standby.

 

I've locally modified the Autofan script and it's been running correctly for a few weeks. Unfortunately my local changes gets wiped out every time I reboot the server, so I'd appreciate it if you or the author can update the script to fix this bug.

 

Thanks in advance!

 

I'm seeing the same issue. Is there a way to fix this (myself?) to keep this working after a reboot?

 

Thanks!

1 hour ago, Soulplayer said:

 

I'm seeing the same issue. Is there a way to fix this (myself?) to keep this working after a reboot?

 

Thanks!

the issue is the fan speed plugin zip file gets extracted on boot, thats why your changes are overwritten

 

use the user scripts plugin and write a script to replace that line in the plugin with yours.

or

modify the zip with you changes, then it will persist on reboot

I am looking for some way to control fan speed in my computer case primarily for the hard drives. They consistly run around 46C during heavy loads such as parity check and playing 4K videos. I am not sure if the Dynamix plugin is workable for my system. I have a Thermaltake Core V71 computer case with a ASUS PRIME Z690-P UEFI BIOS motherboard. I am also running Unraid v 6.12.10 and my array disks are all xfs format.

 

Will this work for me?

1 minute ago, dchamb said:

I am looking for some way to control fan speed in my computer case primarily for the hard drives. They consistly run around 46C during heavy loads such as parity check and playing 4K videos. I am not sure if the Dynamix plugin is workable for my system. I have a Thermaltake Core V71 computer case with a ASUS PRIME Z690-P UEFI BIOS motherboard. I am also running Unraid v 6.12.10 and my array disks are all xfs format.

 

Will this work for me?

if you did your homework you would have your answer. on unraid open the terminal and run sensors-detect to see if your board is supported.

 

post the output

Here is the posted output:

 

# sensors-detect version 3.6.0
# Board: ASUSTeK COMPUTER INC. PRIME Z690-P
# Kernel: 6.1.79-Unraid x86_64
# Processor: 12th Gen Intel(R) Core(TM) i7-12700K (6/151/2)

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): YES
Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   No
AMD Family 10h thermal sensors...                           No
AMD Family 11h thermal sensors...                           No
AMD Family 12h and 14h thermal sensors...                   No
AMD Family 15h thermal sensors...                           No
AMD Family 16h thermal sensors...                           No
AMD Family 17h thermal sensors...                           No
AMD Family 15h power sensors...                             No
AMD Family 16h power sensors...                             No
Hygon Family 18h thermal sensors...                         No
Intel digital thermal sensor...                             Success!
    (driver `coretemp')
Intel AMB FB-DIMM thermal sensor...                         No
Intel 5500/5520/X58 thermal sensor...                       No
VIA C7 thermal sensor...                                    No
VIA Nano thermal sensor...                                  No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): YES
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'...               No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Nuvoton/Fintek'...               Yes
Found `Nuvoton NCT6798D Super IO Sensors'                   Success!
    (address 0x290, driver `nct6775')
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'...               Yes
Found unknown chip with ID 0x0101

Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no): YES
Probing for `IPMI BMC KCS' at 0xca0...                      No
Probing for `IPMI BMC SMIC' at 0xca8...                     No

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (yes/NO): yes
Probing for `National Semiconductor LM78' at 0x290...       No
Probing for `National Semiconductor LM79' at 0x290...       No
Probing for `Winbond W83781D' at 0x290...                   No
Probing for `Winbond W83782D' at 0x290...                   No

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no): YES
Found unknown SMBus adapter 8086:7aa3 at 0000:00:1f.4.
Sorry, no supported PCI bus adapters found.
Module i2c-dev loaded successfully.

Anyone who have problem with the original auto fan plugin, install this plugin in the webgui will likely fix your issue. I have the issue where the plugin didn't see my SSD which cause my ssd to run hot as the sun. But after install this it is recognized correctly.
https://raw.githubusercontent.com/characat0/dynamix/refs/heads/master/unRAIDv6/dynamix.system.autofan.plg

Reporting an incompatibility issue/bug with Dynamix System Temp plugin when using a Corsair PSU.

 

Basically, from what I can tell, the Corsair PSU reports its temperatures under "chip "corsairpsu-hid-3-1""

The plugin will load temperatures after doing the scan, but once you save changes everything goes back to Not Used.

Running sensors -u gives an error

Error: File /etc/sensors.d/sensors.conf, line 13: Undeclared bus id referenced
sensors_init: Can't parse bus name

Going to /etc/sensors.d/sensors.conf and commenting out that line (chip "corsairpsu-hid-3-1") will enable the CPU temp to be picked up and shown again. I'm unsure of how this actually breaks the plugin, I'm just reporting this based on my findings and experience.

Hello everyone, this seems to be a serious problem … 

I am using dynamix S3 sleep plugin to make the server sleep and wake up at desired time by following spaceinvaderone’s video , but when the server sleeps wake up the docker containers which used to use gpu like example don’t recognise the gpu example jellyfin doesn’t do transcoding or any container which used to use gpu seems like cannot see the gpu and only way to make them see the gpu is rebooting the server .

 

fixes i tried : updated nvidiadrivers , restarting the docker containers upon wake up 

but nothing is working, this seems to be long standing problem , looking for a possible resolution 

 

thanks

7 hours ago, drmetro said:

looking for a possible resolution 

actually, sleep % servers are not always a good solution, specially when talking about pcie plugin cards.

 

thre is hardware out there which doesnt like it, more common when talking about GPU passthrough for VM's which likes to break after sleep & wake ... and sadly, most common solution left, no sleep or different hardware ...

 

so either shut down and start full instead sleep & wake or try different hardware

12 hours ago, alturismo said:

actually, sleep % servers are not always a good solution, specially when talking about pcie plugin cards.

 

thre is hardware out there which doesnt like it, more common when talking about GPU passthrough for VM's which likes to break after sleep & wake ... and sadly, most common solution left, no sleep or different hardware ...

 

so either shut down and start full instead sleep & wake or try different hardware

Thats sad but i feel this is possible Only if there was a way to stop the docker container which is using the gpu automatically before the server goes to sleep and automatically restarts the container after the server wakes up , this way the docker container wont recognise that server went to sleep or not … may a script or a plugin will do this ? 
need more opnions on this

Edited November 20, 20241 yr by drmetro

53 minutes ago, drmetro said:

may a script or a plugin will do this ? 
need more opnions on this

before you go this way deeper

 

- when you manually stop the docker before you "sleep"

- when you manually start the docker after "sleep"

 

and then it works, then a script could resolve your issue