There seems to be a bug when a restart occurs

[eltonajmenezes]

I have observed if you restart the raspberry pi the service works, however the TACHO reading shows 0 throughout and although the PWM pin shows RPM reading

the fan doesn't seem to come on at all.

This is despite waiting for several minutes to an hour

If you manually stop and start the service it works, But I do not think this is designed in that manner. I tried this using v1.4

Screenshot with TACHO

FYI: The taco seems to give just 1 reading at the start up and the fan shuts off and doesn't come on again until you manually restart the service

I have tried setting this up from scratch 3-4 times and see the same behavior

So in order to mitigate it, I have added this crontab @reboot sleep 60 && sudo systemctl restart fan-control

[ar51an]

• How do you know the fan is not running? Did you look at the fan when it was showing "PWM-PIN .... RPM: 1500" in the logs? Were you even tailing the log [OR] just printed the status?
• What fan you are using?
• What OS you are using?
• What is the raspberrypi model?
• Paste the ouput of these cmds here:

  ls -l /opt/gpio/fan/ cat /opt/gpio/fan/params.conf cat /etc/systemd/system/fan-control.service

Here is the log I recorded right now after a fresh reboot of rp4 with Tacho enabled and a brief stress test to increase temperature:

[eltonajmenezes]

Yes I looked at the fan when it shows PWM-PIN with RPM 1500 and the fan did not turn on and the temperature exceeded 50 deg C, I checked the log sudo journalctl -u fan-control and the status as well sudo systemctl status fan-control

I even kept it for several hours and the fan just did not turn on. When a restart was done, the fan turned on and then off and back to square 1 where it did not turn on again

I am using the Noctua 5V PWM OS:

Raspberry Pi Model is: 4B

Here is the information you requested in the form of a screenshot

and here it is in the form of text

eltonajmenezes@eltonsraspberrypi:~ $ ls -l /opt/gpio/fan/
total 20
-rwxr-xr-x 1 root root 15600 Nov 10 17:08 fan-control
-rw-r--r-- 1 root root   145 Nov 10 17:11 params.conf

eltonajmenezes@eltonsraspberrypi:~ $ cat /opt/gpio/fan/params.conf
PWM_PIN=18
TACHO_PIN=23
RPM_MAX=5000
RPM_MIN=1500
RPM_OFF=0
TEMP_MAX=70
TEMP_LOW=40
WAIT=5000
THERMAL_FILE=/sys/class/thermal/thermal_zone0/temp

eltonajmenezes@eltonsraspberrypi:~ $ cat /etc/systemd/system/fan-control.service
[Unit]
Description=Fan Speed Control Service
Before=sysinit.target
After=local-fs.target
DefaultDependencies=no

[Service]
Type=simple
User=root
ExecStart=/opt/gpio/fan/fan-control
ExecStop=/bin/kill -s SIGINT $MAINPID
Restart=on-failure

[Install]
WantedBy=sysinit.target

This is another test done by me after a restart

The Noctua Fan is off. as you can see in the picture

Also These are the result of the commands you asked when the fan is in this state:

eltonajmenezes@eltonsraspberrypi:~ $ ls -l /opt/gpio/fan/
total 20
-rwxr-xr-x 1 root root 15600 Nov 10 17:08 fan-control
-rw-r--r-- 1 root root   145 Nov 10 17:11 params.conf

eltonajmenezes@eltonsraspberrypi:~ $ cat /opt/gpio/fan/params.conf
PWM_PIN=18
TACHO_PIN=23
RPM_MAX=5000
RPM_MIN=1500
RPM_OFF=0
TEMP_MAX=70
TEMP_LOW=40
WAIT=5000
THERMAL_FILE=/sys/class/thermal/thermal_zone0/temp

eltonajmenezes@eltonsraspberrypi:~ $ cat /etc/systemd/system/fan-control.service
[Unit]
Description=Fan Speed Control Service
Before=sysinit.target
After=local-fs.target
DefaultDependencies=no

[Service]
Type=simple
User=root
ExecStart=/opt/gpio/fan/fan-control
ExecStop=/bin/kill -s SIGINT $MAINPID
Restart=on-failure

[Install]
WantedBy=sysinit.target

And one more screenshot for clarity

