KNX automation becomes significantly more powerful when a system can make decisions instead of simply passing commands from one device to another.

A presence sensor can trigger lighting only when it is dark. A fan can operate only when temperature and humidity exceed defined limits. A blind can move when sunlight reaches a threshold, but only when the room is occupied and the wind condition is safe.

This is where KNX logic and automation are used.

Logic functions can be implemented using logic modules, logic controllers, multifunction devices, actuators with built-in logic, sensors and other KNX-capable devices. KNX-certified products can provide functions such as Boolean logic, timers, comparisons, arithmetic, scaling, conversion and other processing functions, depending on the device and application program.

For integrators, the important question is not simply “Which logic module should I use?” but:

What condition should cause the automation, what conditions must be satisfied, what action should occur, and what should happen when conditions change?

---

1. What Is KNX Logic?

KNX logic allows the system to evaluate one or more inputs and produce an output according to defined rules.

A simple direct KNX function looks like:

Push Button
     │
     ▼
Group Address
     │
     ▼
Light ON/OFF

Logic adds decision-making:

Presence
    │
    ├──────────┐
    ▼          │
Brightness     │
    │          │
    └────┬─────┘
         ▼
       LOGIC
         │
         ▼
      Light ON

For example:

IF
    Presence = TRUE
AND
    Brightness < 300 lux

THEN
    Light = ON

This is fundamentally different from simply linking the presence sensor directly to the light.

Common KNX logic operations

Depending on the device, common functions include:

• AND
• OR
• XOR
• NOT / inversion
• NAND
• NOR
• Comparators
• Thresholds
• Timers
• Delays
• Counters
• Arithmetic
• Scaling
• Mapping
• Conversion
• Multiplexing

For example, a KNX logic module may provide Boolean operations and input/output inversion, while other KNX logic products provide timers, comparisons, arithmetic and conversion functions.

Why logic matters

Without logic:

Presence → Light ON

With logic:

Presence
   +
Low Lux
   +
Occupied Mode
   +
Time Window
   +
No Manual Lock
        │
        ▼
      Light ON

The second approach is much closer to how real commercial and residential automation systems need to behave.

---

2. Triggers, Conditions and Actions

A useful way to design KNX automation is to divide every function into three parts:

TRIGGER
   │
   ▼
CONDITIONS
   │
   ▼
ACTION

Trigger

The trigger is the event that causes the logic to evaluate.

Examples:

• Presence detected
• Button pressed
• Temperature changed
• Lux value received
• Time reached
• Window opened
• Mode changed
• Energy consumption exceeded threshold

Conditions

Conditions determine whether the action should actually happen.

Example:

Presence = TRUE
AND
Lux < 300 lx
AND
Mode = OCCUPIED

Action

The action is the resulting KNX command.

Light ON

Example

Consider a corridor:

TRIGGER:
Motion detected

CONDITIONS:
Lux < 200 lx
AND
Time = 18:00–06:00

ACTION:
Corridor light ON

The complete logic becomes:

Motion
   │
   ▼
Lux < 200?
   │
   ├── NO → Nothing
   │
   └── YES
        │
        ▼
Time within night period?
        │
        ├── NO → Nothing
        │
        └── YES
             │
             ▼
          Light ON

This way of thinking is extremely useful when writing the control philosophy before programming ETS.

---

3. AND, OR, NOT and Other Logic Functions

Boolean logic is the foundation of many KNX automation functions.

AND logic

All conditions must be TRUE.

Presence = TRUE
        AND
Lux < 300 lx
        AND
Occupied = TRUE
        │
        ▼
     Light ON

If any one condition is FALSE, the output remains FALSE.

OR logic

At least one condition must be TRUE.

Presence
   │
   ├──────►
           OR ───► Light ON
   │
Button ───►

For example:

IF
    Presence = TRUE
OR
    Manual ON = TRUE

THEN
    Light ON

NOT logic

NOT reverses a Boolean state.

Window Open = TRUE
        │
        ▼
       NOT
        │
        ▼
Window Closed = TRUE

This is useful when the required logic is the opposite of an available signal.

XOR

XOR produces TRUE when the required inputs are different.

Conceptually:

Input A = TRUE
Input B = FALSE
      │
      ▼
     XOR
      │
      ▼
    TRUE

XOR is less common in basic room automation but can be useful in more specialised logic.

Combining functions

Real projects normally combine several operations:

Presence ──────┐
               AND ───────┐
Dark ──────────┘          │
                          OR ───► Light ON
Manual ON ────────────────┘

