Visualisation Systems - KNX

Visualisation Systems 

KNX Association

KNX ADVANCED COURSE 

Table of Contents 

1 Visualisation systems .................................................................................................3 

1.1 General ..............................................................................................................3 

1.2 Requirements for a Central Display ....................................................................4 

1.3 Terms .................................................................................................................4 

1.3.1 The term ‘visualisation’: ..................................................................................4 

1.3.2 The term “Data Point” .....................................................................................5 

1.3.3 The term “Process point” ................................................................................5 

1.3.4 Static Images..................................................................................................5 

1.3.5 Dynamic Image Elements (Variables).............................................................6 

1.4 Transfer of the KNX Project Design Data ...........................................................8 

1.5 Notes for Recording the Status with the Visualisation ........................................8 

1.6 Notes for Starting the Visualisation.....................................................................9 

1.7 Connection of the Visualisation to the Bus System .............................................9 

1.7.1 Direct connection via hardware interface ........................................................9 

1.7.2 Indirect connection via gateway (Hardware) or server (Software, e.g. OPC 

server) ..................................................................................................................... 10 

1.7.3 Direct access to a KNXnet/IP-Server ............................................................ 12 

1.8 Exporting project data: Support by ETS ........................................................... 15 

1.9 Physical access point in the Bus System .......................................................... 16 

1.10 Telegrams sent across Lines/Areas ................................................................. 17 

1.10.1 Enabling the Filter Table ........................................................................... 17 

1.10.2 Correcting the Filter Table via Dummy Devices ........................................ 18 

1.11 Types of Bus Communication ........................................................................... 19 

1.11.1 Program start up: ...................................................................................... 19 

1.11.2 Normal operation condition ....................................................................... 19 

1.11.3 Data Recording Modes ............................................................................. 21 

1.11.4 Summary of Bus Access ........................................................................... 21 

Home and Building Management Systems 

KNX Association 

Visualisation Systems Visualisation Systems_E0905b 2/21


1 Visualisation systems 

1.1 General 

A KNX installation naturally has a distributed structure in which all the devices 

communicate with each other when required. It is not necessary to control them centrally. 

Nevertheless, this technology provides the opportunity of establishing control stations 

which represent all the functions in graphical format both as remote operating 

elements and display symbols. 

Figure 1: Example of an installation with various input - and output variables 





1.2 Requirements for a Central Display 

The operator would like to be able to detect from a central location whether e.g.: 

Lights are still switched on somewhere, although they should be turned off already, 

Blinds are still closed somewhere, although they should have been retracted already 

Windows or doors are open which would cause problems with security 

So generally said: The operator would like to have collective status messages of 

certain groups of functions or devices 

He would further like to know exactly the place in which building/floor/room the light is 

still switched on and would like to be able to switch it off from a central location. 

When monitoring building services systems, the operator would like to know whether 

alarms or faults are present 

the images of integrated video cameras are shown 

the current status of consumption/metering statistics is shown 

in which part of the building a displayed fault is located 

and when the defect occurred 

Beyond these requirements more and more users demand to have the operational data 

displayed independent from location or hard- / software platforms (e.g. Type of PC and 

OS). If such requirements are fulfilled, service providers can take over the buildings 

management’s tasks for cost optimization sake, who don’t have to be onsite all the time. 

Platform independence – however – also means that the original data have to be 

available in a format that allows various communication channels and pc-environments to 

be used! 

1.3 Terms 

1.3.1 The term ‘visualisation’: 

Visualisation is the representation of states (observation) and the selection of states 

(operation). In building automation technology, this is generally understood to be a 

software package which can be assigned parameters relatively easily and can be 

implemented on a mini computer. The term ‘mini computer’ covers PCs but also CPUs 

which have been prepared for this special task. In the widest sense, you can also 

designate miniature panels as depicted here as ‘visualisation terminals’. To save space 

and time we but wish to limit the description to a visualisation system designated to run on 

a PC. Many of the statements made here however also apply to the operation of panel 

units. 

Figure 2: Visualisation terminal as a display and operation element for KNX 





1.3.2 The term “Data Point” 

