PoE fan issue


I figured I’d respond to you both in one post. I reviewed these two locations:

I attempted many of the suggestions posted and to no avail. Based on what I was reading I set my config.txt to the following:


After I ran a shutdown -r now and after it came back up I ran vcdbg log msg and saw that it loaded my overlay and dtparam’s

002468.000: brfs: File read: /mfs/sd/overlays/rpi-poe-overlay.dtb
002494.917: Loaded overlay 'rpi-poe'
002494.987: dtparam: poe_fan_temp0=55000
002495.667: dtparam: poe_fan_temp0_hyst=5000
002496.365: dtparam: poe_fan_temp1=66000
002497.103: dtparam: poe_fan_temp1_hyst=5000
002497.852: dtparam: poe_fan_temp2=71000
002498.631: dtparam: poe_fan_temp2_hyst=5000
002499.429: dtparam: poe_fan_temp3=73000
002500.258: dtparam: poe_fan_temp3_hyst=5000

I did take a look at the trip points and as the pages state, they are reverse but the order should not matter:

tail /sys/class/thermal/thermal_zone0/trip_point_?_temp /sys/class/thermal/thermal_zone0/trip_point_?_hyst
==> /sys/class/thermal/thermal_zone0/trip_point_0_temp <==

==> /sys/class/thermal/thermal_zone0/trip_point_1_temp <==

==> /sys/class/thermal/thermal_zone0/trip_point_2_temp <==

==> /sys/class/thermal/thermal_zone0/trip_point_3_temp <==

==> /sys/class/thermal/thermal_zone0/trip_point_0_hyst <==

==> /sys/class/thermal/thermal_zone0/trip_point_1_hyst <==

==> /sys/class/thermal/thermal_zone0/trip_point_2_hyst <==

==> /sys/class/thermal/thermal_zone0/trip_point_3_hyst <==

They also align with the dtparams I set in config.txt

I even went so far as to install on a separate SD card a clean, most up-to-date OSMC install and a clean, most up-to-date Raspberry PI OS to see if that changed any behavior.

For OSMC behavior was identical to my existing system but for Raspberry Pi OS after booting the fan kicked on and stayed on during my testing. I did notice that in the config.txt file for Raspberry Pi OS there is no mention of the POE overlay but the fan worked regardless. I even went so far as to copy the rpi-poe.dtbo on the Raspberry Pi OS renamed it to rpi-poe-overlay.dtb and replaced the existing file on my OSMC system but after a reboot there was no change in behavior but it did load the .dtb without complaint.

I also utilized dtc to alter the cooling-levels on the OSMC .dtb to a recommended setting but that also seemed to not alter any sort of behavior. I will continue to play around with customizing the rpi-poe overlay but I figured I give you both what I have looked at so far.

Good work.

We have come across situations on OSMC where the GPIO pins weren’t working and it turned out that there was no gpio group on OSMC, but there is one on Raspbian. That was resolved by a change in the udev rules so that, rather than creating a gpio group, the osmc group was given access to the necessary hardware.

It seems that the PoE hat uses I2C and I see that my Raspbian Pi does have an i2c group, whereas OSMC doesn’t. It might not be the source of your problem, but it’s still worth noting.

Doing some further searching, I came across this: i2c - PoE hat fan activation on OS other than Raspbian - Raspberry Pi Stack Exchange. Perhaps iyou will find something useful in it.

1 Like

Thanks for the kudos, I think we are getting closer to the culprit!

What you found is exactly what I was suspecting of something additional needing to be added but I just didn’t know enough to say anything substantial. I did create that udev rule and nothing changed. Though that post got me thinking, I noticed that OSMC does not have a /sys/class/thermal/cooling_device0 symlink or base location at /sys/devices/virtual/thermal/cooling_device0. I was operating under the incorrect assumption that thermal_zone0 was some sort of artifact with a different name but looking at the Raspberry Pi OS system both exist:

ls -l /sys/class/thermal/
total 0
lrwxrwxrwx 1 root root 0 Jun  9 15:18 cooling_device0 -> ../../devices/virtual/thermal/cooling_device0
lrwxrwxrwx 1 root root 0 Jun  9 15:18 thermal_zone0 -> ../../devices/virtual/thermal/thermal_zone0

And as that article alluded to, I checked the types of both and they are different:

tail /sys/class/thermal/cooling_device0/type /sys/class/thermal/thermal_zone0/type
==> /sys/class/thermal/cooling_device0/type <==

==> /sys/class/thermal/thermal_zone0/type <==

For comparison’s sake OSMC’s /sys/class/thermal looks like this

ls -l /sys/devices/virtual/thermal/
total 0
drwxr-xr-x 3 root root 0 Jun  9 08:37 thermal_zone0

And with the expected type of cpu-thermal

cat /sys/devices/virtual/thermal/thermal_zone0/type

So I think the culprit is the cooling_device0 device missing on OSMC installs. Now solving that is out of my realm but if there is any material I can review that could point me in the right direction, I am willing to test out my theory.

There might be a CONFIG option in the kernel that needs setting.

Ok I’ll poke around but admittedly I am out of my depth on kernel building but at the very least I should be able to do a compare between what the kernel config is on OSMC vs Raspberry Pi OS.

Hmmm. Found this on Raspbian**, but not on OSMC:


** Apparently now called Raspberry Pi OS.

Further info: Add rpi-poe-fan driver · raspberrypi/linux@6bad15a · GitHub

1 Like

Good spot. I’ll kick off a new build with that change shortly.


Thank you so much Sam! Let me know when it is available and I’d happily test it.

Also, thanks @dillthedog too for discovering the lead!


I just wanted to follow up on this to see if we have a recommended path forward.


Unfortunately, I can’t find any kernel patch on the OSMC github repo that includes the configuration option CONFIG_SENSORS_RPI_POE_FAN.

You need to wait until after the Buster release


I figured as much, don’t blame you for focusing on the much larger and impactful release. Thank you both for checking in and best of luck with Buster!

Just a quick update, I went ahead and gave the Buster repo’s a try just to see any of the slew of new updates changed anything regarding the POE fan but sadly it did not. Still no, cooling_device0 in /sys/class/thermal/

I will wait until the offical release of Buster before I try picking this back up on this thread. Thanks guys!

It will come in the next major kernel update, which will likely be 5.4 based.

Sounds good. I’ll wait until the testing announcement for 5.4 to investigate further, which I assume will be a bit of time from now. Thanks as always Sam.

Hi @porksoda103 - the PoE HAT fan should now work as expected (I have tested the hardware myself) with Kodi v19, which ships with a 5.10 kernel for Raspberry Pi. You can find a test thread here: [TESTING] Kodi v19 builds for Raspberry Pi 2/3/4



Fabulous! I will give this a whirl tonight and update this thread, I am sure it will work perfectly for me too though!

Thanks for all of your and the team’s hard work Sam!

1 Like

Please read the post on osmc.tv/blog about Kodi v19 before upgrading however.


Yup! Definitely aware of the caveats with Kodi v19. The OSMC team has taken great care to communicate the regressions to users (I hope that the user base actually listens to the repeated comms about decoding and playback).

Got the new build on my Raspberry Pi 4 with a PoE Hat and I can confirm that it is working as expected. I am currently playing with the poe_fan_temp and poe_fan_tempX_hyst dtparms but I confirmed that the command disable_poe_fan=1 works so it seems like not only is the kernel running the fans but I can definitely tweak the fan as needed in a config-user.txt file.

I will also check this with my Pi 3+ but I have no doubt it will work the same.