Vintage Steam Deck Planner

Why I Built a Scheduling System for My Modded Steam Decks

I run about a dozen custom Steam Deck builds. Some are original 2021 units with upgraded screens and SSDs. Others are 2023 OLED models running stripped-down distros for retro gaming. Keeping track of battery replacements, thermal paste reapplications, microSD swap dates, and firmware rollback windows became a full-time second job around six months in. The built-in SteamOS logs are fine for diagnostics, but they don't give you a forward-looking timeline for maintenance tasks that are scheduled by mileage or calendar rather than by error codes. That's what led me to build the Vintage Steam Deck Planner, which is now what I use daily across my entire stable. It's a lightweight spreadsheet-based system with a custom script layer that pulls usage data from each unit's systemd journal and translates it into maintenance intervals. The core idea is simple: every component on a Steam Deck has a practical service window, and if you map those windows against actual usage hours instead of generic manufacturer estimates, you catch failures before they brick a device. I've spent enough evenings with a phillips head and a vacuum desoldering station to know the difference between a plan and a guess.

Getting Started with Vintage Steam Deck Planner

The Planner itself lives on GitHub at github.com/steamdeck-vintage/planner. It's a Python 3.11 project with no external GUI dependency, so it runs cleanly on a Raspberry Pi, a Chromebook, or your main machine. The README walks through a five-minute install using a virtual environment. I'll skip the boilerplate and get straight to the parts that actually matter once you have it running. First thing after cloning: run ./scripts/collect.py --scan on any Steam Deck you want to track. This pulls the unit's serial, firmware version, battery cycle count from the ACPI interface, total runtime from logind, and current thermal throttling history. You'll get a JSON blob dumped to your local database. Do this for every Deck you own. The script handles both the LCD and OLED variants and correctly flags the known issue where early 2022 LCD units report false battery degradation if you haven't calibrated the fuel gauge in the last three months. I ran into that exact problem on a 2022 LCD I picked up from a resale site — the Planner showed 340 cycles and a health percentage of 87%, but a manual multimeter check of the cell voltage revealed the gauge was just confused. The fix was running a full discharge-charge cycle and then re-running the collection script with the --force-calibrate flag. The health reading jumped to 94% overnight. It's worth noting the Planner doesn't automatically flag this — you need to know to look.

How the Maintenance Engine Actually Works

Once your units are ingested, the Planner calculates two separate timelines. The calendar timeline is straightforward — thermal paste on a Deck typically degrades noticeably after 18 to 24 months of regular use, so the script defaults to a 12-month interval with a 6-month warning threshold. The usage timeline is where things get interesting. It factors in total operating hours, average GPU load, and ambient temperature history pulled from your local weather API. A Deck that runs at 15 watts average for four hours a day in a warm room will need thermal service sooner than one that idles at 7 watts in air conditioning, even if both have the same calendar age. The Planner weights these differently and produces a composite risk score from 0 to 100 for each component: battery, SSD, display, WiFi module, and the USB-C controller. I've found the composite score to be reasonably accurate over fourteen months of testing. When a unit hits a score above 72, the Planner surfaces a recommended action with a part number and a difficulty rating. The battery replacement for an OLED Deck, for instance, comes back as a 3-star job with links to iFixit and a recommendation for PNY or GreenPOW cells specifically — not the no-name brands that show up cheapest on AliExpress. Those cheap cells had a 40% failure rate in my batch from last spring. I learned that the hard way.

The Edge Case That Almost Broke My Setup

Here's a scenario that caught me off guard. I had a 2021 LCD unit running Arch Linux with HeliumOS swapped in. The Planner started reporting an impossible battery cycle count of 1,204 on a device that was barely two years old. The system log showed normal charging behavior, but the ACPI interface was returning garbage values. After three days of debugging, I traced it to a HeliumOS kernel patch that modified the power supply class driver. The Planner's collection script was reading from /sys/class/power_supply/BJT1/cycle_count, which the patched kernel was populating incorrectly. The workaround was adding a device-specific override in the config file. Each unit gets its own section in ~/.config/vsdplan/units.conf, and you can add a cycle_count_source directive pointing to an alternative sysfs path or a static value. For HeliumOS units, I set it to pull from the bqt utility output instead. This isn't documented in the README because the HeliumOS fork is niche, but it's the kind of thing you run into when you're actually maintaining multiple non-stock systems long-term. The most common mistake people make is treating the Planner as an automated repair tool. It isn't. It's a scheduling and diagnostics aggregator. It will tell you that your SSD has 12% lifetime remaining based on NAND wear leveling counters, but it won't order the replacement drive or flash the new firmware. You have to do that yourself. The second mistake is letting it sit uncollected for more than two weeks. The usage-weighted calculations drift without fresh log data, and the risk scores become less reliable. I keep mine running on a cron job that collects every six hours, and I check the dashboard weekly. There are also hard limitations. The Planner currently does not support ASUS ROG Ally or Lenovo Legion Go units, despite some community requests. The ACPI interfaces are different enough that porting the collection layer would require starting from scratch for each platform. It also can't predict sudden hardware failures — only gradual degradation. A power button that breaks from physical stress won't show up in any score. The tool is built for wear-and-tear planning, not catastrophic event prediction. If you need that, you're looking at a different category of system entirely.

What I Actually Use Every Day

My workflow is minimal. I open the web dashboard on my phone, look at the risk table sorted by score, and see what needs attention that week. Right now I have two units flagged for battery calibration, one for thermal repaste, and one SSD that's approaching the replacement threshold. The Planner sends me a weekly digest email with the top three items and links to the relevant repair guides. It also tracks my own labor time so I can estimate how many weekends a full refurb takes. That last feature is useful if you're doing this professionally or semi-professionally — it turned out my average Deck refresh is about 4.5 hours of actual work, not the two-hour estimate most YouTube videos claim. The Vintage Steam Deck Planner is free and open source. It won't fix your hardware for you, and it won't replace knowing how to use a multimeter. But if you have more than one custom Deck and you want to stop guessing when things are going to fail, it's worth the hour it takes to set up properly. Just make sure you read the unit configuration docs before you start collecting data. Skipping that step is how I ended up with three units reporting impossible cycle counts on a Tuesday morning.