Too many taps. Too many menus. Too much “smart” layered on top of what should be instant.

So instead of fighting the UI, I built my own.

The Touch Panel That Replaced Everything

At the centre of this setup is a Waveshare ESP32-S3 touchscreen running ESPHome with LVGL. No Android tablet. No iPad. No cloud dependencies. Just a purpose-built interface that does exactly what it needs to–and nothing more.

The entire UI is a 5×5 grid of buttons.

That’s it.

And that’s the point.

Each button maps directly to something real in the room: TVs, lights, curtains, chargers. Tap it, and it happens instantly. No animations, no loading states, no second-guessing whether the command actually went through.

What makes it work isn’t just the layout–it’s the feedback loop. Every button reflects the actual state from Home Assistant in real time. If a device is unavailable, the button disables itself. If something turns on elsewhere, the panel updates immediately. It’s not a remote. It’s a live mirror of the system.

There’s no abstraction layer to fight against.

Designing for Real Life, Not Demos

A lot of smart home interfaces are designed like they’re being shown off, not used.

This one is designed around how things actually happen:

• Walking into a room → tap one button
• Going to bed → hit the alarm page
• Leaving → glance, confirm, done

The grid layout isn’t flashy, but it’s predictable. Muscle memory kicks in fast. After a few days, you’re not looking for buttons anymore–you’re just pressing them.

Even small decisions matter:

• Large tap targets so you never miss
• Consistent placement so nothing moves around
• No scrolling, ever

It behaves more like a physical control panel than an app.

The Screen That Knows When to Get Out of the Way

One of the most underrated parts of this setup is what happens when you don’t use it.

After 30 seconds of inactivity, the display shuts off. Completely. Backlight off, LVGL paused, even a subtle “snow” effect to prevent burn-in.

Touch the screen again, and it wakes instantly–right back to where you left it.

It’s a small detail, but it changes how the panel feels. It’s not constantly glowing in the background. It’s not demanding attention. It’s just there when you need it.

And gone when you don’t.

A Dedicated Alarm Interface That Feels Right

The second half of the project is something I’m disproportionately proud of: a dedicated alarm page.

Instead of cramming alarm controls into the main UI, it gets its own space–with a layout inspired by old-school physical keypads.

Mode buttons on the left. Keypad on the right. Code entry front and centre.

It behaves exactly how you expect:

• Enter a code → it masks with asterisks
• Arm/disarm → sends directly to Home Assistant
• Alarm triggers → screen turns on automatically and switches pages

There’s even a small touch that makes a big difference: when the system is arming, the display changes to “Arming…” instead of sitting there blankly.

It feels responsive. Intentional. Alive.

Why This Works Better Than a Tablet

A tablet can do more. That’s exactly why it’s worse for this job.

This panel is:

• Instant – no OS, no background apps, no lag
• Local-first – nothing breaks if the internet drops
• Single-purpose – no distractions, no drift
• Ridiculously efficient – barely sips power

Most importantly, it removes friction.

You don’t think about using it. You just do.

The Real Upgrade Wasn’t Hardware

The hardware is nice. The ESP32-S3 is more than capable. LVGL is flexible enough to build anything you want.

But the real upgrade is philosophical.

Instead of adapting to someone else’s idea of a smart home interface, this setup flips the equation:

The interface adapts to you.

No unnecessary features. No forced workflows. No compromises.

Just a grid of buttons that does exactly what you expect–every single time.

If anything, this project proves something simple:

The best smart home UI isn’t the one with the most features.

It’s the one you stop noticing entirely.

But strip away the UX sins and what you’re left with is something surprisingly powerful: instant, local, zero-latency control.

This ESPHome-based IR node leans into that idea hard.

At its core, it’s an ESP8266 (ESP8285 board) running both a receiver and transmitter. That alone isn’t special. What makes it interesting is how it’s wired into Home Assistant–not as a workaround, but as a first-class control layer.

IR as Input, Not Just Output

Most setups treat IR as a one-way street: send commands, hope for the best.

Here, the remote becomes a trigger device.

Specific NEC codes–like the colored buttons on an LG remote–are mapped directly to Home Assistant actions:

• Pink button → toggle TV lights
• Green button → toggle bedroom light
• Yellow button → toggle soundbar power
• Blue button → toggle TV power

No cloud. No polling. No delay. Press button → thing happens.

That’s the entire philosophy.

And because it’s ESPHome, you’re not stuck with whatever some manufacturer thought was useful. You decide what every button means.

The Quiet Killer Feature: IR Proxy

Buried in this config is something that feels like a glimpse into the future:

    infrared:
      - platform: ir_rf_proxy

Right now, it’s rough. Definitely not plug-and-play. But conceptually? It’s huge.

This is the beginning of IR becoming network-native inside Home Assistant.

Instead of:

• Capturing codes manually
• Writing YAML
• Flashing firmware

You eventually get:

• Discoverable IR devices
• Reusable command sets
• Shared control layers

In other words, IR stops being a hack and starts acting like a real integration.

We’re not fully there yet–but this is the direction.

Output Still Matters

On the flip side, the transmitter side is just as important.

Every key TV function is exposed as a Home Assistant button:

• Power
• Volume up/down
• Mute
• Navigation
• Playback

Which means your “dumb” TV is now:

• Scriptable
• Automatable
• UI-controllable
• Fully local

No app. No API. No nonsense.

Just raw IR, weaponized properly.

HDMI-CEC: Listening Instead of Guessing

If the IR node is about control, the HDMI-CEC node is about awareness.

And honestly, this is the more interesting one.

Because most smart home setups fake device state. They assume the TV is on because you told it to turn on.

This one doesn’t assume anything.

It listens.

Sniffing the HDMI Bus

Using an ESP32 and this esphome-hdmi-cec component, this device taps directly into the HDMI-CEC line and watches traffic in real time.

Not controlling (well, not primarily)–just observing.

With:

    promiscuous_mode: true
    decode_messages: true

…it’s basically Wireshark for your HDMI cable.

And from that stream, it extracts something incredibly useful:

A Real Power State Sensor

Two messages matter here:

• 0x36 → Standby (OFF)
• [0x90, 0x00] → Power ON

That’s it.

No guessing. No delays. No “wait 10 seconds and hope.”

Just:

• TV says it’s off → sensor updates
• TV says it’s on → sensor updates

Which means your automations suddenly get way smarter.

Lights, sound, notifications–everything can react to what’s actually happening, not what you think is happening.

Minimal Control, Maximum Precision

There’s also a small but important addition:

    hdmi_cec.send:
      destination: 0x0
      data: [0x36]

A clean, direct “turn off everything” broadcast.

No IR blasting. No aiming. No interference.

Just a message on the HDMI bus that every device understands.

Why This Setup Works So Well

Individually, these projects are solid.

Together, they’re kind of ridiculous–in a good way.

You end up with:

IR → Control Layer

• Instant input from physical remotes
• Reliable output to “dumb” devices
• Fully local, zero latency

HDMI-CEC → State Layer

• Real device awareness
• No guesswork
• Clean integration into automations

And the combination solves a problem most people don’t even realize they have:

Smart homes are great at sending commands.

They’re terrible at knowing what actually happened.

This setup fixes that.

The Bigger Picture

What’s happening here isn’t just “cool ESPHome stuff.”

It’s a shift in how you think about devices.

Instead of asking:

“Does this support Home Assistant?”

You start asking:

“Can I make this support Home Assistant?”

IR? Yes.

CEC? Yes.

RF (soon)? Probably.

And suddenly, entire categories of “dumb” hardware become viable again–without any of the baggage of cloud apps, firmware updates, or abandoned ecosystems.

Final Thought

There’s something deeply satisfying about turning off your TV with a 20-year-old protocol…

…while a microcontroller quietly logs the event and updates your house in real time.

It’s not flashy.

It doesn’t need to be.

It just works–and more importantly, it works on your terms.

Now the landing page handles introductions while the blog lives at blog.aidanmaurinjones.com, focused entirely on posts and projects.

The Goal

I wanted something that:

• loads instantly
• works entirely from static files
• stays easy to maintain
• feels like me — straightforward, clean, and a little nerdy around the edges

No flashy animations, no bloat, no signup forms. Just a name, a short blurb, and a link to the blog.

The Build

The site runs on Hugo with the Hermit-V2 theme — lightweight, elegant, and fast.
I kept the layout minimal: title, subtitle, one link to the blog, and a simple contact section.

Everything is built locally with Hugo Extended, then deployed automatically using GitHub Pages.
Once the workflow was behaving, the entire site could rebuild and publish in under 30 seconds.

The Result

What you see now is the distilled version of everything I wanted:
a quiet, fast landing page that does exactly one job — introduce me and point you in the right direction.

It’s clean, responsive, and entirely under my control.
No third-party builders, no analytics scripts, no compromises.

Closing Thoughts

I didn’t rebuild the blog — I just gave it a better home.
The content, feeds, and archives all live on at blog.aidanmaurinjones.com; the main domain is now a simple, focused landing page that introduces who I am and where to find my work.

