I recently acquired an 8Gb Raspberry Pi 4 and promptly installed Ubuntu 20.04 on it to see how it worked. Right away, I was excited that the PoE Hat worked and that it booted without any problems, except that the fan on the Hat was no longer controllable the way that it used to be.
It appears that the old way of using config.txt and friends to override those settings no longer works.
Here’s what you need to do:
sudo nano /etc/udev/rules.d/50-rpi-fan.rules
Put this in it to start with, and tweak as needed for your situation:
SUBSYSTEM=="thermal"
KERNEL=="thermal_zone3"
# If the temp hits 81C, highest RPM
ATTR{trip_point_0_temp}="82000"
ATTR{trip_point_0_hyst}="3000"
#
# If the temp hits 80C, higher RPM
ATTR{trip_point_1_temp}="81000"
ATTR{trip_point_1_hyst}="2000"
#
# If the temp hits 70C, higher RPM
ATTR{trip_point_2_temp}="71000"
ATTR{trip_point_2_hyst}="3000"
#
# If the temp hits 60C, turn on the fan
ATTR{trip_point_3_temp}="61000"
ATTR{trip_point_3_hyst}="5000"
#
# Fan is off otherwise
When trying to use Disk Utility to make a backup of one of my Raspberry Pi’s, I was repeatedly seeing an error that was causing my backup to fail.
Operation cancelled
Disk Utility
Not particularly helpful.
For me, the fix involved setting the Disk Utility application to have Full Disk Access inside macOS System Preferences, under Security & Privacy, and then Privacy.
Once I did this, everything started working again! 🥳
At the beginning of April, GitLab updated their repository signing key. If you try to update, you will see an error during sudo apt update :
W: An error occurred during the signature verification. The repository is not updated and the previous index files will
be used.
GPG error: https://packages.gitlab.com/gitlab/gitlab-ee/ubuntu bionic InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 3F01618A51312F3F
W: Failed to fetch https://packages.gitlab.com/gitlab/gitlab-ee/ubuntu/dists/bionic/InRelease The following signatures couldn't be verified because the public key is not available:
NO_PUBKEY 3F01618A51312F3F
W: Some index files failed to download. They have been ignored, or old ones used instead.
The easiest fix appears to be simply to update the signing key:
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:
/opt/vc/bin/vcgencmd measure_temp
And you’ll get something like:
temp=42.0'C
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.
Name: rpi-poe
Info: Raspberry Pi PoE HAT fan
Load: dtoverlay=rpi-poe,<param>[=<val>]
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
dtparam=poe_fan_temp0=65000,poe_fan_temp0_hyst=5000
dtparam=poe_fan_temp1=67000,poe_fan_temp1_hyst=2000
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.
A lot of folks online are being critical of Ubiquiti about releasing the UDM Pro with the features it has and the hardware it’s configured with, because they feel it does not have the same obvious market fit that most of their other hardware has always had prior to it.
I believe that the UDM Pro makes big economic sense for Ubiquiti, and will likely carry their “Gen2” products onwards to be their most successful lineup so far.
The UDM Pro is priced competitively ($379 USD) against their own Security Gateway Pro ($344 USD) while also being physically more powerful in every way. Nearly everyone is going to choose the newest one for $55 more over the older one (which is obsolete anyways) for the power capabilities alone.
Ubiquiti’s goal with the UDM Pro is to give everyone an appliance that can easily run Protect, Access, and Talk at the same time, to help them get a basic understanding of what they are and how they work (and inevitably outgrow them) at which point they can up-sell you to their dedicated Protect, Access, and Talk appliances. The UNVR for Protect is the only one of those available in the Early Access store, and I’m assuming dedicated Access and Talk controllers are in the pipeline.
If the UDM Pro were more expensive – say $500 USD, the value proposition against the USGP alone wouldn’t make much sense anymore, especially if you don’t need 10G and don’t care about having the newest hardware.
And if the UDM Pro were simply an upgraded Gateway without the hard drive bay and 8 port switch, it wouldn’t also replace their CloudKey appliances and wouldn’t be able to run Protect, Access, or Talk.
In my observations, the people being the most critical are the ones who should be the most excited: professional installers. They don’t seem to see (or care) how huge of an up-sell opportunity Ubiquiti has handed everyone with the UDM Pro being what it is. Now every networking client that asks “hey how about cameras/phones/nfc readers” already has what they need to get started and room to expand later.
On paper, the UDM Pro is not the most powerful device of its kind when compared to some Cisco or pfSense alternatives, but I think Ubiquiti is taking a page from the Apple playbook here, and trusting that their tight software integration will be enough of a draw to win people over, and I believe this will work out positively for them in the long run.
My UDM Pro will arrive this afternoon via UPS (shout out to our super cool UPS driver!) and I’m excited for it to replace the USGP and Raspberry Pi 3 in my server rack.
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.)
What happened?
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.
My dad passed away just before New Year’s, at 75 years young.
I was the most involved with him near the end, so I’m also helping with everything that is now happening afterwards.
He was in hospice at the Veteran’s Home in King, Wisconsin. It was not sudden, and everyone else around him is doing OK. He was a cook in the army, and let me tell ya… his approach to cooking did not deviate very far from what he learned there.
He bought me my very first computer (maxing out a credit card at Sears in the process) that I used to teach myself Visual Basic and did a ton of early-internet experimenting with, even though he didn’t really understand why I wanted it so desperately or why the phone line was always clogged-up because of it.
It was a Packard Bell Pentium 100, with 8Mb of RAM and a SoundBlaster 16. Most of the time it smelled like cigarettes and warm plastic, but I spent nearly every waking moment on that thing until its heart gave out.
My dad was a hard worker. He was cantankerous. He was loyal and dedicated. He wasn’t school smart (he never really learned to read or write) but he was a veracious observational thinker and enjoyed sharing whatever his latest epiphanies were. He was always ten steps ahead, and always had a hard time explaining how he got there.
He… did not really care about what was appropriate. He spoke his mind, right or wrong. Sometimes funny. Sometimes mean. Sometimes really mean. Sometimes really funny.
He only ever had a single job, from age 15 to 60, as a Sexton at Forest Home Cemetery in Milwaukee. It was not an easy job, and I think he secretly enjoyed the hour commute from East Troy because it gave him some alone time, but he did not look forward to his working overtime on Saturday or Sunday as much as I did.
For me, it meant I’d get to go with him into the big city and ride my bike all around his work, possibly scoring a trip to Toys-R-Us afterwards. For him, it meant a few extra hours of overtime to give up his entire weekend, which was usually reserved for keeping the house and cars running, or splitting wood to prepare for winter.
He did his best with me, and I think that’s all any dad can do with a boy as uncompromising and intractable as his daddy.
A lot of people spend their whole lives trying to not be like their parents. I’ve tried to embrace what they made me to be, the next version of them both with the hope that their next revision ends up as more than just bug fixes & performance improvements.
My dad did what I think good dads are supposed to do. He made sacrifices and learned from most of his mistakes. He was always there when I needed anything. He made me figure stuff out on my own. He cared in all the ways he knew how.
His version of teaching me to drive a stick-shift was “here’s the key, figure it out, try not to wreck it, I need it to get to work.” I figured it out, I didn’t wreck it (right away) and he got to work just fine.
Alas, my dad’s overworked heart gave out too, as overworked hearts are prone to do. Dads aren’t perfect, and but mine was for me. Even as thorny as he could be.
