Blind Motorisation & IBMS Integration for Specifiers

From Manual to Motorised: Framing the Integration Problem

Motorising a blind is trivial; integrating shading into a building's intelligence is an engineering discipline, and this opening lecture establishes the distinction that the whole course depends on. A specifier who writes 'supply motorised blinds' onto a drawing has deferred every decision that actually determines whether the system works: motor torque adequacy, control protocol, power and cabling topology, the interface to the building management system, and the sensor and commissioning logic that makes the shading behave intelligently rather than merely move. We frame the four layers the course unpacks in turn — the motor (the actuator), the control bus (RTS, io-homecontrol, Zigbee, wired), the integration interface (dry contacts, KNX, BACnet, Modbus), and the intelligence (sun, wind and BMS logic) — and show how a failure at any layer collapses the value of the others. Using a Sandton commercial tower whose 600 motorised blinds were specified without an IBMS interface and therefore never tracked the sun, we trace the cost of treating motorisation as a product rather than a system.

In depth

Motorisation and integration are two different engineering problems that specifiers routinely conflate, and the conflation is the root cause of most disappointing 'smart blind' installations on South African commercial projects. Motorisation is the local problem: replacing a hand chain or crank with an electric actuator — almost always a tubular motor inserted into the roller tube, headrail or pelmet — sized to lift the fabric or slat package reliably for tens of thousands of cycles. Integration is the system problem: making that actuator one controllable, addressable, monitorable node in a larger control architecture so that the shading responds to the sun, the wind, the time of day, the HVAC state and the occupant, in concert with lighting and climate. The course treats these as four stacked layers, and the central thesis is that the system is only as strong as its weakest layer.

Layer one is the actuator: a Somfy-class tubular motor (the market reference, with families such as Sonesse, Altus, Glydea track motors and the LV/DC ranges) rated in newton-metres of torque, selected against the calculated load of the specific blind. An undersized motor stalls, overheats and trips its thermal cut-out; an oversized one wastes capital and can over-stress fabric and brackets. Layer two is the control bus — how the motor receives commands. The choice is between radio-frequency control (Somfy RTS one-way, io-homecontrol two-way, or Zigbee in third-party ecosystems) and wired control (dry-contact, digital bus, or DC motors on a low-voltage data line).

RF is fast to install and ideal for retrofit; wired is robust, deterministic and preferred for large new-build integration. Layer three is the integration interface: how the shading control layer talks to the building management system. On commercial work this is rarely a consumer hub — it is a gateway translating between the shading manufacturer's protocol and a building automation protocol: KNX for European-style integrated building control, BACnet for HVAC-centric building automation, or Modbus for industrial and simpler device-level links. Layer four is the intelligence: the sun-tracking, wind-retraction, scene, scheduling and feedback logic that turns a set of movable blinds into a daylight- and energy-management system, fed by rooftop and facade sensors and by the BMS itself.

The Sandton anchor case makes the failure concrete: a tower fitted with 600 quality motorised roller blinds, each individually controllable from a wall switch, but with no gateway to the BMS and no sun or wind logic. The blinds moved, so the contract was signed off, yet they never tracked the sun, never retracted in high wind, and were left in whatever position the last occupant chose — delivering none of the daylight-harvesting or peak-load benefit that justified the motorisation premium, and exposing the facade to wind damage. The lesson framing the course: specify the system, not the product. Name the torque basis, the control protocol, the integration interface and the control logic explicitly, because each is a decision a 'motorised blinds' line item silently leaves to chance.

The compliance and safety envelope — IEC 60335-2-97 for the motor's electrical safety and SANS wiring rules for the installation — sits underneath all four layers and is introduced here as a constraint every later decision must respect.

Tubular Motors: Anatomy, Families and the Somfy Reference

The tubular motor is the workhorse of shading motorisation, and a specifier must understand its anatomy before sizing or integrating one. This lecture dissects the tubular motor — the motor head, the gearbox reduction, the integral limit system, the thermal cut-out and the crown-and-drive adaptor set that couples it to a specific tube diameter — and maps the Somfy product families that have become the de facto reference across the industry. We distinguish AC mains motors from low-voltage DC and battery (RTS Li-ion) motors, mechanical-limit from electronic-limit types, and the heavier track and projection-screen motors from standard roller-blind units. We also introduce the duty cycle concept — these are intermittent-rated, not continuous-rated, machines — and the consequence for sizing and for any integration that might issue rapid repeated commands. A Cape Town hotel retrofit that mixed three incompatible motor families on one control system illustrates why family selection is an integration decision, not just a hardware one.

In depth

A tubular motor is a self-contained electromechanical assembly designed to slide inside the roller tube of a blind, and understanding its parts is the precondition for both sizing (Lecture 3) and integration (Lectures 5-9). Working from the motor head outward: the head houses an AC induction or DC brushless motor coupled to a multi-stage planetary or epicyclic gearbox that trades the motor's high speed for the high torque and low output speed a blind needs — typical output speeds are 12-34 rpm and the gearbox reduction is what delivers the rated newton-metres. An integral limit system stops the motor at the top and bottom of travel: older and cheaper motors use a mechanical cam-and-gear limit set with adjustment buttons or a setting tool, while electronic-limit motors (and all the higher Somfy ranges) store limits digitally, allow point-precise setting, support intermediate 'my' favourite positions, and are what make accurate scene control and sun-tracking possible. A thermal cut-out protects the windings: because these are intermittent-duty machines the cut-out trips after a defined run time (commonly around 4 minutes continuous) and the motor will not respond again until it cools — a fact with direct integration consequences, because control logic that commands long or rapidly repeated moves can trip motors out of service.

The crown (fixed end) and drive adaptor (rotating end) are tube-specific plastic or alloy parts that couple the motor to a given tube diameter and profile; specifying the wrong adaptor set is a common cause of slip and noise. The Somfy families are the industry reference points a specifier should be able to name and place. g. Sonesse 30, 40, 50 in RTS, io and the wired/DC RS485 variants) is the interior roller-blind benchmark, prized for quiet running essential in hotels, boardrooms and residential.

The Altus and Orea ranges cover heavier interior and light exterior duties. The Glydea range is a track motor for curtains rather than rollers. Dedicated heavier motors exist for projection screens, large external screens and folding-arm awnings. Across these, three orthogonal choices matter.

First, power type: AC mains motors (230 V) are the default for permanently wired commercial blinds; low-voltage DC motors (often 24 V) run quieter, allow data-over-cable control and are favoured in integrated wired systems; battery/Li-ion RTS motors enable cable-free retrofit at the cost of recharge logistics. Second, limit type: insist on electronic limits for any integrated or sun-tracking system. Third, control variant: the same mechanical motor is sold in RTS, io-homecontrol and wired/RS485 versions, and this variant choice is an integration decision (Lecture 4) that must be made up front because it is not field-changeable. Duty cycle deserves emphasis: continuous-duty assumptions imported from industrial actuators are wrong here, and any integration designer must respect the rated run-time and a cool-down between cycles, or motors will drop offline mid-day exactly when sun-tracking is most active.