It’s a small change that makes everything clearer and easier to manage — one site for reading, one site for meeting.

→ aidanmaurinjones.com
→ blog.aidanmaurinjones.com

But every time I sit down with it, I leave thinking the same thing: “huh…”

⸻

The Promise of Obsidian

Obsidian is marketed as a plain text knowledge base. It provides backlinks, a graph view, and a huge plugin ecosystem that can turn Markdown into just about anything — daily journals, task managers, or even kanban boards. For someone who wants an all-in-one workspace, it’s fantastic.

⸻

My Workflow Is Different

The reason it doesn’t click for me is simple: my workflow is built on a different philosophy.

• Markdown is the source of truth. I write everything in plain .md files. No special syntax, no hidden metadata. If I want to preview formatting, I open it in Marked 2.
• PDF is the permanent format. When I need something shareable or archival, I export to PDF. That’s my version of locking it down in stone.
• Finder organizes, Alfred retrieves. Finder handles long-term storage, Alfred lets me get to anything instantly, and Hazel keeps everything tidy in the background.
• Automation glues it all together. Keyboard Maestro, Shortcuts, and BetterTouchTool let me spin up templates, transform files, or publish to Hugo and Buttondown in minutes.

Within this setup, I can create a new document template in 10 minutes. I am not proud of it, but in Obsidian, I spent two hours fiddling with plugins just to get a string quoted or a JSON array formatted consistently without any success.

⸻

The Real Difference

What I’ve realized is that Obsidian and my stack solve different problems:

• Obsidian is for people who want a unified workspace where notes, tasks, and links all live together.
• My stack is for people who want modular tools that each do one job well and can be connected through automation.

That’s why Obsidian feels to me like the love child of MS Word and VSCode. It’s polished, powerful, and versatile — but also too “workspace-y” for the way I prefer to work.

⸻

Why That’s Okay

None of this is a knock on Obsidian. It’s a great app, and I can see why it’s so widely loved. If I needed cross-platform syncing or a personal knowledge graph, it would be near the top of my list.

But for me, life revolves around Markdown as the living format and PDF as the permanent format. BBEdit, Marked 2, Hugo, Buttondown, Alfred, Hazel, Keyboard Maestro, and Shortcuts give me everything I need. Obsidian just doesn’t solve a problem I actually have.

And that’s the real takeaway: the best tool isn’t the one with the most features. It’s the one that disappears into your workflow and feels natural every day.

BBEdit

Marked 2

Obsidian

That philosophy led me to a new Shortcut I built for my Buttondown newsletter. With it, I can take the exact same Markdown file I use for my Hugo-based site’s Newsletter Archive page, and publish it straight to Buttondown in one step. No duplication, no reformatting, and no breaking my Markdown-first workflow.

⸻

A Dual-Purpose Draft

Every newsletter draft I write starts as a Markdown file in my Hugo project. It includes the standard YAML front matter — title, date, tags — so it can live side-by-side with my blog posts and generate an archive page on my site.

At the bottom, I’ve also standardized on a Hugo shortcode that handles things like subscribe links and callouts.

The front matter makes it valid Hugo content, but Buttondown doesn’t need that metadata. Likewise, the shortcode at the bottom is great for my archive page but doesn’t belong in an email. The Shortcut’s job is to strip out those bits and isolate the actual content.

⸻

Regex to the Rescue

To solve that, I leaned on regular expressions. The Shortcut matches everything after the closing — of the YAML front matter and before the buttons-list shortcode.

The pattern looks like this:

\A---[\n\s\S]*?---\s*([\n\s\S]*?)\s*\{\{\s*buttons-list\s*\}\}

The captured group becomes the newsletter body. Meanwhile, the Shortcut takes the filename of the Markdown draft and uses it as the subject line. That way, one file works for both Hugo (which uses the front matter) and Buttondown (which only needs subject + body but I hope one day it supports front matter).

⸻

Publishing via Buttondown’s API

The final step is an API call. The Shortcut uses the Get Contents of URL action, configured with:

• Endpoint: https://api.buttondown.com/v1/emails
• Headers: Authorization token (pulled from a secure Shortcut)
• Body: JSON with subject, body, and status

I set status to about_to_send, which creates the email in Buttondown ready for review. If I’m confident, I can flip this to sent and fire it off instantly.

⸻

Why This Matters

The beauty of this setup is that I never have to write the same thing twice. My Hugo site automatically builds out a Newsletter Archive page from the Markdown file, while this Shortcut takes that same file and pushes it to Buttondown.

Plain text is the source of truth, Hugo and Buttondown are just outputs.

This also gives me flexibility: if I ever change services, or if I want to generate a PDF archive, I don’t need to rewrite anything. I’ve already got everything in a neutral, Markdown-first format that can be re-used anywhere.

⸻

Why This Works So Well

Like many of my favorite automations, this Shortcut doesn’t feel flashy — it feels inevitable. Once you decide everything should start as Markdown, the next step is making sure the publishing side bends around your workflow, not the other way around.

Shortcuts, Buttondown, and Hugo all line up perfectly here. It’s one file, two destinations, and zero overhead. And that’s exactly the kind of automation that keeps me writing and publishing more often.

Publish Newsletter to Buttondown

I hope this finds you well and a little curious — I’ve got a fresh batch of blog posts to share! Whether you’re into smart home automations, shortcuts that save time, or just a little bit of silliness when dealing with spam, there’s something here for you.

⸻

📰 What’s New

Here are the recent posts you might enjoy (plus one or two you may already have seen):

• Fighting Spam with Automation: A Shortcut for Writing Hilarious Replies

Ever want to send snarky replies to spam—but without typing them out yourself? This post walks through a Shortcut that drafts sarcastic, AI-powered responses to spam, just for the chuckle.

• Automating TP-Link / Kasa Devices with Shortcuts

Unlock more control over your smart plugs and bulbs by integrating them with Apple Shortcuts.

• Get This Week’s Events: A Smarter Calendar Shortcut

Automate the process of extracting your week’s events and display them in the Apple Shortcuts app.

• App Store Links Made Beautiful with Shortcuts

Turn ugly, long App Store links into clean, pretty ones (and even automate it).

• I Could Write This Blog in Notepad

A reflection on how simple the publishing stack really is—plain text, Markdown, GitHub Pages, and some automation.

⸻

✨ Spotlight

Fighting Spam with Automation is the kind of fun-first Shortcut project I love doing: it’s not optimized for productivity, but it stretches the boundaries of what Shortcuts + local AI can do. Using AppleScript + a local LM Studio model, the setup fetches an email, crafts a witty (borderline absurd) reply, and drops it into a draft. I didn’t send it — mostly I just laughed. 

But beyond the jokes, there’s a deeper idea here: using Shortcuts to glue together different systems—in this case, email, scripting, and local AI. Everything is local, everything is private, and everything is yours to tinker with.

⸻

🛠️ Why You Might Try These

If any of this resonates, here are some ways you could put these posts to use:

• Make your smart home more powerful it –> Automate TP-Link, SwitchBot devices via Shortcuts + API
• Simplify blog or web publishing it –> Use the “Post Buttons” or “iCloud Links it –> Share Buttons” tricks
• Tidy up link clutter it –> Beautify App Store links or automate Alfred app cards
• Laugh at spam instead of regretting it –> Build the “roast the spammer” Shortcut
• Understand the minimal stack behind your blog it –> Read the “I Could Write This Blog in Notepad” piece

⸻

If you liked any of those, I’d appreciate it if you’d:

1. Reply it –> tell me which post you liked (or which one you’re going to try)
2. Share it –> forward this newsletter to a friend who loves automation
3. Bookmark it –> keep it somewhere you’ll revisit when you need inspiration

As always, thanks for reading. I’m already brainstorming what’s next (maybe something with HomeKit, or combining shortcuts + other tools you love). Stay tuned.

Cheers,

Aidan 👋

aidanmaurinjones.com

It’s not practical. It’s not productive. But it’s very satisfying.

⸻

How It Works

At its core, the Shortcut is a four-part pipeline:

1. Grab the Email Contents Using a short AppleScript snippet, the Shortcut fetches the subject, sender, and body of the currently selected message in Apple Mail. If no message is selected, it returns a friendly “No message selected.” To keep things stable, the Shortcut also checks if the text exceeds LM Studio’s character limit and truncates it if necessary.

tell application "Mail"
	set selectedMessages to selection
	if selectedMessages is not {} then
		set theMessage to item 1 of selectedMessages
		set theSubject to subject of theMessage
		set theSender to sender of theMessage
		set theContent to content of theMessage
		return "Subject: " & theSubject & linefeed & "From: " & theSender & linefeed & linefeed & theContent
	else
		return "No message selected."
	end if
end tell