The format of information that is to be displayed (=Data Point Type in ETS3) is set with 

the data point. That does not only include the value of a function, but comprises also its 

further interpretation. E.g. a 2-Byte value, which originally is just a hexadecimal figure, 

could be an unsigned integer, a signed integer, or a floating point value. Beyond this units 

can be declared (like “Lux”, “°C” or the like), or so called status texts (mainly used for 

binaries, like “On”, “Off” instead of 0 / 1), which describe the value better for the user. 

So a “data point” is nothing else but a template, which is put on a value to make it 

readable in a display or a monitor. It describes a class of different values which have the 

same format in common. 

1.3.3 The term “Process point” 

The process point is the ‘interface’ between the information for display/selection and their 

graphical representation on the screen, i.e., the display type of a certain value. The term 

“process point” unfortunately is not known too well – most people use always “data point” 

and mean a process point. But this is not very practicable, because confusion is usually 

the result, and you lose one layer of definitions, which ensures a better category 

assignment of the data. 

A process point is based on a certain data point type. It however adds important 

information which may not be neglected in order to display and use it in the proper way: 

Which group address “carries” the information? (There can be more than one, in case 

a bus device doesn’t have a status object all group addresses assigned to e.g. a 

switching object must also be known to the process point, that it always displays the 

correct status). 

Is a value only used for display, or also for control? (“Transmit Flag”). 

Which user level may have access for read only, or read / write? (= Lights should be 

switched on and not only be displayed) 

Which additional tasks have to be carried out with the values of this process point? 

(Save data cyclically in a “value data base”, create event messages, alarms, start 

another display page on a certain condition, mandatory confirmation of an alarm etc.) 

1.3.4 Static Images 

As a visual aid for the user of the visualisation program, static background images can be 

created or imported which e.g. show the ground plan of the visualised area or enable a 

3D representation of the room. 

Current states cannot be indicated using a static background image. 





1.3.5 Dynamic Image Elements (Variables) 

Using dynamic image elements or variables, the required information/states can be 

displayed on the screen. 

Figure 3: Appearance possibilities of image variables 

The appearance of an image variable is modified depending on the process state (shape, 

colour, text, flashing, etc.). Switching and positioning commands can be preselected on 

the bus. A range of predefined types of variables are available for selection. The 

individual types can be freely positioned on the screen and overlay part of the static 

background image. The appearance, colour, function etc. are set via the parameters. The 

size can be changed in the usual way by dragging the image. A process point must be 

assigned to each variable which is allocated from the list of process points using ‘drag 

and drop’. 

Simple visualisation packages don’t provide “data points” or “process points” as separate 

items, but include it all in the image variables. In this situation it is quite easy and quick for 

the user to assign group addresses, activate the “switchable” function (=activate “send 

flag”), set up the display format, units etc, but since this needs to be done from scratch 

again and again, it is only acceptable in smaller projects, not in large ones. 

The characteristics of high performance visualisation software packages include: 

one central or several networked visualisation/operator terminals 

the generation and parameterisation of the process points for display, 

the reading in of images as pixel or vector graphics, 

an integrated image editor for vector graphics with a macro library, 

various dynamic picture elements (variables) for the display of current states, values, 

information, 

the printing of event, overview and parameter logs as well as colour screenshots, 

display, operation and logging, in several languages 

powerful additional functions such as statistical functions, Internet ISDN connections, 

event and timer programs. 





Figure 4: Screen image from an industrial application: various, freely selectable, graphical 

and numerical representations of the same process point. The data in the lower graphic can 

also be recorded and evaluated over longer periods 

Figure 5: Picture from a home application: user-friendly, clear layout but predefined operator 

and display functions 





1.4 Transfer of the KNX Project Design Data 

The assignment of group addresses to sensors and actuators is carried out when 

designing an installation using Engineering Tool Software (ETS). 

The data that has been configured in ETS can in many cases be directly transferred by 

the visualisation program. The following data is transferred: 

• Existing bus devices and their comments 

• Existing objects and their settings 

• Configured group addresses and their comments 

