<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Automation on Charlie Howlett</title>
		<link>https://charliehowlett.co.uk/tags/automation/</link>
		<description>Recent content in Automation on Charlie Howlett</description>
		<generator>Hugo</generator>
		<language>en-gb</language>
		
		
		
		
			<lastBuildDate>Sat, 22 Aug 2026 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://charliehowlett.co.uk/tags/automation/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Automating Backing Tracks</title>
				<link>https://charliehowlett.co.uk/posts/2026-08-22-automating-backing-tracks/</link>
				<pubDate>Sat, 22 Aug 2026 00:00:00 +0000</pubDate>
				<guid>https://charliehowlett.co.uk/posts/2026-08-22-automating-backing-tracks/</guid>
				<description>&lt;p&gt;When rehearsing, alone or with others, I sometimes like to play along to backing tracks with a few of the original instrument parts removed. My &lt;a href=&#34;https://charliehowlett.co.uk/posts/2025-05-03-building-compact-hybrid-drumming/&#34;&gt;hybrid drumming rig&lt;/a&gt; works well for this, but preparing the backing tracks can be a pain. Typically, I&amp;rsquo;d download an MP3 of the song, manually upload it to a stem-separation service, then re-export it in the TM-2’s expected format: stereo 44.1 kHz PCM WAV. This works, but preparing a couple of songs for a rehearsal can take quite a bit of time.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Managing My Homelab with Ansible</title>
				<link>https://charliehowlett.co.uk/posts/2026-08-18-managing-my-homelab-with-ansible/</link>
				<pubDate>Tue, 18 Aug 2026 00:00:00 +0000</pubDate>
				<guid>https://charliehowlett.co.uk/posts/2026-08-18-managing-my-homelab-with-ansible/</guid>
				<description>&lt;p&gt;In previous posts, I described how I set up my &lt;a href=&#34;https://charliehowlett.co.uk/posts/2026-05-22-repurposing-a-laptop-as-a-home-server/&#34;&gt;repurposed laptop server&lt;/a&gt; and &lt;a href=&#34;https://charliehowlett.co.uk/posts/2026-06-12-raspberry-pi-server-rack/&#34;&gt;Raspberry Pi server rack&lt;/a&gt;. Together, they have grown into a useful little homelab.&lt;/p&gt;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&lt;img&#xA;  class=&#34;image-large&#34;&#xA;  src=&#34;https://charliehowlett.co.uk/posts/2026-08-18-managing-my-homelab-with-ansible/homelab-topology.svg&#34;&#xA;  alt=&#34;Topology diagram showing SSD directly connected to Raspberry Pi 3, with all hosts connected to a shared Ethernet bus.&#34;&#xA;  decoding=&#34;async&#34;&gt;&#xA;&#xA;&#xA;&lt;p&gt;The top-level topology is simple, but the deployed services and their configuration complicate things quickly.&lt;/p&gt;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&#xA;&lt;img&#xA;  class=&#34;image-large&#34;&#xA;  src=&#34;https://charliehowlett.co.uk/posts/2026-08-18-managing-my-homelab-with-ansible/homelab-topology--services.svg&#34;&#xA;  alt=&#34;Topology diagram showing applications deployed on each homelab host: the server laptop runs Super Productivity, a productivity planner; every host runs Alloy; Pi 2 also runs device monitoring and Git Auto Sync, while Pi 3 hosts SSD storage, Samba, PostgreSQL, and the Grafana and Loki monitoring stack.&#34;&#xA;  decoding=&#34;async&#34;&gt;&#xA;&#xA;&#xA;&lt;p&gt;It can be tricky to keep track of:&lt;/p&gt;</description>
			</item>
			<item>
				<title>Automating LinkedIn Cross-Posting</title>
				<link>https://charliehowlett.co.uk/posts/2026-08-05-linkedin-cross-posting/</link>
				<pubDate>Wed, 05 Aug 2026 00:00:00 +0000</pubDate>
				<guid>https://charliehowlett.co.uk/posts/2026-08-05-linkedin-cross-posting/</guid>
				<description>&lt;p&gt;I&amp;rsquo;ve been writing posts here for quite a while, and during that time the site has grown to cover a fairly wide mix of topics. I felt it would be nice to share that work with a larger audience, so I decided to implement a CI/CD pipeline for automatically cross-posting to LinkedIn.&lt;/p&gt;&#xA;&lt;h2 id=&#34;implementation&#34;&gt;Implementation&lt;/h2&gt;&#xA;&lt;p&gt;I originally considered using Zapier for this, but the free tier did not offer the functionality I needed, so I built a small publishing pipeline myself using GitHub Actions.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Monitoring My Homelab with Grafana</title>
				<link>https://charliehowlett.co.uk/posts/2026-06-17-monitoring-my-homelab-with-grafana/</link>
				<pubDate>Wed, 17 Jun 2026 00:00:00 +0000</pubDate>
				<guid>https://charliehowlett.co.uk/posts/2026-06-17-monitoring-my-homelab-with-grafana/</guid>
				<description>&lt;p&gt;Once I had several processes running continuously in my homelab, I needed a single place to inspect what they were doing. Connecting to a machine via SSH and reading logs directly is useful, but hardly convenient, so I set up an observability platform. I use Grafana for querying and visualising logs, Loki for storing and querying logs, and Grafana Alloy for collecting and forwarding logs. The components run as Docker containers on a Raspberry Pi with an attached SSD for persistent storage.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Git Auto Sync</title>
				<link>https://charliehowlett.co.uk/posts/2026-06-14-git-auto-sync/</link>
				<pubDate>Sun, 14 Jun 2026 00:00:00 +0000</pubDate>
				<guid>https://charliehowlett.co.uk/posts/2026-06-14-git-auto-sync/</guid>
				<description>&lt;p&gt;After setting up my &lt;a href=&#34;https://charliehowlett.co.uk/posts/2026-06-12-raspberry-pi-server-rack/&#34;&gt;Raspberry Pi home lab&lt;/a&gt;, I deployed a small project onto one of the Pis and immediately wanted a cleaner method for continuous deployment. The app lived in a Git repository, and I wanted the running copy on the Pi to update automatically whenever the repo changed.&lt;/p&gt;&#xA;&lt;p&gt;The obvious approach would have been a webhook: GitHub sends a request, a local service receives it, and the Pi pulls the latest code. I decided against that for security reasons. I did not want to expose a service on my home network just so GitHub could tell it that a commit had landed, and I did not want to build a tunnel or webhook receiver for something that could be solved more simply.&lt;/p&gt;</description>
			</item>
			<item>
				<title>GitHub Action to Automate Screenshots</title>
				<link>https://charliehowlett.co.uk/posts/2026-05-06-update-screenshots-action/</link>
				<pubDate>Wed, 06 May 2026 00:00:00 +0000</pubDate>
				<guid>https://charliehowlett.co.uk/posts/2026-05-06-update-screenshots-action/</guid>
				<description>&lt;p&gt;Screenshots can make project documentation much clearer, but they quickly become misleading when they fall out of date. I built update-screenshots-action to automate that maintenance: capture a web page, save the image in the repository, and update a known section of a Markdown file.&lt;/p&gt;&#xA;&lt;h2 id=&#34;implementation&#34;&gt;Implementation&lt;/h2&gt;&#xA;&lt;p&gt;The action takes a URL, opens it in Chromium through Playwright, and captures either a PNG or an animated GIF at a repository-relative path. It then rewrites a marked block in a Markdown file so the reference remains in sync with the generated asset. Optional commit-and-push support allows the action to run on a schedule or after changes to a site without requiring additional workflow steps. Even within that narrow scope, running reliably in CI required handling several operational details. Navigation is retried while local preview servers start, and commits are only created when one of the managed files has actually changed.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Automating Lights with a Raspberry Pi</title>
				<link>https://charliehowlett.co.uk/posts/2021-09-02-pi-lights/</link>
				<pubDate>Thu, 02 Sep 2021 00:00:00 +0000</pubDate>
				<guid>https://charliehowlett.co.uk/posts/2021-09-02-pi-lights/</guid>
				<description>&lt;p&gt;Pi Lights was a fairly simple idea and my first exploration into DIY home automation: measure the ambient light level throughout the day using a Raspberry Pi, then switch Wi-Fi lights on or off automatically.&lt;/p&gt;&#xA;&#xA;&#xA;&#xA;&lt;div class=&#34;video-frame teletext-box&#34;&gt;&#xA;  &lt;iframe&#xA;    class=&#34;video-frame__iframe&#34;&#xA;    src=&#34;https://www.youtube-nocookie.com/embed/ZpO6WK41Bb8&#34;&#xA;    title=&#34;Pi lights demo video&#34;&#xA;    loading=&#34;lazy&#34;&#xA;    allow=&#34;accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share&#34;&#xA;    referrerpolicy=&#34;strict-origin-when-cross-origin&#34;&#xA;    allowfullscreen&gt;&#xA;  &lt;/iframe&gt;&#xA;&lt;/div&gt;&#xA;&#xA;&lt;h2 id=&#34;implementation&#34;&gt;Implementation&lt;/h2&gt;&#xA;&lt;p&gt;The system polls several light-dependent resistors and averages their readings before deciding whether to switch the lights. Using multiple sensors and rate-limiting changes made the automation less sensitive to brief shadows or sudden changes in brightness. A dedicated light-sensing Raspberry Pi HAT would have been more accurate, but I wanted to see if I could build a first pass using components I already had lying around. I ran the software as a Linux service so it would start automatically and continue working in the background without needing any attention.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