2. Prepare the Prompt The Shortcut sets a variable for the LM Studio model ID (gemma-3-4b-it in my case) and builds a carefully worded prompt. The instructions tell the model to write a “brutally funny, insult-filled response to a spam email. Be sarcastic and creatively rude… End with an absurd, over-the-top (but never threatening) final warning.” The result is a prompt that guides the AI into crafting exactly the kind of unhinged reply you’d never actually send, but will absolutely laugh at.

3. Send It to LM Studio With the email contents and the prompt combined, the Shortcut makes a call to LM Studio’s local API (http://localhost:1234/v1/chat/completions). The response is parsed as JSON, and the draft text is extracted. Because it runs locally, there are no cloud services involved—everything stays private.

curl -X POST "http://localhost:1234/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma-3-4b-it",
    "messages": [
      {
        "role": "system",
        "content": "Write a brutally funny, insult-filled response to a spam email. Be 
        sarcastic and creatively rude (no slurs or hate speech). Make it clear I never 
        want to hear from them again. Reference the content of the email when possible. 
        End with an absurd, over-the-top (but never threatening) final warning, and a 
        signature that sounds unhinged yet articulate. Do Not include subject lines or 
        metadata."
      },
      {
        "role": "user",
        "content": "<<< email contents go here >>>"
      }
    ]
  }'

4. Open in Mail’s Reply Window Finally, another AppleScript takes over: it opens a reply window to the original spam message and drops the AI-generated draft into the compose area. From here, you can either hit send (bold!) or just chuckle at the absurdity and close the window.

on run {input}
	tell application "Mail"
		set selectedMessages to selection
		if selectedMessages is not {} then
			set theMessage to item 1 of selectedMessages
			set replyMessage to reply theMessage with opening window
			set content of replyMessage to input
		end if
	end tell
end run

⸻

Why Build This?

I won’t pretend this Shortcut is essential to my workflow. Nobody needs an AI-crafted insult generator for spam. But that’s the fun of automation: sometimes it’s about play, not productivity.

Spam clogs our inboxes daily, and most of us simply delete it. This Shortcut flips the script, giving you a mischievous outlet for all that frustration. Whether you actually send the replies or just read them for a laugh, it makes the experience of dealing with spam weirdly delightful.

⸻

A Perfect Example of Local AI + Shortcuts

The real story here is how easily Shortcuts can integrate with local AI tools like LM Studio. By combining AppleScript’s system-level hooks with Shortcuts’ automation glue, you can build workflows that feel custom-tailored to your sense of humor—or your productivity needs.

In this case, the Shortcut isn’t saving me time or streamlining my day. But it is showcasing the power of running AI models locally, where latency is low, privacy is intact, and you can experiment with ideas that wouldn’t make sense on a cloud-based service.

⸻

The Result

The first time I ran the Shortcut, the reply draft began with a sarcastic takedown of the email’s fake “investment opportunity,” segued into a rant about how the spammer’s grammar deserved jail time, and closed with a completely unhinged signature that read:

“Sincerely, Lord Emperor of My Inbox, Eternal Defender Against Your Nonsense.”

I didn’t send it. But I laughed harder than I have at an email in years. And that’s exactly the point.

⸻

Bottom line: Not every Shortcut has to be practical. Sometimes, the best ones are the ones that bring you joy—even if that joy comes from imagining a spammer’s reaction to an AI-written roast they’ll never actually read.

Write Reply to Spam & Junk Email

Apps Used to Create This Shortcut

LM Studio

Script Debugger

How It Works

The Shortcut starts by establishing today’s date and formatting it into a value that the rest of the workflow can understand. From there, it leans on a Dictionary that acts like a custom lookup table for each day of the week. This dictionary defines offsets for both the start and end of the week depending on the current day.

For example:

• Sunday maps to {Start: 0, End: 6}
• Monday maps to {Start: 1, End: 5}
• Wednesday maps to {Start: 3, End: 3}

This clever setup means the Shortcut doesn’t have to assume whether your week starts on Sunday, Monday, or any other day–it adapts automatically by subtracting and adding the right number of days from the current date.

Calculating the Range

Once the dictionary hands back the correct offsets, the Shortcut does a simple bit of date math:

• Subtract the “Start” offset from the current date to calculate the Start of Week.
• Add the “End” offset to the current date to calculate the End of Week.

Both results are saved into variables, which become the boundaries for the next step.

Finding Your Events

With the week’s start and end pinned down, the Shortcut uses the Find Calendar Events action to grab only the events whose start date falls between those two values. That means whether you run this on a Tuesday or a Friday, you’ll always get a list scoped neatly to the current week, no manual scrolling required.

Why This Matters

On the surface, it looks like a simple “show me my week” automation–but the beauty here is in how it generalizes. By abstracting the week’s structure into a dictionary, you can easily tweak how you want your weeks defined. For instance, you could redefine Saturday as the end of the week or experiment with rolling five-day “work weeks” instead of calendar weeks.

This kind of flexibility is exactly why Shortcuts shines: you’re not stuck with Apple’s defaults–you can make the system reflect your schedule.

My Take

I’ve tried plenty of ways to get a weekly overview–widgets, third-party apps, even manually filtering in Calendar–but nothing beats the elegance of this Shortcut. It’s fast, it’s reliable, and it always gives me the right slice of time, no matter the day. It’s a perfect example of how Shortcuts can take something that feels rigid and make it fluid again.

Get This Week’s Events

For those unfamiliar, Unix time is a standard way of representing dates as the number of seconds since January 1, 1970, at midnight UTC. It’s widely used in APIs, databases, and automation tools because it turns messy human dates into a single number that’s easy for computers to understand.

How the Shortcut Works

The Shortcut begins with a conditional check:

• If Shortcut Input has a value → use that as the date.
• Otherwise → fall back to the current date.

This flexibility means you can pass in a date from another Shortcut, an app, or a file–and it’ll just work. If you don’t supply anything, it defaults to “now,” which is handy for most uses.

Next, the Shortcut defines a fixed reference point:

1970-01-01T00:00:00Z

This is the start of Unix time (known as the epoch). The Shortcut parses that text into a date object.

Finally, it calculates the difference in seconds between the chosen date (from input or current) and the epoch date. The result is a clean integer: Unix time.

Why This Is Useful

I reach for this Shortcut whenever I’m working with APIs that require timestamps or when I need a quick way to normalize dates into a standard format. It’s especially useful in web automations, logging workflows, and even in Home Assistant setups where Unix time values can simplify comparisons.

What I love about this Shortcut is how it elegantly combines a few building blocks–conditional input, a static reference date, and a date difference–into a tool I use far more often than I expected. It turns a concept buried deep in programming textbooks into a tap-friendly utility.

Try It Yourself

You can run this Shortcut as-is for an instant timestamp or pass in dates from elsewhere to convert them. Either way, you’ll always get a precise Unix time value at the end.

Convert Current Date to Unix Time

Over the past week, I’ve been experimenting with three public Shortcuts that unlock the Kasa cloud API:

1. Get Kasa API Token

2. Get Kasa Device Details

3. Turn On/Off Kasa Device

Together, they form a powerful workflow that lets you log in to your account, retrieve all of your devices, and control them–all without ever opening the Kasa app.

Step 1: Authenticating with the Kasa Cloud

Everything starts with the Get Kasa API Token Shortcut. This Shortcut asks for the email and password tied to your Kasa account, along with a UUID (a unique identifier that mimics the Kasa app itself). With these values, the Shortcut sends a login request to the Kasa cloud endpoint:

https://wap.tplinkcloud.com/

The response includes a temporary API token–your golden ticket for making further requests. Without it, nothing else works. Tokens do expire occasionally (usually after an app update), but re-running the Shortcut instantly refreshes your access.

Step 2: Retrieving Your Devices

Once you have a token, the next step is to get a list of devices tied to your account. That’s where Get Kasa Device Details comes in.

This Shortcut takes your token and sends a getDeviceList request. The response is a JSON dictionary containing all of your Kasa devices–each with a friendly name (alias), a deviceId, and an appServerUrl (the regional server that manages the device).

The Shortcut loops through this dictionary, extracts the essentials, and combines them into a clean, human-readable list. Instead of parsing raw JSON, you get something like:

"Living Room Plug": {"Device ID": "8006XXXXXX", "App Server URL": "https://use1-wap.tplinkcloud.com"}

This is the crucial information you’ll need to actually control the device.

Step 3: Turning Devices On and Off

With the token, device ID, and server URL in hand, the final piece of the puzzle is Turn On/Off Kasa Device.

This Shortcut first prompts you for the values you retrieved in step two, then asks you to choose an action: On or Off. Internally, those options map to 1 and 0, which the API uses to change the relay state.

The Shortcut builds a JSON request that looks like this:

{
  "method": "passthrough",
  "params": {
    "deviceId": "YOUR_DEVICE_ID",
    "requestData": "{\"system\":{\"set_relay_state\":{\"state\":1}}}"
  }
}

Send that request to the Kasa cloud, and–like magic–your smart plug or bulb responds instantly.

Why This Matters