The Cape Town hotel retrofit illustrates the family-selection trap: a refurbishment specified 'Somfy motors' generically, and three trades fitted RTS battery motors in guest rooms, io motors in the conference centre and wired motors in the atrium — three protocols that a single head-end could not address uniformly, forcing three parallel control systems and gateways where one coordinated specification would have used a single wired or io backbone. The deliverable of this lecture is a motor-family selection note per zone: power type, limit type, control variant and the duty-cycle constraint, recorded before any control architecture is drawn.

Motor Sizing: Torque, Loads and the Newton-Metre Calculation

Motor sizing is where specification becomes engineering, and getting the torque calculation right is the single most important technical decision in motorisation. This lecture builds the torque calculation from first principles: the load the motor must overcome is the weight of the fabric or slat package plus the bottom bar acting at the radius of the loaded tube, and the required torque is that force multiplied by the effective radius, divided by mechanical efficiency, with a safety margin applied. We work the full calculation for a real roller blind — fabric mass per square metre, drop, width, tube diameter and the build-up of fabric on the tube that changes the effective radius — and select a Somfy motor from its Nm rating with the correct margin. We extend the method to the heavier cases that catch specifiers out: large external screens with windload, blackout fabrics, and curtain-track motors rated in pull-force rather than torque. A Johannesburg atrium where under-sized motors stalled on 4-metre drops anchors the consequences of skipping the calculation.

In depth

Torque sizing is the calculation that separates a specifier who engineers motorisation from one who guesses, and stalled, overheating or prematurely-failed motors are almost always traceable to a skipped or sloppy torque calculation. The physics is straightforward but must be applied with care. The motor on a roller blind must generate enough torque to rotate the tube and lift the suspended load. 81 m/s2.

That force acts at the radius at which the fabric leaves the tube, so the static torque demand is T = F x r, where r is the effective radius — and here is the subtlety that catches specifiers: r is not the bare tube radius but the radius to the outer wrap of fabric, which grows as fabric rolls onto the tube. The worst case for starting torque is usually the fully-rolled-up condition (largest r) for lifting, so size against the loaded radius, not the bare tube. 5x, more for exterior and high-cycle duty) before choosing the next standard motor up the Somfy Nm ladder (common interior ratings: 6, 10, 15, 20, 30, 40, 50 Nm and beyond for exterior). 32 kg total.

4 N. 4 Nm — comfortably inside a 6 Nm Sonesse 50, which would be the conservative, quiet selection. The number looks small because interior roller blinds are light; the calculation matters far more for the heavy cases. Large external zip/screen blinds add windload acting on the fabric area, which can dwarf the gravity term and is the dominant design force on exterior shading — the motor (and the brackets and fixings) must hold the blind against the design wind pressure, computed from the SANS 10160-3 regional wind speed and the exposed area, not merely lift its weight.

8 kg/m2, multiplying the load. Wide blinds increase tube deflection, which raises friction and effective torque demand and may force a larger tube diameter (which in turn raises r and torque) or a split into two narrower blinds — a layout decision driven by the torque calc. Curtain-track motors (Glydea class) are rated not in tube torque but in pull-force (newtons) and maximum carried mass, so the calculation shifts to total curtain mass plus track friction against the motor's rated pull. Two integration-relevant cautions complete the picture.

First, the duty cycle from Lecture 2 interacts with sizing: a motor run near its torque limit heats faster and trips its thermal cut-out sooner, so on high-cycle sun-tracking duty a generous margin is not waste but reliability. Second, document the calculation, because it is the evidence that survives value engineering and the basis a contractor must match when substituting an 'equivalent' motor. The Johannesburg atrium case is the cautionary tale: 4 m-drop blackout blinds were fitted with motors sized on a supplier's quick-pick chart that ignored the heavy fabric and the build-up radius; the motors stalled on the lift, repeatedly tripped their thermal cut-outs in the afternoon sun, and the entire atrium had to be re-motorised one size up — a calculation that would have taken ten minutes at design stage. The deliverable is a torque-sizing worksheet per blind type: suspended mass, effective radius, efficiency, margin, required Nm and the selected motor, with windload added explicitly for every exterior unit.

Control Buses: RTS, io-homecontrol, Zigbee and the RF vs Wired Decision

Once the motor is sized, the next decision is how it receives commands — and the choice of control bus governs reliability, feedback, integration capability and retrofit feasibility for the life of the building. This lecture compares the dominant control technologies: Somfy RTS (one-way 433 MHz radio, simple and ubiquitous but no feedback), io-homecontrol (two-way encrypted radio with position feedback and interoperability across io-partner brands), Zigbee (mesh radio used in third-party and IoT ecosystems), and wired control (dry-contact, RS485/digital-bus and DC data-over-cable). We weigh range, latency, feedback, security, channel/group addressing and coexistence with WiFi, then address the strategic fork every project faces: radio for speed and retrofit, or wired for determinism and large-scale integration. A Durban office that chose RTS for 300 blinds and then could not report a single blind's position to the BMS illustrates why feedback capability is an architecture decision, not a feature.

In depth

The control bus is the nervous system of a motorised shading installation, and choosing it correctly is a once-only architectural decision because the motor's control variant (RTS vs io vs wired) is fixed at manufacture and not field-convertible. Begin with the radio options. 42 MHz as a one-way protocol: a transmitter (handset, wall point or RTS-output controller) sends a command and the motor obeys, but the motor sends nothing back. RTS is cheap, mature, ubiquitous and excellent for residential and simple retrofit, but its one-way nature is decisive for integration: the control system can command 'down' but can never confirm the blind actually moved or report its position, so true closed-loop sun-tracking and BMS status reporting are impossible.

io-homecontrol is Somfy's two-way, AES-encrypted radio protocol (around 868-870 MHz in most regions) shared across an alliance of partner brands (window, door and shading manufacturers); it provides position feedback, fault reporting, secure pairing and interoperability, which is why it is the radio choice for integrated and feedback-dependent systems. 4 GHz band with WiFi and demands careful channel planning. Against all radio sits wired control, which subdivides into three idioms. Dry-contact (volt-free) control is the simplest: a relay closes a contact for up/down/stop, universally interfaceable to any controller including a BMS output module, but typically open-loop with no feedback.

