Controls connect to devices
A function for you. A connection to the equipment.
You want to set a target temperature or invoke an approved action. Turning that intention into a device request requires a suitable control, mapping and provider connection.
A control describes the task
A control gives a usable device capability a meaningful place on your unit. A target temperature, for example, describes what you want to set.
The device or technical control point belongs to the provider connection. Its location in a technical device inventory is not automatically your spatial structure.
A mapping connects the two
A correctly configured mapping identifies the supported technical target for an action. A working provider connection is also needed to send the request.
Device model, reported capabilities and permissions determine what is available. A listed device or product does not guarantee that every manufacturer function can be used.
Distinguish requests from outcomes
A scheduled time describes when an action should run. Depending on the provider, acceptance may initially confirm only that the request was received.
An open door or a room reaching a temperature is a physical result. Review execution history and available states without treating request acceptance as automatic proof of that result.
An everyday example
Sending a target temperature
octopancy schedules a target temperature and sends the request to the mapped heating control. Even after acceptance, the room needs time to warm up. A target value and measured room temperature describe different things.
Good to know
Your questions, answered.
Do all devices in a category support the same controls?
No. What matters is the capability of the particular device and the permissions available.
Does an accepted door command guarantee an open door?
Acceptance is not evidence of physical effect. Device readiness, provider processing and on-site configuration still matter.
Explore what connects