Kasa devices are popular because they’re inexpensive, reliable, and don’t require a separate hub. But until now, integrating them with Shortcuts has meant relying on Homebridge, third-party apps, or clunky workarounds.

These three Shortcuts cut out the middleman. They give you direct control over your Kasa devices from within Shortcuts, meaning you can tie them into existing automations:

• Turn on a desk lamp when you start a Focus mode.
• Power cycle your router with a tap on the Home Screen.
• Shut off everything in the house with a single command to Siri.

Credit Where It’s Due

All of this is made possible thanks to the excellent research and documentation by Joshua Tz, who published the Kasa API details. His guide is available here and is an invaluable resource for anyone who wants to go deeper into the API beyond what Shortcuts can do.

Future Improvements

Right now, the workflow involves some copy-paste steps–retrieving the token in one Shortcut, then pasting it into another. With a bit of refinement, the whole process could be chained into a single Shortcut: log in, fetch devices, pick one, and toggle it–all in one go. That’s the kind of polish that makes Shortcuts shine.

But even as-is, this trio of Shortcuts transforms Kasa devices from “app-only” gadgets into fully programmable components of your Apple ecosystem. And that’s the magic of Shortcuts: giving you the tools to bend devices and services to your will–even when their makers don’t.

Get Kasa API Token

Get Kasa Device Details

Turn ON & OFF Kasa Device

Apps Used to Create This Shortcut

Actions

Jayson

In this post, I’ll walk you through two Shortcuts I built: one to fetch a list of all my SwitchBot devices, and another to send commands to them. Together, they let me control my smart home directly from Siri, widgets, or automations.

Getting Device Details

The first Shortcut is a template for retrieving all registered SwitchBot devices from the company’s cloud API.

It starts with a simple Text action where I paste in my API authorization key. That’s followed by another Text action containing the endpoint URL:

https://api.switch-bot.com/v1.0/devices/

The real magic happens in the Get Contents of URL action. Set to GET, this step includes a header named Authorization, pulling in the key from the earlier Text block. When the Shortcut runs, the response contains a full list of my devices and their details–device IDs, types, names, and more.

For me, this shortcut is especially useful when I need to look up a device ID to use in the second Shortcut.

Sending Commands

The second Shortcut is where things get really interesting: sending a command to a specific device. It uses the same authorization key, but adds a few more building blocks:

• Device ID (so the API knows which device to target)
• Command Type (usually “command”)
• Command (for example, “turnOn”, “turnOff”, or “toggle”)
• Parameter (some commands require additional values, like brightness levels or modes)

The API endpoint looks like this:

https://api.switch-bot.com/v1.0/devices/{deviceId}/commands

And instead of GET, this time the Shortcut uses a POST request with a JSON body. The Get Contents of URL action sends fields for commandType, command, and parameter, all filled from earlier Text actions in the Shortcut.

With this structure, I can turn lights on and off, start a fan, or even trigger my SwitchBot Curtain with a single tap. All without ever opening the SwitchBot app.

Why This Matters

There are countless ways to integrate SwitchBot devices with other smart home platforms, but building these Shortcuts has two big advantages:

1. Speed – I can tie them directly into Siri, widgets, or automations. Saying “Hey Siri, turn on the fan” actually triggers my Shortcut, which hits the SwitchBot API in less than a second.

2. Flexibility – Since the commands are just text values, I can duplicate the Shortcut and customize it for any device and action I want, without writing code or digging through menus.

For someone like me, who’s already knee-deep in Shortcuts for other parts of my life, this setup feels natural. I can slot these actions into bigger workflows–turning on my SwitchBot devices when I leave work, or including them in a “Good Morning” routine alongside music and calendar events.

Final Thoughts

Shortcuts may not be the most glamorous way to control smart home gear, but you can do it. By working directly with the SwitchBot API, these automations skip the app entirely and give me the confidence that when I tap a button, my devices respond.

It’s yet another example of how Shortcuts can serve as the glue between platforms, devices, and services. And for SwitchBot users, it’s a reminder that sometimes the simplest approach is also the most powerful.

Get SwitchBot Devices Template

Send Command to SwitchBot Template

⸻

The Problem

When you share a Shortcut publicly, Apple gives you an iCloud link that looks something like this:

https://www.icloud.com/shortcuts/123abc…

It works fine for sharing with friends, but when I want to add that Shortcut to my blog, I need more than just the link. I need:

• The Shortcut’s proper name
• Its icon image
• A clean HTML/Hugo shortcode block I can drop into a Markdown file

Doing all of this by hand was tedious. So I automated it.

⸻

How the Shortcut Works

The Shortcut breaks down into three key stages: fetching metadata, processing the icon, and generating the blog card.

Fetching Metadata

The Shortcut starts by receiving a Shortcut iCloud link (or grabbing it from the clipboard if none is passed in). From there:

• It rewrites the link into Apple’s hidden API endpoint at https://www.icloud.com/shortcuts/api/records/.
• Using Get Contents of URL, it downloads the Shortcut’s metadata as JSON.
• With Get Dictionary from Contents of URL, I can then pull out fields like fields.name.value (the Shortcut’s title) and fields.icon.value.downloadURL (the actual icon).

Processing the Icon

Here’s the clever part: I don’t just hotlink the icon from iCloud. Instead:

• I construct a GitHub API URL pointing to my site’s static/images/Shortcuts Icons folder.
• The Shortcut checks whether a file with the same name already exists (by calling GitHub’s API and looking for a SHA).
• If the icon isn’t there, it downloads the image, renames it with the Shortcut’s title, and encodes it in Base64.
• Finally, it uploads the icon to GitHub via the API, neatly slotting it into my Hugo site’s image folder.

Now every Shortcut I publish has its own local icon, version-controlled alongside the rest of my site.

Generating the Blog Card

The Shortcut assembles the code automatically, copies it to my clipboard, and I can paste it directly into my Markdown post. No typing, no file juggling, no guesswork.

⸻

Why It Matters

This Shortcut may sound niche, but it’s been a huge time saver for me. I publish a lot of posts about Shortcuts, and before this, each one meant multiple minutes of repetitive work: saving icons, renaming them, uploading them, writing out HTML. Now it’s one tap.

The broader lesson here is that Shortcuts isn’t limited to “personal productivity” hacks. It’s powerful enough to serve as part of a publishing pipeline, gluing together iCloud’s hidden APIs, GitHub’s developer endpoints, and Hugo’s templating system.

And that’s why I love this Shortcut: it turns Apple’s barebones sharing into a complete, blog-ready package.

Share Shortcut HTML Button

Apps Used to Create this Shortcut

Jayson

The Mac App Store gives you a tidy preview link and icon, but direct-purchase apps don’t. That means if I want to share an app like BBEdit or Audio Hijack, I’d normally have to dig into the app bundle, extract the icon, save it out, rename it, upload it, then write the HTML myself. Way too much friction.

So I built a Shortcut that does all of it for me. And because I run it as an Alfred File Action, all I have to do is select the app and hit the hotkey. The Shortcut takes care of the rest, turning any Mac app—App Store or not—into a polished HTML app card ready to paste into my Hugo blog.

⸻

How It Works

The Shortcut is split into two halves: finding the app’s details and icon, then uploading and generating the HTML snippet.

Extracting the app’s icon and name

It begins with an AppleScript that points at the selected .app bundle and looks inside its Info.plist for the CFBundleIconFile. If that value’s missing, the script gracefully falls back to the default AppIcon.

From there, it resolves the .icns file inside /Contents/Resources/, hands it back to Shortcuts, and Shortcuts grabs the actual image. At the same time, it extracts the app’s display name so I don’t have to type it myself later.

Handling the upload

With the icon in hand, the Shortcut preps the upload for GitHub. It checks if the icon is already in my site’s /static/images/App Icons/ folder using the GitHub API. If it doesn’t exist, the Shortcut converts the image to base64 and uploads it automatically.

This is especially handy for apps outside the Mac App Store, since I can’t rely on Apple’s CDN to serve up a clean app icon for me. Once uploaded, the image is there permanently, ready for reuse across future posts.

Assembling the HTML card

Finally, the Shortcut generates the Hugo shortcode I use for app cards. This snippet is copied straight to my clipboard, so I can paste it into BBEdit alongside the rest of the post. To help me fill in the missing link (since there’s no App Store URL), the Shortcut even runs a DuckDuckGo search for the app’s name + “mac app.” Nine times out of ten, that surfaces the official website instantly.

⸻

Why This Shortcut Matters

This automation is all about eliminating barriers. Whether the app is on the Mac App Store or sold directly through a developer’s site, I get the same consistent app card on my blog. No manual exporting, no renaming files, no repetitive uploads.

It also means I can highlight great indie apps without worrying about the extra effort. For someone who posts often, these saved minutes add up, but more importantly, they keep me in flow. When the tools fade into the background, the writing comes forward.

⸻

Alfred + Shortcuts = A Perfect Match

