Selecting base-32 alphabet

For a project of mine I needed a base 32 encoding. Why base-32? Well, I wanted my encoding to have a few nice properties.

Firstly, I wanted my encoding to be case insensitive. If I stick to the letters and numbers, that gives me a maximum of 36 characters to use. Nearest power of 2 value is thus 2^{5. This would allow me to use simple bit shifting to encode value, instead of dealing with big integers.}

The first alphabet that fits this requirement is one described in RFC4648.

And here my second desired property comes in play. I wanted my encoded value to retain lexicographic order of underlying data. I short, base-32 encoding of data should sort the same as underlying binary data would. And this is not what the default base-32 alphabet does. However, the same RFC4648 does specify alternative extended hex alphabet.

And this encoding was probably good enough. But, this alphabet has one subtle issue when printed out. Depending on the font, 1, I, and l can be easily mistaken for one another. Same as 0 and O.

Thus, I needed to kick some of those characters out. And the probably best implementation for such requirement already exists. And GPS lovers might already know it - Geohash.

Here we kick out I, l, O and A. This is actually the system I decided to use for Id26 output in my Uuid7 project. It was the best “standard” alphabet that fit my requirements.

However, I think I missed a good chance to bring my own alphabet to the game. Out of 5 problematic characters, I can remove 4. After giving it some thought and going over multiple fonts, I’ve settled on removing I, l, 0, and O. These characters looked the most similar to my eyes and thus had to go. The resulting alphabet is in table below.

Now, am I overthinking it? Probably. But there is a reason why there are so many base-32 alphabets around - everybody got their itch to scratch.

PS: For curious, here are the most common base-32 alphabets.

Virtual MQTT Sensor in Home Assistant

As I keep using Home Assistant for my home temperatures, I started looking at my hard disks. Why shouldn’t I see their temperatures in Home assistant too? Well, considering I’m using MQTT already, that wasn’t that hard.

The first step was installing MQTT client on my machine.

sudo apt install -y mosquitto-clients

Once client was installed, I was ready to create a device with a single command.

Register device (notice -r to retain config it in MQTT so HA can rediscover it).

mosquitto_pub -h 192.168.1.1 -p 1883 \
              -u 'mqttuser' -P 'password' \
              -t 'homeassistant/sensor/virtual_disk_test_device/temperature/config' -r -m \
  '{
    "name": "Temperature",
    "unique_id": "virtual_disk_test_temperature",
    "state_topic": "homeassistant/sensor/virtual_disk_test_device/temperature/state",
    "device_class": "temperature",
    "state_class": "measurement",
    "unit_of_measurement": "°C",
    "device": {
      "identifiers": ["virtual_disk_test_device"],
      "name": "Disk",
      "manufacturer": "Virtual",
      "model": "Test"
    }
  }'

With this, our new disk temperature device should instantly become visible in Home Assistant. If you made an error, you can remove device using the same topic and -n.

mosquitto_pub -h 192.168.1.1 -p 1883 \
              -u 'mqttuser' -P 'password' \
              -t 'homeassistant/sensor/virtual_disk_test_device/config' \
              -r -n

Alternatively, if you wish to monitor messages, you can also subscribe using mosquitto_sub.

mosquitto_sub -h 192.168.1.1 -p 1883 \
              -u 'mqttuser' -P 'password' \
              -t 'homeassistant/sensor/virtual_disk_test_device/config' -v

And now finally, we can send temperature using mosquitto_pub.

mosquitto_pub -h 192.168.1.1 -p 1883 \
              -u 'mqttuser' -P 'virtual_disk_test_device' \
              -t 'homeassistant/sensor/virtual_disk_test_device/temperature/state' -r -m '23.5'

If you script around smartctl, this is all you need. However, if you need a bit of a starting point, I’m also including an example.

Lowering Bazzite Power on Framework Intel Gen 11

My home theater setup is an old Framework 13 Intel Gen 11 board. Connected directly to TV, it makes for a nice home theater machine. But, one thing has bothered me for a while now - high power usage in idle.

After a bit of investigation, cause was clear: excessive interrupts. A minute after a restart, it was already close to million.

cat /proc/interrupts | grep snd_hda_intel

  16:          0          0          0          0          0          0     644440          0  IR-IO-APIC                 16-fasteoi   intel_ish_ipc, i801_smbus, snd_hda_intel:card0

Since the same interrupt line is used by multiple modules, I started disabling them in order. And stuck the gold on the first try. After applying changes, interrupt frequency reduced greatly.

sudo rpm-ostree kargs --append="module_blacklist=intel_ish_ipc"
systemctl reboot

I didn’t really investigate why intel_ish_ipc was causing a fuss. My assumption is that Framework’s laptop mainboard simply didn’t take nicelly to a new life as a desktop computer and one of the sensors was misbehaving as it hung on the back of TV. Or something completely different. Since system can live happily without this module, I was more than willing to close my eyes to the exact cause.

Leap No More

Everyone who worked in computer for a while has a story about leap second. I still remember “fun times” when Cisco crapped its pants back in 2016, But, like year-2K bugs, this will be just a story to scare young engineers.

Like most good news these days, this one too comes from the Europe. At the General Conference on Weights and Measures it was decided that leap seconds are dead as of 2026-10-15. As part of Resolution 5, no further adjustment between astronomical and “real” time is to be done. In short, 17 extra seconds that were added will remain but no further adjustment will be done until difference reaches 1 hour. Since 1 hour has 3600 seconds, unless something really unexpected happens, that’s not problem I will deal with.

As someone who had to deal with testing of leap second behavior quite a few times, good riddance! While I might be insensitive to the plight of astronomers that will now need to pay attention to this difference, I am happy not to have this in my life. Now, only to get rid of daylight savings time changes… :)

HA Redirect

One of the first thing you ought to do with Home Assistant is to setup SSL/HTTPS. It is mandatory if you plan to expose it to the world and good idea even on your local network. But one thing was bugging me when I got my HTTPS setup. Home Assistant wouldn’t redirect good old port 80 requests to the new HTTPS port. Nope, it would just listen on port 443.

And yes, strictly speaking, that is acceptable behavior. But, after being redirected to error page one more time, I decided to do something about it.

After messing a lot with Nginx add-in, I figured that either I am doing something wrong or Nginx add-on simply cannot be configured to do what I want. And, realistically, I needed something much simpler than that. As it often happens, I decided to see how hard is it to make Home Assistant add-on. Good new - it is not that hard.

Fruit of that research is HA Redirect add-on. It is a simple Alpine-based nginx installation that will listen on port 80 (configurable). And the only thing that it does is a humble redirect.

At the same time, I think it is a great example of minimal Home Assistant add-on. It is as close as one can get to the bare minimum while still providing a service.

Now, this app might not be needed for everybody. Maybe you were more successful in setting up Nginx add-on or this “issue” doesn’t bother you because you use HSTS so https redirect will be remembered. Or you were better than me at finding already existing solution. But, if you do have the same issue I had, this add-on might be for you.

Project is available on GitHub.