Camiel Schoonens

Testing my Canon RF 15-35mm with a Benro Pro Filter Kit

2026-06-09T00:00:00Z

I recently added two new pieces to my photography gear, the Canon RF 15-35mm f/2.8L IS USM and the Benro Pro Filter Kit. The RF 15-35mm is a huge step up from the RF 16mm prime I have had in my bag for the last two years. I took both the new lens and the filter kit out for the first time tonight with the purpose to practice working with the setup before going on summer holiday.

As you can see, the lens at the wide end at 15mm gives a sense of depth and space that works well in landscape photography, I look forward to using it a lot this summer in Costa Rica.

The filter kit

The Benro kit I bought includes a filter holder, a 2-stop graduated ND and a 3-stop graduated ND, plus a 6-stop solid ND. The system uses a slot-in holder with a gear-driven knob to position the graduated filters. The system is expensive but the build quality is really good. That said, I still need a lot of practice to get the filter positioning right consistently. One practical issue: the two graduated filters (2-stop and 3-stop) are nearly impossible to tell apart in the field. They are the same size and shape, and the difference in glass density is not visible to my eye. I need to find a way to tag or mark them so I can grab the right one without holding each up to the light.

What I shot

Shot 1/3 - Canon EOS R6 Mark II + RF 15-35mm f/2.8 L IS @ 16mm without filters

Shot 2/3 - Canon EOS R6 Mark II + RF 15-35mm f/2.8 L IS @ 16mm with a 3-stop graduated ND

Shot 3/3 - Canon EOS R6 Mark II + RF 15-35mm f/2.8 L IS @ 16mm with a 3-stop graduated ND combined with 6-stop ND

Canon EOS R6 Mark II + RF 15-35mm f/2.8 L IS @ 15mm with a 2-stop graduated ND

Canon EOS R6 Mark II + RF 15-35mm f/2.8 L IS @ 35mm with a 3-stop graduated ND

Tracking Max Verstappen's private jet with Home Assistant and ADS-B

2026-05-19T00:00:00Z

Every commercial and private aircraft broadcasting ADS-B is publicly visible to anyone willing to poll the right API. Max Verstappen's Dassault Falcon 900 with registration PH-UTL (Unleash The Lion) is no exception. I thought it would be fun to wire this into Home Assistant and have a dedicated Mastodon bot post updates whenever the jet takes off or lands somewhere.

The result is @waarismax on my own Fediverse instance. It posts publicly whenever PH-UTL moves. The bot posts in Dutch.

Why

Because I could.

Finding the data

adsb.lol is a free, no-auth API that queries live ADS-B data by ICAO hex code. A single GET request returns the current position and state of any broadcasting aircraft:

https://api.adsb.lol/v2/icao/4867e6

When the aircraft is airborne, the response includes an ac array with fields for altitude, ground speed, lat/lon, callsign, and more. When it's on the ground with its transponder off, ac is empty and total is 0. That on/off toggle is the trigger for the automations.

The sensor setup

Everything lives in configuration.yaml. A rest: block polls the API every 60 seconds and derives six sensors from the response: status (airborne/offline), altitude, speed, latitude, longitude, and flight number.

The max_jet_status sensor is the key one. It flips between airborne and offline and is what the takeoff and landing automations watch.

Reverse geocoding the position

Lat/lon coordinates are not readable in a Mastodon post. I wanted "Keulen, Duitsland" rather than "50.868, 7.121". OpenStreetMap's Nominatim API handles this for free, with no API key required, as long as you respect the fair use policy.

Rather than polling Nominatim on a fixed interval, a rest_command calls it on demand and a dedicated automation fires that command whenever the aircraft's latitude changes state. This means Nominatim only gets called when the aircraft is actually moving.

A city → town → village fallback chain handles the fact that Nominatim doesn't always return a city field, depending on how rural the position is.

The Mastodon bot

I created a separate Mastodon account @waarismax@social.schoonens.nl on my self-hosted instance and connected it to Home Assistant.

The automations

Two automations watch sensor.max_jet_status and post to the bot when it changes. A for: duration of 5 minutes debounces brief signal dropouts. One automation handles takeoff (offline to airborne), one handles landing (airborne to offline).