The logic structure should be documented rather than left only inside a device’s parameter configuration.

---

4. KNX Timers, Delays and Time-Based Automation

Timers are among the most useful logic functions in KNX.

A sensor event often should not cause an immediate permanent command.

For example:

Motion Detected
      │
      ▼
   Light ON
      │
      ▼
  5 Minute Timer
      │
      ▼
   Light OFF

On-delay

An ON-delay waits before activating the output.

Input ON
   │
   ▼
[ 10 sec ]
   │
   ▼
Output ON

Example:

A ventilation fan may start only if a condition remains true for 30 seconds.

Off-delay

An off-delay keeps the output active for a defined period after the input becomes inactive.

Motion
  │
  ▼
Light ON
  │
Motion stops
  │
  ▼
[ 5 min ]
  │
  ▼
Light OFF

This is extremely common for occupancy lighting.

Pulse / monostable timer

A pulse timer can generate a fixed-duration output.

Button Press
     │
     ▼
  Output ON
     │
     ▼
[ 3 sec ]
     │
     ▼
 Output OFF

Cyclic timer

Some logic products can also generate repeating ON/OFF sequences.

For example:

ON 10 min
OFF 20 min
ON 10 min
OFF 20 min
...

The exact timer functions depend on the KNX device/application program. KNX-certified logic products demonstrate that timers can include functions such as on/off delays and pulse or cyclic operation.

Timer design question

Always define what happens when a new trigger occurs while a timer is already running.

For example:

Motion
 │
 ▼
5-minute timer
 │
 ├── Motion again
 │
 └── Timer?

Possible behaviours include:

• Restart timer
• Extend timer
• Ignore new trigger
• Reset output
• Retrigger pulse

The correct behaviour depends on the application and device capabilities.

---

5. Comparators, Thresholds and Value-Based Logic

KNX automation frequently uses values rather than simple ON/OFF signals.

Examples include:

• Temperature
• Lux
• CO₂
• Relative humidity
• Power
• Energy
• Wind speed
• Position
• Fan speed

A comparator converts a numerical value into a logical decision.

Temperature example

Temperature
     │
     ▼
Compare > 26°C
     │
     ├── FALSE → Fan OFF
     │
     └── TRUE
          │
          ▼
        Fan ON

Lux example

Lux Value
   │
   ▼
< 300 lux?
   │
   ├── NO → Light OFF
   │
   └── YES
        │
        ▼
Presence?
        │
        ├── NO → Light OFF
        │
        └── YES → Light ON

Two-threshold control

A common engineering problem is preventing rapid switching around a single threshold.

For example:

ON  when temperature > 26°C
OFF when temperature < 24°C

This creates a 2°C differential between ON and OFF conditions.

Conceptually:

Temperature

28°C ─────── FAN ON
26°C ─────── ON threshold
             │
24°C ─────── OFF threshold
             │
22°C ─────── FAN OFF

This type of hysteresis can reduce unnecessary switching, but the actual implementation depends on the device’s available logic functions.

---

6. Interlocks, Mutual Exclusion and Priority

Interlocking is essential whenever two commands should not be active simultaneously.

A classic example is motorised blinds:

Blind UP
   │
   ├──────────────┐
   │              │
   ▼              ▼
UP command     DOWN command
   │              │
   └──────┬───────┘
          ▼
      INTERLOCK

The objective is to prevent contradictory commands from being active simultaneously.

Example: ventilation

Suppose a system has:

Heating = ON
Cooling = ON

These states may be undesirable simultaneously.

Logic can enforce:

Heating ON
     │
     ▼
Cooling forced OFF

and:

Cooling ON
     │
     ▼
Heating forced OFF

Interlock is different from simple logic

A normal AND condition says:

Both conditions must be true.

An interlock says:

One state prevents another state from being active.

This distinction becomes important in HVAC, motor control, shading and equipment sequencing.

Priority control

Large systems may have multiple command sources:

Local Button
Schedule
Presence
Weather
Security
BMS

If they all control the same output, the integrator should define the priority.

For example:

SAFETY / PROTECTION
        ↓
MANUAL OVERRIDE
        ↓
CENTRAL COMMAND
        ↓
AUTOMATIC LOGIC
        ↓
DEFAULT STATE

The actual priority hierarchy must be defined by the project’s functional specification; it should not be assumed universally.

---

7. Practical KNX Automation Examples

Example 1: Corridor Lighting

Requirement:

Turn corridor lights ON when motion is detected and the area is dark. Keep them ON for five minutes after the last movement.