RS485 / digital-bus control (Somfy's wired DC ranges, the Animeo and similar building controllers, and manufacturer-specific buses) carries addressable commands and feedback over a data pair, allowing individual addressing, position reporting and diagnostics across hundreds of motors on a structured cable network. DC data-over-cable motors combine low-voltage power and control on one cable for quiet, addressable, feedback-capable operation favoured in high-end integrated fit-outs. 4 GHz Zigbee versus the building WiFi, 433/868 MHz versus other site RF). The strategic fork is the heart of the lecture: choose radio (io for integration, RTS for simple/retrofit, Zigbee for IoT ecosystems) when cabling is impractical, the building exists, or speed of install dominates; choose wired (RS485/DC or dry-contact into a controller) when the project is new-build, large-scale, integration-critical, or in an RF-hostile facade, because wired delivers deterministic control, full feedback and the cleanest gateway to KNX/BACnet/Modbus.

Mixing is legitimate but must be deliberate and gatewayed, not accidental as in the Cape Town hotel of Lecture 2. The Durban office case crystallises the feedback issue: 300 blinds were specified in RTS to save cabling cost, the system worked for manual and timed control, but when the client later asked the BMS dashboard to show which blinds were open the answer was that it physically could not — RTS sends nothing back, so retrofitting status meant adding position sensors or replacing motors with io/wired units across the whole building. Feedback is not a bolt-on; it is determined the day the control variant is chosen. The deliverable is a control-architecture decision record: the chosen bus per zone, the justification against the criteria above, an explicit statement of feedback capability, and the RF coexistence or cabling plan.

Power, Cabling and Low-Voltage Topology

Motorised shading is an electrical installation, and the power and cabling topology decided at design stage determines whether the system is safe, serviceable and integration-ready or a maintenance liability. This lecture covers the practical electrical engineering: AC mains versus low-voltage DC distribution, circuit grouping and the number of motors per circuit, cable types and sizing for power and for data buses, the segregation of power from data and from other building services, and the provision of isolation, local switching and accessible junctions. We address the South African wiring context — SANS 10142-1 for the low-voltage installation, the role of the registered electrician and the Certificate of Compliance — and the coordination with the architect and electrical engineer that motorised blinds demand but rarely receive. A Pretoria project where 80 AC motors were daisy-chained onto two circuits with no isolation, making any single-motor fault a whole-facade outage, shows why topology is a specification concern.

In depth

Every motorised blind is a point of electrical load and, increasingly, of data, and the topology that delivers power and control to it is a genuine electrical-engineering task that must be coordinated, specified and certified rather than left to the blind installer. Start with the power architecture. AC mains motors (230 V single phase in South Africa) are wired on conventional final circuits; the practical question is how many motors per circuit, governed by the sum of running and inrush currents against the circuit breaker and the volt-drop over the cable run. Tubular AC motors draw modest running current (often around 1 A) but a higher inrush at start, and because integrated systems can command many blinds to move simultaneously (a sun event, a wind retraction, a morning scene) the design must consider coincident starting, not just running, load — staggering group moves in the controller or splitting circuits prevents nuisance tripping.

Low-voltage DC systems (commonly 24 V) change the topology: a central or zonal power supply feeds DC motors over distribution cabling, with the advantages of SELV safety, quiet operation and the ability to carry data on the same or a parallel pair, but with the constraint that DC volt-drop over distance is significant, so cable cross-section and run length must be calculated and power supplies located close to their zones. ) using the specified twisted-pair, screened cable with correct topology (RS485 and KNX prefer daisy-chained bus or line topologies, not stars, and require correct termination resistors at the bus ends — a frequent commissioning failure). Segregation is a code and reliability requirement: power and data must be separated to avoid induced noise corrupting the bus, and shading cabling must be coordinated with, and segregated from, other services in the ceiling void and facade zone. Provide isolation and local control: each circuit or zone needs an accessible means of isolation for maintenance, and the design should avoid the single-point-of-failure topology where one fault disables a whole facade.

Accessible junctions and a labelling/addressing scheme are essential because a motor buried behind a fixed pelmet with an inaccessible junction is an expensive failure. The South African regulatory frame is specific: the fixed low-voltage installation falls under SANS 10142-1 (the wiring code), the work must be done or certified by a registered person, and a Certificate of Compliance (CoC) is required for the electrical installation — the blind contractor is generally not the certifying electrician, so the interface between trades must be defined in the specification. IEC 60335-2-97 governs the safety of the motor/drive as an appliance (Lecture 12), but the building wiring that feeds it is SANS 10142-1 territory; both must be satisfied. Coordination is the recurring theme: motorised shading needs power positions, containment, data routes and gateway locations that must appear on the electrical and ceiling coordination drawings at design stage, yet blinds are often a late finishes-package decision, so the cabling is improvised on site — the avoidable origin of most topology failures.

The Pretoria case is exactly this failure: 80 AC motors were daisy-chained onto just two circuits by the installer with no per-zone isolation and no coincident-load analysis, so a single motor's wiring fault took down an entire facade's blinds, and servicing any one unit meant isolating forty others. A designed topology — circuits grouped by zone and orientation, coincident-start staggering in the controller, per-zone isolation, accessible junctions and a labelled addressing scheme — would have made the same installation safe and serviceable. The deliverable is a power-and-cabling topology drawing and schedule: power architecture (AC/DC), motors per circuit with coincident-load check, cable types and sizes for power and data, segregation and containment, isolation and junction provisions, gateway/PSU locations, and the SANS 10142-1 / CoC responsibility split between trades.

Integration Interfaces I: Dry Contacts and the Gateway Concept

Integration begins with the simplest interface and the most important concept: the dry contact and the gateway. This lecture explains how a shading system exposes control to the wider building — at the crudest level through volt-free dry contacts that any controller can drive, and at the proper level through a gateway that translates between the shading manufacturer's native protocol and a building automation protocol. We define dry (volt-free) versus wet contacts, the typical up/down/stop and group-trigger contact schemes, their inherent open-loop limitation, and when a dry-contact interface is genuinely adequate versus a false economy. We then introduce the gateway as the keystone of real integration — the device that makes the shading a set of addressable, monitorable objects on the KNX, BACnet or Modbus network — and the architectural decision of where intelligence lives: in the shading controller, in the gateway, or in the BMS. A Stellenbosch winery visitor centre that integrated 40 blinds to the BMS through eight dry contacts, losing all individual control, frames the trade-off.

In depth

Integration is the act of making the shading system controllable and observable by the rest of the building, and it exists on a spectrum from the crude-but-universal dry contact to the rich, addressable gateway — a specifier must know where on that spectrum a project belongs. Start with the dry contact, the lowest common denominator of building integration. A dry contact (also called volt-free) is a relay or switch contact that carries no voltage of its own; the controlling device (a BMS output module, a lighting relay, a time clock) applies its own signal across the contact, and the closing of the contact triggers an action. This is contrasted with a wet contact, which carries its own voltage and so constrains what can be connected.