Here is the reading of TACHO with my crontab command to restart the service. (As you can see it shows 0 but after restarting the service it provides a reading which is exactly the behavior of the fan)

FYI My /etc/systemd/journald.conf I have set to retain only these values Could that be the cause? (just a speculation)

[ar51an]

I will give you marks for making the effort. This comment explains things in a much better way.

FYI My /etc/systemd/journald.conf I have set to retain only these values Could that be the cause? (just a speculation)

It has nothing to do with journald.conf. You can keep any settings in it according to your preference. It is just logging.

So based on what you have mentioned so far. When you restart the service through cronjob or manually after system reboot fan-control works as expected. It has something to do with service unit (fan-control.service). Fan-control service is supposed to be started after mounting the filesystem. There is something different about your mount unit.

Are you using sd-card [OR] SSD [OR] HDD?

Make sure you are running the v1.4 binary in /opt/gpio/fan/ folder. You can use newly built binary with Tacho enabled later if everything works fine. Inspect the fan visually.

---

Try this, edit your fan-control.service: sudo nano /etc/systemd/system/fan-control.service

Remove lines Before=sysinit.target and After=local-fs.target. fan-control.service will look like below:

[Unit]
Description=Fan Speed Control Service
DefaultDependencies=no

[Service]
Type=simple
User=root
ExecStart=/opt/gpio/fan/fan-control
ExecStop=/bin/kill -s SIGINT $MAINPID
Restart=on-failure

[Install]
WantedBy=sysinit.target

Save fan-control.service. Execute below cmds and then reboot:

sudo systemctl disable fan-control
sudo systemctl enable fan-control

---

If above change does not work. Try this, edit your fan-control.service: sudo nano /etc/systemd/system/fan-control.service Use below service unit in it:

[Unit]
Description=Fan Speed Control Service
After=network.target
DefaultDependencies=no

[Service]
Type=simple
User=root
ExecStart=/opt/gpio/fan/fan-control
ExecStop=/bin/kill -s SIGINT $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target

Save fan-control.service. Execute below cmds and then reboot:

sudo systemctl disable fan-control
sudo systemctl enable fan-control

---

For me all 3 work fine including v1.4 fan-control.service. I use SSD.

[eltonajmenezes]

So to your questions, Yes I use an sd-card and yes I am using v1.4 fan-control.service with TACHO. I also tried the one without the TACHO and there was no difference at least 3 times fully installing it. (mentioned below I uninstalled for the nth time and redid it without TACHO)

I have tried whatever you have mentioned to the point but I still see TACHO reading as 0 and PWM as whatever RPM.

I got a screenshot to illustrate what I mean when I see TACHO reading of a certain value and then it's just 0

This showcases how the behavior is during startup which is so baffling.

And again only when you type this command sudo systemctl start fan-control does the service start to work as intended.

I have also found this article which is less in depth than yours and that's why I would like to use your code. Anyway this is the article: https://www.the-diy-life.com/connecting-a-pwm-fan-to-a-raspberry-pi/

In this article the author mentions to use GPIO 14 but I am using the PWM_PIN 18 to check and see if it is defective or something is wrong on my side.

So I deployed it and the to my sigh of relief nothing is wrong with my firmware I guess. The only difference between your code and the code from the article that I see is that he is directly running a script and you have a service.

So he invokes the code using a crontab. The fan started and stopped after rebooting and then started and stopped when the temperature reached the set value. This is the code: https://github.com/mklements/PWMFanControl/blob/main/FanProportional.py

Also he doesn't take care of the minimum RPM which you do and that's why I would prefer that I can get this code working the way you intended it to work.

So to my issue with the service: I think that the PWM works but then for some odd reason the signals are lost and that is illustrated by way of the TACHO reading 0 and only a restart works

Hope this piece of troubleshooting helps.

So as I mentioned above. I uninstalled it completely, restarted the service and still no go, the PWM Shows this

I have also attempted the troubleshooting steps above and still the same result

But the fan is still as ever unfortunately 🥲 (even the images of the fan are at different time stamps, not kidding 😉)

Just a suggestion: Would it be possible to add logic to the code to see if TACHO reading is 0 and PWM is not 0 for 1 mins or 30 seconds or however long necessary because if the PWM is sending signals constantly to increase the RPM speeds but the TACHO is constantly showing 0 isn't that an indication that something is wrong? and so then if there is no change restart the service (sort of a bootstrap restart 🤷🏻‍♂️)

