AprilNEA/OpenLogi · error

no wired (direct-USB) Logitech device found — is the…

Error message

no wired (direct-USB) Logitech device found — is the keyboard plugged in?

What it means

The no-query sibling of the wired-device lookup failure in the lighting diagnostic: thrown when no `--device` was supplied and the inventory contains no wired (direct-USB) Logitech device at all. The message hints that the keyboard must be plugged in, since lighting control is direct-USB only.

Solutions

  1. Plug the Logitech keyboard into a USB port directly (not via its receiver).
  2. Wake the keyboard (press a key) so it enumerates, then retry.
  3. Confirm with `openlogi list` that a wired Logitech device is visible before running lighting commands.
  4. Use a USB cable to connect wireless- capable boards (e.g. G915) when doing RGB work.

Example fix

// before
$ openlogi diag lighting --color ff0000
// error: no wired (direct-USB) Logitech device found...
// after: connect via USB
$ openlogi list   # verify wired device appears
$ openlogi diag lighting --color ff0000
Defensive patterns

Strategy: fallback

Validate before calling

// bail out early when no wired Logitech device exists
let inv = enumerate_inventory().await?;
if !inv.iter().any(|i| i.is_direct_usb() && i.is_logitech()) {
    eprintln!("no wired Logitech device; connect one via USB before lighting commands");
    std::process::exit(1);
}

Try / catch

// degrade gracefully in scripts: skip lighting when no wired device
if let Err(e) = run_lighting(args).await {
    if msg_contains(&e, "no wired (direct-USB) Logitech device") {
        eprintln!("skipping lighting step (no wired device)");
        return Ok(()); // optional step
    }
    return Err(e);
}

Prevention

When it happens

Trigger: Running the lighting command without `--device` while every enumerated Logitech device is receiver- or Bluetooth-routed, or while no Logitech device is connected at all.

Common situations: Trying to set keyboard RGB on a wireless keyboard connected only via receiver; keyboard unplugged or asleep; running on a machine where the keyboard is an internal laptop keyboard (not a Logitech USB device).

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors


AI-assisted analysis of AprilNEA/OpenLogi@e846e6f4b4 (2026-09-13). Data as JSON: /api/errors/52094191895393f5. Report an issue: GitHub.

Appendix: source

Thrown at crates/openlogi-cli/src/cmd/diag/lighting.rs:88

                    "{:04x}:{:04x}",
                    inv.receiver.vendor_id, inv.receiver.product_id
                )
            });
            if let Some(ref n) = needle
                && !name.to_lowercase().contains(n.as_str())
            {
                return None;
            }
            let route = DeviceRoute::Direct {
                vendor_id: inv.receiver.vendor_id,
                product_id: inv.receiver.product_id,
            };
            Some((route, name))
        })
        .ok_or_else(|| match &device_query {
            Some(q) => anyhow!("no wired device matches `--device {q}`"),
            None => {
                anyhow!("no wired (direct-USB) Logitech device found — is the keyboard plugged in?")
            }
        })?;

    let method: LightingMethod = args.method.into();
    println!("setting {name} ({route}) to #{r:02x}{g:02x}{b:02x} via {method:?}");
    openlogi_hid::set_keyboard_color_with(&route, method, r, g, b).await?;
    println!("done — {name} should now be solid #{r:02x}{g:02x}{b:02x}");
    Ok(())
}

#[cfg(test)]
mod color_validation_tests {
    use openlogi_core::color::RgbParseError;

    use super::{LightingArgs, Method, run};

    fn args(color: &str) -> LightingArgs {
        LightingArgs {

View on GitHub (pinned to e846e6f4b4)