Shading systems typically expose, or accept, dry-contact interfaces in two directions: as inputs, where an external contact closure commands the shading (a BMS 'fire mode' contact raises all blinds; a wind-alarm contact retracts external screens; a time clock triggers a morning scene), and as outputs, where the shading controller closes a contact to signal a state to another system. Typical schemes use separate contacts for up, down and stop, or a pair for a two-state move, or a set of group-trigger contacts each invoking a pre-set scene. The defining limitation of dry-contact integration is that it is almost always open-loop and coarse-grained: a contact can say 'go down' but cannot say 'go to 60%', and the shading cannot report back over a dry contact which position it reached or whether a motor faulted (any feedback needs separate contacts and rapidly becomes unwieldy). Dry contacts are genuinely adequate when the integration requirement is simple and group-based — fire/life-safety overrides, a global wind retraction, a handful of scheduled scenes for a whole zone — and they have the virtue of being universally and cheaply interfaceable to any controller ever made, which is why they remain valuable for safety-critical overrides even in sophisticated systems.

They become a false economy the moment the project needs individual addressing, position setting, status monitoring or coordination with daylight and HVAC — which is most commercial integration. That is where the gateway enters, and the gateway is the conceptual keystone of this and the next lecture. A gateway is a protocol-translating device that sits between the shading manufacturer's native control bus (io-homecontrol, RS485, Animeo, a proprietary bus) and a standard building-automation protocol (KNX, BACnet or Modbus, covered in Lecture 7). It exposes each blind, or each group, as one or more addressable objects on the building network: a position setpoint object, a status/feedback object, fault and override objects.

Through the gateway the BMS, the lighting system and the facade controller can read and write shading state as naturally as they read a temperature or write a setpoint, enabling true closed-loop sun-tracking, daylight harvesting and load coordination. The architectural decision the gateway forces is where the intelligence lives. g. a Somfy Animeo building controller that runs sun-tracking and wind logic locally and exposes summary objects to the BMS), intelligence in the gateway/integration layer (a building-automation controller that owns the logic and treats blinds as dumb actuators), or intelligence in the BMS itself.

The robust commercial pattern is usually a dedicated shading controller owning fast, safety-critical local logic (especially wind retraction, which must not depend on a BMS round-trip) while exposing higher-level scene, setpoint and status objects to the BMS over the gateway — a hierarchy that keeps life-safety responses local and deterministic while still allowing building-wide coordination. The Stellenbosch case is the instructive trade-off: a visitor centre integrated 40 individually-motorised blinds to its BMS through just eight dry-contact group triggers to save on a gateway, and in doing so collapsed 40 addressable blinds into eight all-or-nothing groups with no feedback — the BMS could fire a scene but could never set or read an individual blind, so the daylight-harvesting feature the client paid for was impossible. A modest gateway exposing each blind as a KNX or BACnet object would have preserved the granularity. The deliverable is an integration-interface decision: dry-contact schedule for safety/global overrides, gateway selection and the object model it must expose (position, status, fault, override per blind or group), and an explicit statement of where each layer of intelligence resides.

Integration Interfaces II: KNX, BACnet and Modbus

This lecture gives the specifier working fluency in the three building-automation protocols that a shading gateway speaks: KNX, BACnet and Modbus. We characterise each — KNX as the decentralised, peer-to-peer European building-control standard with its group-address model; BACnet as the HVAC-centric building-automation protocol with its rich object/property model and BACnet/IP and MS/TP variants; and Modbus as the simple, robust, register-based industrial protocol common on device-level and legacy links. For each we explain how a blind is represented — KNX group addresses and datapoint types for move, position and status; BACnet objects (Analog/Binary Value and Multistate) and BIBBs; Modbus holding and input registers — and the practical commissioning, addressing and interoperability realities. We then give the protocol-selection logic: match the shading integration to whatever the building's BMS already speaks, and specify the gateway accordingly. A Midrand corporate campus that ran KNX for lighting and BACnet for HVAC, and had to gateway shading to both, illustrates multi-protocol reality.

In depth

KNX, BACnet and Modbus are the three protocols a South African commercial shading integration will almost always meet, and a specifier who can characterise each and describe how a blind is represented on it can write an integration specification a controls contractor can actually build to. KNX is the open, internationally-standardised (ISO/IEC 14543-3) building-control protocol with deep penetration in lighting, shading and room control, especially on European-influenced projects. Its defining trait is decentralisation: devices (sensors, actuators, controllers) are peers on a twisted-pair bus (KNX TP, with KNXnet/IP for backbone and IP coupling) and communicate by group addresses rather than a central master, so a wall switch and a blind actuator share a group address and the switch's telegram drives the blind directly. A blind on KNX is represented through standardised datapoint types (DPTs): a 1-bit move-up/down object, a 1-bit step/stop object, a 1-byte (0-100%) position setpoint object, and 1-byte status objects reporting actual position and slat angle — so a KNX shading actuator or gateway exposes 'move', 'stop', 'set position %', 'set slat %', 'status position' and 'status angle' per channel.

Commissioning is done in ETS (Engineering Tool Software), where group addresses are assigned and linked — a skilled-trade task the specifier must allow for. BACnet (ASHRAE 135, also ISO 16484-5) is the building-automation protocol born in the HVAC world and dominant in larger commercial BMS, where it excels at interoperable monitoring and control across multi-vendor plant. It is object-oriented: every controllable or observable thing is an object with properties, and a blind is represented by standard objects — an Analog Value or Analog Output object for position setpoint (0-100%), Binary Value/Output objects for up/down/stop or override flags, Multistate objects for mode (auto/manual/wind), each with a present-value property the BMS reads and writes. BACnet runs over BACnet/IP (Ethernet, dominant in new commercial work) and BACnet MS/TP (an RS485 serial variant for field devices), and interoperability is described by BIBBs (BACnet Interoperability Building Blocks) and device profiles that the gateway's PICS (Protocol Implementation Conformance Statement) declares — a specifier should require the gateway's PICS to confirm it supports the object types and services the BMS needs.

Modbus is the simplest and oldest of the three: a register-based master/slave protocol (Modbus RTU over RS485, Modbus TCP over Ethernet) ubiquitous in industrial and device-level integration and on many legacy systems. g. a register for commanded position 0-100, a register for command up/down/stop) and input registers (read-only status/position), and the integration depends entirely on a register map document that both the gateway and the BMS must agree on. Modbus is robust and cheap but offers no discovery, no standard semantics and no inherent feedback richness beyond what the register map defines, so it suits simple, well-documented links rather than large interoperable estates.

