I noticed yesterday that the fans on the PoE Hat of my Raspberry Pi 4’s were behaving strangely. They were both kicking on based more on time than temperature, even though neither of them seemed that hot.
You can check the temperature via the command line like this:
And you’ll get something like:
That didn’t seem hot enough to me to warrant the fans going full blast, and it doesn’t help that these fans have a high-pitched whine to them, making them audibly louder than all of my rack mounted Ubiquiti gear.
I decided to take the fan configuration into my own hands, but I had to go hunting for the proper settings first.
Info: Raspberry Pi PoE HAT fan
Params: poe_fan_temp0 Temperature (in millicelcius) at which the fan turns on (default 50000)
poe_fan_temp0_hyst Temperature delta (in millicelcius) at which the fan turns off (default 5000)
poe_fan_temp1 Temperature (in millicelcius) at which the fan speeds up (default 55000)
poe_fan_temp1_hyst Temperature delta (in millicelcius) at which the fan slows down (default 5000)
Open Nano to edit the boot config, like this:
sudo nano /boot/config.txt
Near the bottom add something like this:
# PoE Hat Fan Speeds
Then, reboot! Now, the fans won’t kick on until they hit 65’C, they’ll speed up at 67’C. For my setup, that silences them almost completely, while still keeping them reasonably cool and safe.
If you’re like me, then you probably searched the web for a clue, maybe found some threads in the UI.com Community Forums, but ultimately left feeling pretty uneducated about what it number means and anything you should do about it.
Good news! This number being high isn’t going to negatively impact the performance of your network, but it also isn’t good. It’s the equivalent of a denial-of-service attack. Some wireless device is trying and failing to connect to your network, over and over again.
This happened to me and my home network after tuning my WiFi Access Point channels and Hue Bridge channels, trying to avoid as much interference between them as possible. After a few hours of RF scans and reconfigurations triggering reboots, I saw this number skyrocket from single-digits to over 10k eventually. (Keep in mind that I’d only switched WiFi channels, and did not rename the SSID or password, and didn’t enable or disable any 2.4 or 5 gigahertz bands.)
The SSID and Passwords on all devices in my home were set and working totally fine before, so why all of a sudden would rebooting a few access points cause problems? My best guess is that something related to DTIM simply prevented a properly configured wireless client from successfully reconnecting to the network, but I’m honestly not really sure.
What should I do?
If you are in control of the wireless devices that connect to your network (like a home network or a small office) then this is completely within your power to fix.
All you need to do is figure out which wireless device(s) are trying and failing.
The Unifi Network Controller software does not give you any tools or logs to help you here. You’ll simply need to deduce on your own what they are.
Depending on the number and types of devices on your network, this deduction/elimination process may not be super simple. I started with problematic devices first, but resetting them didn’t help. I used the Unifi Network Controller Client list to go through them one at a time and check them manually.
My iPad Pro was successfully connected to my wireless network according to Network Controller, and that iPad was showing up as a connected HomeKit hub on Standby, so clearly it’s connecting, right?
The first time I had this happen, it was a Nintendo 3DS XL. But recently, it was that darned iPad Pro! Touching the screen revealed it was connected to LTE, and not WiFi. I opened the Settings app and went to WiFi, but connecting to the SSID for my home failed, and prompted me to update the password. Typing in the same password did not allow the device to connect either time. I needed to delete the SSID from the settings, and add it back in.
This was tricky on the iPad Pro, because the WiFi networks you connect your devices to get saved in your iCloud account. Removing it from one device removes it from others, which meant I needed to reconnect my iPhone and my laptop too.
Having done so, this number has reduced itself down to a more reasonable value:
It would be nice if the Network Controller logged failed attempts to access the network somewhere. I get that this could probably be easily spammed, but it isn’t a super good experience to show off some huge scary number without any indication as to what is going wrong or what to do about it.
systemctl status homebridge to check the service status.
Contents of /etc/defaults/homebridge:
# Defaults / Configuration options for homebridge
# The following settings tells homebridge where to find the config.json file and where to persist the data (i.e. pairing and others)
# If you uncomment the following line, homebridge will log more
# You can display this via systemd’s journalctl: journalctl -f -u homebridge
Contents of /etc/systemd/system/homebridge.service:
At 4:33am this morning, a lady passed our house, slammed on her brakes, threw her car in reverse, threw her hazards on, parked facing oncoming traffic, on a state highway, to steal 2 steel goats we had on our front lawn.