A further possibility of transferring the functionality of the bus devices is to read out the 

existing bus devices directly from the bus system. You will, however, only receive the 

numerical structure of the addresses and their data field width and no text descriptions. 

The group addresses can also always be entered manually, if no data interface between 

ETS and the software exists. 

Visualisierung Visualisation –- Structured Strukturiertes Project Design 

P j kti 

Einheitstexte Unit text 

Zustandstexte 

Status text 

Hinweistexte Notes 

DPT EIS-Typ type 

Datenpunkt Data point 

Eigenschaften 

Properties 

Group Gruppenadressen 

addresses 

Prozeßpunkt 

Process point 

Flankenauswertung 

Edge evaluation 

Image Bildvariablen variables 

Figure 6: Structured Project Design 

1.5 Notes for Recording the Status with the Visualisation 

The states that should be recorded in a KNX installation are detected by the visualisation 

through listening into the bus telegrams. In some bus devices, it is possible however to 

carry out a switching operation not directly with a telegram but to start periods which 

trigger switching operations with a delay or via a logic operation with other states. This 

means that the telegram cannot be used in these cases as a status image. In specific 

applications, additional ‘status objects’ are therefore available in which the current 

switching state is mirrored. If these objects do not transmit by themselves, they must be 

read out cyclically by the visualisation software via read requests. 

Note: The read flag must be set in the status object so that the bus device responds to 

the read request. 





1.6 Notes for Starting the Visualisation 

As already mentioned above, the visualisation receives its information during operation 

from the bus devices by listening to the relevant telegrams on the bus. 

After a restart of the visualisation program e.g. after a voltage drop, it must ‘query’ the 

current states of the bus devices as they are only updated in the visualisation after a 

corresponding telegram on the bus. This interrogation of the states is carried out 

automatically once the visualisation is started up i.e. the states of all the bus devices are 

read out gradually. 

To do so, the read flag must however be set in the corresponding object of the bus device 

and the group address entered in the process point must be defined as a ‘sending group 

address’ in the object. This address thereby becomes ‘readable’ and the visualisation 

knows which object must be read out in which bus device when updating the process 

point. 

Several group addresses can be linked in a process point – similar to a device object. It 

now depends on the correct setting of the process point whether it has been initialised 

correctly after start-up. It can be problematic if several group addresses are set as 

readable and indicate a different state. This means that the process point always accepts 

the status of the last group address in the process point that was allocated as ‘readable’ 

using the ‘equivalence’-processing processing rule. In the event of a logic operation, the 

result of the OR or AND function is indicated via all readable groups – which may not 

always be correct. 

A central address or an address that is used by several bus devices may never be 

implemented as a sending group address in the objects of the bus devices. The response 

telegram as the result of a read request will be interpreted as a normal write telegram at 

least by all affected mask 1.x bus couplers, but all the other bus coupler types can be set 

up accordingly, when the “Update-Flag” is set. So the response telegram, using by 

coincidence a central function group address, will switch lights or move blinds although 

this was never intended to! 

1.7 Connection of the Visualisation to the Bus System 

The PC on which the visualisation program is installed can be connected to the KNX 

system in various ways. 

1.7.1 Direct connection via hardware interface 

In small or medium systems even today a direct interface is preferred, especially, if only a 

“KNX” – system exists as stand alone, and no other data interface, e.g. to a overhead 

building control system is required. In order to perform that type of coupling, just a data 

interface must be used which is supported by the visualisation package in question. This 

may be today RS 232, FT 1.2, USB, UDP/IP or TCP/IP – protocol based interfaces. 





1.7.2 Indirect connection via gateway (Hardware) or server (Software, e.g. OPC 

server) 

Large installations usually operate on an overhead building management or - control 

system (BMS). On the field level always several different buses exist. So the BMS should 

collect the data of all these dependent partial system. Two possible solutions are known 

today: 

1.7.2.1 Connection via gateway 

In this case the visualization will still be connected directly (by hardware) on the BMS. The 

BMS on the other hand uses protocol converters (Gateways) to read or control data from / 

to the dependent field level systems. 

