01
Define what to control, then what to know.
‘Centralise everything’ is not yet a brief. Describe each function with a zone, trigger, action and exception: switch reception off on departure but retain the occupied office. Then specify who can act and how local control takes over. The same approach applies to a villa, office or multiple building zones.
Building management may add operating requirements: zone views, histories, schedules, permissions or fault handling. Enumerate included functions instead of inferring them from a touchscreen. A sent setpoint, reported state and physical measurement answer different questions; the brief must distinguish them.
02
From request to action, then feedback.
KNX is one documented example of this chain, not the assumed protocol of the whole catalogue. Selected references must support the required functions, with verified interfaces and configuration.
01 · Input
Button, schedule or sensor: name the event and its origin. Presence sensing, manual commands and schedules provide different information.
02 · Logic and priority
Describe conditions, exceptions and override duration. For competing requests, state which prevails and how the user sees the active rule.
03 · Communication and interface
In KNX, media and functional associations are configured for the project. For a gateway, check direction, exposed points and versions; sharing an IP network is insufficient.
04 · Acting on the load
Switching, dimming, moving shading or sending a climate setpoint require suitable interfaces. Check the load, existing controls and limits before selecting an actuator.
05 · Feedback and supervision
Document the origin of each displayed state. If position is estimated or data is unavailable, the interface must say so; command acknowledgement is not a measurement.
03
Five decisions that shape operation.
Scroll the table horizontally to compare all three columns.
| Decision | Practical question | What to confirm |
|---|---|---|
| Renovation or new build | Which cables, panels, controls and equipment stay? | Feasible architecture and related works; neither bus nor radio selected without a survey. |
| Functions and protocols | Which actions and information cross each interface? | Point list, types, units, read/write direction and documented restrictions. |
| Local or remote control | What remains usable without Internet, a server or an external account? | Dependencies per function and an agreed degraded-operation test. |
| Command conflicts | What happens to a manual override at the next scene? | Explicit priority, scope, duration and return-to-automatic condition. |
| Handover and expansion | Who retains configuration, access and editing means? | Handed-over backups, roles, licences and planned reserves; no assumed unlimited expansion. |
04
Example: a departure scene with one office still occupied.
ILLUSTRATIVE EXAMPLE
Fictional case with three zones: reception L-01, meeting room L-02 and office L-03. IDs belong to the brief, not a real installation. Here the office override lasts until the user explicitly releases it.
Write actions and the exception
The ‘Leaving’ button requests L-01 and L-02 off. L-03 retains its previous state because an override is active. The scene must neither erase that override nor report that the entire building is off.
Separate request from available state
The report separates requests, received feedback and unknown points. A blind S-01 without position feedback cannot become ‘confirmed closed’ merely because the command was sent. Old or estimated information is labelled accordingly.
Test taking control again
The user releases the L-03 override, then deliberately reruns the scene to verify the agreed rule. In a controlled test, also check functions claimed to remain available after losing an external service. Do not infer the result from a protocol logo.
This scene resets no fire system, disarms no alarm and validates no motor safety. Those systems retain dedicated logic and responsibilities; any interfaces need a separate scope.
05
Six questions for a usable functional brief.
Which zones and loads?
Plan, IDs, lights, motors, climate controls and retained equipment. Attach references and known characteristics; flag unknowns.
Which triggers and exceptions?
For each scene: event, zones, result, manual priority and automatic-mode return. Describe actual use, not only the scene name.
Which interfaces are documented?
Protocol, versions, exchanged points, units and read/write permissions. Confirm gateway limits and required licences.
Which states can actually be displayed?
For each point, record sensor evidence, reported state or estimate and behaviour when data is missing. Plan clear wording for uncertain states.
Which dependencies and access?
Power, network, server, accounts and any remote service. Separate everyday user, administrator and service roles; do not share secrets in a public brief.
Which tests and handed-over files?
List scenes, criteria, exceptions, versions and open issues. Request exportable configuration where provided, backups, access rights and a user guide; specify follow-up scope.
06
Document integration function by function.
KNX sources explain functional associations and ecosystem interfaces; they do not certify a reference list selected without verification. Separate Inovexia supply, programming, installation, commissioning and support in the offer. History, alerts, export, remote access and energy savings do not follow merely from a supervisory interface: specify points, conditions and required evidence before approval.
07
What to ask beyond the app.
Does one central screen mean everything is compatible?
No. Verify references, exchanged functions and interface limits. Seeing two devices in one app does not establish every desired scene.
Does local control always work without Internet?
It depends on architecture and function. Request a dependency list and an agreed test. Do not confuse losing remote access with losing all local control.
What should shading without a position sensor display?
What is actually known: request sent, documented estimate or unknown position. An estimate may be useful when labelled; it must not be presented as a confirmed measurement.
Can a scene overwrite a manual command?
Define the rule rather than assume it. State which overrides persist, their duration and release. Explicitly test conflicts so a user does not lose an exception without explanation.
Can savings be claimed when equipment is selected?
Not from this page or a scene alone. A quantified result needs a method, baseline and comparable data. A project may seek better control without promising an unmeasured percentage.
Technical sources
External reading references. These documents explain principles; they do not certify catalogue products or their combination.
- KNX TechnologyKNX Association · Sources consulted on
- KNX IoT: the Summum of InteroperabilityKNX Association · Sources consulted on