The selection logic is the practical core: you do not choose the protocol in the abstract, you match the shading integration to whatever the building's BMS and adjacent systems already speak, and you specify a gateway that bridges the shading bus to that protocol. If the BMS is BACnet/IP (common in large SA commercial buildings), specify a shading gateway with a BACnet/IP server interface and require its PICS; if room control and lighting are KNX, a KNX gateway lets shading share group addresses with lighting scenes; if the link is to a simple PLC or legacy panel, Modbus may be all that is available. Multi-protocol buildings are normal, and the gateway (or a multi-protocol controller such as Somfy's Animeo with BACnet/KNX options) must be chosen to serve each interface it faces. The Midrand campus case is the multi-protocol reality: lighting and room control ran on KNX while the central plant and BMS ran BACnet/IP, so the shading had to present scene and switch objects to the KNX side (for occupant and lighting-coordinated control) and position/status/override objects to the BACnet side (for sun-tracking and energy coordination by the BMS) — achieved with a controller carrying both interfaces, with the specification explicitly listing the objects required on each.

The deliverable is a protocol integration specification: the building's existing protocol(s), the gateway and its declared interface (with PICS for BACnet or DPT list for KNX or register map for Modbus), and the per-blind/per-group object list the shading must expose on each protocol it faces.

Sensors and Intelligence: Sun, Wind and Daylight Logic

Motors and protocols give a blind the ability to move; sensors and logic give it the intelligence to move correctly, and this lecture builds the sensing and control strategy that turns motorised shading into a daylight- and safety-management system. We cover the sensor suite: rooftop global and facade-specific sun (irradiance/lux) sensors, the wind sensor (anemometer) that drives the non-negotiable high-wind retraction of exterior shading, rain and temperature sensors, and interior glare/lux sensors for closed-loop daylight control. We then assemble the logic: sun-tracking that positions slats or screens by computed solar position and measured irradiance, daylight-harvesting that coordinates with lighting dimming, scheduling and scenes, occupancy and BMS-state inputs, and the priority hierarchy that ensures wind-safety always overrides comfort and energy logic. A George coastal office where exterior screens were destroyed in a winter storm because the wind logic was routed through the BMS rather than held locally illustrates why safety logic must be fast and local.

In depth

Intelligence is the layer that distinguishes managed shading from merely motorised shading, and it is built from a sensor suite feeding a prioritised control logic — a specifier must define both, because the manufacturer will supply hardware but the behaviour is a design decision. Take the sensors first. The primary input for energy and comfort logic is solar: a rooftop sensor measuring global irradiance (W/m2) or illuminance (lux) gives the building-wide sun condition, while facade-mounted sun sensors per orientation capture the actual sun on each face — important because a north facade can be in full sun while the south is overcast. These feed sun-tracking and the decision of when to deploy shading.

The single most important sensor for exterior shading is the wind sensor (anemometer), because external screens, awnings and venetians are vulnerable to wind damage and must retract above a wind-speed setpoint; this is a life-and-property safety function, not a comfort feature, and its placement (exposed, representative of the worst facade), its setpoint (derived from the product's rated wind class and the SANS 10160-3 site wind data) and crucially its control path (Lecture's key point) are design decisions. Rain sensors protect fabrics and trigger retraction of certain awning types; temperature sensors inform combined thermal logic; and for closed-loop daylight control, interior lux/glare sensors measure the actual delivered daylight at the workplane so the system can modulate blind position to a target rather than open-loop guessing. Now the logic, assembled in layers. Sun-tracking computes the solar position (altitude and azimuth) for the site and time — astronomically, the same geometry as facade analysis — and combines it with measured irradiance to position external venetian slats at the cut-off angle that blocks direct beam while admitting diffuse daylight, or to deploy/retract screens by orientation as the sun moves around the building; this is the core energy-and-glare behaviour and it demands feedback-capable motors (Lecture 4) so the controller knows the blind reached the commanded position.

Daylight-harvesting closes the loop with the lighting system: as the shading admits more daylight, lighting dims, and the two must be coordinated (often over the same KNX or BACnet network) so they cooperate rather than fight — the energy case for the whole system depends on this coordination. Scheduling and scenes handle predictable patterns (morning deploy, end-of-day open, presentation 'blackout' scenes in boardrooms), occupancy inputs prevent moving blinds in unoccupied or do-not-disturb spaces, and BMS-state inputs let shading respond to HVAC mode, fire mode and demand-response events. The architectural keystone of this lecture is the priority hierarchy: these logics conflict (comfort wants the blind down for glare; daylight-harvesting wants it up for light; the occupant wants manual override; wind safety wants it retracted now), and a defined priority order must resolve them deterministically. The non-negotiable top priority is safety: high-wind retraction (and fire/life-safety overrides) must pre-empt every other command and, critically, must be executed by fast, local logic in the shading controller — not routed through the BMS — because a BMS round-trip, a network delay or a BMS fault must never be able to leave an exterior blind deployed in a gale.

Below safety sit, typically, manual override (with a timeout returning to auto), then scheduled scenes, then automatic sun/daylight logic. The George coastal case is the textbook violation: a coastal office routed its anemometer signal into the BMS, which was to command the exterior screens to retract on high wind; during a winter storm the BMS was mid-reboot for a software update, the retraction command never issued, and the deployed screens were torn from the facade — a failure that local wind logic in the shading controller, hard-wired to retract on the anemometer threshold independent of the BMS, would have prevented. The professional rule: comfort and energy logic may live in the BMS, but wind and life-safety logic lives locally and overrides everything. The deliverable is a sensor-and-logic specification: the sensor schedule (type, quantity, placement per orientation), the wind setpoint and its derivation, the control-logic description per zone (sun-tracking, daylight-harvesting, scenes, occupancy), and an explicit written priority hierarchy with wind/safety logic mandated as local.

Designing the Integrated System: Architecture and Zoning

With motors, buses, interfaces, power and sensors understood individually, this lecture assembles them into a coherent system architecture — the drawing-and-schedule deliverable that a controls contractor builds from. We work through facade and zone definition (grouping blinds by orientation, room and control intent), the controller hierarchy (local shading controllers, gateways, BMS), the network and addressing plan, and the head-end and user-interface layer (wall keypads, touch panels, BMS graphics, mobile apps). We address how zoning decisions made here propagate back to cabling topology (Lecture 5) and forward to commissioning (Lecture 10), and how to right-size the architecture so a small project is not over-engineered nor a large one under-provisioned. A Rosebank mixed-use development whose 1,200 blinds were architected as a single flat control group — making every sun event move all 1,200 at once — illustrates why zoning is the architecture's foundation.

In depth