Running this Shortcut through Alfred is what makes it truly seamless. Instead of digging through Finder or hunting down app paths manually, I just select the app in Alfred, trigger the File Action, and let Shortcuts do the heavy lifting.

This combination works beautifully: Alfred is my quick-launch interface, and Shortcuts is the automation engine in the background. Together, they make sharing Mac apps—App Store or not—as easy as a keyboard command.

⸻

The Bigger Picture

This Shortcut fits into a larger workflow where I’ve automated nearly every part of blogging, from uploading screenshots to posting entire drafts to GitHub. Each piece removes just enough friction to make publishing easier and more enjoyable.

The end result is that I can write more, share more, and showcase apps without worrying about where they’re sold. The Mac App Store doesn’t have to be the gatekeeper for clean links and icons anymore.

Share Mac App HTML Button

Apps Used to Create this Automation

Jayson

Alfred 5

Script Debugger

That’s where this Shortcut comes in. Built entirely with stock Shortcuts actions, it takes a single App Store link and spits out a polished Hugo shortcode ready to paste into a blog post, complete with app name, link, and icon. What used to be a multi-step process is now a single tap.

⸻

How It Works

Getting the App Store ID

The Shortcut starts by receiving an App Store URL, either from the Share Sheet or your clipboard. Using a quick regex ((?<=id)\d+), it extracts the numeric app ID buried in the link. That ID becomes the key for looking up everything else.

Pulling App Metadata

Next, Shortcuts’ built-in Find on the App Store action does the heavy lifting. It takes the app ID and returns structured data: the app’s name, its store page, and, crucially, the artwork URL for the icon.

At this point, the Shortcut already knows enough to generate a working app card, but it goes further.

Naming and File Prep

The app’s name is cleaned up and stored in a variable, then URL-encoded so it can be used safely as a filename. That ensures that even apps with spaces, dashes, or punctuation won’t break the upload process later.

Uploading the Icon

Here’s where things get clever. The Shortcut builds a GitHub API request to upload the app icon directly into the site’s repository. It grabs your personal API key, encodes the file, and sends it off with a PUT request. If the file already exists, the Shortcut skips the upload to avoid duplicates.

Behind the scenes, this means your blog’s /static/images/App Store App Icons/ folder is automatically updated with the latest app logos—no manual dragging or renaming required.

Assembling the Shortcode

Finally, everything comes together in a Hugo appcard snippet:

This block gets copied straight to your clipboard, ready to paste into any Markdown file. The icon path matches the uploaded file, the link points back to the store, and the name is exactly as it appears in Apple’s listing.

⸻

Why It Matters

This is a classic example of automation as time-saving infrastructure. Writing about apps often involves dozens of small formatting chores that add up. By moving them into a Shortcut, you don’t just save a few clicks—you make the whole workflow predictable, repeatable, and error-free.

Better still, it’s all built with the tools Apple ships on every device. No third-party apps, no scripting languages, no dependencies. Just Shortcuts, GitHub, and a bit of creativity.

⸻

The Result

Now, when inspiration strikes, I don’t have to think about sourcing icons or formatting snippets. I just share an App Store link, run the Shortcut, and paste the finished card into my blog post. It’s instant, it’s reliable, and it makes my site look great with zero extra effort.

For a blog that lives and breathes apps, this Shortcut has become one of those invisible automations that pays dividends every single day.

Share App Store App HTML Button

Apps Used to Create this Shortcut

Jayson

Unlike platforms like Squarespace, Wix, or WordPress, I don’t have to deal with heavy dashboards, recurring subscription fees, or bloated themes that can slow everything down. There are no hidden limits, no proprietary lock-in, and no fear that a company will suddenly change its pricing model or redesign the editor. My blog is lean, fast, and completely mine — built from plain Markdown files and served directly from GitHub with almost no overhead.

Fast, Free, and Reliable

Hugo compiles my site in seconds, spitting out plain HTML that GitHub Pages serves instantly. That’s the beauty of a static site: it’s nothing more than pre-built pages sitting on a server, ready to be delivered the moment someone visits. There’s no database query, no server-side code, no waiting for templates to render. The site is already fully assembled before it ever reaches the browser, which is why it loads so quickly.

Contrast that with a site you’d build on Squarespace or a traditional CMS like WordPress. Those platforms generate pages on the fly. When a reader visits, the server has to pull content from a database, render it through a template engine, load plugins, and then send it all back. That’s powerful, but it adds complexity and overhead — more moving parts, more chances for something to break, and more ways for the site to slow down.

With Hugo and GitHub Pages, none of that exists. The entire site is already built ahead of time on my computer, then pushed as plain HTML, CSS, and JavaScript. GitHub Pages simply serves those files as-is. The result is a site that’s incredibly fast, nearly impossible to break, and requires zero maintenance.

And because GitHub Pages is handling hosting, I get free HTTPS, rock-solid uptime, and global distribution without ever paying a cent. That’s tough to beat.

Version Control Built In

Because it’s GitHub, every change is automatically versioned. If I make a mistake, I can roll back with a single command. If I want to experiment with a new design, I can branch, test, and merge—exactly like software development, but for my writing.

Markdown as the Foundation

The most important part, though, is that everything is just Markdown files. My posts aren’t trapped in a database or hidden behind a proprietary editor. They’re plain text, human-readable, and universally portable. If Hugo disappeared tomorrow, I’d still have every word I’ve written, ready to be dropped into another system.

Markdown makes my blog future-proof. It’s a format that has stood the test of time, and it gives me confidence that I’ll never lose access to my own content. I can edit posts in Drafts, VS Code, or even Notes if I want to — the tools don’t matter, because the content is mine.

The Right Balance: Workflow Over Design

What makes this setup perfect for me is that it lets me focus on the part I actually care about: the backend and the posting workflow. I never wanted to spend hours tweaking a front-end or dragging blocks around to make a site look just right. With Hugo, I pick a theme once, and that’s it. The design takes care of itself.

What matters to me is how I write, publish, and maintain my blog. And in that respect, Hugo + GitHub Pages is ideal. My workflow is streamlined: write in Markdown, commit to Git, push, and I’m done. I get all the reliability, portability, and automation I want on the backend without having to think about the front-end at all.

Backups Made Simple

Because my site is nothing more than a folder of Markdown files and a Git repository, backing it up is effortless. I always have a complete copy on my computer, and duplicating it anywhere else is as simple as syncing the folder.

Want a backup on an external drive? Copy the folder. Want cloud redundancy? Drop it in iCloud, Syncthing, or any storage service I like. There’s no complex database export, no special tools, no hoops to jump through.

The result is peace of mind: no matter what happens to GitHub or my computer, my blog exists in multiple places, always under my control.

Automation Heaven

One of my favorite parts is how well this setup fits into my automation workflows. From Shortcuts on my iPhone to custom scripts on my Mac, I can publish new posts, upload images, or tweak site layouts without ever opening a CMS. It’s just Markdown files and Git.

True Ownership of Content

That’s the real magic of this setup: ownership. My words live in my repository, under my control. No ads. No third-party lock-in. No subscription to keep the lights on. Just a blog I fully control, powered by the simplest possible ingredients.

Why It Works for Me

There are plenty of publishing platforms out there, but Hugo + GitHub Pages hits the balance I’ve been chasing for years. It’s fast, reliable, and deeply personal. Most importantly, it ensures my writing will always be accessible, portable, and safely backed up.

The biggest win, though, is simplicity. Since my posts are just Markdown files, I don’t have to wrestle with a visual editor, fight with formatting, or wonder if my text will look different once it’s published. I write in plain text, add a little front matter for metadata, and Hugo handles the rest. My words stay clean and consistent, no matter how long I’ve been away or what app I use to write them.

That simplicity takes away the friction. Instead of spending energy maintaining a CMS, updating plugins, or tweaking layouts, I can focus entirely on the thing that matters: writing. The blog feels invisible in the best possible way — it doesn’t demand attention, it just works.

Sometimes the best platform is the one that gets out of the way. For me, that’s Hugo, GitHub Pages, and a folder full of Markdown files. It’s a setup that respects my time, my content, and my workflow. And I’ve never enjoyed blogging more.

Here’s how it works, step by step:

1. Take a Markdown file as input

The Shortcut starts by receiving a file – either from the Share Sheet or by prompting me to pick one. This file is the blog post I’ve written in plain text.

• Action: Receive Files from Share Sheet
• Why: Keeps things flexible – I can run the Shortcut from Finder on my Mac, Drafts on my iPhone, or anywhere else that can share a Markdown file.

2. Prepare the file name

Next, the Shortcut grabs the file’s name, URL-encodes it (so it’s safe for GitHub’s API), and saves it as Pretty File Name.

• Action: Get Name from Blog Post → URL Encode → Set Variable

This ensures my post shows up as my-post.md inside the Hugo content/posts/ folder.

3. Encode the post content

The raw text of the file is pulled out and converted to Base64. GitHub’s API requires files to be sent this way.

