The glass switches when the correct power is applied. Controls determine who operates which circuits and when. One large pane may need one signal, while zoned glass can require several independent channels combined into scenes.
The more advanced the system, the more important a simple base mode becomes. A meeting-room user should not need a phone, login or cloud connection to begin a confidential conversation. Integration should shorten the task, not make the core function dependent on more technology layers.
1. Draw the circuits before selecting an interface
A circuit is a physical group of active areas switched together. One Classic pane usually forms one circuit. DGF Segment can contain several areas, each needing its own channel if it is to operate independently. Several panes in one wall can switch together or separately; the decision affects wiring and equipment capacity.
A pane–zone–channel map comes before switches and scenes. The app name then corresponds to the documentation and service can identify a circuit without disconnecting panes experimentally.
- pane number and location
- active-zone number and connection edge
- power or controller channel
- local control and scene name
2. Wall switch: the simplest and often best
A wall switch sits where the user makes the privacy decision. It requires no phone, network, account or training. For a meeting room, consulting room or bathroom it is usually the most predictable control.
Define the action type, label and relationship to lighting and nearby switches. Where accessory appearance matters, the actuator can work with an agreed switch range, but electrical compatibility and logic must be confirmed.
3. Remote control: convenience without an app, with device responsibility
A remote suits situations without a convenient switch position or where operation from several places is needed. It needs no network infrastructure but can be lost, run out of power or be moved to the wrong room.
In a commercial building, storage, labelling and re-pairing procedures should be planned. A remote should not be the only way to restore privacy in a critical room.
4. Apps and scenes: when they genuinely add value
An app is useful for multiple panes, zones, schedules or remote status checks. With DGF SUPLA, users can operate scenes within the agreed system scope. Account ownership, permissions, handover and behaviour after router or provider changes must still be planned.
Good scenes are named after tasks: “meeting”, “presentation”, “cleaning”, “evening”. They set several zones predictably. A “wow effect” used only in a sales demonstration does not justify everyday complexity.
| Method | Best for | Risk to plan |
|---|---|---|
| Switch | Single room and frequent use | Clear label and position |
| Remote | Operation without wiring to a switch | Storage, battery and re-pairing |
| App | Multiple zones, scenes and remote access | Account, network, permissions and handover |
| BMS | Large building and central logic | Interface, responsibility and failure test |
5. BMS integration: define the signal before selecting a brand
Integration can link glass to a room mode, booking, access control or central building shutdown. First define the signal, resulting state, duration and who may override it locally.
Technical details depend on devices, protocols and the controls design. Compatibility with every BMS should not be promised from a generic label. DGF, controls integrator and electrician must confirm interface, power, signal isolation and test scenario.
6. What should happen when power fails and returns?
DGF PDLC returns to its frosted state without power. This is logical for many privacy applications, but visual communication, evacuation, display function and user requirements must be considered. If backup power is needed, its scope and duration cannot be left undefined.
After power returns, the system may remain in its default state or restore a scene depending on controller and design. Handover should include controlled tests of power loss, network restart and app unavailability. Only then is independent local operation confirmed.
In practice: Failure behaviour is part of the function, not a service afterthought. It belongs in the controls description and handover record.
