SAIWENNA / CONTROL ENGINEERING
RS485 Shade-Motor Protocol Checklist for Integrators
“RS485 motor” identifies an interface family, not a complete integration contract. Before selecting a controller or writing a driver, obtain the exact motor protocol and the documents that define the supported commands, responses and installation path.
One label, three different documents
Texas Instruments explains that RS485 specifies electrical characteristics of drivers and receivers, rather than an application protocol. A protocol may use that physical layer, but its addresses, commands and data meanings must be defined elsewhere.
| Document | Question it answers | What it does not replace |
|---|---|---|
| Motor/product data and installation instructions | Which exact device, supply and intended application are being reviewed? | The complete protocol or project wiring design |
| Bus/wiring guide for the selected system | What topology, connections and electrical conditions does this system require? | Message definitions and command semantics |
| Protocol/integration guide | How do devices identify themselves, receive commands and report information? | Model-specific capacity, installation approval or guaranteed gateway compatibility |
These documents may be combined by a manufacturer or supplied separately. What matters is that the required information is available and applies to the chosen device and revision.
Read a real integration guide as a document map
Somfy’s SDN Integration Guide, DOC155888/003 (July 2023), separately organizes device identification, addressing, acknowledgements, serial configuration, message structure and device status. It refers wiring and topology questions to a separate SDN Bus Wiring Guide. This is a useful example of the document layers an integrator should look for.
Those SDN details belong to Somfy’s specified products. They are not a universal RS485 format, a Modbus register map or proof that a proposed Saiwenna motor accepts the same messages. This page does not supply transferable terminal assignments, byte sequences or bus limits.
Build the protocol request matrix
| Field to request | Record with it | Acceptance question |
|---|---|---|
| Device and firmware | Motor/controller model, hardware and protocol revision | Does the guide cover this exact device? |
| Physical interface | Selected wiring-guide reference and responsible designer | Are power, bus and connectors clearly distinguished? |
| Serial configuration | Documented communication settings and permitted variations | Do both endpoints use the required settings? |
| Addressing and discovery | Individual/group identity rules and commissioning record | Can the intended opening be identified unambiguously? |
| Commands | Required functions and supported messages | Are open/close/stop/position requests actually supported? |
| Responses and errors | Acknowledgement meaning, error cases and allowed retry behavior | What does success mean, and how is failure reported? |
| Feedback | Position/status meaning, update trigger and timestamp basis | Is a value reported, estimated or merely the last target? |
| Controller/gateway | Exact hardware, driver version and supply/programming owner | Has the complete path been demonstrated? |
| Change control | Baseline versions and affected opening list | What must be retested after a component or firmware change? |
Turn a vague RFQ into a testable request
Instead of “Please confirm RS485 compatibility,” send a bounded request: “For motor model ___ and revision ___, provide the applicable protocol and wiring documents. Identify support for our required commands and feedback fields, the proposed controller/driver, and who will verify the complete path. Mark unsupported or undocumented items.”
Keep any representative bench-test result tied to the tested hardware, firmware and configuration. A working demonstration with another motor or software version is useful context, but it does not close every item in the current matrix. The selected system’s qualified integrator should define and execute the test; the procurement record preserves what was established.
Use the result in the wider controls brief
The existing control-method comparison helps select a control approach. This matrix becomes useful after RS485 is a candidate and the team needs an exact protocol document set. Use the BMS guide to allocate gateway and commissioning responsibilities.
No stock availability, driver certification or complete-system compatibility is implied. The selected motor and equipment path remain subject to technical confirmation.
Send the protocol evidence request Include the intended openings, exact equipment, required commands, feedback and missing documents. Do not send network passwords or unrelated credentials.
Sources and scope
- Texas Instruments, The RS-485 Design Guide, SLLA272B, revised May 2008, p.1
- Somfy SDN Integration Guide, DOC155888/003, July 2023, pp.3–13 and 26–27
- Protocol request matrix: original integration-procurement method
Reviewed 20 October 2026. Named manufacturer examples retain their own applicability. Supply scope and project acceptance require the selected equipment and responsible review.