• Action: Get Text from Blog Post → Encode Text with Base64

Now I’ve got my post ready in a format GitHub understands.

4. Build the API request

The Shortcut constructs a URL to the right location in my repo:

https://api.github.com/repos/<username>/<repo>/contents/content/posts/<Pretty File Name>.md

This points GitHub’s API directly to where the Markdown file should live.

5. Check if the post exists

The Shortcut sends a GET request to that URL:

• If a file exists, GitHub’s response includes a sha value (basically the file’s unique ID).
• If it doesn’t exist, there’s no sha.

This lets the Shortcut decide whether to update an existing post or create a brand new one.

6. Update or create the post

Depending on the result, the Shortcut runs one of two PUT requests:

• Update Blog Post → PUT with the sha included
• Post New Blog Post → PUT without the sha

Both requests send JSON with:

{
  "message": "Posted via Shortcuts - <Name of BlogPost>",
  "content": "<Base64 Encoded Markdown>",
  "branch": "main",
  "sha": "<if updating>"
}

GitHub commits the file to my repo, and Hugo + GitHub Pages do the rest.

7. Done!

That’s it. Within seconds, the post appears on my live site – no browser, no dashboard, no manual uploads.

Why This Is So Good

• Cross-platform: I use it on my Mac via Finder + Service Station, as an Alfred file action, in BBEdit via AppleScript, and on my iPhone via Drafts. If I had an iPad, it would work there too.
• Minimal setup: The Shortcut is just a chain of built-in actions. No scripts, no third-party apps.
• Future-proof: The only input it needs is a Markdown file – and that’s the one thing my blog will always be built on.

Post to Blog

Apps Mentioned in this Post

Drafts

Service Station

BBEdit

Alfred 5

So, I built a Shortcut that solves this problem: it extracts every link from an episode’s show notes in Overcast and saves them neatly to Drafts.

How the Shortcut Works

The Shortcut starts with Current Episode Info from Overcast, which hands me both the title of the episode and its full show notes in raw HTML.

From there, I do a quick conversion dance:

• Make Rich Text from Show Notes HTML
• Make Markdown from Rich Text

The reason? Markdown gives me a predictable link structure that’s easy to parse with a regex.

Extracting the Links

With the text in Markdown, I use a Match Text action to find every link in the notes. The Shortcut then lets me pick which ones I actually want to save. That way, I’m not cluttering Drafts with every single link from an episode–just the ones I care about.

Saving to Drafts

Here’s the clever bit: before creating a new draft, the Shortcut searches Drafts to see if I already have a note for that episode.

• If nothing exists, it creates a brand new draft with the episode title and the selected link(s).
• If a draft already exists, it appends the new links to it–no duplicates, no mess.

The end result is a running note per episode with all the links I wanted to keep.

Why This Is Useful

This Shortcut saves me from the usual friction of copy-pasting URLs out of Overcast. I don’t have to jump between apps or worry about losing context. Everything ends up in Drafts, which is my text inbox and the place where I process notes later.

It’s a small thing, but like so many good automations, it’s one less manual step in my day. Now, when a host mentions a new app or service, I know I can capture the link in a couple of taps without breaking my listening flow.

Final Thoughts

This is exactly the kind of automation I love: lightweight, repeatable, and tuned to the way I work. Overcast gives me the show notes, Drafts gives me the archive, and Shortcuts does the glue work in between.

The next time I need to reference that obscure link from a podcast episode I heard weeks ago, it’ll be sitting there in Drafts, right where it belongs.

Save URLs from Show Notes

Apps & Tools Used to Create this Shortcut

Overcast

Drafts

Why I Built It

When I need a ride, I almost never know which service will be cheapest or fastest. Sometimes Uber has the best price, sometimes Lyft does, and often Hopp beats them both. Checking each app manually meant digging through my Home Screen or Spotlight searching–friction that often made me default to just one app. That laziness cost me more than I realized.

How the Shortcut Works

This is about as beginner-friendly as Shortcuts get. The flow is just:

• Open Uber
• Open Lyft
• Open Hopp

That’s it. No menus to build, no variables to configure, no scripting required. When I run the Shortcut, it simply opens all three apps in sequence. By the time I’m done glancing at Uber, Lyft, and Hopp, I know which one has the best deal.

The Real Benefit

Because this Shortcut makes it effortless to compare services, I’ve gotten into the habit of checking all three every time I book a ride. The result? I almost always end up picking the cheapest option. Over time, those small savings really add up–I’ve already saved enough to cover multiple months of my phone bill just by avoiding surge pricing.

Why It Stands Out

The magic here isn’t technical–it’s behavioural. By lowering the friction to compare prices, the Shortcut nudges me into making better choices. It’s a reminder that you don’t need advanced automations or APIs to get value out of Shortcuts. Sometimes a handful of “Open App” actions can save you more money than the most complex setups.

If you’ve been curious about building your first Shortcut but felt intimidated, start here. It’s dead simple, immediately useful, and might just pay for your next coffee–or your next month of rides.

Open Ride Share Apps

Apps Used In This Shortcut

Hopp

Uber

Lyft

How It Works

I designed the Shortcut to be flexible. It accepts input either from the Share Sheet or directly from my clipboard. That means I can grab a link from Safari, Messages, or anywhere else and send it straight into the Shortcut without any extra steps.

Here’s the flow it follows once I trigger it:

1. Extract the URL – The Shortcut pulls out the link from whatever I share or copy.

2. Regex Matching – A quick regular expression finds the correct page identifier from the Wikipedia link, so it works even if the URL has extra junk in it.

3. Build the API Request – Wikipedia has a little-known REST API that can generate a PDF version of any article. The Shortcut automatically constructs that request.

4. Fetch the PDF – The API serves up the article as a PDF.

5. Save to Files – Finally, the Shortcut saves the PDF wherever I choose, ready to open in Books, Preview, or any other PDF app.

Why I Find It Useful

Wikipedia does have a “Download as PDF” feature, but it’s buried in the desktop site’s menus and isn’t very friendly on mobile. With this Shortcut, I can grab a clean PDF in just a couple of taps.

I use it most when I’m traveling and don’t want to rely on spotty internet access. It’s also handy when I’m doing research and want to keep a local archive of detailed articles.

Small Touches I Like

A few details make the Shortcut feel smooth in practice:

• Clipboard fallback – If I don’t run it from the Share Sheet, it automatically checks my clipboard for a valid link.
• Regex cleanup – It doesn’t assume Wikipedia URLs are always clean; it handles variations.
• Automation potential – I can imagine extending it by having the PDFs saved directly into a tagged folder in Files, or even synced into Obsidian or DEVONthink.

Final Thoughts

This Shortcut is a simple example of how I like to use automation: take a clunky process and reduce it to a single tap. By leaning on Wikipedia’s API, I get a smooth way to save articles for offline use.

I’ve already found myself reaching for it constantly, whether I’m archiving something interesting or putting together a reading list for later. If you rely on Wikipedia as much as I do, this little Shortcut makes it effortless to keep what you find.

Wikipedia Article Downloader

Apps & Tools Used to Create this Shortcut

Jayson

How It Works

Here’s the flow I put together:

1. Grab Today’s Wordle

