andreas/vanlink
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

van-leds: drive the R5C power/LAN/WAN/WiFi LEDs (ENABLE_LEDS, LED_* vars, post-check probe)

Browse Source 
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KqhjP7nud5gdBg25zCiRk9
This commit is contained in:
andreas
2026-09-23 22:04:11 -04:00
co-authored by Claude Sonnet 5
parent e2036c295d
commit 0f643be719
9 changed files with 382 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+4
View File
@@ -251,6 +251,10 @@ see that file's own comment). After editing the dashboard, copy both places and
- **Tuning**: edit `/etc/van-nvme-watch/config.json` (`grace_period`, `cooldown`, device paths), then `systemctl restart van-nvme-watch`.
- Status: `systemctl status van-nvme-watch`, `journalctl -u van-nvme-watch -f`, or `cat /run/van-nvme-watch/state.json`.
### Front LEDs (`van-leds`, NanoPi R5C)
Drives the R5C's four LEDs from `leds/van-leds` (config `/etc/van-leds/config.json`, rendered from the host file). **Power** is on; **LAN** blinks with activity on `LAN_IFACE`; **WiFi** blinks with activity on `WIFI_5G_IFACE` (the 5GHz AP radio); **WAN** follows the active uplink from van-failover (`/run/van-failover/state.json`): activity on that device while it is healthy, a heartbeat when an uplink has link but no healthy internet (or failover state is unavailable but the wired uplink has carrier), off when there is no uplink. It is re-evaluated every 5 s. Enabled per host with `ENABLE_LEDS=1` and the sysfs names `LED_POWER LED_LAN LED_WAN LED_WLAN` (empty = leave that LED alone; on the R5C `red:power green:lan green:wan green:wlan`); the Pi 5 has `ENABLE_LEDS=0`. Needs the Armbian `nanopi-r5c-leds` overlay in `/boot/armbianEnv.txt` (`--post-check` warns when an LED is missing or a static LED has the wrong trigger).
### Battery monitor (`van-battery`)
- Watches mains vs battery via `/sys/class/power_supply/AC0/online` (0 = on battery) and charge via `BAT0/capacity`. Both resolve by `type` (Mains/Battery) if those names ever differ.
- **Only while on battery**, it sends escalating **Pushover** alerts at **25 / 20 / 15 %**, and at **10 %** sends a final alert and runs `systemctl poweroff` (after `shutdown_grace`, default 8 s, so the alert flushes first).