Make the RPI POE Hat Fan user-controllable and adjustable

[hansamann]

I am controlling my kids gecko/hamster cams with a RPI and got POE hats for these PIs. All was great when the fan was still not controlled, e.g. turned off at all times. Now, with the october raspbian update the fan was on all time as it seems the temp it turns on is 45 and that pretty much the case at all times.

As I was running the PEO hats for several weeks with the fan completely off and my cpu temp is just a little above the 45 degrees, it seems fair to at least adjust the fan temps to some degree. I would hope that raspi-config would allow me to turn the fan-control on/off completely and for on I would love to see different levels (aggressive fan, less aggressive).

I really think this needs fixing as many will have RPIs with POE hats around during night time and especially for all private users at home (potentially with kids) the subtle humming / cracking of the fan can be very disturbing.

[hansamann]

For now I have unplugged the fan and of course I destroyed one of the connectors. Can someone also please let me know the exact name of the connector so I can order a replacement connector with cables so I can easily solder it back on?

[XECDesign]

If you don't need the fan, you can turn it off by putting disable_poe_fan=1 in config.txt. The behaviour of the fan is defined in the device tree overlay for it, which can be edited as necessary.

Device tree can be a bit tricky, so some of the options have been made adjustable through config.txt. That feature hasn't made it into the pre-built kernel yet.

Some links which could be useful:
https://www.raspberrypi.org/forums/viewtopic.php?t=219050&start=25#p1354556
https://www.raspberrypi.org/forums/viewtopic.php?f=45&t=219050&start=50#p1356682 (a little out of date)
#2700

[sbromberger]

Hi there,

I've tried setting

dtoverlay=rpi-poe,poe_fan_temp0=60000,poe_fan_temp1=68000

in /boot/config.txt but it doesn't seem to be having any effect: /sys/class/thermal/cooling_device0/... shows current state of 2 when temp is 51C.

Is there another way to set the fan thresholds? This is on an RPi4 with the POE hat, using 4.19.56-v7l+.

EDIT:

dtc -I fs /proc/device-tree yields, in part,

        rpi-poe-fan@0 {
                cooling-min-state = < 0x00 >;
                compatible = "raspberrypi,rpi-poe-fan";
                cooling-levels = < 0x00 0x96 0xff >;
                firmware = < 0x07 >;
                status = "okay";
                phandle = < 0xcb >;
                cooling-max-state = < 0x02 >;
                #cooling-cells = < 0x02 >;
        };

[sbromberger]

Also, I'm a little confused by the default settings:

(57.0'C) seth@orange:/sys/class/thermal/thermal_zone0$ cat trip_point_0_temp
55000
(56.0'C) seth@orange:/sys/class/thermal/thermal_zone0$ cat trip_point_1_temp
50000

The dtb file shows these reversed (that is, trip point 0 should be 50k, trip point 1 55k). I'm also seeing this switch when I edit the dtb to increase the temps directly. Is this expected?

[patschi]

I've tried it on my RPi4 with the official PoE HAT as well, and I indeed see the same behavior:

# cat /boot/config.txt | grep poe
dtoverlay=rpi-poe,poe_fan_temp0=60000,poe_fan_temp1=68000
# uname -r
4.19.50-v7l+
# vcgencmd measure_temp
temp=48.0'C
# cat /sys/class/hwmon/hwmon0/pwm1
150

(I guess the temp was 50°C, but just went down to 48°C when executing the command)

The fan seems still to turn on at 50 °C, even the fact I've overritten it to 60 °C.

In my environment the fan always turns on for a few seconds every few minutes, as it always comes across the trip0 temperature limit for a relatively short time. So increasing the trip0 should basically solve that for me - but unfortunately does not seem to work as expected.

[sbromberger]

I managed to work around this by decompiling the overlay with

dtc -I dtb -O dts /boot/overlays/rpi-poe.dtbo > rpi-poe.dtb

editing the rpi-poe.dtb to switch the values (and increase them appropriately),
recompiling using

dtc -@ -I dts -O dtb -o rpi-poe-reversed.dtbo rpi-poe.dtb

and then moving the rpi-poe-reversed.dtbo to /boot/overlays/rpi-poe.dtbo. Remember to back up your original in /boot/overlays first.

[JamesH65]

@XECDesign Any thoughts?

[pelwell]

I can take a look in the morning.

[pelwell]

It looks like there might be two issues here - the overlay parameters and the trip point ordering.

1. Contrary to the documentation, the overlay doesn't currently have any parameters. Instead it gives the base dtb some parameters of its own. This makes more sense when you realise that the POE HAT EEPROM causes the overlay to be loaded automatically, so there isn't an obvious way (*) to pass the parameter values. Replacing your dtoverlay line with dtparam=poe_fan_temp0=60000,poe_fan_temp1=68000 should do what you are trying to do, at least as far as the DT contents goes:

pi@raspberrypi:~$ od -An --endian=big -td4 /proc/device-tree/thermal-zones/cpu-thermal/trips/trip0/temperature
       60000
pi@raspberrypi:~$ od -An --endian=big -td4 /proc/device-tree/thermal-zones/cpu-thermal/trips/trip1/temperature
       68000

To make the documentation correct and to avoid future confusion, I've added real parameters to the overlay.

2. The trip points are appearing in reverse order. This sounds like a thermal subsystem/Device Tree change, which needs more investigation.

(*) It is possible to pass parameters to a HAT overlay - the overlay is "in scope" until the next dtoverlay=..., so a dtparam=... before the first dtoverlay=... will refer to the overlay loaded for a HAT or, if no matching parameter is found, the base Device Tree.

[sbromberger]

@pelwell - thanks for the response. I have the dtparam line above as the first uncommented line in config.txt, but in my /proc/device-tree/.../cpu-thermal output, I have 50000 for trip0 and 55000 for trip1, so I don't think they're actually being set.

I take that back. I forgot to comment out the dtoverlay line below it, so I guess it was getting reset or something.

[pelwell]

I believe the order of the trip points is irrelevant - their content and that of the cooling maps defines the implicit ordering. If you (or anyone else) feels the cooling isn't working as it should then please correct me.

[sbromberger]

@pelwell - thanks so much for your help here. I've run using the dtparams config mentioned above for the past couple of days and can confirm the trip points are being set correctly (despite the ordering issue). At this point there is no need to modify the dtb file directly; the dtparams handles everything.

Man, those PoE fans are loud :)

[pelwell]

Closing, as I think the issues raised have been addressed.