Building a network monitoring dashboard in Home Assistant

2026-05-15T00:00:00Z

I run a full UniFi stack at home, a Cloud Gateway Fiber Gateway (UCG), five different switches, and five access points spread across the house. The UniFi integration for Home Assistant gives you device status and connected client counts, but it doesn't expose bandwidth data as sensors. I wanted to see real-time throughput on my HA dashboard. This post documents how I built that.

Why SNMP

My first instinct was to look for a purpose-built integration, but nothing reliable existed for per-AP bandwidth at the time. The UniFi switches (USW Flex 2.5G) don't support SNMP at all, which ruled out the obvious approach of polling switchport counters. The gateway and access points do support SNMP though, which turned out to be enough.

SNMP is the right approach as every UniFi device keeps internal byte counters per interface. By polling those counters periodically, you can calculate throughput as a delta over time. The performance impact is negligible, a few hundred bytes per query over UDP, even at 10-second intervals.

Setting up SNMP

SNMP is disabled by default on the UCG. Enable it under Settings > System > SNMP in the UniFi console, set version to SNMP v2c, and note your community string.

Before adding any sensors to Home Assistant, I used snmpwalk from my Mac to identify the right interface:

snmpwalk -v2c -c homelab 192.168.1.1 1.3.6.1.2.1.2.2.1.2

This returns all interfaces the device knows about. For my UCG, the WAN uplink is eth6.701. VLAN 701 is what my ISP uses. The interface index was 21.

The sensor pipeline

Getting from raw SNMP data to a Mbit/s reading in Home Assistant takes three layers:

1. SNMP sensors — raw cumulative byte counters, tagged state_class: total_increasing so HA handles resets correctly.

2. Derivative sensors — calculate the rate of change in octets per second. A time_window of 30 seconds smooths out polling jitter without introducing too much lag.

3. Template sensors — convert octets/s to Mbit/s (octets × 8 / 1,000,000). A | max with 0 prevents negative spikes when the derivative briefly dips below zero.

I went through a few failed approaches before landing on this pipeline. My first attempt used template sensors that stored the previous value as an attribute and calculated the delta themselves. This fails because HA evaluates current and previous_value in the same render cycle, so the delta is always zero. The derivative platform solves this cleanly by doing the math in HA's core rather than in a template.

The dashboard

For the WAN graph I used mini-graph-card. It's cleaner than apexcharts for simple time-series and doesn't need a formatter function to display units.

Data usage tracking

Once the SNMP sensors were in place, adding daily and monthly data counters was straightforward using utility_meter. I added template sensors on top to convert octets to GB for display, since raw octet values in the billions are not useful on a dashboard card.

A note on entity IDs

One thing that caused me grief: when migrating from the legacy platform: template syntax to the modern template: block syntax (required since HA 2026.6), entity IDs change. The fix: always set unique_id on every sensor. HA uses the unique_id as the stable internal identifier, so renaming via the UI won't break references.

Building a travel website with Jekyll and Cloudflare Pages

2026-05-04T00:00:00Z

Over the past few days, I worked with Claude to build a travel website from scratch for our upcoming family trip to Costa Rica this summer. The result is puravidareis.nl, a Jekyll-based site using the Chirpy theme, hosted on Cloudflare Pages with automatic deployments triggered by Git pushes.

To round out the static site stack, I added Cloudflare R2 for image hosting, Matomo for privacy-friendly analytics, and an RSS-to-Mastodon pipeline that automatically sends toots when new posts go online. The workflow is straightforward: I write a post on my iPhone or iPad via Working Copy, push it to GitHub, and Cloudflare builds and deploys the website in under 60 seconds.

My photo cleanup workflow

2026-04-25T00:00:00Z

I have 25 folders (filled with many subfolders) filled with photos from 2001 to 2026. All the folders are stored on my NAS. When I import new photos from my DSLR into Lightroom, I automatically back up the photos to my NAS drive. For pictures taken on the four iPhones in our household, I back up the images from iCloud to my NAS, usually once a year. The result of this process? There are thousands of JPEG files in these folders, and since 2023 the number of pictures we take has increased exponentially.