1.7.2.2 Connection via OPC server 

In OPC – in contrary to direct connection – each bus segment provides the necessary 

data on a server. The format of the data follows the definitions of the OPC foundation 

(OPC = Object linking and embedding for process control). So there are as many OPC 

servers as bus systems in one installation. But the BMS draws a big advantage from the 

fact that all data exist in the same format on OPC servers! Now a parallel access to all 

these different servers via the local data network is possible, which is usually Ethernet 

communication (TCP/IP or UDP/IP). The OPC server itself is nothing else but a software 

for data transfer, intermediate saving (buffering the process image) and if necessary 

conversion. According to the OPC specification it is also defined, that an OPC server 

must be multi client capable, i.e., it can be accessed simultaneously by multiple 

monitoring stations. 

The OPC server runs regularly on any standard PC (but should better be implemented on 

a real server workstation, due to higher endurance quality), but it can also be 

implemented (embedded) in specific hardware. Even an OPC server after all needs to 

have a direct data access point to the bus. This again can be one of the kinds already 

stated above in 1.7.1 (direct connection). 

An embedded OPC server combines hardware interface and server software, and offers 

the advantage of a higher reliability compared to a PC, consuming less power, due to 

having no moving mechanical parts, and serving for only one single task, the risk of a 

crash can be neglected. 

The advantage of an OPC server in general is – the process image of the bus installation 

is stored in its memory, and is always up to date, even, if the monitoring system of the 

BMS may be temporarily out of service. The restart of the monitoring system will be much 

faster than with direct bus access at a speed of not more than 9,6 Kbit/s! 





Figure 7: OPC server operation concept 

1.7.2.3 Example 1: The KNX - OPC-Server 

More or less manufacturer independent, KNX Association offers an OPC server for the 

KNX connection. This server is optimized for the use in the KNX world. What matters in a 

decentralised system like KNX is, that all process points must be completely mirrored, 

i.e., they must be linked to all group addresses which control the same output, or come 

from the same physical value. By far not all OPC servers have this feature! Further on the 

start-up behaviour as stated above in 1.6 must be heeded and correctly configured. When 

restarting a visualisation it is recommended not to overload the bus by too many read 

telegrams, but nevertheless trying to update the process points on the monitor as fast as 

possible. This is provided by the server. An additional service is the “life check” of the bus 

devices (not a normal OPC standard , but KNX – specific!). 

Figure 8: Configuration- and test interface of the KNX-OPC-server 





Figure 9: Configuration parameters of the KNX-OPC-server: Here mainly the update speed 

after restart (initial read) and during normal operation (read speed) is specified. 

Figure 10: Busmonitor (simple structure) provided by the OPC server 

1.7.3 Direct access to a KNXnet/IP-Server 

With the introduction of the new KNXnet/IP specification from now on we also have the 

possibility of location independent KNX network access via Ethernet. In this case the 

access point to the KNX network is a KNXnet/IP capable device, e.g. a so called IP 

router. Three core services are defined to connect a KNXnet/IP visualization to the bus: 

a) Routing service 

b) Tunnelling service 

c) Object service 

These services distinguish themselves as follows: 

“Routing” is nothing else but a line coupler’s function, transferred to Ethernet. The group 

address filter tables of the IP Routers are activated, and rule the data exchange between 

the KNX-TP1 (bus) side and the LAN. On the LAN level all IP routers and also the 

visualisation servers communicate via a common so called IP multicast address. Its 

notation reads like all other IP addresses. The address 223.12.0.13 is worldwide 

published and standardized as the default KNX-Multicast address. That means, this 





address is basically blocked in all LAN routers worldwide, in order to avoid unintended 

broadcasting of KNX protocols. As long as all “members” of the same shared multicast 

address remain in the same IP subnetwork, they will simultaneously read all messages 

(=datagrams), like line couplers do it from the main or area line. Advantage of the routing 

service: The server can act like another IP router in the network, it can send datagram 

without special dedication, because they are filtered as appropriate by the IP routers. 

Disadvantage: The data load on Ethernet is higher, because the datagrams must be 

forwarded to all IP routers of the same group. 

