Feature Request: Add support for fan status monitoring

[sannidhyaroy]

It'd be helpful if DietPi Dashboard would also report the fan status. Since, everyone wouldn’t have a fan installed, so this feature could be made optional that we can manually turn on and customizable (as the fan may be attached to different GPIO pins). I have an Argon40 Mini Fan HAT on my Raspberry Pi 4 Model B, and the fan works in PWM mode by adding the line dtoverlay=gpio-fan,gpiopin=18,temp=55000 to the /boot/config.txt file. There's no way to know if my fan is running or not without physically looking at the Pi 4.

[MichaIng]

The problem might be that there is no generic API to read the fan status, similar like there is no generic sysfs API to adjust fan settings, trip points and all that. There might be one which works with the particular RPi fan device tree overlay, but it wouldn't work on any other platform.

We started to develop a dietpi-fan tool years ago, but quickly gave up on it because of this problem. It works by times completely different on different SBCs, and between different kernel versions etc.

So it is unlikely that we will have the time and mood to maintain an own list/set of APIs per SBC to even just read the current fan status. But there might be a Rust crate which does this, which would then be an option for the dashboard.

[ravenclaw900]

Just did a little bit of research, there doesn't seem to be a standard crate for reading fan speeds, probably for the reasons that were mentioned.

One possibility to get this to work is to allow running custom commands to get data on the dashboard. In that case, you could put in whatever command gets your fan speed, and it would be shown in the dashboard. This is unlikely to happen right now, but it's something I might consider implementing in the future.

[MichaIng]

Good idea.

Instead of having this hardcoded as custom fan speed readout, I would then suggest to have it as custom numeric value readout. We could start to just have and use two additional TOML config keys, like custom_stats_cmd and custom_stats_name, or even as arrays to add multiple custom values to the graph. Colouring them could be an issue, if there is no clever random colour picker with an option to exclude those which have insufficient contrast to the background 😄.

Or not as graph, but just as additional value at the right side of the page. In this case it does not even need to be numeric, but the command could return any value or text.

[sannidhyaroy]

I see. Do you know if there's any command that can report if the fan is on or off? I usually don't need the fan speed but it's probably a valuable data for other users to monitor. Thanks in advance!

[MichaIng]

Does /sys/devices/platform/pwm-fan/ exist? And can you check /sys/class/hwmon/hwmon0/ and /sys/class/thermal/thermal_zone0/ for anything that looks like a status or PWM value? I have a single trip point defined there, which looks like it would be used by the fan dtoverlay, but I do not see anything that looks like a current status there.

[sannidhyaroy]

I got it working using WiringPi...
gpio -g read 18 (Pin 18 in my case)

Maybe DietPi Dashboard could use this data if it detects WiringPi is installed. Although it's limited, as it just tells if the fan is active or not but for me that's all I wanted. Others would probably want the fan speed as well but I don't think mine (Argon40 Mini Fan) supports dynamic speeds.

[MichaIng]

Hmm, I think this is way too specific to add this to the dashboard. I mean a fan could be attached to any GPIO pin, could be only on/off or an actual PWM value, and even the pin numbers are absolutely not consistent across SBCs. Also WiringPi is available only for RPi and Odroids and can be seen as obsolete/superseded by libgpio, which again does not yet work on all SBCs (depending on kernel).

If there is a sysfs node which contains the value which actually controls the fan, then okay, but I would avoid reading from the GPIO interface.

To me this sounds like a perfect example for a custom command idea 🙂.

[sannidhyaroy]

To me this sounds like a perfect example for a custom command idea 🙂.

Yes, that's makes more sense in this use case.