Run any Skill in Manus with one click

aeon-power

Stars13

Forks3

UpdatedJune 17, 2026 at 15:27

Check whether an AEON Magick Orb is on wall power or running on its battery backup (a Waveshare UPS HAT), and how much charge is left. Read-only. Load this before any long, unattended operation on an Orb so you know it won't power off mid-task and leave you blind. Returns {present:false} (not an error) on an Orb with no UPS. Per-Orb battery state is also summarized in the aeon-fleet roster, so for many Orbs read the roster instead of polling each.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

AEON-7

AEON-7/aeon-magick-ai-computer-control

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

2 files

SKILL.md

readonly

name

aeon-power

description

aeon-power

Is this Orb on battery, and is it about to die? An Orb can run off a Waveshare UPS HAT (E) stacked on the Pi. GET /api/ups relays the live battery picture so you know whether the device you're operating is on wall power or about to power off. Read-tier — a plain GET, no writes.

Credentials. Auth = Authorization: Bearer $AEON_TOKEN against https://$AEON_HOST (self-signed → curl -k). The token is never in this skill — export AEON_TOKEN=<your token> (e.g. from your password manager) or load ~/.openclaw/aeon-magick.env (set -a; . ~/.openclaw/aeon-magick.env; set +a). A 401 means the token is unset/wrong — fix that, don't switch tools.

ups — battery state

curl -sk -H "Authorization: Bearer $AEON_TOKEN" "https://$AEON_HOST/api/ups"

The aeon-ups daemon owns the HAT's I2C bus and publishes the power picture to /run/aeon/ups.json every 2 s; this endpoint relays that file.

{
  "present": true,
  "charge": 84,
  "on_battery": false,
  "charging": true,
  "voltage": 16.4,
  "minutes_to_empty": null
}

Field	Meaning
`present`	HAT detected + daemon running. `false` = no UPS on this Orb — power is whatever the wall gives it.
`charge`	battery state-of-charge, 0–100 %.
`on_battery`	`true` = wall/USB-C input is gone, running on the cells right now.
`charging`	input present and topping the cells up.
`minutes_to_empty`	estimated runtime left when `on_battery`; `null` while charging / on wall power.

Per-cell voltages / VBUS / current may also appear — informational. The four that matter: present, charge, on_battery, minutes_to_empty.

{"present": false} is the normal answer on an Orb with no UPS HAT — not an error. Don't treat a missing battery as a fault; it just means power-state is unmonitored there.

when to care

Check ups before any long, unattended operation (an OS install, a slow download, a multi-step macro you won't be watching):

on_battery: true + low/falling charge → the Orb may shut down mid-task. The controlled machine keeps running, but you lose your eyes and hands on it the moment the Pi dies.
present: false → no battery backstop at all; a power blip drops the Orb hard. Same caution for unattended work.
Pair with a snapshot diagnosis: snapshot frozen / stream dropped while on_battery: true and charge low → the Orb is likely powering down, not a capture problem.

For a fleet, every peer's ups summary is already in GET /api/fleet/roster (see the aeon-fleet skill) — spot a low Orb without polling each one.

No write surface here — purely an observability read. Pi power itself (/api/system/pi-reboot, /pi-poweroff) is a separate admin-only capability, not an agent action. No MCP tool — REST-only.

More from this repository

same repository

aeon-magick

AEON-7/aeon-magick-ai-computer-control

Drive a target host's keyboard, mouse, trackpad, AND screen capture through an AEON Magick AI Computer Control Orb on the LAN — and pick among several Orbs in a fleet. Each Orb's USB-C OTG port emulates a real USB keyboard + mouse (+ optional Apple multi-touch trackpad) on its target; the Orb does its OWN HID — it both sees AND acts, no external dongle. Vision comes from a switchable capture source (Cam Link USB, Pi-5 HDMI→CSI bridge, or a CSI camera), so an agent can flip between watching the controlled screen and looking at a physical thing. All ops are atomic HTTPS calls — there is no `key_down` / `key_up` split that can leave the target with a stuck key after a packet drop. Use to operate the USER'S OWN computers, accounts, and services.

2026-07-1913

aeon-bench

AEON-7/aeon-magick-ai-computer-control

Benchmark an open LLM on real hardware and submit an attested run to the AEON Bench leaderboard. Deploy the Aeon Bench Pod (pull → verify → serve → benchmark → sign → submit) onto a connected GPU server, watch it through its phases, and open its dashboard. Load this when the task is to EVALUATE / benchmark / leaderboard a model. The pod needs an NVIDIA GPU, so it deploys to a connected system, not the Orb itself.

2026-07-0713

aeon-update

AEON-7/aeon-magick-ai-computer-control

Keep an Aeon Orb current and secure — apply OS security patches, toggle automatic patching, and check whether a newer Orb IMAGE has been published. Load this when the task is to update / patch the Orb, check its version, or ask "is my Orb up to date?". Two distinct layers: OS packages (apt, live) and the whole image (re-flash from Patreon — the Orb never self-flashes).

2026-07-0513

aeon-model-share

AEON-7/aeon-magick-ai-computer-control

Find, import, and move AI models across the Intergalactic Model Share — a decentralized IPFS network every Orb joins at boot. List models shared by Orbs across the network, import one straight from HuggingFace / Ollama / Civitai (verified), pull it down to this Orb's library, and push it onto a connected GPU server to serve. Load this when the task is about GETTING A MODEL onto a machine; for benchmarking a model use aeon-bench, for driving a screen use the core aeon-magick skill.

2026-07-0513

aeon-cameras

AEON-7/aeon-magick-ai-computer-control

Choose what an AEON Magick Orb's eye is pointed at. An Orb can have several video inputs wired to it — a USB HDMI-capture stick, a Pi-5 HDMI→CSI bridge (watch the controlled machine's screen), and a Pi-5 CSI camera (look at a physical scene through a lens). This skill reads the available capture sources and switches the live source so the console snapshot/stream shows what you need. Pi-5-only sources (camera-csi, hdmi-csi) are gated by the Orb's model. Load this when you need to switch between "see the screen I control" and "see a physical thing"; for plain screen viewing use the core aeon-magick skill's vision reference.