“Tunnelling” is the direct access to an IP gateway (or router). In this mode filter tables are 

ignored; the bustelegrams are literally “tunnelled” through the filtertable of the router. The 

advantage: you can use all group addresses, even, if the filter tables have not been set 

up correctly. The data load on Ethernet is less than with routing. Disadvantage: Only one 

line can be accessed by a single UDP datagram from the server. 

“Objectservermode” means finally, that the IP visualisation server is connected to an 

application device with normal bus communication objects, which also has a LAN 

connection on the other side. One could call it routing plus tunnelling at the same time, 

because only the specifically group addresses used by the device will work – in both 

directions. 

1.7.3.1 Example 2: IP-Visualisation via IP-Process-Server 

Figure 11: Configuration manager of an IP visualisation: Here all three core services can be 

used simultaneously 





Figure 12: Configuration tool of a simple table style web based monitoring – and operation 

software 

Figure 13: The result when activating the configuration shown in the previous picture. A 

platform independent web page which can be operated under any standard web browser 





1.8 Exporting project data: Support by ETS 

To get the necessary group address data from ETS into the visualisation, a special data 

export function is provided by ETS. Only groups are not sufficient information – you’ll 

need also the information about the assigned data point format (the DPT’s, mentioned in 

1.3.2). In addition to this minimum information it is recommended to have knowledge 

about the active communication flags of the objects being assigned to the group 

addresses. Only with that knowledge a visualisation can decide immediately which data 

points are readable, and which are not (e.g. for cyclic update services). Presently ETS 

doesn’t export these additional data. 

Figure 14: OPC data export file from ETS 

The following table is exported by this function: 





1.9 Physical access point in the Bus System 

In principle, the visualisation can be connected at any point in the bus system, no matter 

what type of coupling is chosen (OPC, KNXnet/IP or direct). In view of good bus 

dynamics, particularly in larger bus systems, it is however a good idea to consider the 

suggested access point places. 

If the bus system only consists of a line, the visualisation is of course connected here. 

If the bus system consists of several lines, it is advisable to connect the visualisation to 

the main line, to enable optimum access to all lines: 

Main line 

EDI 

LC 1 

LC n 

Visualisation 

DVC 1 

DVC 1 

Line 1 

DVC 64 

Line n 

DVC 64 

1 < n < 16 

Figure 15: Optimal physical access point when there is one area with several lines 

EDI: Electronic data interface; e.g. USB 

If several areas are used, the visualisation is best connected to the backbone line. It is 

thus guaranteed that the information from the various areas and lines can reach the 

visualisation using the shortest route. 

Backbone line 

EDI 

BC 1 

Visualisation 

Main line 

LC 1 

LC n 

DVC 1 DVC 1 

1 < n < 16 

Line 1 

DVC 64 DVC 64 

Line n 

BC 

LC 

DVC 

= Backbone coupler 

= Line coupler 

= Bus device 

Figure 16: Optimal physical access point when there are several areas 

EDI: Electronic data interface; e.g. USB 





1.10 Telegrams sent across Lines/Areas 

If information across lines or areas should be processed by the visualisation or if 

commands from the visualisation are generated on other lines or areas, the behaviour of 

the coupler must be taken into account: 

Each line/backbone coupler has a filter table which contains the information as to whether 

a global telegram is required in its line (area) or whether a local telegram is also required 

outside its line (area). 

This filter table is created by the ETS program in the course of the project design. 

The visualisation is however not taken into account by ETS and this information is 

therefore omitted. But a visualisation can be considered to be a very complex bus device 

with plenty of group addresses. 

There are therefore two different options for preparing the couplers for use with a 

visualisation: 

1.10.1 Enabling the Filter Table 

The behaviour of the filter table is set separately per direction for each coupler via the 

parameter list: 

Direction of primary line ↔ secondary line: 

Block (no telegrams are routed) 

Enable (all telegrams are routed) 

Normal (filter table decides whether telegrams are routed) 

The first step is to consider in detail the route of each telegram which should be taken into 

account by the visualisation or sent by the visualisation to the bus devices. 

