Live physical device running automated GO Battle League matches, move timing, and charged attacks via ADB.
The project
What it is
This project brings the repetitive parts of my daily Pokémon GO routine into a unified Python automation toolkit. A concise set of named commands coordinates gift sending, friend code queuing, GO Battle League matches, peer-to-peer trading, bulk transfers, and berry feeding across tethered devices.
The public architecture separates reusable device-interaction logic from private credentials. You supply your own device identifiers, screen resolutions, and friend lists. The codebase provides the complete execution pipeline so another developer or AI coding agent can reproduce the setup on independent hardware.
Media & Artifacts
Screenshots & production checks
Shield Timing & Defense
Sub-pixel template matching and frame timing to trigger defensive protect shields against incoming opponent charged moves.
Charged Attack Execution
Real-time optical frame evaluation detecting super-effective multipliers, charged move mini-game swiping, and stat changes.
Party Selection & Matchmaking
Automated league navigation, party composition verification, and match queuing without manual inputs.
Inside the project
How it works
01
One entry point per job
Descriptive Python entry points route directly into platform-specific Android (ADB) and iOS workers rather than burying execution in an unmaintainable monolith.
02
A shared fleet layer
Device discovery, battery thresholds, readiness checks, and optional remote-machine dispatch operate independently from game-specific loops.
03
Private configuration by design
Device serials, machine IPs, account tokens, friend lists, and execution logs stay strictly within private configuration directories, using generic templates in version control.
04
Inspectable execution plans
Running any command with --plan previews device routing, screen coordinates, and target counts without touching physical game state.
The public entry points
One file for each workflow
Run these commands from the repository in your Python environment. The examples preview workflow routing; fleet.py status checks readiness. Each entry file links to the public source.
Coordinate a selected pair of devices for the trading workflow. Select two devices on the same host. Pair names come from your private inventory; these names are examples.
Rather than blindly sending tap events on fixed timers, the pipeline samples screen frames using fast ADB framebuffer grabs, applying OpenCV template matching to confirm animations completed.
Fleet Health & Thermal Throttling
Devices run prolonged background batches. The fleet monitor polls battery levels and CPU temperatures, inserting cool-down intervals when thermal throttling threatens frame rates.
A practical starting point
Recreate the setup on your hardware
1
Install the package and device tools
Set up Python dependencies and verify ADB connectivity for Android devices or the documented WebDriverAgent connection for iOS hardware.
2
Create your private inventory
Copy pokemon-fleet.example.yaml into ~/.config/pokemon-go-automation/ and map your connected device serials and screen calibrations.
3
Check readiness and review a plan
Run python fleet.py status to verify battery and connection health, then execute your target command with --plan.
4
Run and inspect physical results
Execute live workflows with small batches while monitoring the physical screen to verify gesture alignment and network latency tolerances.
Build on the work
Documentation for people and coding agents
Start a new AI coding session with AGENTS.md and the AI handoff guide. Then supply your own environment details privately. The guides connect each command to its configuration, implementation, and verification steps.
These workflows interact directly with the Pokémon GO interface on physical hardware. Screen layouts, game updates, and network lag can alter timing. Always review proposed trades and transfers with --plan prior to live runs.
