Auto power-on the SIM868 module via its PWRKEY GPIO line

Root-caused a "GPS not working" report to the SIM868 module chip being
fully powered off (the HAT's 5V rail can be live while the chip itself
stays off until PWRKEY is triggered) - confirmed by getting zero AT
response at any baud rate while the app's GPS thread had the serial
port open normally.

Discovered this specific HAT revision has the "P4" GPIO power-on mod
wire installed (Waveshare FAQ / GSM_PWRKEY.rar script), letting PWRKEY
be triggered via physical pin 7 (BCM GPIO4) instead of a manual button
press. Verified live: pulsing it low for 4s then high brought the
module from zero AT response to responding immediately.

modules/app_gps.py: added _module_responds()/_pulse_pwrkey()/
_ensure_module_powered(), wired into _poll_loop() before the existing
GNSS power-on check. Checks AT first and only pulses PWRKEY if the
module isn't already responding, since PWRKEY is a toggle (pulsing an
already-on module would turn it back off).

Also fixed a related logging gap found while debugging: print()
diagnostics from app_gps.py were invisible in yaris-obd.log for
months because Python fully-buffers stdout when it isn't a TTY.
deploy/yaris-obd.service now sets PYTHONUNBUFFERED=1.

requirements.txt: added RPi.GPIO.
PLAN.md: documented both findings and the Pi deploy gotchas (systemd
unit file changes need a manual copy + daemon-reload; requirements.txt
changes need a manual venv pip install - neither is picked up by a
plain git pull + restart).

Co-authored-by: Copilot <[email protected]>

PLAN.md

@@ -30,8 +30,14 @@ pick up the project without needing prior chat history.
 - **The SIM868 module chip itself needs its PWRKEY button pressed and held (~1-2s) to power on**
   — this is separate from the board's 5V/PWR LED, which can be lit while the module chip is
   fully off. AT commands get zero response if the module chip isn't powered, even with perfect
-  UART wiring/config. This is a manual step needed on every power cycle unless a P4
-  GPIO-power-on hardware mod (per Waveshare FAQ) is done — not pursued so far.
+  UART wiring/config. **Update 2026-08-09: this HAT revision DOES have the "P4" GPIO-power-on
+  mod wire installed** (per the Waveshare FAQ/`GSM_PWRKEY.rar` script) — confirmed by pulsing
+  physical header pin 7 (BCM GPIO4) LOW for 4s then HIGH while the module was unresponsive, after
+  which it immediately answered `AT`. This is now automated in `modules/app_gps.py`
+  (`_ensure_module_powered()`), which checks `AT` first and only pulses PWRKEY if the module
+  isn't already responding (PWRKEY is a toggle — pulsing an already-on module would turn it back
+  off, so this check-first behavior is required). No more manual button-pressing needed after a
+  Pi power cycle.
 - Confirmed AT command baud rate: **115200**.
 - GNSS workflow: `AT+CGNSPWR?` to check GNSS power state, `AT+CGNSPWR=1` to power on,
   `AT+CGNSINF` to poll for a fix. Response format:
@@ -577,7 +583,18 @@ optimization. Not scoped/designed yet.
   `~/app/yaris-obd/yaris-obd.log` (not journald - the systemd unit redirects both streams there),
   so use `tail`/`grep` on that file, not `journalctl`, to see application-level prints (upload
   progress, OBD/GNSS errors, etc.) - `journalctl -u yaris-obd.service` only shows service
-  start/stop/crash lifecycle events.
+  start/stop/crash lifecycle events. **Update 2026-08-09**: plain `print()` calls were silently
+  invisible in that log for months because Python fully-buffers stdout when it's not a TTY (a
+  file, in this case) — `logging`-based lines (e.g. the `obd` library's own logger, which uses
+  stderr) showed up fine, but bare `print()` diagnostics from `app_gps.py` never did. Fixed by
+  adding `Environment=PYTHONUNBUFFERED=1` to the systemd unit
+  (`deploy/yaris-obd.service`) — **remember to also copy the updated unit file to
+  `/etc/systemd/system/yaris-obd.service` and run `sudo systemctl daemon-reload`** on the Pi, a
+  plain `git pull` + restart does NOT pick up systemd unit file changes (the live
+  `/etc/systemd/system/` copy is independent of the repo's `deploy/` copy).
+- **Pi deploy loop, requirements.txt changes**: after any `requirements.txt` change (e.g. adding
+  `RPi.GPIO`), also run `~/app/yaris-obd/venv/bin/pip install -r requirements.txt` on the Pi — a
+  `git pull` alone doesn't install new dependencies into the venv.
 - **Pi memory budget**: ~900MB usable RAM, no swap. Any code path that might buffer a whole
   dashcam-sized file (hundreds of MB) in memory is unsafe on this hardware - stream, don't buffer
   (see Phase 10).