Not sure again if this makes sense or if it would be possible? just had an idea

[ar51an]

I have also found this article which is less in depth than yours and that's why I would like to use your code. Anyway this is the article: https://www.the-diy-life.com/connecting-a-pwm-fan-to-a-raspberry-pi/

In this article the author mentions to use GPIO 14 but I am using the PWM_PIN 18 to check and see if it is defective or something is wrong on my side.

So I deployed it and the to my sigh of relief nothing is wrong with my firmware I guess. The only difference between your code and the code from the article that I see is that he is directly running a script and you have a service.

So he invokes the code using a crontab. The fan started and stopped after rebooting and then started and stopped when the temperature reached the set value. This is the code: https://github.com/mklements/PWMFanControl/blob/main/FanProportional.py

Also he doesn't take care of the minimum RPM which you do and that's why I would prefer that I can get this code working the way you intended it to work.

Biggest difference between python scripts and this C source code is the usage of system resources. Python script based fan controllers use a lot more system resources (memory and cpu usage). You can test this out later with htop or top cmd by running them individually and check the memory and cpu usage they are consuming. RP4 supports hardware PWM on GPIO pins 12, 13, 18 & 19. If you use any other GPIO pin apart from these ones they will use software PWM that is less efficient. I mentioned that in the source code and documentation.

---

Stick to the basics if you want to resolve this issue. Do not switch binaries between the pre-built v1.4 binary and the one you built with Tacho. When you are posting screenshots with Tacho output it means you switched the binary.

If after reboot fan-control service is starting fine with cronjob or manually. There is no issue with your hardware pin.

I did some testing with sd-card and all 3 fan-control.service files work fine. I have very strong feeling this is self inflicted issue. You are trying to do too many things together. Make sure you DO NOT have any other fan controlling script/binary running on your system, that includes any python script or any other binary of fan-control. There should be only 1 binary on your system and that is the fan-control pre-built v1.4 (without Tacho enabled).

Do this exactly as mentioned below:

• Disable the cronjob to start fan-control after reboot
• Use the pre-built binary from v1.4
• Use the default params.conf avaialble in v1.4

• Use below /etc/systemd/system/fan-control.service. (This is the one I was planning to update in the repo as well in the future after some testing):

  [Unit]
  Description=Fan Speed Control Service
  DefaultDependencies=no
  
  [Service]
  Type=simple
  User=root
  ExecStart=/opt/gpio/fan/fan-control
  ExecStop=/bin/kill -s SIGINT $MAINPID
  Restart=on-failure
  
  [Install]
  WantedBy=sysinit.target

• Save fan-control.service. Execute below cmds:

  sudo systemctl disable fan-control
  sudo systemctl enable fan-control

• Do not start fan-control.
• Reboot the system

Post these outputs here:

• Visually inspect the fan. Fan should start at full speed when the system is booted and either it will turn off or switch to lower speed depending on your system temperature when fan-control service starts. Post the result of your visual inspection in the comment. (No screenshot nothing else is needed)
• When system is booted run this cmd: sudo journalctl -u fan-control -n 200 -f Post the result of this command (screenshot). Visually inspect if the fan is not running, Is the log printing a line after every 5 seconds? (mention it here)
• Run this cmd: raspi-gpio get 18 Post the output of this cmd here. (screenshot)
• Run this cmd: htop -p "$(pgrep -d, fan-control)" Post the output of this cmd here. (screenshot)

Do NOT start fan-control service manually or with cronjob during this whole test.

[eltonajmenezes]

The fan after a cold boot started and then stopped, then started for 1 second and stopped completely. Then I removed all traces of the installed tool and I at least saw that it started to come on and go off by itself! So that was the culprit for the fan not starting at all. But; it only turned itself on when the temp reached closer to 50deg and not when it was above 40deg which is not expected.

Result of the command: sudo journalctl -u fan-control -n 200 -f

Result of the command: raspi-gpio get 18

Result of the command: htop -p "$(pgrep -d, fan-control)"

And I did not start the fan-control service manually or with cronjob.