Using ETS, the filter table should then be enabled in the relevant coupler for the 

corresponding direction and the program should be reloaded. 

By enabling the filter table, all the telegrams are routed in the appropriate direction. This 

will have a negative influence on the bus dynamics in larger installations, primarily, if a 

large number of central functions and control systems have been configured. This 

possibility is only available in installations where the enabling of the filter tables does not 

lead to the overloading of individual lines. As the determination of the actual bus load in 

enabled filter tables can only be carried out manually and is very time-consuming, the 

filter tables should generally be used. 





1.10.2 Correcting the Filter Table via Dummy Devices 

To enable the ETS program to consider the visualisation when creating the filter table, 

dummy devices should be configured on the line where the visualisation accesses the 

bus. All the group addresses must be entered in these devices which the visualisation 

listens to or sends. 

Specially developed applications are available as dummy devices which have been 

included by several manufacturers in their product databases. These dummy devices 

have the advantage that any data point types can be set and up to 500 group addresses 

can be linked in one dummy. Only the communication flag and the write flag may be set 

for the objects as otherwise – in case of automated data transfer from ETS to 

visualisation - the program later attempts to access such groups although their flags do 

not really exist as found in the dummy. 

Figure 17: Parameters and objects of the dummy application 





After extending the project by the dummy devices using ETS, the filter tables of all 

affected couplers must now be reloaded. 

The dummy devices are only used to recognize the visualisation settings when creating 

the filter table. 

These devices do not need to and cannot be put into operation. 

If neither option is implemented, telegrams that are required by the visualisation for status 

display may not be routed to the line in which the visualisation is installed or a command 

telegram is not routed to the line in which the target actuator is located. 

1.11 Types of Bus Communication 

1.11.1 Program start up: 

When starting the program, basically all groups should be read out, beside those which 

are not set as “readable”. It thus depends on a well settled ETS project, if the images and 

information display works correctly. Read flags may be set only once per group address, 

only in this case it is guaranteed, that the read telegrams will trigger exactly one response 

telegram upon start up. In general, the status objects are to be connected to the 

visualisation, because they are the only objects which always guarantee a correct display. 

Switch or value objects can send wrong values, depending on the parameter settings. 

Figure 18: General strategy to read status information 

1.11.2 Normal operation condition 

During the normal operation period, the process image is already stabilized, and only few 

changes take effect now and then. It is now important to verify such changes of process 

points immediately. Three strategies are possible in this situation: 

a) permanent listening into the bus: all display relevant telegrams are also routed to 

the visualisation. 

b) Read back after transmitting: a sent telegram is verified as soon as it was sent as 

the visualisation sends a read telegram to collect the new status of the controlled 

channel (a method which becomes more and more obsolete which automatic 

responding status objects) 





Figure 19: Behaviour in transient condition: specific process points are checked for their 

actual state once a telegram is sent, if the status does not respond automatically 

c) cyclic read back: this method to keep status information as current as possible is 

only used, if on the one hand the status objects cannot send changes back on 

their own, or on the other hand an automatic status transmission on change would 

lead to an unacceptable high busload. Examples for such kind of devices are 

operational hours counter. They usually count in a second ‘s resolution. If they 

would send a telegram on each value change, the bus’ data capacity would be 

used up literally in a minute! To avoid this, the visualisation can do a cyclical 

update of these values, e.g. every 120 seconds. 

Figure 20: Specific picture elements are updated at defined intervals 





1.11.3 Data Recording Modes 

Visualizations are nor only used for current operations such as display changes and 

operate functions, but mainly for data tracking. So the operator later can analyse very 

verbosely how the user behaviours have been, the consumption of the resources versus 

the users, and many more things (Operation statistics). It is also possible to draw 

decisions on the maintenance activities and schedules. 

Figure 21: The events that are to be logged can be stored in various databases and 

evaluated at a later date. A direct online output can be carried out on the logging printer. 

1.11.4 Summary of Bus Access 

Figure 22: Summarized graphic showing all possible communication modes between a 

visualisation and the bus devices

Visualisation Systems - KNX

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?