The Shortcut starts by formatting the current date and plugging it into the New York Times’ Wordle API (https://www.nytimes.com/svc/wordle/v2/[date].json). That gives me the official solution for the day in JSON format.

2. Parse the API Response

I use Shortcuts’ “Get Dictionary from” action to pull out the solution field – the actual word for today’s puzzle. Normally that would be game over, but that’s where the next step comes in.

3. Ask AI for a Hint

Instead of showing the word, the Shortcut creates a prompt:

“Without telling me the word, provide a hint to what the given word is below.”

I pass that along with the solution to Gemma 2B v2, a small local model I’m running. The model generates a creative hint while keeping the answer hidden.

4. Show the Hint

Finally, the Shortcut displays the hint in an alert, giving me just enough of a push without ruining the puzzle.

Why I Like It

What I enjoy about this Shortcut is how it combines three different things I love tinkering with:

• Web data: pulling JSON directly from the NYT Wordle API.
• Automation: using Shortcuts to parse and structure everything.
• Local AI: letting an on-device model do the fun part of writing the hint.

The result is quick, private, and surprisingly fun – every time I run it, I get a slightly different hint for the same word.

Final Thoughts

I wanted a way to make Wordle more approachable on the days when the word feels impossible, without crossing into outright cheating. This Shortcut hits that sweet spot for me. It’s a simple automation, but it feels fresh and playful every time I use it.

Wordle Hint

Apps Used to Create this Shortcut

OfflineLLM: Private AI Chat

Jayson

It’s a small thing, but it makes my life much easier.

How It Works

The Shortcut really boils down to three main steps:

1. Fetching the schedule

I start with Get Contents of URL to download the CSV file the city publishes with all of the collection dates and types. It’s just plain text, but the formatting is predictable enough to work with.

2. Parsing and filtering

Once I split the text into individual lines, I use a filter to find the rows that match my pickup day and today’s date. That narrows down the entire dataset to just what I care about.

3. Turning codes into plain English

The CSV doesn’t actually spell out “Garbage” or “Recycling.” Instead, it uses numbers to represent each type of waste. To fix this, I built a dictionary inside Shortcuts that maps those numbers to labels (e.g., 1 = Green Bin, 2 = Garbage). A repeat loop goes through each row, checks which items are marked T (true), and then looks up the proper label.

Handling Multiple Bins

One of the tricky parts was making the results readable when more than one type of waste is collected.

If there’s only one item, the output is simple: “Garbage.” But if two or three bins need to go out, I wanted it to sound natural.

The Shortcut counts the number of matches, and then formats them like this:

• Two items → “Green Bin and Recycling”
• Three or more → “Green Bin, Garbage, and Yard Waste”

It’s a small touch, but it makes the alert feel like something I’d actually write, not just machine output.

The End Result

When everything’s processed, the Shortcut shows me an alert with the result. On pickup days, I just run it and immediately know what to take to the curb:

“Today’s pickup: Green Bin, Garbage, and Yard Waste.”

No more scrolling through PDFs, no more guessing which week is recycling week.

Why I Like This Shortcut

This project really highlights why I enjoy using Shortcuts:

• It takes local data and turns it into something that actually fits my life.
• The automation is readable and flexible, even when dealing with messy CSV data.
• It’s practical–this Shortcut saves me time and prevents mistakes every week.

For now, though, it’s already become part of my weekly routine. It’s not flashy, but it’s one of those little automations that quietly makes life better–one trash day at a time.

Toronto Garbage Schedule

Apps & Tools I Used to Create this Shortcut

Inspect Browser

Jayson

⸻

The Idea

The premise is straightforward: I want to type in the name of a movie or TV show, and instantly see whether it’s available to stream in my region. No need to scroll through JustWatch, no extra apps, no hunting through five different services. Just one quick Shortcut that opens Safari with the results.

⸻

How It Works

The Shortcut starts by letting me choose between Movie or TV Show. Behind the scenes, this choice determines which TMDb endpoint it will query. For example:

• movie queries film titles
• tv queries series titles

Once I make a choice, the Shortcut asks me to type in the name. That query string gets URL-encoded and sent off to TMDb’s search API.

⸻

Handling Results

TMDb often returns multiple matches (think about searching for “Batman”). To handle this, the Shortcut loops through results and builds a list of title/ID pairs. I can then pick the correct match from a clean, combined list:

The Dark Knight : 155
Batman Begins : 272

If no results are found, the Shortcut gracefully shows a “No results found :(” message and stops.

⸻

Streaming Providers

Here’s where it gets good: once I’ve selected the right result, the Shortcut uses its TMDb ID to fetch the watch/providers endpoint. This API call returns a region-specific breakdown of streaming availability.

The Shortcut checks for my country code (CA in this case), and if providers exist, it pulls the first available streaming link. Safari then opens directly to the movie’s or TV Show’s JustWatch webpage. If nothing is available in my region, the Shortcut tells me:

“Unfortunately this title is not available in your region :(”

⸻

Why I Love This

Where To Watch has quickly become one of my most-used Shortcuts. It’s the perfect blend of lightweight automation and practical everyday use. Instead of juggling apps or websites, I can now quickly search for a movie or tv show and it tells me instantly where I can watch something–or if I need to wait until it arrives in Canada.

Where To Watch

Apps & Tools Used to Create this Shortcut

Jayson

⸻

The Problem I Wanted to Solve

Scanning a QR code on macOS isn’t straightforward. You either have to send the image to your iPhone or use a third-party app. Neither felt seamless. I wanted something that fit directly into my workflow: capture the QR code on my screen, decode it, and open the link—no extra devices or steps.

⸻

How My Shortcut Works

I designed the Shortcut in two phases:

Phase 1: Capturing the QR Code

• The Shortcut opens the Mac’s Interactive Screenshot tool, which lets me select just the portion of the screen where the QR code is visible.
• If I don’t actually grab anything, the Shortcut just stops cleanly. No errors, no wasted steps.

Phase 2: Decoding and Opening the Link

• Once I’ve got the screenshot, the Shortcut sends it to the QRServer API (http://api.qrserver.com/v1/read-qr-code/).
• The API responds with the decoded content in a dictionary. I pull out symbol.1.data, which is where the actual text or URL lives.
• If it’s a valid URL, the Shortcut opens it immediately in Safari.
• If there’s nothing useful, I get a simple alert: “No URL Found.”

⸻

Why I Like This Approach

What I like most about this Shortcut is how resilient it is. I added error checks at two points—first to make sure an image was actually captured, and second to verify that the decoded content is a valid URL. Both failure cases are handled gracefully.

It’s also a nice example of how powerful Shortcuts can be when you mix in APIs. By leaning on QRServer, I made a feature that Apple hasn’t brought to macOS yet, and I didn’t need to install extra apps to get there.

⸻

How I Use It

Now, anytime I run into a QR code on my Mac, I just trigger this Shortcut. Whether it’s a menu, a payment link, or a download, I can scan and open it instantly without breaking my flow.

It’s a small thing, but it’s one of those utilities I use often enough that I can’t imagine not having it anymore.

Scan QR Code On Screen

Apps & Tools I Used to Create this Shortcut

Jayson

BetterTouchTool handles the automation side, triggering these Shortcuts when certain conditions are met, so I don’t have to think about it. The result is a more balanced charging cycle and less battery stress—all fully automated.

⸻

The Building Blocks

The setup consists of two Shortcuts:

• Charge MacBook: Handles turning the charger on or off depending on the battery percentage.
• Check MacBook Charger on Login: Verifies the charger’s state when I log in or at periodic intervals.

Both Shortcuts talk to Home Assistant through its API. I store my API key and endpoint in reusable helper Shortcuts, which makes the main flows cleaner and easier to maintain.

⸻

Charge MacBook

This Shortcut first checks the current battery level. If it’s above 21%, it assumes charging isn’t critical. From there, if the level hits 100%, it sends a request to Home Assistant to switch off the charger using the /api/services/switch/turn_off endpoint.

If the battery is below 21%, the Shortcut flips the logic: it calls /api/services/switch/turn_on, waits a few seconds, and then double-checks whether the MacBook actually registered as charging. If it didn’t, I get an alert that says “Charge MacBook!!” so I can fix it manually.

It’s a nice mix of automation and failsafe. Most of the time, I don’t need to do anything—but if something misfires, I get a clear prompt.

⸻

Check MacBook Charger on Login

The second Shortcut adds some resilience. On login (and also every hour), BetterTouchTool triggers it to confirm the charger’s state.

Here’s how it works:

1. It checks the MacBook’s current battery percentage.
2. It queries Home Assistant for the state of the switch.macbook_charger entity.
3. If the battery is full and the switch is still on, it powers it down.
4. If the battery is at or below 21% and the charger is off, it powers it on.
5. Finally, it waits a few seconds and checks whether the MacBook is actually charging. If not, it throws the same “Charge MacBook!!” alert.

This creates a feedback loop where the system not only sends commands but also confirms whether those commands actually worked.

⸻

BetterTouchTool Triggers

The final piece of the puzzle is automation via BetterTouchTool. I’ve set up triggers for:

• Battery drops below 21% → Run Charge MacBook.
• Battery rises above 99% → Run Charge MacBook.
• On screen unlock → Run Check MacBook Charger on Login.
• Every hour → Run Check MacBook Charger on Login.

This combination ensures that charging is always managed proactively, whether I’m actively using the MacBook or not.

⸻

Why It Matters

Apple’s built-in battery management is good, but not always predictable—and it doesn’t give me direct control. With this Shortcuts + BetterTouchTool setup, I can enforce my own rules: charge only when needed, stop at full, and always keep an eye on the charger’s actual state.

It’s a small project, but one that makes a noticeable difference in daily use. My MacBook now charges only when it should, with BetterTouchTool quietly handling the details in the background.

Charge MacBook

Check MacBook Charger on Login

Apps and Tools Used for this Project

Home Assistant

BetterTouchTool

That’s where the ESP32 comes in. I flashed it with ESPHome and wired it straight into the Pi’s GPIO pins so I can treat the whole setup like a real smart-home appliance: I can power it on, shut it down safely, reboot it, and always know its current state inside Home Assistant.

⸻

How I Wired It

The wiring is pretty simple. Raspberry Pi GPIO14 goes into ESP32 GPIO27, which gives me feedback about whether the Pi is on or off. The Pi’s RUN pins are connected to ESP32 GPIO13, so I can pulse them to power it on. For shutdown and reboot, I used GPIO26 and GPIO13 on the Pi, wired to ESP32 pins that trigger those actions.

This way, the ESP32 can send commands to the Pi, and the Pi can talk back about its state.

⸻

My ESPHome Config

On the ESP32, I wrote an ESPHome config with a few pieces:

• A template switch that acts as the main power control. It checks the binary sensor to see if the Pi is already on before trying to pulse the RUN pins.
• A shutdown switch that pulls Pi GPIO26 high, which my shutdown script listens for.
• A reboot button that does the same thing with GPIO13 for rebooting.
• A binary sensor tied to GPIO14 that tells me if the Pi is running or not.

Here’s the core YAML I’m running:

switch:
  - platform: template
    name: "Raspberry Pi Switch"
    id: raspberry_pi_switch
    lambda: |-
      return id(raspberry_pi_power_state).state;
    turn_on_action:
      - if:
          condition:
            lambda: 'return !id(raspberry_pi_power_state).state;'
          then:
            - switch.turn_on: turn_on_pi
    turn_off_action:
      - switch.turn_on: turn_off_pi

  - platform: gpio
    name: "Turn On Raspberry Pi"
    pin: GPIO13
    inverted: true
    id: turn_on_pi
    internal: true
    on_turn_on:
      - delay: 500ms
      - switch.turn_off: turn_on_pi

  - platform: gpio
    name: "Shutdown Raspberry Pi"
    pin: GPIO12
    id: turn_off_pi
    internal: true
    on_turn_on:
      - delay: 500ms
      - switch.turn_off: turn_off_pi

  - platform: gpio
    name: "Reboot Raspberry Pi"
    pin: GPIO14
    id: reboot_pi
    internal: true
    on_turn_on:
      - delay: 500ms
      - switch.turn_off: reboot_pi

binary_sensor:
  - platform: gpio
    pin: GPIO27
    name: "Raspberry Pi Power State"
    id: raspberry_pi_power_state
    device_class: power
    filters:
      - delayed_on_off: 800ms

⸻

The Pi Side

On the Raspberry Pi, I wrote two tiny Python scripts. One listens on GPIO26 and calls shutdown now, the other listens on GPIO13 and calls reboot. They just loop forever in the background, waiting for a HIGH signal from the ESP32:

# shutdown_monitor.py
import RPi.GPIO as GPIO, time, os
GPIO.setmode(GPIO.BCM)
GPIO.setup(26, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)

while True:
    if GPIO.input(26) == GPIO.HIGH:
        os.system("sudo shutdown now")
    time.sleep(0.5)

# reboot_pi.py
import RPi.GPIO as GPIO, time, os
GPIO.setmode(GPIO.BCM)
GPIO.setup(13, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)

while True:
    if GPIO.input(13) == GPIO.HIGH:
        os.system("sudo reboot")
    time.sleep(0.5)

I wrapped both of these in simple systemd services so they start automatically on boot and restart if they crash. That way, the Pi is always listening for signals from the ESP32.

⸻

What It Feels Like in Practice

Now, inside Home Assistant, the Pi just shows up like any other smart switch. If it’s off, flipping the switch pulses the RUN pins and boots it up. If it’s on, flipping the switch triggers the shutdown script and powers it down cleanly. There’s also a reboot button when I need it. And the binary sensor tied to GPIO14 means I always know its current state.

The best part is how natural it feels. The Pi and Stream Deck live on my desk like a little smart-home console, but behind the scenes it’s running with the same polish you’d expect from a dedicated appliance. Everything is local, reliable, and integrated with the rest of my Home Assistant setup.

It’s one of those projects where the wiring is simple, the software is lightweight, but the result makes my whole setup feel more “finished.”

Apps and Tools Used for this Project

• Stream Deck HACS Integration
• Home Assistant
• ESPHome - Smart Home Made Simple

⸻

How It Works

At the core, my shortcut pulls live data straight from the TTC’s JSON endpoint:

https://alerts.ttc.ca/api/alerts/list

Here’s the basic flow I set up:

• Fetch the feed – I use Get Contents of URL to grab the JSON.
• Parse the response – The raw data is turned into a dictionary, which makes it easy to work with inside Shortcuts.
• Check for active alerts – If the routes field has values, the shortcut moves forward.

If not, I skip right to a “No Service Alerts at this time” message.

⸻

Iterating Through Alerts

When there are active alerts, the shortcut loops through them one by one. For each alert, it pulls out the key pieces of info:

• headerText for the main message
• lastUpdated for the timestamp

I then format the date into something readable and wrap everything in a bit of HTML. By setting font sizes, bolding headers, and adding dividers, the output looks more like a proper dashboard than just plain text.

⸻

The Final Output

Once all the alerts are collected, I combine them into a single block of text, convert it into rich text, and name it “TTC Service Alerts.” From there, I preview it in Quick Look.

If there aren’t any alerts, the shortcut just shows me a simple popup that says: “No Service Alerts at this time.”

⸻

Why I Made It

As someone who relies on public transit, I was tired of wasting time checking for service interruptions. This shortcut solves that problem: I get structured, up-to-date info from the official TTC feed, formatted in a way that’s quick to read.

It’s a small automation, but one that makes my daily routine less stressful.

TTC Service Alerts

Apps & Tools I Used to Create this Shortcut

Inspect Browser

Jayson

⸻

Checking for Fresh Data

The first thing my Shortcut does is make sure I’m not working with stale results. I format the current date, subtract one day (since advisories usually trail by a day), and call the city’s last_update API. From there, I grab the lastUpdate field and confirm whether it matches the date I expect.

If no data is available, the Shortcut stops and shows me an alert: “No recent results found.” That way, I’m not wasting time on old advisories.

⸻

Fetching the Results

Once I know the data is current, I build a URL against the beach_results API. I pass both a startDate and endDate based on the formatted date, and I also define a list of beach IDs. Right now I have two beaches set up—IDs 8 and 9—but I can easily add more later.

A Repeat loop runs through each beach ID, fetching its data individually and parsing the results. This keeps the Shortcut flexible if I want to expand it.

⸻

Formatting the Data

This is the part I had the most fun with. The Shortcut parses out the CollectionDate, statusFlag, eColi count, and any advisory notes. To make the results clear at a glance, I map:

• SAFE → green
• UNSAFE → red
• Anything else → black

I then build an HTML card for each beach, using large black headers for the beach name, medium-sized text for the collection date, and a color-coded status flag for the water quality. Everything is wrapped in elements with inline font sizes so the final report looks neat and easy to read.

⸻

Displaying the Report

After the loop finishes, the Shortcut combines all of the HTML snippets into one page. It converts that text into rich content and opens it in a Safari web view. What I end up with is a simple dashboard that shows the latest conditions for each beach I care about.

If the data feed has no values for that day, I just get a quick alert instead of a blank page.

⸻

Why I Built It

For me, this Shortcut strikes the right balance between utility and presentation. It’s not just dumping JSON—it’s validating freshness, parsing results for multiple beaches, and presenting them in a way that’s useful at a glance.

Now, instead of digging through government websites or spreadsheets, I just run the Shortcut and instantly see whether it’s safe to swim. It’s become part of my summer routine, and I love how it turns raw open data into something practical and personal.

Toronto Beaches Water Quality

Apps & Tools I Used to Create this Shortcut

Inspect Browser

Jayson

⸻

How I Built It

The Shortcut pulls from this endpoint:

https://www.dysartetal.ca//modules/NewsModule/services/getalertbannerfeeds.ashx

That feed contains JSON data with alert banners, including fire ban notices. Here’s what happens step by step:

1. Fetch the feed – Using “Get Contents of URL,” the Shortcut retrieves the raw JSON.

2. Parse into a dictionary – I convert the response into a Dictionary so each item can be checked.

3. Scan for fire ban notices – A “Match Text” action looks for the string Fire Ban. If there are matches, I know there’s an active ban.

4. Extract title and description – I loop through the items, grab the title and description fields, and convert the HTML-rich text into plain strings.

5. Build a styled HTML card – If a ban is active, the Shortcut injects the title and description into a block of HTML with big, bold text so it’s easy to read.

6. Display the result – The HTML card is shown in a Safari-style web view. If no fire ban is in effect, I get a simple alert that says: “No Fire Ban Status currently available.”

⸻

Why I Use It

Municipal websites aren’t always designed for quick updates, especially on a phone. With this Shortcut, I don’t have to waste time hunting for information—I get a direct answer in seconds.

It’s also a great example of how I like to use Shortcuts: not for giant, flashy automations, but for small, thoughtful utilities that make my day smoother.

⸻

Customizing the Shortcut

Since the Shortcut outputs HTML, it’s easy to tweak the look:

• Change font sizes to make the text more readable.
• Add colors—red for “ban in effect,” green for “ban lifted.”
• Include extra fields from the feed if needed.

And because it’s all built with system actions, I can extend it further: send a push notification when a ban starts, or log changes to a running Notes document.

⸻

Final Thoughts

This Shortcut takes raw municipal data and turns it into something useful that I can check at a glance. It removes friction, saves me time, and gives me peace of mind knowing I can always find out the current fire ban status instantly.

Fire Ban Status

Apps & Tools I Used to Create this Shortcut

Inspect Browser

Jayson