FYI: Also now if you edit the temperature on the HIGH side to be 70deg and not 50deg then you do not see the fan turning on at all. It's like it only senses the max temperature boundary and even if it does sense the lower temp bound it is not turning on unless you restart the service manually or using a cron

[ar51an]

Then I removed all traces of the installed tool and I at least saw that it started to come on and go off by itself!

I specifically mentioned remove everything before starting this test.

---

then started for 1 second and stopped completely.

My guess was write you have something else that is trying to control the fan or gpio pin 18. It is your self inflicted issue. It seems like you tried too many things to control fan and most probably you do not even remember what else you did on your system for controlling fan. You might even have it enabled from raspi-config as well.

Result of the command: sudo journalctl -u fan-control -n 200 -f

You did not mention that log was moving or not when fan was not running?

FYI: Also now if you edit the temperature on the HIGH side to be 70deg and not 50deg then you do not see the fan turning on at all. It's like it only senses the max temperature boundary and even if it does sense the lower temp bound it is not turning on unless you restart the service manually or using a cron

It works perfectly fine for any temperature range. I have tested it for 30-60 | 30-70 | 40-60 | 40-70 | 40-80 | 40-90 degree ranges. The minimum RPM is 1500 so it should fire up as soon as you hit TEMP_LOW.

---

I am using it for almost 2 yrs on multiple rp4 and it works perfectly fine. This repo has biweekly hit of around 50+ and no one have complained about it. Documentation is written in the easiest possible way that newbies can understand it. Only you can figure out what else you did with your system

[eltonajmenezes]

sudo journalctl -u fan-control -n 200 -f

So when I ran this the fan moved only when it reached around 50deg celsius but not when it was above 40deg (It stopped then)

[eltonajmenezes]

So I just wiped my entire SD-Card and reinstalled a fresh copy of Raspberry Pi.

I tested it and unsurprisingly the same behavior. The fan stopped and did not turn on after crossing 41deg celsius. I followed step by step and even tested with TACHO but nothing

[ar51an]

So when I ran this the fan moved only when it reached around 50deg celsius but not when it was above 40deg (It stopped then)

I did not ask about fan running or not. I asked the log was still printing statements or not after every 5 seconds when the fan was not running after reboot. This is the third time I asked this. If the log is still printing statements with cmd "sudo journalctl -u fan-control -n 200 -f" when the fan is not running after reboot, it means something on your system has pulled down the gpio pin or changed its mode. Further proof is when you restart fan-control manually or with cronjob everything works fine. BTW screenshots in your first closed issue indicate everything was working fine without any cronjob.

I am not sure why you are so obsessed with enabling Tacho while trying to resolve the issue. It is not controlling your fan speed or anything. It only tells you the approx fan rpm that you can visually inspect as well.

One last thing you can check is that you are using latest WiringPi lib version 2.70.

Sorry can't help you further on this. You can use the one that you can make work.

[eltonajmenezes]

@ar51an Yes the log was printing every 5 seconds even when the fan was not running. But the fan didn't turn on above 40deg and only when it hit 50deg.

I cannot understand why!

I have now tried this after setting up the raspberry pi from scratch and I see without TACHO the same behavior and with TACHO.

That's my observation.

[ar51an]

Make sure you have latest WiringPi lib. Installation is just 2 step process mentioned in my documentation. https://github.com/WiringPi/WiringPi/archive/refs/heads/master.zip

You can check the WIringPi version with this cmd on rp4: gpio -v

Here are few things you can try.

Test 1:

• Connect only ground pin, 5v pin (make sure you connect it to RP4 5 volt AND NOT 3.3 volt) and PWM pin (To GPIO 18). DO NOt connect tacho pin.
• Install the pre-built binary from v1.4.
• Do not copy params.conf in /opt/gpio/fan/ dir. This dir should have only pre-built v1.4 binary.
• Reboot the system.
• Do not do anything else during this whole test. Observe the behavior visually.

If it is same as you previously replied? (fan runs at full speed, then runs for 1 second and then stops)

Test 2:

• Disable fan-control service. Reboot the system. Observe the behavior visually.

Does the fan runs on full speed and keeps on running?

---

I tried every scenario that you have mentioned and other possibilities. I am not able to replicate your issue.

[eltonajmenezes]

So the version is

