An automated window doesn’t need someone standing in front of it to open or close it. That’s the point of automating it, but it also raises a question worth resolving properly at design stage: what stops the window closing on something, or someone, in its path?
This is generally referred to as trap hazard mitigation, the methods used to reduce the risk of an automated opening closing on an obstruction. It’s not a single product or a tick-box requirement. Depending on the project, it can be addressed through where the window sits and who can reach it, how the control system schedules and times movement, or the addition of a sensor that monitors the closing path directly. Which of these applies, and how many are needed together, depends on the specific opening, and getting that judgment right is as much a part of specifying automated windows as choosing the correct actuator.
Why automation changes the risk
A manually operated window is opened and closed by a person who can see what’s in front of it. If a hand is resting on the sill, a cord is hanging across the opening, or someone is leaning through the frame, the person closing the window notices and stops. An automated window can be triggered by a wall switch, a building management system, a sensor, or a schedule, often without anyone in the room at the time, and without that instinctive check taking place.
That doesn’t make automated windows inherently unsafe. It does mean the question a person answers instinctively when closing a window by hand, is anything in the way, needs to be answered by the system instead. Where an opening is genuinely low risk, that answer can come from where the window is and how it’s used. Where it isn’t, the system needs another way to check.
This is a genuinely different design problem to specifying the actuator itself. An actuator is selected against the window’s geometry, weight and required stroke, questions that can largely be answered from a set of drawings. Trap hazard mitigation is answered against how the space around the window is actually used, who can reach it, when it’s occupied, and what else is likely to be near the opening while it moves. That’s a question about the building and its occupants as much as the window, which is why it needs its own consideration rather than being assumed to follow automatically from the actuator specification.
It’s also worth separating this from the related, but distinct, question of fall risk at low-level openings. Restricting how far a low-level window can open is generally about preventing someone falling through it or an object dropping from it, particularly where the opening faces a footpath or thoroughfare. Trap hazard mitigation is about what happens on the way to that restricted position, or on the way to fully closed, not the maximum opening itself. A project can need to address both, and they’re usually resolved through different parts of the specification.
Three ways trap hazard risk is addressed
Window positioning and reach
The simplest form of mitigation is removing the opportunity for contact altogether. A high-level, out-of-reach opening carries a fundamentally different risk profile to one at head height in a corridor or above a walkway. Where an automated window is genuinely inaccessible to occupants, that positioning is itself doing a lot of the risk-reduction work, before any control logic or sensor is added.
This is one of the reasons opening type and location get resolved early in a specification. A top-hung, outward-opening window at high level isn’t just a natural ventilation preference, it also tends to sit well clear of anywhere someone could be caught by its movement. The same logic applies in reverse: a low-level opening in a corridor, foyer or publicly accessible facade needs to be treated differently from the outset, rather than having risk mitigation added on as an afterthought once the window type has already been chosen.
Control logic and timing
Where a window is within reach, or operates in a space that’s occupied while it moves, the control system itself can reduce risk. This can include scheduling movement for times a space is known to be unoccupied, using slower or more controlled closing speeds rather than a single fast stroke, and building in obstacle-detection at the actuator or controller level.
WindowMaster’s MotorLink-enabled actuators, for example, include an obstacle-detection function that reverses the actuator if it meets resistance while closing. That’s a useful layer of protection, but it’s a mechanical response to resistance already being met, not a substitute for checking the path is clear before the window closes fully. On its own, it’s rarely the whole answer for a genuinely accessible opening.
Control logic also needs to account for what happens when something goes wrong elsewhere in the system, a power interruption, a fault, or a manual override triggered by a building occupant or the fire system. A window that’s mid-cycle when power is lost, or that’s commanded to close by an override while someone is nearby, still needs to behave safely. This is one of the reasons trap hazard mitigation is considered alongside the control strategy as a whole, rather than treated as a single add-on feature.
Sensing the closing path directly
For openings where positioning and control logic aren’t enough on their own, typically low-level windows in occupied or publicly accessible areas, a sensor can be added that monitors the closing path itself and signals the control system to stop, or reverse, before the window makes contact.
A laser sensor is one way this is done. In general terms, this kind of sensor scans the plane the window is closing through, using the reflection of the laser to detect whether the path is clear, and reports back to the controller in real time rather than waiting for the actuator to meet physical resistance. This is a meaningfully different kind of check to obstacle-detection at the actuator: it’s designed to stop the movement before contact occurs, not after.
Not every automated window needs this. It depends on where the window sits, how accessible it is, and how it operates within the wider system. But it’s a good example of the kind of thinking a proper trap hazard assessment involves: the movement itself is only part of the picture, and what happens if something’s in the way needs to be considered too.
Why this isn’t a standard answer
It would be simpler if every automated window needed the same level of protection, but that’s not how the risk actually works. A high-level window with no public access underneath it carries a different risk profile to a low-level, publicly accessible opening in a busy building, and a window opening onto a private plant area is a different case again to one opening above a public foyer or thoroughfare. Occupancy pattern, opening height, whether the space is public or restricted, and how the window fits into the broader automation and control strategy all affect what’s appropriate.
Specifying a sensor on every automated window regardless of risk isn’t a genuinely safer default, either. It adds cost and complexity to openings where the risk was already low, and it can create a false sense of security elsewhere on the project if a team assumes the same approach applies everywhere without checking. Equally, assuming positioning alone is sufficient because a similar-looking window on another project didn’t need a sensor can miss something specific to this building, a change in floor level, a walkway added at design development, or a change of use in the space below.
A trap hazard risk assessment is a project-specific exercise rather than a specification default. It’s carried out for the actual opening, in its actual location, rather than assumed from a similar-looking window on another project.
A recent example
On the Harbourside Redevelopment in Darling Harbour, Sydney, Blue Squared is working alongside facade contractor Chevalier Aluminium on a project where low-level automated windows form part of the specification in an area with public access. A BEA LZR-FLATSCAN laser sensor is being used to monitor the closing path of these openings, signalling the control system to stop the actuator if it detects an obstruction before the window fully closes.
This project is a useful illustration of the principle rather than a template to copy directly. The same solution won’t automatically apply to every low-level opening; it reflects what the risk assessment for this specific location requires, including how accessible the openings are, how the space around them is used, and how the windows fit into the wider automation and control system for the building.
Coordination across the project team
Trap hazard mitigation rarely sits with a single discipline. The architect and facade consultant generally set the opening type and location that determine baseline accessibility. The mechanical engineer or facade automation specialist works through the control logic and, where required, the sensor and its interface with the controller. The electrical contractor runs and terminates the wiring for that sensor alongside the actuator cabling. And the builder or head contractor needs to know, well before installation, whether a low-level opening on the project requires this additional scope so it can be programmed and priced correctly rather than discovered on site.
Where this coordination happens late, it tends to show up as a late change: a sensor added after the window and control system have already been detailed, rather than designed in from the outset. That can mean re-running cable routes that were already fixed, revisiting a bracket or mounting detail that didn’t allow for a sensor housing, or a controller that needs an additional input it wasn’t originally specified with. None of this is difficult to accommodate if it’s known about early, but each of these becomes a variation, rather than a line item, once the design is locked and the trades are on site. Resolving it during design avoids that rework and gives every discipline a clear view of what’s required before tender.
Testing, commissioning and documentation
Specifying the right combination of positioning, control logic and sensing is only half the job. Whatever mitigation is used needs to be tested and confirmed working before the building is handed over, not simply assumed to be functioning because it was installed correctly on paper.
For a sensor-based solution, this generally means confirming the sensor detects an obstruction reliably across the relevant part of the closing path, that the signal to the controller correctly stops or reverses the actuator, and that this behaviour is repeatable rather than a one-off test result. Where control logic or scheduling is the primary mitigation, commissioning needs to confirm the window actually behaves as intended under the conditions it will operate in, not just under test conditions.
This should be documented as part of the project’s handover package, so a building owner or facilities team understands what mitigation is in place on which openings, and so it can be checked again if the control system or actuator is ever serviced or replaced later in the building’s life. A sensor that isn’t included in that documentation is easy to overlook during future maintenance, particularly if the person servicing the window years later wasn’t involved in the original design.
A practical takeaway for design teams
Trap hazard mitigation works best when it’s considered alongside the rest of the automation design, not bolted on afterwards. Questions worth resolving early include:
Where does the window sit in the building, and is it genuinely accessible to occupants or the public? Is the space occupied while the window is scheduled to move, and can timing reduce that overlap? Does the opening warrant a sensor that monitors the closing path directly, in addition to any obstacle-detection built into the actuator? Who is responsible for specifying, supplying and wiring that sensor, and how does it interface with the controller? How will the mitigation be tested and documented at commissioning, so it’s confirmed working before handover rather than assumed?
Leaving these questions until installation tends to mean retrofitting a solution around a design that didn’t account for it, which is a harder and more expensive way to solve the same problem.
Conclusion
Trap hazard mitigation isn’t a single product decision. It’s a combination of where a window sits, how the control system schedules and manages its movement, and, where warranted, a sensor that checks the path is clear before the window closes. Getting the combination right for a specific opening is what a proper risk assessment is for, and it’s worth carrying out before the window and controls are locked into a specification rather than after.
Blue Squared can carry out a trap hazard risk assessment as part of the design and specification process for a commercial automated window project, working through positioning, control logic and sensing needs for the specific openings involved, and coordinating the outcome with the rest of the project team before it needs to be resolved on site.
If you’re working through trap hazard mitigation on a current project, get in touch with the team at Blue Squared.