System architecture is where the preceding component decisions become a buildable whole, and the quality of the zoning and hierarchy designed here determines whether the installation is intelligent, serviceable and commissionable or an unmanageable monolith. The foundation of the architecture is zoning. Blinds must be grouped into control zones that reflect how they should behave together, and the primary zoning axis is orientation, because all the sun and shadow logic (Lecture 8) acts per facade — north, south, east and west faces see the sun at different times and must be controlled as separate groups so each tracks its own sun condition. Within orientation, secondary zoning follows room and use (a boardroom needs its own scene control independent of the open-plan floor it adjoins; a double-height atrium differs from the offices around it) and control intent (manual-priority spaces versus fully-automatic spaces).

Good zoning produces groups small enough to behave correctly and be serviced independently, yet aggregated enough to be manageable — a balance the specifier sets deliberately. On top of zoning sits the controller hierarchy. The robust commercial pattern is layered: individual motors (addressable, feedback-capable) report to local or zonal shading controllers that run fast local logic (sun-tracking computation, and the mandatory local wind retraction from Lecture 8); those controllers connect via a gateway to the building-automation network (KNX/BACnet/Modbus per Lecture 7); and the BMS sits above, issuing high-level scene, setpoint and demand-response commands and reading status, while never owning the safety-critical local logic. This hierarchy is what keeps wind safety deterministic and local while still allowing building-wide coordination and a single BMS dashboard.

g. floor-orientation-zone-blind) so that commissioning, fault-finding and future changes are tractable — an ad-hoc addressing scheme is a commissioning and maintenance tax paid for the life of the building. The head-end and user-interface layer is the human face of the architecture: wall keypads and 'my'-position buttons for local manual control, touch panels or BMS graphics for facility management, scene controls in meeting spaces, and increasingly mobile/web interfaces — each of which must be mapped to the zones and objects the architecture defines, and each of which is a place where override priority (Lecture 8) is exercised. Crucially, the architecture is not designed in isolation: the zoning decided here propagates backward to the cabling topology of Lecture 5 (circuits and buses should follow zones so a zone can be isolated and serviced as a unit, and so coincident-start staggering can be applied per zone), and forward to the commissioning of Lecture 10 (you commission and test zone by zone, so the zones must be defined and addressed before commissioning can be planned).

Right-sizing is a professional judgement the lecture emphasises: a small project (a single boardroom, a clinic) does not need a full BMS-integrated hierarchy and may be served well by a standalone controller with local scenes and a wind sensor, while a large estate needs the full layered architecture — over-engineering the small project wastes capital and under-provisioning the large one (no gateway, flat grouping, no feedback) cripples it, which is the recurring failure mode of the course's case studies. The Rosebank case is the zoning failure at scale: 1,200 blinds across a mixed-use tower were architected as a single flat control group with one set of logic, so every sun event commanded all 1,200 motors to move simultaneously — a coincident-load nightmare for the power circuits (Lecture 5), visually jarring, and incapable of letting the shaded south behave differently from the sunlit north; the building had the hardware for intelligence but an architecture that prevented it. Proper orientation-and-use zoning, with a layered controller hierarchy and a documented addressing plan, would have let each facade and each space behave correctly and be serviced independently. The deliverable is the integrated-system architecture package: a zoning plan (orientation x use x intent), a controller-hierarchy diagram, a network and addressing schedule, the head-end/UI schedule, and the cross-references to the cabling topology and commissioning plan.

Commissioning: From Installed Hardware to Verified Behaviour

Installed and wired is not the same as commissioned, and this lecture sets out the structured commissioning process that turns a physically complete shading installation into a verified, documented, intelligent system — the stage projects most often skimp and most often regret. We sequence the work: motor limit-setting and direction checking, address assignment and group/zone configuration, gateway and protocol binding (KNX group addresses, BACnet object mapping, Modbus register verification), sensor calibration and the critical wind-retraction proving, then sun-tracking and daylight-logic tuning, scene programming, and integrated testing with the BMS and lighting. We stress the test artefacts — a commissioning record per zone, a point-to-point verification against the object list, and a witnessed wind-safety test — and handover with as-built documentation and client training. A Centurion data-centre office where commissioning was cut to save time, leaving sun-tracking 'configured but never proven', anchors why witnessed verification matters.

In depth

Commissioning is the disciplined process of proving that every layer of the system actually does what the specification said, and it is the single most undervalued stage in motorised-shading projects — hardware that is installed and powered is not a working intelligent system until it has been systematically configured, calibrated, integrated and verified. The process follows a deliberate sequence, each step depending on the last. First, at the motor level: set the upper and lower limits on every motor (point-precise on electronic-limit motors), verify direction of travel (a reversed motor is a classic install error), confirm smooth full-travel operation, and check for noise, slip or binding that indicates a sizing or adaptor error from Lectures 2-3 — caught here, it is a motor swap; caught after handover, it is a callout. Second, addressing and grouping: assign each motor its unique address per the Lecture 9 addressing plan, and configure the control zones and groups so that 'south facade', 'boardroom' and so on command the correct motors — this is where a logical addressing scheme pays off and an ad-hoc one costs hours.

Third, gateway and protocol binding: bind the shading objects to the building-automation network — assign and link KNX group addresses in ETS, map BACnet objects and verify the BMS can read present-values and write setpoints, or verify the Modbus register map point by point — and confirm bidirectional operation (the BMS can both command and read back). Fourth, sensor calibration and the safety proving: calibrate sun/lux sensors to meaningful thresholds, and — the non-negotiable step — prove the wind-retraction function by a witnessed test, physically confirming that an over-threshold wind signal (simulated at the anemometer or via a test input) drives the exterior blinds to retract through the local controller logic, independent of the BMS, within the required time. This wind-safety proving is the commissioning step that the George storm of Lecture 8 shows must never be skipped. Fifth, logic tuning: with sensors live, tune the sun-tracking (verify slats/screens reach the correct cut-off positions as the sun moves, using motor feedback to confirm achieved position), tune the daylight-harvesting coordination with lighting dimming, and adjust thresholds and hysteresis so the system is responsive without 'hunting' (constantly small-stepping, which annoys occupants and wears motors).

Sixth, scene programming: set and verify the named scenes (morning, evening, presentation, fire mode) and the 'my' favourite positions, and confirm the override priority hierarchy behaves as specified — manual override times out to auto, wind overrides everything. Seventh, integrated testing: run end-to-end scenarios with the BMS and lighting together — a simulated sun event, an occupancy change, a fire-mode trigger, a wind event — and confirm the whole system responds coherently. Throughout, the discipline is documentation and witnessing: a commissioning record per zone listing each motor's limits, address and direction; a point-to-point verification sheet against the Lecture 7 object list confirming every BACnet object / KNX group address / Modbus register reads and writes correctly; a witnessed and signed wind-safety test certificate; and the tuning parameters recorded so the system can be restored after any future controller replacement. Handover completes commissioning: as-built drawings and schedules reflecting the actual installed addressing and zoning, the commissioning records, the object/register documentation the facilities team and any future integrator will need, operation-and-maintenance manuals, and crucially client/FM training so the building operator can use, override and maintain the system rather than abandoning it to a default state (the very failure of the Sandton tower in Lecture 1).