eltonajmenezes@eltonsraspberrypi:~ $ gpio -v
gpio version: 2.70
Copyright (c) 2012-2018 Gordon Henderson
This is free software with ABSOLUTELY NO WARRANTY.
For details type: gpio -warranty

Raspberry Pi Details:
  Type: Pi 4B, Revision: 05, Memory: 8192MB, Maker: Sony 
  * Device tree is enabled.
  *--> Raspberry Pi 4 Model B Rev 1.5
  * This Raspberry Pi supports user-level GPIO access.

So now to your 2 asks.

1. Connected only GRND PIN, 5V, PWM to GPIO 18, DISCONNECTED TACHO
2. Used v1.4 of binary
3. did not copy params only used prebuilt and deleted the downloaded file so as to not have any potential conflicts after I copied to the directories.
4. Rebooted the system.
5. Observing the fan, yes it runs at full speed then for a second and then only when it approaches 50deg and not above 40deg

Test 2 Disabled the fan-control service and the fan runs at full speed and keeps on running.

My best understanding here and this is just an assumption: The service is starting prematurely before it can get the band of temperatures and cannot make a clear determination of when to turn on the fan. (Would there be a way of delaying the start of the service? at bootup? )

[ar51an]

Keep it simple and use the pre-built v-1.4 binary without connecting Tacho wire and without params.conf. Till everything works fine using one of the below services, then you can move on from their and use Tacho and params.conf.

Option 1: Use below service in "/etc/systemd/system/fan-control.service" it will start fan-control very late in the systemd chain.

[Unit]
Description=Fan Speed Control Service
After=multi-user.target
DefaultDependencies=no

[Service]
Type=simple
User=root
ExecStart=/opt/gpio/fan/fan-control
ExecStop=/bin/kill -s SIGINT $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target

Option 2: If first option does not give you desired results. You can further delay start of systemd service by using this service in "/etc/systemd/system/fan-control.service" . It has "ExecStartPre" which can further delay the start of only fan-control service using sleep parameter. Adjust sleep parameter accordingly, gradually increase sleep value with increments of 1 to find the optimal sleep value at which fan-control service will start without any issue. Downside of ExecStartPre is whenever you will restart service manually it will add that delay in the service start.

[Unit]
Description=Fan Speed Control Service
After=multi-user.target
DefaultDependencies=no

[Service]
Type=simple
User=root
ExecStartPre=/bin/sleep 1
ExecStart=/opt/gpio/fan/fan-control
ExecStop=/bin/kill -s SIGINT $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target

---

During testing both options, keep in mind that fan will run at full speed much longer at the startup so system temperature will be lower when the fan-control service will start. Do not rush to the conclusion that it did not work, give it some time to make sure it worked (may be few minutes).

---

There are other options as well like using custom target [OR] use systemd timer, but they will be an overkill for this simple delay and have their own downsides.

• Do you have any extra temp monitor/sensor packages or software installed? (that are not part of default OS)
• Do you use lite version of OS or full version?

---

The service is starting prematurely before it can get the band of temperatures and cannot make a clear determination of when to turn on the fan.

The fan-control service is reading system temperatures at every 5 second interval. Unless you have some extra package or software for sensor monitoring that is interfering with the default retrieval of system temperatures. Answers to above questions may give some clue.

[eltonajmenezes]

Do you have any extra temp monitor/sensor packages or software installed? (that are not part of default OS) Nothing else

Do you use lite version of OS or full version? Full Bullseye 64Bit OS of Raspberry Pi official

The referenced Option 1 DID THE TRICK!!

[Unit] Description=Fan Speed Control Service After=multi-user.target DefaultDependencies=no [Service] Type=simple User=root ExecStart=/opt/gpio/fan/fan-control ExecStop=/bin/kill -s SIGINT $MAINPID Restart=on-failure [Install] WantedBy=multi-user.target

THANK you so much for this. I rebooted and tested with and without TACHO and it worked!

[ar51an]

Full Bullseye 64Bit OS of Raspberry Pi official

I use lite 64bit Bullseye version in headless mode with further optimization to disable unwanted kernel modules. In your case full graphical Bullseye is loading extra modules and packages that are interfering with correct temperature retrieval early in the startup process.

---

You are welcome. I will add this service in the repo as well, along with updating the documentation. As part of a planned release that will make Tacho configurable through config file and few optimizations in near future.