Logic:

Motion
   │
   ▼
Lux < 200?
   │
   ▼
   AND
   │
   ▼
Light ON
   │
   ▼
5 min OFF-delay
   │
   ▼
Light OFF

Possible Group Addresses:

2/1/1  Corridor Motion
2/1/2  Corridor Lux
2/1/3  Corridor Light Command
2/1/4  Corridor Light Status

---

Example 2: Bathroom Exhaust Fan

Requirement:

Start exhaust when humidity exceeds 70% and continue operating for five minutes after humidity falls below the threshold.

Logic:

Humidity > 70%
      │
      ▼
   Fan ON
      │
      ▼
Humidity < defined OFF threshold
      │
      ▼
  5 min delay
      │
      ▼
   Fan OFF

Using separate ON and OFF thresholds can prevent rapid cycling around one value.

---

Example 3: Conference Room AV and Lighting

Requirement:

When a conference room is occupied, enable presentation lighting. When the room becomes unoccupied, switch the presentation state back after a delay.

Presence
   │
   ▼
Occupied?
   │
   ▼
Presentation Mode
   │
   ├── Lighting Scene
   ├── Blinds Position
   └── AV Control

When the room becomes unoccupied:

No Presence
    │
    ▼
15 min timer
    │
    ▼
Room Shutdown
    │
    ├── Lights OFF
    ├── AV OFF
    └── Blinds → defined position

This is an example where KNX logic can coordinate several building systems rather than simply controlling one actuator channel.

---

Example 4: Exterior Lighting

Requirement:

Exterior lighting should turn ON when it is dark, but only during the permitted time period.

Lux < Threshold
       │
       ▼
     AND
       ▲
       │
Time Window
       │
       ▼
Exterior Lights ON

The logic could be expanded:

Lux Low
   AND
Time Valid
   AND
Building Occupied
   AND
No Maintenance Lock
        │
        ▼
Exterior Lighting ON

---

Example 5: Window-Based HVAC Interlock

Requirement:

When a window is open, prevent normal heating or cooling operation in that room.

Window Open
     │
     ▼
Interlock
     │
     ├── Heating → Block / defined state
     └── Cooling → Block / defined state

When the window closes:

Window Closed
     │
     ▼
Normal HVAC Control

The exact implementation depends on the HVAC actuator/controller and its supported objects and priority functions.

---

8. KNX Logic Architecture: Where Should Logic Live?

There is no single universal location for all KNX logic.

Logic can be distributed across different devices depending on project requirements and manufacturer application programs.

1. Sensor with integrated logic

Some sensors provide internal logic functions.

Advantages:

• Simple
• No separate logic device
• Useful for local functions

Limitation:

• Logic is tied to that device’s capabilities.

2. Actuator with integrated logic

Some actuators include logic, timers, thresholds or scenes.

This can be useful when the logic is closely associated with the output.

3. Dedicated KNX logic module

A dedicated logic module can centralise reusable logic.

Sensors
   │
   ▼
KNX Bus
   │
   ▼
Logic Module
   │
   ▼
KNX Bus
   │
   ▼
Actuators

KNX Association’s current Logic Module example provides multiple channels with Boolean operations and configurable inputs/outputs, illustrating the type of dedicated processing available in KNX.

4. Logic controller

More advanced projects may use a dedicated logic controller.

For example, KNX-certified controllers can provide extensive logic editing, simulation and large numbers of logic elements.

5. Visualization / automation controller

A higher-level controller may coordinate KNX with:

• HVAC
• AV
• Security
• Energy monitoring
• Third-party systems
• Schedules
• Databases
• APIs

This can be appropriate for complex buildings, but the KNX architecture should remain understandable even if the higher-level controller is unavailable.

Design principle

Do not put all project logic into one device simply because it is technically possible.

Consider:

• Reliability
• Maintainability
• Commissioning
• Device replacement
• Project documentation
• Network dependency
• Failure modes
• Future expansion

---

9. Logic Troubleshooting in ETS

Logic problems can be difficult because the physical devices may be working perfectly.

The problem may be in the decision chain.

Use a structured approach.

Step 1 – Verify the trigger

Example:

Did the presence sensor actually transmit?

Check the Group Monitor.

Step 2 – Verify each condition

For:

Presence
AND
Lux < 300
AND
Occupied Mode

check each input individually.

Presence = TRUE       ✓
Lux = 180             ✓
Occupied = FALSE      ✗

The logic is therefore correctly preventing the output.

Step 3 – Check the logic output