The Centurion case is the commissioning-skimp lesson: under programme pressure the sun-tracking and daylight logic were 'configured' in the controller but never proven against the live sun and never integrated-tested with the lighting, the wind test was signed off on paper without a witnessed retraction, and the project handed over; within the first month occupants found blinds that did not track, lights that did not dim with daylight, and — most seriously — exterior screens that did not retract in the first strong wind because the configured-but-unproven wind logic had a mis-mapped sensor input. Every one of these was a commissioning-stage catch that the skimped process missed. The deliverable is the commissioning and handover pack: per-zone commissioning records, the point-to-point object verification, the witnessed wind-safety certificate, the logic-tuning parameter record, as-built documentation, and the client training sign-off.

Standards, Safety and Compliance: IEC 60335-2-97 and the SA Frame

Motorised shading sits inside a safety and compliance framework that a specifier must map, because non-compliance stalls approvals, voids warranties and creates liability. This lecture decodes the key standards: IEC 60335-2-97 as the particular safety standard for the drives of rolling shutters, awnings, blinds and similar equipment; the general appliance-safety standard IEC 60335-1 beneath it; the South African electrical installation frame of SANS 10142-1 and the Certificate of Compliance; the wind-action standard SANS 10160-3 that underpins exterior-blind retraction setpoints; and the EMC and low-voltage directive context for the equipment itself. We connect compliance to the earlier technical layers — how IEC 60335-2-97 informs thermal cut-out behaviour and obstacle detection, how SANS 10142-1 governs the cabling of Lecture 5, and how wind standards set the safety logic of Lecture 8. A Bloemfontein retail project where non-compliant imported motors failed an electrical inspection illustrates the cost of ignoring the frame.

In depth

Compliance is not paperwork bolted on at the end; it is a set of constraints that shape the technical decisions of every preceding lecture, and a specifier who maps the framework up front avoids the approval delays, warranty voids and liability exposure that catch the unwary. The cornerstone product standard is IEC 60335-2-97, 'Household and similar electrical appliances — Safety — Particular requirements for drives for rolling shutters, awnings, blinds and similar equipment'. It is a 'Part 2' particular standard that works in conjunction with the general standard IEC 60335-1 ('Safety — General requirements'): together they define the electrical and mechanical safety the motor/drive must meet — insulation and earthing, temperature rise limits, the thermal cut-out behaviour that protects the windings (the intermittent-duty cut-out discussed in Lecture 2 is a 60335 requirement, not merely a design choice), protection against hazardous moving parts, and, for relevant products, obstacle/obstruction detection and the avoidance of hazards from inadvertent operation. When a specifier requires motors 'compliant with IEC 60335-2-97', that requirement carries real engineering content: it is why a reputable tubular motor trips and cools rather than burning out, and why its limits and force are controlled.

The standard also intersects with EMC and the low-voltage equipment directives that govern CE-marked product placed on the market, and with the cordless-window-covering child-safety concern that, while more prominent for manual cord systems, is part of why motorisation (which removes accessible cords) is itself a safety improvement. Beneath the product sits the installation, and in South Africa the installation is governed by SANS 10142-1, 'The wiring of premises', which sets how the fixed low-voltage electrical installation feeding the motors must be designed, installed and protected, and mandates that the work be certified by a registered person with a Certificate of Compliance (CoC) issued for the installation — the legal instrument without which the electrical installation is non-compliant and insurance and occupancy can be jeopardised. This is the standard that governs the cabling topology of Lecture 5, and it draws the responsibility line between the blind installer and the certifying electrician that the specification must make explicit. The wind-action standard SANS 10160-3 ('Basis of structural design and actions for buildings — Part 3: Wind actions') provides the regional wind-speed and pressure data from which the design wind load on exterior shading is derived — feeding both the structural fixing design and the torque/holding calculation of Lecture 3, and the retraction setpoint of the wind-safety logic of Lecture 8; an exterior blind's rated wind class must be reconciled with the SANS 10160-3 site wind pressure to set a defensible auto-retract threshold.

Around these sit the product's own rated classes (wind class, IP rating for exterior exposure, operational temperature range) which the specifier should require on the submittal. The professional method is to write compliance into the specification as explicit, checkable requirements: motors and drives compliant with IEC 60335-2-97 / IEC 60335-1 with declared conformity; the electrical installation to SANS 10142-1 with a CoC as a contractual deliverable and a defined trade responsibility split; exterior shading wind class reconciled with SANS 10160-3 site data and the retraction setpoint documented; and the relevant IP and EMC declarations on the submittal — so that a building-control inspector, an insurer or the client's engineer can verify each. The Bloemfontein retail case is the cost of ignoring the frame: a contractor substituted cheaper imported tubular motors that lacked credible IEC 60335-2-97 conformity and were wired by an unregistered installer; the electrical inspection failed for want of a valid CoC and for non-compliant equipment, the motors were rejected, and the project incurred a full re-supply and re-installation delay plus the loss of any warranty recourse against the grey-import supplier — every cost avoidable by specifying the standards explicitly and verifying conformity at submittal. The deliverable is a compliance map: the product-safety requirement (IEC 60335-2-97 / -1) and its evidence, the installation requirement (SANS 10142-1 + CoC) and the trade-responsibility split, the wind compliance (SANS 10160-3 reconciliation and documented setpoint), and the submittal checklist of declarations the specifier will require before approval.

The Motorisation & Integration Specification: Documentation and Hand-off

The course closes where real projects live — in the specification and documentation that carry the design into procurement, installation and operation. This capstone lecture assembles every preceding deliverable into the two artefacts that govern a motorised, integrated shading project: the motorisation-and-integration specification and the project documentation set. We set out a specification structure that a SACAP architect, an ECSA electrical/controls engineer and a controls contractor can each act on, and we show how to write it so it survives value engineering by binding every technical requirement to a consequence — torque margins to reliability, feedback to functionality, gateways to integration, wind logic to safety. We dissect a complete C21-format specification for an SA commercial project, tracing each clause back to its lecture, and we define the documentation chain from spec through submittal review to commissioning records and as-builts. A Sandton retrofit specification that defeated a value-engineering attempt to strip the gateway and feedback closes the course on the discipline that makes all the engineering count.

In depth

