openclaw - 💡(How to fix) Fix [Feature]: Android Health Connect read-only node commands [1 comments, 2 participants]

Summary

Add optional, read-only Android Health Connect node commands so an OpenClaw operator can request selected local health metrics from their own paired Android device with explicit on-device Health Connect permission grants.

Problem to solve

OpenClaw Android nodes already expose useful device-local capabilities through explicit node commands, but there is no first-class way to query Health Connect data from a paired Android device.

For personal automation, local health dashboards, and assistant-driven wellness summaries, the useful data is already available on-device through Android Health Connect. Without a supported OpenClaw command family, users have to rely on separate exports, screenshots, manual app checks, or custom local patches.

This should remain privacy-preserving: the Android app should only read data types the user explicitly grants through Health Connect, and the gateway should only allow known read-only commands.

Proposed solution

Add a new Android health capability and a small set of read-only health.* node commands:

• health.sleep — returns sleep sessions and stage segments when Health Connect provides them.
• health.heartRate — returns heart-rate samples.
• health.steps — returns step records and a total for the returned records.
• health.weight — returns weight records.
• health.oxygenSaturation — returns oxygen saturation records.

Suggested command params:

{
  "startISO": "optional ISO-8601 instant",
  "endISO": "optional ISO-8601 instant",
  "limit": 20
}

Behavior/UX:

• Commands are read-only.
• Android app requests Health Connect read permissions via the standard Health Connect permission flow.
• The node advertises the health capability and specific commands only when Health Connect is available.
• If permissions are missing, commands return a clear HEALTH_PERMISSION_REQUIRED error.
• Gateway default Android command allowlist includes only the supported read-only health.* commands.
• Documentation should call out privacy boundaries and the exact data types requested.

Alternatives considered

• Manual Health Connect exports: works, but is not interactive or assistant-friendly.
• Screenshots from Samsung Health / Health Connect: brittle and not machine-readable.
• A third-party plugin only: useful eventually, but Android runtime permission handling and node command advertisement are already in the Android app/gateway surface, so a small core command family seems cleaner if maintainers are comfortable with the privacy surface.
• One generic health.read command: less safe, harder to allowlist, and makes permission/data-type boundaries murkier. Separate commands make privacy and gateway policy clearer.

Impact

Affected users/systems:

• Android users who want personal, local, permissioned health summaries through OpenClaw.
• Android node bridge and gateway node command policy.

Severity:

• Enhancement / workflow unlock, not a bug.

Frequency:

• Useful for recurring daily summaries, sleep reports, activity summaries, and ad hoc health questions.

Consequence:

• Avoids manual exports/screenshots and enables local-first assistant analysis while preserving Android Health Connect consent boundaries.

Evidence/examples

I have a local prototype working against a personal Android device using sanitized/local validation only. The prototype successfully demonstrates:

• Android Health Connect permission request flow.
• Read-only command handling for sleep, heart rate, steps, weight, and oxygen saturation.
• Node capability/command advertisement.
• Gateway allowlist enforcement.
• Basic docs and unit coverage for command constants/registry/dispatcher behavior.

No real health values, screenshots, or personal datasets are included in this issue.

Additional information

Privacy/safety constraints that seem important:

• Keep the initial feature read-only.
• Do not request broad Health Connect permissions beyond the specific supported commands.
• Do not include real user health data in tests, docs, logs, or examples.
• Prefer synthetic fixtures for tests.
• Keep commands individually allowlisted rather than allowing arbitrary Health Connect record access.

If maintainers agree this belongs in core Android/gateway rather than as a plugin-only experiment, I can prepare a focused PR with Android implementation, gateway allowlist update, docs, and tests.