Integrator project coordination
Motorized Shading Control Coordination for Integrators
A protocol or platform name is not a compatibility result. Share the product and opening schedule, power, requested control path, commands, feedback and responsibility split so the exact motor-side evidence and interface path can be reviewed before quotation.
- Motor-side path review
- Commands and feedback mapping
- Responsibility and commissioning handoff
Control-layer separation
Separate Product, Motor, Interface and Project Platform
Record the physical shading system, selected motor/controller, motor-side interface, gateway or actuator, project platform and responsible integrator as separate layers. A brand or protocol label does not replace that architecture.
- Product side
- Shade or track system, opening IDs, motor/controller and power direction.
- Interface
- RF, app/gateway, dry contact, RS485 or another documented path.
- Project platform
- Named system, actuator/gateway, panel, network/account and region where applicable.
- Responsibility
- Wiring, programming, testing, installation, commissioning and support owners.
Native path versus interface path
Map How the Requested Command Reaches the Motor
A native path exists only when the exact selected device documents it. An interface path uses a relay, controller, actuator, gateway or bridge and must define electrical or protocol behavior, supported commands, feedback, ownership and commissioning.
Native motor/controller path
Require the exact model, manual, supported functions and configuration boundary.
Relay or dry-contact path
Define electrical behavior, supported inputs and whether any feedback exists.
RS485 path
Define protocol, addressing, topology, command list, feedback and controller ownership.
Gateway or actuator path
Define supported equipment, account/region or panel requirements and commissioning owner.
Interface boundaries
Treat Dry Contact and RS485 as Defined Technical Paths
Dry contact can provide simple command inputs but does not inherently provide position. RS485 requires an exact protocol, addressing, topology, command list and feedback definition. Neither term proves BMS compatibility on its own.
Building-automation requests
Keep KNX, BMS and Lutron Project-Specific
KNX and BMS require a documented actuator, gateway or controller path. Lutron requests require the exact project system, authorized design/supply party, bill of materials, motor-side interface and responsibility map.
No Saiwenna partnership, certification or universal compatibility is implied. Do not publish or reuse private project topology or customer hardware sequences.
Commands, feedback and infrastructure
Define the Required Behavior Before Freezing Equipment
Use one row per system type or repeated opening group. Unresolved model, protocol, firmware, region, account or responsibility fields remain open questions.
| Input group | Information to provide | Review purpose |
|---|---|---|
| Product side | System type, opening/window IDs, selected motor/controller if known | Ties the interface request to real equipment and openings. |
| Power | Voltage, frequency, power point, motor position and cable route | Connects motor selection to the electrical plan. |
| Interface | RF, app, dry contact, RS485 or project-specific actuator/gateway | Defines the technical path instead of relying on a platform label. |
| Functions | Open/close/stop, grouping, scene, limits and required feedback | States what the project expects the path to do. |
| Infrastructure | Cable, panel, network/IP, addressing, gateway/account/region where applicable | Identifies project-side dependencies and ownership. |
| Responsibility | Programming, site test, installation, commissioning, training and support owners | Prevents scope assumptions between supplier and integrator. |
Bench test and representative hardware
Validate the Intended Path Before Bulk Release
Where practical, freeze representative motor/controller hardware, firmware, wiring, commands, feedback and acceptance criteria. Record the result and unresolved points without turning one project test into a universal compatibility claim.
- Freeze hardwareName the representative motor, controller, gateway or actuator and versions.
- Build the pathUse the intended power, wiring, interface and project-side controller.
- Exercise functionsTest required commands, grouping, limits and feedback expectations.
- Record gapsKeep unsupported or unresolved behavior visible for project decision.
- Approve responsibilityName supply, programming, site-test and commissioning owners.
Control Bench-Test Acceptance Checklist / Record
Test the exact proposed motor, controller/interface and firmware/version with representative hardware. Agree expected behavior before testing. Mark a function Not applicable with a reason if the selected interface does not support it; an untested item is not a pass.
| Group | Record |
|---|---|
| Setup | System/model/version, controller/interface, documented power state, wiring/document revision |
| Commands | Open, close, stop, preset, scene and group command only where applicable |
| Response | Observed movement, feedback, local fallback and network-loss behavior where applicable |
| Acceptance | Expected versus observed result, pass/fail/not tested/not applicable, issue owner and retest reference |
| Sign-off | Responsible parties, date/revision and agreed release scope |
Download Control Bench-Test Acceptance Record (XLSX)
This is a blank test record, not a completed test or proof of compatibility. The selected motor/PSU instructions govern electrical work; record unresolved behavior before approving a repeated configuration.
Responsibility and commissioning
Name Every Handoff in the Control Scope
- 01Product and motorConfirm the quoted shading system, selected motor/controller and supplied scope.
- 02Power and cablingName electrical design, installation, cable and panel responsibilities.
- 03ProgrammingName platform, gateway/actuator, scenes, commands, feedback and software owner.
- 04TestingDefine bench test, site test, acceptance criteria and issue ownership.
- 05CommissioningDefine final setup, handover, training and support responsibilities.
A quotation is incomplete when these roles are assumed rather than named.
FAQ
Questions That Close a Control-Coordination Brief
Is KNX the same as RS485?
No. KNX is an automation ecosystem; RS485 is a physical communications layer used by defined protocols.
Does dry contact provide position feedback?
Not by itself. Feedback requires supported equipment or a separate documented sensing path.
Can Saiwenna promise Lutron compatibility?
Only a project-specific, documented and approved system, motor/interface and bill-of-materials path can be reviewed. No general compatibility or partnership claim is made.
What is required for a representative bench test?
The selected motor, controller/gateway, power, wiring, commands, feedback, versions and acceptance criteria.
Buyer decision guides
New Planning and Acceptance Resources
Use the guide that matches the decision your project must make next.
Some configurations may retain a documented local path, but there is no universal answer without the selected equipment and test.Motorized Shade App and Gateway Requirements: Pre-Order IT Readiness
An app label does not define gateway, cloud, region, onsite/remote access or commissioning requirements.Motorized Shade Site Commissioning Acceptance Checklist
A bench baseline does not prove field installation; site results must be tied to opening, version and field conditions.Motorized Shading Handover Documentation Checklist
PC09 asks whether the installed system met criteria; PC10 asks whether the owner can operate and support it afterward.
Ready to Map a Motorized Shading Control Scope?
Send the product/opening schedule, power, requested interface, commands, feedback, project platform and responsibility split. Final equipment and compatibility decisions follow the documented selected path.