Root cause of the silent-alarm-on-HDMI bug, measured on the host rather than
inferred:
$ pactl list cards | grep 'alsa_card.pci-0000_01_00.1' -A1
Active Profile: off
$ pactl list short sinks
61 alsa_output.pci-0000_0d_00.6.analog-stereo IDLE
While that card's profile is "off" the G27Q's HDMI sink does not exist, so
_list_real_sinks() cannot return it. _play_on_all_sinks re-enumerates sinks
every beep cycle -- its docstring says it picks up late outputs "without
re-running activation" -- but that can never find a sink whose card is off.
There is nothing to enumerate.
Activation runs exactly once, at startup. At wake time the monitor has not
finished its HDMI handshake, the profile reads "available: no",
_parse_profile_line drops it, and the card is never revisited. Silent alarm.
_reactivate re-runs activation on a decaying schedule (3,5,7,10,15,20,30s)
on a daemon thread, logging the full enumerated sink list every pass so the
next failure is diagnosable from the JSONL log instead of guessed at.
Verified end to end on this machine:
BEFORE: ['alsa_output.pci-0000_0d_00.6.analog-stereo']
AFTER : ['alsa_output.pci-0000_01_00.1.hdmi-stereo',
'alsa_output.pci-0000_0d_00.6.analog-stereo']
and a 1 kHz tone plays through the HDMI sink (paplay exit 0). Note the
constant ALARM_AUDIO_SINK was correct all along; only the activation was
failing.
Wiring into WakeAlarm lands with the _alarm.py split, since touching that
478-line file trips the 250-line gate.
399 tests, 100% branch coverage.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EckWmyfetYq3Mi8MAnUudh
|
||
|---|---|---|
| .github/workflows | ||
| docs/explanations | ||
| phone_app | ||
| prompts | ||
| scripts | ||
| wake_alarm | ||
| .gitignore | ||
| .pre-commit-config.yaml | ||
| AGENTS.md | ||
| CLAUDE.md | ||
| DOCS-speaker-recommendation.md | ||
| install.sh | ||
| pyproject.toml | ||
| README.md | ||
| requirements.txt | ||
| shutdown-wrapper.sh | ||
| sleep-hook.sh | ||
| TODO-file-length-250.md | ||
| wake-alarm-fans.sh | ||
| wake-alarm-trigger.service | ||
| wake-alarm-trigger.timer | ||
| wake-alarm.service | ||
wake_alarm
A phone-driven wake alarm for an always-on PC. The alarm time is whatever the
companion phone app last synced (via the shared crdt_sync transport over a
private GitHub repo); a per-minute systemd user timer fires at exactly that
time, showing a fullscreen, challenge-dismissed alarm with fan ramp and
optional TP-Link Tapo P110 smart-plug control.
Change the alarm on the phone at any hour and the PC follows within ~5
minutes. If the PC does happen to be powered down, a shutdown wrapper
hibernates with rtcwake set to the same synced time, as a fallback.
Install
bash install.sh
This installs the package + dependencies into system Python's user
site-packages (the systemd units run /usr/bin/python directly, not a venv —
see CLAUDE.md), installs and enables the per-minute trigger timer, the
systemd-sleep resume hook, the shutdown wrapper that hibernates with
rtcwake as a fallback, the fan-ramp script, and (optionally) python-kasa
for smart-plug control.
Reading the phone's alarm needs a GitHub token with repo scope, at
~/.config/wake_alarm/sync.json as {"token": "..."}. If that file is
absent, a sibling app's ~/.config/{diet_guard,screen_locker}/sync_token is
used instead, so one token covers every app syncing through kuhyx/syncs.
Usage
python -m wake_alarm._alarm --demo # test the alarm window (safe, closeable)
python -m wake_alarm._sync --show # what alarm time the PC resolves
python -m wake_alarm._trigger --dry-run # what the next tick would do
journalctl --user -fu wake-alarm-trigger.service # watch it live
The alarm fires automatically once installed; no manual invocation is needed in normal operation.
Development
python -m venv .venv && .venv/bin/pip install -r requirements.txt
.venv/bin/pre-commit install && .venv/bin/pre-commit install --hook-type pre-push
.venv/bin/python -m pytest wake_alarm/tests/ --cov=wake_alarm --cov-branch --cov-fail-under=100
See CLAUDE.md for scheduling details, the hibernate/rtcwake mechanism,
the cross-repo workout_log.json read, and production deployment gotchas.