HSR Dashboard - HoYoLab desktop companion

The problem

Honkai: Star Rail has several useful account surfaces, but they are spread across game menus, HoYoLab pages, reward pages, and redemption forms. The information is simple individually: stamina, daily reward status, characters, expeditions, and codes. The friction comes from checking all of it manually and repeating the same small actions every day.

HSR Dashboard turns those repeated checks into a desktop companion. Instead of opening multiple pages, the app gives one Windows GUI for Trailblaze Power, daily check-in, character roster browsing, and single or batch redemption codes.

My role

This was a solo build. I wrote the HoYoLab API client, request signing headers, local config/cache handling, background scheduler, CustomTkinter interface, and PyInstaller packaging script.

The main engineering work was making a personal automation tool behave like a small product: setup flow, UID detection, tab navigation, loading states, error handling, auth-expired prompts, background refresh, and a distributable executable.

System design

The app starts with a setup dialog where the user provides a HoYoLab session cookie, UID, server, and optional advanced request-signing salt. It can detect the bound Star Rail role from the account, infer server from UID, normalize cookie text, and persist the app configuration under the user's home directory.

Once configured, the dashboard creates a shared HSRClient and four primary tabs. Stamina pulls real-time note data and updates the "full in" timer every second from the last fetched snapshot. Check-In loads the monthly reward calendar and can claim the daily reward. Characters combines index, roster, and challenge data, then caches the roster locally for faster startup. Redeem supports a single code or batch redemption with a delay between requests.

Key technical decisions

• Desktop GUI instead of command-line-only automation. A GUI made the tool easier to use daily because status, errors, and results are visible without remembering commands or flags.
• One API client around HoYoLab endpoints. The HSRClient centralizes cookies, headers, DS signing, request timeouts, retcode handling, authentication errors, and endpoint-specific parsing.
• Threaded background tasks for UI responsiveness. API calls run in worker threads and report back through Tk callbacks, so long network calls do not freeze the interface.
• Scheduled refresh with manual control. The app can auto-refresh notes, check-in status, and character data on separate intervals while still exposing a "Refresh All" button for explicit updates.
• Local cache for expensive roster data. Character data is saved to a JSON cache after a successful sync, which gives the Characters tab useful content even before the next network refresh completes.
• Packaged Windows build. The build.ps1 script creates a one-file, windowed PyInstaller executable named HSR Dashboard, so the tool can run without launching Python manually.

Results

The repo reached a complete v1 desktop utility with setup, account detection, four functional tabs, scheduled background refresh, auto check-in on launch, single and batch code redemption, authentication error prompts, local character caching, and a packaged Windows executable.

The implementation is compact but covers the full product path: 10 Python source files, a typed config model, a HoYoLab API wrapper, UI tabs separated by responsibility, and a build script that packages the app into dist/HSR Dashboard.exe.

What I would do differently

I would move session storage out of the JSON config file and into the Windows Credential Manager or a system keychain. The current local config is simple, but credential-sensitive desktop tools should treat session cookies more carefully.

I would add API fixtures and tests around the response parsers. HoYoLab payload shapes can change, and the app already has several defensive parsing helpers; tests would make those assumptions explicit and easier to maintain.

I would also add clearer rate limiting and backoff around batch redemption and scheduled refresh. The current delay protects the basic batch path, but a more production-ready version should handle retries, cooldowns, and endpoint-specific failures more deliberately.