I've long wanted to clean up this digital mess by removing duplicate photos and selecting one photo from a series of photos. The purpose of all this is not to save disk space; it's to create physical photo albums for the years since we have children and are a family.

I've made use of the following two macOS apps: PhotoSweeper and ExifRenamer. This is my approach:

Create a zip file of every single year folder for backup purposes. Upload these to Backblaze, my off-site S3 backup solution.
Copy a single folder with all subfolders from my NAS to my desktop computer, mainly for performance reasons while processing, but also to create a working folder without touching the files on my NAS.
Have PhotoSweeper analyze the contents of the year folder and subfolders. My desktop computer is an M4 Mac Mini, and PhotoSweeper is incredibly fast at this.
Manually go through three types of comparisons PhotoSweeper does: filename and EXIF comparison, series comparison for images taken within one minute of each other, and having the app's algorithm handle image comparison by looking at the images.
Mark all the images I want to delete based on the analysis, following PhotoSweeper's advice about which one to delete 9 out of 10 times.
Let PhotoSweeper delete all the marked photos.
I'm now left with a cleaned-up annual folder with no more duplicate photos or burst series.
The final processing step is to have ExifRenamer go through the folders and move the individual JPEG images to a new folder while updating the filenames based on the EXIF data. I name the files with the following syntax: yyyymmdd hhmmss – (Camera Name).jpg.
The result is a cleansed annual archive of images sorted alphabetically in the file system.

Travelling with the Ubiquiti UniFi Travel Router

2026-04-22T00:00:00Z

I run a full UniFi stack at home. I have a UniFi Cloud Fiber gateway, multiple switches and APs, a doorbell and a set of Protect cameras covering my property. UniFi is my go-to brand for networking and security. Yes, it's expensive, but the convenience of a product that works is worth it, if you ask me.

Before picking up the UniFi Travel Router (UTR), my mobile networking setup was already solid and secure. I have dedicated WireGuard VPN connections on every mobile device in my household that auto-connect based on SSID identification. It worked fine and it still does. The UTR is not a fix for a broken setup, it's the elimination of the friction of having to connect to public wifi on multiple devices.

Until today, I had a setup with per-device WireGuard installations and an SSID-based auto-connecting VPN. It is a legitimate solution that served me well for years. But it also has a consistent pain point: public wifi captive portals. Every device needs to hit the portal individually before the tunnel can come up. This is time-consuming and sometimes not even possible when hotels or airlines limit the number of devices you can connect.

The UTR collapses that entirely. The UTR connects to the hotel Wi-Fi. You sign in to the captive portal via the UniFi app, and that's it. Once the UTR is online it sets up the WireGuard tunnel to my Cloud Fiber Gateway at home and I'm ready to go. Every device behind the UTR is online and tunneled immediately.

The UTR is a real travel device. It's small and runs on just 5W, so any USB port works. The device has two USB-C ports (one for power and one for tethering) and two GbE RJ45 ports for WAN and LAN connections. You can configure the WAN port as an additional LAN port if needed. The case does get warm under load. The radio stack is Wi-Fi 5, which is dated but, in practice, not a bottleneck for day-to-day usage.

Home Assistant Bot tracks planes flying over my house

2026-04-21T00:00:00Z

I have a small Home Assistant Bot running on my own Fediverse instance. It sends me private messages about what's happening around the house. At some point I thought: why stop at lights and energy monitoring when I can do more fun things by connecting different APIs?

So I connected the bot to Flight Radar.

What it does

Whenever a plane flies over my house on its approach to Amsterdam Schiphol, the bot sends me a (Dutch) private message on Mastodon with all the details:

The airline and flight number
Origin and destination
The altitude at which it's passing
The expected arrival time at Schiphol

Why the Fediverse?

Because I could.
I already run a Mastodon instance for our household, so the Fediverse was a natural fit. The bot posts directly to my account as a private/direct message, which means no extra apps, no push notification service to maintain — just a message popping up in my timeline like any other. It keeps everything self-hosted and under my control, which fits perfectly with the spirit of both Home Assistant and the Fediverse.