AprilNEA/OpenLogi · error
no supported standalone light found
Error message
no supported standalone light found
What it means
The CLI's light `select` helper enumerates standalone (non-receiver) lights and picks one automatically only when exactly one is connected. When the enumeration result is empty and no `--device` query was supplied, there is nothing to auto-select, so it throws "no supported standalone light found". It is an upfront precondition failure, not an I/O failure: the command never reached a device.
Solutions
- Plug in the Logitech light and confirm the OS sees it (check System Information / lsusb).
- Run `openlogi list` to verify the light is enumerated as a standalone device.
- On macOS, grant Input Monitoring to the OpenLogi agent process, then restart it.
- If the light is a non-Litra product, confirm it is in the supported-model table; unsupported products are not enumerated as supported standalone lights.
Example fix
// before (CLI invocation relying on auto-select with no device attached) $ openlogi light set-power on error: no supported standalone light found // after $ openlogi light set-power on --device "Litra Glow" # or plug the light in first
Defensive patterns
Strategy: validation
Validate before calling
let devices = openlogi_cli::cmd::light::standalone_devices()?; // or your enumeration source
if devices.is_empty() {
eprintln!("no supported standalone light attached; connect a Litra and retry");
return Ok(());
} Prevention
- Always enumerate and check the standalone-light list before invoking a light command.
- On macOS verify Input Monitoring is granted before first use.
- Distinguish receiver-connected devices from standalone ones when scripting.
When it happens
Trigger: Calling any of the light commands (`set_power`, `set_brightness`, `set_temperature`, or `selection_requires_disambiguation_and_supports_name_queries`) without `--device` while the enumerated `StandaloneDevice` list is empty (a `[]` slice passed to `select`).
Common situations: No Logitech Litra (Glow/Litra Beam etc.) is plugged in; the light is connected via a receiver and thus not listed as standalone; the HID backend lacks permission to see the device (e.g. macOS Input Monitoring not granted) so enumeration returns nothing; or a typo in an unsupported product means it was filtered out as 'supported'.
Understand the failure class
Background: "Not found" and "does not exist" errors: why "Task not found", "No such folder", and "Can't find" fire when a lookup comes back empty — this error's family across 14 libraries.
Related errors
- unsupported light product
- raw-HID devices support profile-only contributions
- the selected device has no stable synthetic identity for…
- the selected direct-capture target does not match the…
- no addressable physical device candidate was found
AI-assisted analysis of AprilNEA/OpenLogi@e846e6f4b4 (2026-09-13).
Data as JSON: /api/errors/d061a5ca33b873af.
Report an issue: GitHub.
Appendix: source
Thrown at crates/openlogi-cli/src/cmd/light.rs:184
let route = DeviceRoute::RawHid {
vendor_id: device.address.vendor_id,
product_id: device.address.product_id,
usage_page: device.address.usage_page,
usage_id: device.address.usage_id,
identity: device.address.identity.clone(),
};
openlogi_hid::apply_litra(&route, model, command)
.await
.context("failed to write the light command")
}
fn select<'a>(
devices: &'a [StandaloneDevice],
query: Option<&str>,
) -> Result<&'a StandaloneDevice> {
let Some(query) = query else {
return match devices {
[] => Err(anyhow!("no supported standalone light found")),
[device] => Ok(device),
_ => Err(anyhow!(
"multiple standalone lights found; select one with --device"
)),
};
};
let query = query.to_ascii_lowercase();
let mut matches = devices.iter().filter(|device| {
device.display_name.to_ascii_lowercase().contains(&query)
|| device
.address
.identity
.to_ascii_lowercase()
.contains(&query)
});
let Some(device) = matches.next() else {
return Err(anyhow!("no standalone light matches --device {query}"));
};View on GitHub (pinned to e846e6f4b4)