The capstone deliverable of the whole course is a specification and documentation set that turns the engineering of Lectures 1-11 into a procurable, buildable, operable and defensible reality — because analysis that is not specified is not built, and a system that is not documented cannot be operated or maintained. Two artefacts carry the work forward. The motorisation-and-integration specification is the buildable instruction; the project documentation set is the record that survives into operation. The specification should be structured so each of its three readers can navigate to their concern.

Open with a system description and design intent — what the shading is to achieve (energy, glare, daylight, comfort, safety) and the system architecture from Lecture 9 — because this frames every clause that follows. Then, in a logical order mirroring the course: motor requirements (family, power type, electronic limits, the torque-sizing basis and per-blind selections from Lecture 3, IEC 60335-2-97 conformity from Lecture 11, duty-cycle acknowledgement); control-bus requirements (the chosen protocol per zone and the explicit feedback capability from Lecture 4); power and cabling requirements (topology, circuits and coincident-load staggering, segregation, isolation, the SANS 10142-1 / CoC responsibility split from Lecture 5); integration-interface requirements (the gateway and the per-blind/per-group object list it must expose on KNX/BACnet/Modbus from Lectures 6-7, with PICS/DPT/register-map requirements); sensor and control-logic requirements (the sensor schedule, the wind setpoint and its SANS 10160-3 basis, the control-logic description and the written priority hierarchy with wind/safety mandated local, from Lecture 8); and commissioning and handover requirements (the structured commissioning sequence, the witnessed wind-safety test, the point-to-point object verification and the as-built/training deliverables from Lecture 10). The art of the specification — the discrete professional skill this lecture teaches — is writing it to survive value engineering. The failure mode is a spec that lists requirements without consequences, so a quantity surveyor under cost pressure deletes the gateway, downgrades feedback-capable io motors to one-way RTS, or strips the wind logic, because nothing in the document says what breaks.

The robust specification binds every requirement to its consequence: the torque margin is tied to reliability and the duty-cycle thermal trip ('reducing the specified motor one size will run it near its torque limit, accelerating thermal cut-out trips and shortening life'); feedback is tied to functionality ('one-way RTS cannot report position; substituting it makes sun-tracking verification and BMS status reporting impossible — the daylight-harvesting energy benefit is forfeited'); the gateway is tied to integration ('without the gateway the blinds collapse from individually-addressable objects to a few dry-contact groups, defeating individual and daylight control'); and the local wind logic is tied to safety and liability ('routing wind retraction through the BMS exposes the exterior shading to destruction during any BMS outage — see the documented coastal storm failure mode'). When deletion visibly threatens reliability, function, the energy case and safety/liability, value engineering redirects rather than guts the system. The specification must also be written for three readers at once: the SACAP architect needs the system intent, the visible hardware and the user-interface provision; the ECSA electrical/controls engineer needs the power topology, the protocol and object model, the load and wind calculations and the standards; and the controls contractor needs the addressing scheme, the object/register lists and the commissioning and test requirements precise enough to build and prove. The documentation chain ties it together and is itself a deliverable: specification -> submittal review (where the specifier checks the contractor's proposed motors, gateway, object list and conformity declarations against the spec before approval) -> shop drawings and addressing plan -> commissioning records and witnessed tests -> as-built documentation and O&M/training.

Traceability is the capstone habit: every clause should trace to a calculation (the torque worksheet), a decision record (the control-bus and architecture decisions), an object list (the integration interface) or a standard (the compliance map), so that when challenged — by a cost engineer, an inspector, or in a dispute — the entire chain is defensible. The dissected Sandton retrofit specification shows the discipline working: a value-engineering proposal to remove the BACnet gateway and substitute RTS motors to save capital was defeated clause by clause because the specification documented that doing so would forfeit the sun-tracking energy savings that justified the project's business case, make BMS status reporting impossible, and — by also proposing to route the remaining wind logic through the BMS — recreate exactly the coastal-storm destruction failure mode; faced with quantified consequences the client retained the gateway and feedback. The deliverable, and the deliverable of the entire course, is precisely this: a motorisation-and-integration specification plus documentation set that is engineered, integration-ready, standards-compliant, value-engineering-proof and build-ready for a South African commercial project.

Worked Example 1 — Torque sizing a boardroom roller blind, Sandton

A 2.4 m wide × 3.0 m drop screen-fabric roller blind on a 45 mm tube. Select the motor.

Step 1 — Suspended load

Fabric area = 2.4 × 3.0 = 7.2 m² at 0.35 kg/m² = 2.52 kg, plus a 1.8 kg aluminium bottom bar = 4.32 kg. Force F = m × g = 4.32 × 9.81 = 42.4 N.

Step 2 — Effective radius & tube torque

Bare 45 mm tube radius = 0.0225 m, but with fabric build-up the effective lifting radius ≈ 0.030 m. Tube torque T = F × r = 42.4 × 0.030 = 1.27 Nm.

Step 3 — Efficiency, margin & selection

Motor-side torque = 1.27 / 0.70 (assembly efficiency) = 1.82 Nm; × 1.3 duty margin = 2.4 Nm required. Select a 6 Nm Sonesse 50 — conservative and quiet, the right choice for a boardroom where acoustics matter.

Worked Example 2 — Gateway & protocol selection, Midrand campus

Lighting/room control on KNX, HVAC and central BMS on BACnet/IP. Integrate 480 blinds.

Step 1 — What does the building speak?

Two protocols already exist: KNX for occupant- and lighting-coordinated control, BACnet/IP for the BMS sun-tracking and energy coordination. The shading must face both.

Step 2 — Bus & controller

Feedback-capable io / wired-RS485 motors report to zonal shading controllers (Animeo-class) running local sun and wind logic. A controller/gateway carries both a KNX interface and a BACnet/IP server interface.

Step 3 — Object model

KNX side: scene and switch group addresses (DPT move, stop, position %) shared with lighting. BACnet side: an Analog Value position-setpoint object, status/position objects and a Multistate mode object per group, with the gateway's PICS required at submittal.

Worked Example 3 — Local wind-safety architecture, George coast

Exterior zip screens on an exposed coastal facade. Architect the retraction so a storm cannot destroy them.

Step 1 — The failure to avoid

The original design routed the anemometer into the BMS, which was to command retraction. During a winter storm the BMS was mid-reboot, the command never issued, and deployed screens were torn from the facade.

Step 2 — Wind setpoint

Reconcile the screen's rated wind class with the SANS 10160-3 site wind pressure for George; set the auto-retract threshold below the rated limit with hysteresis to avoid chatter.

Step 3 — Local, deterministic logic

Hard-wire the anemometer to the local shading controller; wind retraction sits at the top of the priority hierarchy and pre-empts every other command, executing independently of BMS availability. Comfort and energy logic may remain in the BMS; safety does not.