denki / docsGitHub ↗

Your first device

Go from an installed CLI to your first energy reading. Denki runs on your computer and talks to devices on your local network. Keep the computer and device on a network that allows them to reach each other; guest Wi-Fi often blocks this.

1. Install Denki

Install Rust with rustup first. Denki requires Rust 1.99 or newer; the repository selects 1.99.1 automatically.

cargo install denki --locked --version 0.2.0
denki --help

For the exact GitHub source tag, use cargo install --git https://github.com/kahwee/denki --tag v0.2.0 --locked.

Cargo installs denki into ~/.cargo/bin by default. If your shell cannot find it, restart the shell after installing Rust or add that directory to PATH.

2. Connect a Kasa device

Scan your network, verify the device address independently, then choose an alias:

denki scan
denki alias "desk plug" 192.0.2.42
denki aliases
denki info "desk plug"

Replace desk plug and the example IP with your verified device. Scan reports Kasa observations but never enrolls a new Kasa alias. Legacy Kasa aliases need explicit re-enrollment before group control. Kasa replies cannot authenticate an address change. If DHCP moves a Kasa device, verify its new IP independently (for example, in your router), then update the saved name with denki alias "desk plug" NEW_IP. Scan will not move it automatically, even if a reply claims the same device ID.

If discovery does not find a device, look up its IP in your router and add it:

denki alias "desk plug" 192.0.2.42
denki info "desk plug"

The 192.0.2.x addresses in this guide are placeholders. Replace them with your device's actual local IP.

2. Connect a Tapo device instead

Tapo requires account credentials. For P125 plugs using TPAP, add the IP with --tapo (--tpap is a synonym); the client negotiates TPAP/KLAP automatically. For other registered Tapo models, use the original --klap client. Save the credentials for the TP-Link account associated with the device. login prompts for the password so it does not go into your shell history.

denki alias "tapo plug" 192.0.2.50 --tapo
denki login "you@example.com"
denki info "tapo plug"

Use the saved alias or its IP for Tapo commands. Unknown IPs default to Kasa. Scan probes saved Tapo aliases; it does not automatically discover unknown Tapo IPs. See the command guide for finding a moved Tapo device.

3. Read energy

Use an energy-capable model from the support table. HS105 and P125, for example, support power control but do not measure energy.

denki energy "desk plug"
denki energy "desk plug" --json

Watts describe power right now. Watt-hours describe accumulated energy. Missing measurements are unavailable, not zero. Read the energy guide before comparing readings or collecting a history.

4. Collect a short recording

denki energy watch "desk plug" --interval 5 --count 12 --format csv > energy.csv

This takes 12 readings with a five-second delay after each completed sample. Open energy.csv in a spreadsheet. Omit --count to keep recording until Ctrl-C.

5. Control power when you are ready

These commands change the device's power state:

denki on "desk plug"
denki off "desk plug"

For a group, preview the matches first. The first command below does not contact devices; the second switches matching devices off.

denki group off "office" --dry-run
denki group off "office"

If anything fails, start with the troubleshooting guide.

Physical identification and fleet health

denki identify "desk plug" --confirm
denki identify "desk plug" --clear
denki doctor --all
denki doctor --all --concurrency 2 --timeout 20 --json
denki doctor --all --failed-only --json

identify requires the exact saved alias and records your own physical observation; it does not contact or switch the device. A saved alias, authentication, and model hardware verification are separate facts. Existing aliases start unconfirmed. Explicit address or protocol changes clear confirmation; authenticated discovery of the same identity preserves it. aliases shows the saved declaration.

Fleet diagnostics check each saved address once, preserve every alias in JSON, and skip conflicting protocol/identity assignments. Checks are read-only, use at most two concurrent probes by default (maximum eight), and have a 20-second deadline per address. Failed checks are not retried by the fleet runner. The JSON devices list contains aliases and diagnostics; summary counts unique addresses, OK, failed, and warning results. Any failed address produces a nonzero exit status while retaining all results. An empty registry returns an empty successful summary. Confirmation shown by diagnostics is a historical user declaration, not proof that an offline or replaced device still matches its label.