@mega-yfue/eufy-sdk / ActionSpec
Interface: ActionSpec
What one action on dev.<cap>() accepts and what it changes — the write-side counterpart to a member's read getter.
Carries no name: it is attached to the method itself (describedAction in ./access.ts), so the action's own key is its name and a rename cannot leave a description behind pointing at nothing.
A spec never gates anything. CapabilityModule.actions alone decides which methods exist; an undescribed action stays fully callable, it just cannot be offered automatically.
Describe the method that TAKES the value, not its aliases. on()/off() drive the same wire as set(v), and describing all three would render three controls for one state.
A stateful action's reflects read is its evidence gate. Each described write works exactly on the devices whose reflected read is installed — the read's backing param and the write's own precondition are the same evidence (motion.setDetection needs the PIR switch a standalone sensor never reports; setHumanOnlyAtNight and setLoiteringDetection each need the id their read gates on). So a description is a promise the method works wherever its read answers, and an action whose read is absent on a device is not offerable there.
Describe only a wire confirmed on real hardware, for the same reason an unverified write rejects rather than guesses: a described control that always fails turns "a present method means a verified wire" into "a present description means nothing".
Extended by
Properties
args?
optional args?: readonly ActionArgSpec[];description?
optional description?: string;form
form: "momentary" | "stateful";reflects?
optional reflects?: string;For a stateful action, the read accessor on the same capability whose value it changes.