If all inputs are correct but no command is generated, inspect the logic device.

Step 4 – Check the output Group Address

Confirm that the logic output is linked to the correct Group Address and receiving objects.

Step 5 – Check competing writers

A correct automation command may immediately be overwritten.

Logic → Light ON
          │
          ▼
     Light ON

Schedule → Light OFF
          │
          ▼
     Light OFF

The user may therefore conclude that the logic is broken when another automation is actually writing to the same address.

Step 6 – Check timing

Timers create another common source of confusion.

Trigger received
      │
      ▼
10-minute timer
      │
      ▼
Output later

Always determine whether the expected action is:

• Immediate
• Delayed
• Retriggered
• Periodic
• Dependent on another event

ETS provides Bus Monitor and Group Monitor functions that can be used during commissioning and diagnosis, including filtering and recording telegrams for analysis.

---

10. KNX Logic Design & Commissioning Checklist

Functional design

• Every automation has a defined objective.
• Trigger is identified.
• Conditions are documented.
• Action is documented.
• Reset behaviour is defined.
• Manual override behaviour is defined.

Logic

• AND/OR/NOT logic verified.
• Thresholds documented.
• Hysteresis considered where required.
• Interlocks identified.
• Priority between command sources defined.

Timers

• ON delay defined where required.
• OFF delay defined where required.
• Pulse duration defined.
• Retrigger behaviour tested.
• Restart behaviour tested after device reset.

Group Addresses

• Logic inputs have clear Group Addresses.
• Logic outputs have clear Group Addresses.
• Command and feedback are separated.
• Unnecessary multiple writers are avoided.
• Naming follows project convention.

Commissioning

• Trigger tested.
• Each condition tested independently.
• Logic output verified.
• Receiving actuator verified.
• Timer behaviour verified.
• Interlock behaviour verified.
• Manual override tested.
• Competing automation sources tested.
• Failure/restart behaviour tested.
• Final logic documented.

---

Practical Logic Documentation Example

A professional integrator should ideally document automation in a format similar to this:

Function	Trigger	Conditions	Action	Timer	Priority
Corridor Light	Motion	Lux < 200 lx	Light ON	5 min OFF	Normal
Exhaust Fan	Humidity	RH > 70%	Fan ON	5 min OFF	Normal
Exterior Light	Time/Lux	Dark + valid time	Light ON	Schedule	Normal
Window HVAC	Window	Window Open	HVAC restricted	None	High
Away Mode	User command	Away enabled	Building shutdown sequence	Project-defined	High
Weather Protection	Weather	Wind threshold	Blinds safe position	Project-defined	High

This table becomes extremely useful during:

• ETS programming
• FAT
• SAT
• Troubleshooting
• Handover
• Future modifications

---

The Most Important KNX Logic Design Principle

A common mistake is to start programming logic directly in ETS without first defining the control sequence.

Instead, define the function in plain language:

When X happens, check Y and Z. If all required conditions are satisfied, perform A. Keep A active for B minutes. If condition C occurs, override or cancel A.

Then translate it into KNX:

EVENT
  ↓
INPUT GROUP OBJECTS
  ↓
LOGIC
  ↓
TIMER / COMPARATOR / INTERLOCK
  ↓
OUTPUT GROUP OBJECT
  ↓
ACTUATOR
  ↓
STATUS FEEDBACK

This approach makes the automation easier to program, test and maintain.

---

Conclusion

KNX logic is the layer that turns individual KNX devices into an intelligent building automation system.

The fundamental structure is simple:

Trigger → Conditions → Logic → Timer/Priority → Action → Feedback

From a simple corridor light to a complete building operating mode, the same design methodology can be applied.

The most important practices for KNX integrators are:

1. Define the functional sequence before programming.
2. Separate triggers, conditions and actions.
3. Use AND/OR/NOT and comparison functions deliberately.
4. Use timers for controlled delays and occupancy functions.
5. Use thresholds and hysteresis carefully for analogue values.
6. Define interlocks and command priorities explicitly.
7. Avoid unnecessary multiple writers to the same Group Address.
8. Keep logic documented outside the device parameters.
9. Test each input and logic stage independently during commissioning.
10. Use ETS Group Monitor/Bus Monitor to prove what is actually happening on the KNX bus.

ETS remains the engineering environment for configuring KNX devices, group addresses and system interactions, while the actual logic capabilities depend on the selected KNX devices and their application programs.

For larger projects, good logic design is not about creating the most complicated automation. It is about creating predictable, testable and maintainable behaviour.