Hi python-miio maintainers,
URML (urml.dev) is a small, Apache-2.0 language for robot intent: an instruction becomes a typed primitive, validated against the device's declared capabilities and a safety envelope, then dispatched. python-miio is the canonical library for the Xiaomi miIO/MIoT protocol, and for the robot-vacuum subset it is a concrete substrate a validated cleaning intent could dispatch to. This is a request for comment (cross-citation only, since python-miio is GPL-3.0).
Nothing here asks the project to adopt, host, or maintain anything.
The mapping, scoped to vacuums: URML validates a cleaning intent (clean these zones, fan speed, go to dock) against the robot's declared features and a safety envelope, then dispatches; python-miio is one path that turns the validated intent into device commands. A miIO/MIoT vacuum advertises the features it supports, and that advertisement maps toward a URML capability manifest, so an unsupported intent is caught before it reaches the device. URML adds the typed pre-dispatch check and an optional natural-language front door; python-miio stays the protocol library, and given the GPL-3.0 license this proposes no shared code, only a dispatch relationship.
Two real questions: (1) for the robot-vacuum subset, is a typed validated intent layer above python-miio useful? (2) Do miIO/MIoT vacuum feature flags map cleanly toward a capability manifest?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0601-python-miio-outreach.md
Thanks for python-miio; a well-maintained protocol library is exactly the kind of substrate a validated intent layer wants to dispatch through rather than reimplement.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see https://github.com/URML-MARS/URML/blob/main/VIBE.md). Human-only correspondence available on request.
Hi python-miio maintainers,
URML (urml.dev) is a small, Apache-2.0 language for robot intent: an instruction becomes a typed primitive, validated against the device's declared capabilities and a safety envelope, then dispatched. python-miio is the canonical library for the Xiaomi miIO/MIoT protocol, and for the robot-vacuum subset it is a concrete substrate a validated cleaning intent could dispatch to. This is a request for comment (cross-citation only, since python-miio is GPL-3.0).
Nothing here asks the project to adopt, host, or maintain anything.
The mapping, scoped to vacuums: URML validates a cleaning intent (clean these zones, fan speed, go to dock) against the robot's declared features and a safety envelope, then dispatches; python-miio is one path that turns the validated intent into device commands. A miIO/MIoT vacuum advertises the features it supports, and that advertisement maps toward a URML capability manifest, so an unsupported intent is caught before it reaches the device. URML adds the typed pre-dispatch check and an optional natural-language front door; python-miio stays the protocol library, and given the GPL-3.0 license this proposes no shared code, only a dispatch relationship.
Two real questions: (1) for the robot-vacuum subset, is a typed validated intent layer above python-miio useful? (2) Do miIO/MIoT vacuum feature flags map cleanly toward a capability manifest?
Full write-up: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0601-python-miio-outreach.md
Thanks for python-miio; a well-maintained protocol library is exactly the kind of substrate a validated intent layer wants to dispatch through rather than reimplement.
Ido Yahalomi (URML, greenvh@gmail.com)
AI-assisted prose, maintainer-reviewed before posting (see https://github.com/URML-MARS/URML/blob/main/VIBE.md). Human-only correspondence available on request.