2026-06-1713

aeon-fleet

AEON-7/aeon-magick-ai-computer-control

See every AEON Magick Orb on the network at once and pick which one to operate. Each Orb is a peer in a decentralized roster; one roster call returns every Orb's identity, what it controls, its capture sources, battery and health — so you choose the right Orb, then drive it directly with the core aeon-magick skill against that Orb's own endpoint. Load this only when there may be more than one Orb; for single-device work just set AEON_HOST and use the core skill.

2026-06-1713

name

aeon-power

description

aeon-power

Credentials. Auth = Authorization: Bearer $AEON_TOKEN against https://$AEON_HOST (self-signed → curl -k). The token is never in this skill — export AEON_TOKEN=<your token> (e.g. from your password manager) or load ~/.openclaw/aeon-magick.env (set -a; . ~/.openclaw/aeon-magick.env; set +a). A 401 means the token is unset/wrong — fix that, don't switch tools.

ups — battery state

curl -sk -H "Authorization: Bearer $AEON_TOKEN" "https://$AEON_HOST/api/ups"

The aeon-ups daemon owns the HAT's I2C bus and publishes the power picture to /run/aeon/ups.json every 2 s; this endpoint relays that file.

{
  "present": true,
  "charge": 84,
  "on_battery": false,
  "charging": true,
  "voltage": 16.4,
  "minutes_to_empty": null
}

Field	Meaning
`present`	HAT detected + daemon running. `false` = no UPS on this Orb — power is whatever the wall gives it.
`charge`	battery state-of-charge, 0–100 %.
`on_battery`	`true` = wall/USB-C input is gone, running on the cells right now.
`charging`	input present and topping the cells up.
`minutes_to_empty`	estimated runtime left when `on_battery`; `null` while charging / on wall power.

Per-cell voltages / VBUS / current may also appear — informational. The four that matter: present, charge, on_battery, minutes_to_empty.

{"present": false} is the normal answer on an Orb with no UPS HAT — not an error. Don't treat a missing battery as a fault; it just means power-state is unmonitored there.

when to care

Check ups before any long, unattended operation (an OS install, a slow download, a multi-step macro you won't be watching):

on_battery: true + low/falling charge → the Orb may shut down mid-task. The controlled machine keeps running, but you lose your eyes and hands on it the moment the Pi dies.
present: false → no battery backstop at all; a power blip drops the Orb hard. Same caution for unattended work.
Pair with a snapshot diagnosis: snapshot frozen / stream dropped while on_battery: true and charge low → the Orb is likely powering down, not a capture problem.

For a fleet, every peer's ups summary is already in GET /api/fleet/roster (see the aeon-fleet skill) — spot a low Orb without polling each one.