DE102015218029B4 - Method for operating a bus device - Google Patents

Abstract

Method for operating a KNX bus device (G1, G2) of a KNX bus-oriented programmable electrical installation (GBS), the KNX bus device (G1, G2) comprising a processor (MK) and a memory (SP), the KNX bus device (G1, G2) realizes a first functionality assigned to the KNX bus device (G1, G2), the KNX bus device (G1, G2) realizing a second functionality assigned to the KNX bus device (G1, G2) if a first one is present defined event, activation of the first functionality is blocked for a user, and the KNX bus device (G1, G2) then executes the second functionality, with a reason for executing the second functionality being detected by means of a problem identification function module.

Description

The invention relates to a method for operating a bus device of a bus-oriented programmable electrical installation. The invention further relates to bus devices suitable for carrying out the method. The invention further relates to a computer program for operating a bus device of a bus-oriented programmable electrical installation and a computer-readable medium which has commands that can be executed on a computer for operating a bus device of a bus-oriented programmable electrical installation.

In order to enable simple and convenient operation of the various bus devices in modern buildings or houses, they can be controlled via an installation bus. Such an installation bus is, for example, the European installation bus (EIB), which is described in the KNX standard.

A building installation device makes it possible to control individual building installations, such as a lamp or a radiator, individually according to a predetermined operating plan by providing a bus device to each building installation, which controls the respective building installation, for example automatically switching a lamp on and off or a Adjusts the thermostat of a radiator. The bus devices can be connected to each other and also to a central configuration device via a building installation bus, so that the devices can exchange data with one another and the bus devices can be configured or reconfigured centrally via the configuration device. The data exchanged between the bus devices can be, for example, sensor data or control data.

The underlying bus system is based on the fact that each bus participant has its own microprocessor and therefore manages its data independently and independently of a central processor. An application program with communication objects and parameters is assigned to each bus participant. When putting such a bus system into operation, the communication relationships between the bus participants must be configured. In the case of the KNX bus, the engineering tool software (ETS) is often used. This is software that runs on a PC or laptop and is connected to the bus. Some possible types of connections are RS232, USB, radio or Ethernet. The ETS is a database-based graphic tool for planning a bus-oriented programmable electrical installation. The configuration data for each individual bus participant or each individual application program is stored in the ETS database.

Complex functionalities are integrated into today's KNX bus devices. This means that it is not easy for the customer (installer or end user) to determine why something in the bus-oriented programmable electrical installation does not work as expected.

Example: A blind actuator supports, for example, automatic opening in the event of a wind alarm and a movement lock during cleaning work. If the user now wants to operate the blind and it doesn't work, he will not receive any information as to whether, for example, a wind alarm has been reported or what else the problem is. In the case of the wind alarm, it is also possible that there is no wind blowing, but the wind sensor has failed. In this case, the blinds move up and can no longer be operated. In this case, it is not easy for even the installer to determine the cause.

It reveals the DE 103 12 183 A1 a building installation system. Furthermore, the reveals DE 196 05 698 C1 a connection device for an electrical installation system. Furthermore, the reveals EP 1 717 410 A2 a procedure to prevent damage to hangings. Finally, the manual “ELSO Electronics and Systems Blind Management for More Comfort and Safety”, Schneider Electric, 03-2012, discloses an electrical installation for a blind control.

There is no solution that is acceptable to the customer. If the problem persists, an installer must appear on site and use appropriate diagnostic tools to locate the fault. This is complex and costly.

It is therefore the object of the present invention to provide a method for operating a bus device of a bus-oriented programmable electrical installation, which enables simple problem or error identification in a bus device.

The object is achieved by a method for operating a bus device of a bus-oriented programmable electrical installation, the bus device comprising a processor and a memory, the bus device being set up to implement a first functionality assigned to the bus device; wherein the bus device is set up to implement a second functionality assigned to the bus device, with the activation of the first functionality being blocked for a user in the presence of a first defined event and the bus device executing the second functionality. Functional modules can therefore be expanded to include functionality that, for example, allows the reason for a “malfunction” to be detected.

Such extended functional modules for problem identification have a “normal” and one (or more) “superordinate” functionality(s). Normal functionality consists of forwarding commands or performing normal processing. The “parent” functionality is functionality that has higher priority over a user action. If the bus device is in “superior functionality” mode, operation by the user has no effect because this is suppressed by the “superior functionality”. A functionality assigned to the bus device is advantageously implemented by the application program loaded onto the bus device. Bus devices can be actuators, sensors or controllers (only have processing logic). The method according to the invention can be used, for example, as a diagnostic interface or diagnostic method for KNX products.

A first advantageous embodiment of the invention is that the bus device is set up to implement a third functionality assigned to the bus device, with the activation of the second functionality being blocked in the presence of a second defined event and the bus device executing the third functionality. In principle, any number of levels of functionality can be implemented, i.e. the prioritization hierarchy of functions is in principle not limited. For example, if a third defined event occurs, activation of the third functionality can be blocked and the bus device can execute a defined fourth functionality. And so forth.

A further advantageous embodiment of the invention is that each functionality is assigned a unique identifier, which can be forwarded to other devices via an interface. Thanks to the unique identifier, each functionality can be specifically addressed, queried, automatically sent when changes are made and clearly identifiable. For example, a user can clearly determine which functionality a bus device is currently executing or which functional mode a bus device is currently in. The current functionality or the current functional mode of a bus device can also be queried by other bus devices or by a control center (e.g. building control center). This means that information about the status of the respective functionality is available passively (can be queried through polling) and actively (event-driven).

A further advantageous embodiment of the invention is that each functionality is assigned a unique identifier that can be set on the bus device. This allows a user to set the functionality of the bus device directly on the bus device. If the bus device is, for example, a blind actuator, the functionalities “Automatic wind alarm active” or “Travel protection active” can be set on site on the device, for example using appropriate switches or buttons. The identifier can be queried and/or displayed on the bus device (e.g. on a display or through other suitable display elements (e.g. LED display). The identifier that is to be sent for a higher-level functionality can therefore be set explicitly.

A further advantageous embodiment of the invention is that each functionality is assigned a unique identifier, which can be set via a configuration device (ETS). The identifier can also be set via a configuration device, in the case of KNX bus systems with advantage via an ETS (Engineering Tool Software), and thus the functionality of the respective device can be determined. This means that the identifier can be set and sent or queried when the superimposed functionality is active.

A further advantageous embodiment of the invention is that each functionality is assigned a unique identifier that can be displayed and/or queried on the bus device. This allows a user on site to quickly and easily determine which functional mode a bus device is currently in.

A further advantageous embodiment of the invention is that each functionality is assigned a unique identifier, which is determined and assigned via a central location. The identifiers are advantageously managed in a central database. This central database can be located on a configuration device (e.g. ETS) or on a specific (dedicated) bus device.

A further advantageous embodiment of the invention is that the first functionality assigned to the bus device corresponds to normal operation of the bus device;
wherein the second functionality assigned to the bus device is a first exception functionality for the bus device; and
wherein the third functionality assigned to the bus device is a second exception functionality for the bus device. Exception functionalities can be defined as desired and are advantageously implemented via a corresponding application program in the bus device.

• - Gerätefehler (z.B. Motor ist defekt)
• - manuelle Übersteuerung (z.B. Fensterputzer der die Verfahrsperre aktiviert)
• - automatische Übersteuerung als Ausnahmefunktionalität (bei Sonnenschein: Jalousie unten; bei Wind: Jalousie oben)
• - Betriebssystem-Update (Beispiel für Fehlersuche)
• - Prinzipiell ist die Priorisierungshierarchie der Funktionen nicht beschränkt. Beschränkungen ergeben sich im Prinzip nur durch die Leistungsfähigkeit des Mikrocomputers oder der Speicherkapazität.

Examples of exception functionality can be:

• - Device error (e.g. motor is defective)
• - manual overcontrol (e.g. window cleaner that activates the travel lock)
• - automatic override as an exception functionality (in sunshine: blinds down; in wind: blinds up)
• - Operating system update (example for troubleshooting)
• - In principle, the prioritization hierarchy of functions is not limited. In principle, limitations only arise from the performance of the microcomputer or the storage capacity.

A further advantageous embodiment of the invention is that when the first defined event occurs, activation of the first functionality for a user is also blocked for other bus devices of the same type and these other bus devices execute the second functionality. This makes it possible for bus devices of the same type to be brought into the same functional mode for a defined area (e.g. floor, hallway, stairwell, facade). For example, for window cleaning, the blind actuators in a specific area outside the house can be temporarily switched to the “travel protection active” functional mode.

A further advantageous embodiment of the invention is that when the second defined event occurs, activation of the second functionality for a user is also blocked for other bus devices of the same type and these other bus devices execute the third functionality. This also makes it possible for bus devices of the same type to be brought into the same functional mode for a defined area (e.g. floor, hallway, stairwell, facade).

A further advantageous embodiment of the invention is that on the other bus devices, an identifier assigned to the respective functionality can be set and/or displayed and/or queried on the respective bus device or by a central point (e.g. control center or configuration device (ETS in KNX systems)). is. This means that, for example, for a defined area of a building (e.g. floor, hallway, stairwell, facade), bus devices of the same type can be very easily brought into the same functional mode or, for example, it can be easily checked by visual inspection of the devices which functional mode they are in .

The task is further solved by a computer program for operating a bus device of a bus-oriented programmable electrical installation, with instructions for carrying out the method according to the invention. This means that problem or error identification can be carried out computer-assisted and effectively, for example by a personal computer (PC), in particular by an end customer in the field.

The object is further achieved by a computer-readable medium which has commands that can be executed on a computer for carrying out the method according to the invention for a bus device of a bus-oriented programmable electrical installation.

As a result, the computer program for operating a bus device of a bus-oriented programmable electrical installation can be very easily implemented or installed on a computer (particularly at an end customer in the field).

A further advantageous embodiment of the invention lies in a bus device of a bus-oriented programmable electrical installation, suitable for carrying out the method according to the invention. With such a bus device, an end customer can easily set or query a functional mode in the field.

The task is further solved by a bus device of a bus-oriented programmable electrical installation, the bus device comprising a processor and a memory, and
wherein the bus device is set up to implement a first functionality assigned to the bus device;
wherein the bus device is set up to implement a second functionality assigned to the bus device, with the activation of the first functionality being blocked for a user in the presence of a first defined event and the bus device executing the second functionality. The bus device according to the invention can be designed as an actuator, sensor or controller (essentially only includes processing logic).

A further advantageous embodiment of the invention is that the bus device is set up to implement a third functionality assigned to the bus device, with the activation of the second functionality being blocked in the presence of a second defined event and the bus device executing the third functionality. In principle, the prioritization hierarchy is not limited in terms of the functionality assigned to the bus device.

A further advantageous embodiment of the invention is that the bus device is set up to receive an identifier that is uniquely assigned to a respective functionality from a central device or a configuration device. The central device can be, for example, a dedicated bus device (e.g. controller) or a control center in the building automation system.

• Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die erste dem Busgerät zugeordnete Funktionalität einem normalen Betrieb des Busgerätes entspricht; und wobei es sich bei der zweiten dem Busgerät zugeordneten Funktionalität um eine erste Ausnahmefunktionalität für das Busgerät handelt; wobei es sich bei der dritten dem Busgerät zugeordneten Funktionalität um eine zweite Ausnahmefunktionalität für das Busgerät handelt.

Further advantageous refinements for the bus device according to the invention:

• A further advantageous embodiment of the invention is that the first functionality assigned to the bus device corresponds to normal operation of the bus device; and wherein the second functionality associated with the bus device is a first exception functionality for the bus device; wherein the third functionality assigned to the bus device is a second exception functionality for the bus device.

A further advantageous embodiment of the invention is that each functionality is assigned a unique identifier, and the bus device comprises an interface via which the identifier can be forwarded to other devices.

A further advantageous embodiment of the invention is that each functionality is assigned a unique identifier, and the bus device comprises an output unit for outputting the identifier.

• 1 eine beispielhafte Anordnung für ein Gebäudeautomatisierungssystem mit zwei beispielhaften Busgeräten,
• 2 eine erste beispielhafte Schemadarstellung für ein beispielhaftes Funktionsmodul für einen Jalousieaktor als beispielhaften Busteilnehmer,
• 3 eine zweite beispielhafte Schemadarstellung mit einem Sensor und dem beispielhaften Jalousieaktor gemäss 2 als beispielhafte Busteilnehmer,
• 4 ein beispielhaftes Ablaufdiagramm für ein Verfahren zum Betreiben eines Busgerätes einer busorientierten programmierbaren Elektroinstallation, und
• 5 ein beispielhaftes Objektmodell für eine beispielhafte zentrale Verwaltung von Fehlermeldungen in einer busorientierten programmierbaren Elektroinstallation.

The invention and advantageous embodiments of the present invention are explained using the following figures as examples. Show:

• 1 an exemplary arrangement for a building automation system with two exemplary bus devices,
• 2 a first exemplary schematic representation for an exemplary functional module for a blind actuator as an exemplary bus participant,
• 3 a second exemplary schematic representation with a sensor and the exemplary blind actuator according to 2 as exemplary bus participants,
• 4 an exemplary flowchart for a method for operating a bus device of a bus-oriented programmable electrical installation, and
• 5 an exemplary object model for an exemplary central management of error messages in a bus-oriented programmable electrical installation.

Building installations, in particular electrical installations for controlling light sources, blinds, fans, heaters, alarm systems, etc., are often implemented using standardized bus technology, e.g. with a KNX bus system. With a KNX bus system, operating elements (sensors) and corresponding actuators are connected and controlled in a building. Each participant in such a bus system has its own microprocessor and can therefore manage its data independently and independently of a central processor. For this purpose, an application program with corresponding communication objects and parameters is assigned to each bus device. When commissioning a KNX bus system (or a similar system), the communication relationships and parameters of the bus devices must be configured. The engineering tool software (ETS) is usually used to configure KNX bus systems. The ETS is a database-based graphic tool for planning bus-oriented programmable electrical installations. Using a database, the configuration data, i.e. H. the communication relationships and the device parameters are created separately for each bus device or each application program and then transferred or fed into the bus system and its bus devices via an interface (e.g. USB data interface).

A building installation device makes it possible to control individual building installations, such as a lamp or a radiator, individually according to a predetermined operating plan by providing a bus device to each building installation, which controls the respective building installation, for example automatically switching a lamp on and off or a Adjusts the thermostat of a radiator. The bus devices can be connected to each other and also to a central configuration device via a building installation bus, so that the devices can exchange data with one another and the bus devices can be configured or reconfigured centrally via the configuration device. The data exchanged between the bus devices can be, for example, sensor data or control data.

1 shows an exemplary arrangement for a GBS building automation system based on a bus-oriented programmable electrical installation with two exemplary bus devices G1, G2, which are connected via an installation bus B1, for example a KNX bus. When depicted according to 1 This is only a schematic representation, whereby the size proportions of the elements shown are not shown realistically.

A bus device G1, G2 usually has a processor MK as a control unit, for example a microcontroller. The MK control unit can generate control commands for the connected GBS building installation and/or evaluate sensor data from the GBS building installation. In order to enable the control unit MK to exchange data with the building installation bus B1, a bus device G1, G2 usually has a special connection circuit as a bus coupler BK. This can be, for example, an integrated circuit (IC Integrated Circuit). The connection circuit BK also includes the electrical connections for connecting the bus device G1, G2 to the building installation bus B1.

• - einen RAM-Speicher (Random Access Memory) zum Speichern von Daten, die während des Betriebs anfallen;
• - einen ROM-Speicher (Read Only Memory), in dem z.B. auch individuelle Gerätedaten abgelegt sein können;
• - einen Flash-Speicher (z.B. EEPROM) für die persistente Speicherung der Applikationsprogramme und der dazugehörigen Projektierungsdaten, sowie des Betriebssystems. In einem Teil des Flash-Speichers können auch die individuellen Gerätedaten abgelegt sein.

A processor MK as the control unit of a bus device G1 usually has the following memory types:

• - a RAM memory (random access memory) for storing data generated during operation;
• - a ROM memory (Read Only Memory), in which, for example, individual device data can also be stored;
• - a flash memory (e.g. EEPROM) for the persistent storage of the application programs and the associated configuration data, as well as the operating system. The individual device data can also be stored in part of the flash memory.

In the representation according to 1 the processor MK of the bus device G1 includes an exemplary flash memory SP, particularly suitable for storing the operating system and the applications (programs and the associated parameterizations) for the bus device G1.

The bus device G1 is advantageously a bus participant (e.g. actuator, sensor or controller) of a bus-oriented programmable electrical installation GBS1 (e.g. KNX system), with the bus device G1 having at least one processor (e.g. microcontroller) MK and a memory SP (e.g. a persistent flash memory).

Furthermore, the bus device G1 is set up to load application programs AP1, AP2 into the memory SP via a bus interface BK (bus coupler) or via an external interface SS (e.g. USB interface). An application program AP2, e.g. from a configuration device KG (upload tool, e.g. ETS (engineering tool software)) can be transferred via the external interface SS to the device G1 via a communication connection KV compatible with the interface SS. The communication connection KV can be a wired connection or a wireless connection (e.g. a radio connection).

The representation according to 1 shows an exemplary bus device G1 according to the invention of a bus-oriented programmable electrical installation GBS, the bus device G1 comprising a processor MK and a memory SP, and
wherein the bus device G1 is set up to implement a first functionality assigned to the bus device G1;
wherein the bus device G1 is set up to implement a second functionality assigned to the bus device G1, with the activation of the first functionality being blocked for a user in the presence of a first defined event and the bus device G1 executing the second functionality. The bus device G1 can be an actuator (e.g. blind actuator), a sensor (e.g. light sensor) or a controller.

Advantageously, the bus device G1 is set up to implement a third functionality assigned to the bus device G1, with the activation of the second functionality being blocked in the presence of a second defined event and the bus device G1 executing the third functionality.

Advantageous embodiments are that the first functionality assigned to the bus device G1 corresponds to normal operation of the bus device G1; and the second functionality assigned to the bus device G1 is a first exception functionality for the bus device G1; and the third functionality assigned to the bus device G1 is a second exception functionality for the bus device G1.

In principle, any number of levels of functionality can be implemented, i.e. the prioritization hierarchy of functions is in principle not limited. For example, if a third defined event occurs, activation of the third functionality can be blocked and the bus device G1 can execute a defined fourth functionality. And so forth.

Each functionality is advantageously assigned a respective unique identifier, and the bus device G1 comprises an interface BK, SS via which the identifier can be forwarded to other devices G2.

Each functionality is advantageously assigned a unique identifier, and the bus device optionally includes an output unit AE (e.g. a display) for outputting or displaying the identifier.

The bus device G1 advantageously includes an input unit EE (e.g. button, switch, touch selection menu) for setting the identifier. The identifier can also be set via a configuration device (e.g. ETS).

Advantageously, the adjustable or assignable identifier is determined and assigned centrally. The identifiers are advantageously managed in a central database DB. This central database DB can be located on a configuration device KG (e.g. ETS) or on a specific (dedicated) bus device G2.

A blind actuator as a bus device supports, for example, automatic opening of the blinds in the event of a wind alarm and a movement lock for the blinds during cleaning work (e.g. window cleaning work). If the user now wants to operate the blind and it doesn't work, he or she will not receive any information as to whether, for example, a wind alarm has been reported or what else the cause is. In the case of the wind alarm, it is also possible that there is no wind but the wind sensor has failed. In this case, the blinds move up and can no longer be operated. It is not easy for the installer to draw conclusions about the cause.

2 shows a first exemplary schematic representation for an exemplary function module FM for implementing the method according to the invention for a blind actuator AK as an exemplary bus participant.

According to the invention, the FM function modules are expanded to include functionality that allows the reason for a “malfunction” of a bus device to be detected. If, for example, the travel protection VFS is active on a blind actuator AK, the FM function module signals this to a “problem identification module” PI1. This module PI1 can now forward this to an external location PA1 (e.g. display on the bus device, etc.) and it can be displayed there. The external location can also be a higher-level building control center, for example.

The automatic wind alarm WAA can even distinguish whether it is a wind alarm or a failed wind sensor WS and report this problem.

The FM function modules with problem identification are advantageously implemented as application programs and loaded into the flash memory (persistent memory) of the respective bus device AK. The FM function modules have a “normal” and one (or more) “superordinate” functionality(s). The normal functionality consists, for example, of forwarding commands or carrying out normal processing. The “parent” functionality is functionality that has higher priority over user action. If a "superordinate" functionality is activated or if the bus device is in a function mode for a higher-level functionality, then operation by the user has no effect because it is suppressed by the "superordinate" functionality.

Example:

The automatic wind alarm system WAA forwards the commands from the input signal evaluation ESW to the next module, as shown in the example 2 to the VFS travel protection module. In the event of a wind alarm, a switch is now made to a higher-level functionality and the commands from the input signal evaluation ESW are no longer forwarded, e.g. commands from the user control BAS (e.g. button inputs on the bus device by the user).

The higher-level functionality consists, for example, of forwarding the previously parameterized commands. In this case, this “problem” can also be forwarded to the “problem identification module” PI1. Another higher-level functionality consists, for example, in detecting the failure of the wind sensor WS, executing the parameterized functionality and forwarding the problem to the problem identification PI1.

In the example according to 2 Messages from the automatic wind alarm WAA and the movement protection VFS are possible. If both are active, only the message with the highest priority is forwarded and displayed by the problem identification module PI1. If both are active, travel protection VFS is displayed.

However, if the VFS movement protection is deactivated, a wind alarm is displayed. This prioritization makes it possible to resolve the problem step by step.

An optional problem display PA1 can also be integrated directly into the device AK. A corresponding error message may appear on an output device (e.g. display).

The problems can optionally also be reported via an external interface (e.g. implemented as a KNX communication object), for example as an error ID or as text.

The exemplary function module FM according to 2 for implementing the method according to the invention for a blind actuator AK includes an input signal evaluation ESW for off Evaluation of the commands from the BAS user control. Through the user control BAS, a user can give commands to the blind actuator AK, e.g. move the blinds up or down. This happens, for example, by pressing buttons or switches.

Furthermore, the exemplary function module FM for a blind actuator AK includes an automatic wind alarm WAA and a movement protection VFS. The automatic wind alarm WAA receives information (e.g. information about the wind strength and/or the wind direction or whether there is wind of at least a certain strength) from one or more wind sensors WS. The “module for travel protection” VFS is activated, for example, using a VSA button. Activated travel protection ensures, for example, that the blinds cannot be lowered during cleaning work (e.g. window cleaning).

The “module for controlling the blind” evaluates the information or commands from the input signal evaluation ESW, the automatic wind alarm WAA and the movement protection VFS and controls the blind motor JM accordingly.

Furthermore, the blind actuator AK includes a module for problem identification PI1. The problem identification PI1 enables problem identification and problem solving to be carried out step by step by prioritizing the functionality with regard to user input, automatic wind alarm and movement protection VFS. This can also be done on site by a user.

The blind actuator AK is optionally equipped with a problem display PA. A corresponding error message can therefore appear on an output unit (e.g. display).

Optionally, the blind actuator AK is also equipped with an external interface (e.g. implemented as a KNX communication object). This means that detected error states can be reported as an error message to other bus devices or to a building control center.

A function module FM according to the invention is advantageously implemented as an application program which is loaded into the memory (e.g. flash memory) of the respective bus device (e.g. blind actuator AK).

According to the invention, a distinction is made between normal and higher-level functionality in the FM function modules. There can also be several higher-level functionalities per FM function module. If the normal functionality is not carried out, a report is sent to a point for problem identification PI1 and further reporting. If several problems or errors can be detected, they must be prioritized to enable meaningful problem resolution. Troubleshooting can therefore be carried out systematically and step by step.

3 shows a second exemplary schematic representation with a sensor and the exemplary blind actuator AK 'according to 2 as exemplary bus participants. In the 3 The listed objects BAS', FM', WS', VSA', ESW', WAA', VFS', AJ', JM', PI1' and PA' correspond to the respective objects (without "'") 2 .

When depicted according to 3 the blind sensor JS is connected to the blind actuator AK' via bus B2 (e.g. KNX connection). This means that the input signal evaluation ESW' of the blind actuator AK' receives signals or commands via the bus B2 from the overcontrol logic USL of the blind sensor JS.

The blind sensor JS according to 3 includes a blind control suitable for shading depending on the position of the sun and corresponding control of the associated blind actuator AK'. The blind sensor JS includes a GPS-controlled clock (clock), on the basis of which a module BS “Calculation of the position of the sun” generates control signals for the override logic module USL, which are forwarded by the module AS “Output control signal” to the override logic module USL. In the override logic module USL, the control signals can be overridden based on the calculation of the position of the sun using information (sensor data) from the light sensor LS. The overcontrol (“overcontrol active”) is assigned a higher priority than the control signals that are based on the calculation of the position of the sun.

In principle, the prioritization hierarchy of functions is also not limited in the JS blind sensor. The problem identification module PI2 can be used to determine whether there is an override by the light sensor LS in the event of a malfunction or whether the clock is defective.

The JS blind sensor is optionally equipped with a problem display (e.g. display). The problem display PA' of the associated actuator AK' can also be used as a problem display for the sensor JS.

Optionally, the JS blind sensor is also equipped with an external interface (e.g. implemented as a KNX communication object). This means that detected error states can be reported as error messages be reported to other bus devices or to a building control center.

The problem identification module PI2 according to the invention is advantageously implemented as an application program that is loaded into the memory (e.g. flash memory) of the respective bus device (e.g. blind sensor JS).

• (VS1) wobei das Busgerät eingerichtet ist eine erste dem Busgerät zugeordnete Funktionalität zu realisieren;
• (VS2) wobei das Busgerät eingerichtet ist eine zweite dem Busgerät zugeordnete Funktionalität zu realisieren, wobei bei Vorliegen eines ersten definierten Ereignisses das Aktivieren der ersten Funktionalität für einen Benutzer gesperrt wird und das Busgerät die zweite Funktionalität ausführt.
• (VS3) Optional ist das Busgerät eingerichtet ist eine dritte dem Busgerät zugeordnete Funktionalität zu realisieren, wobei bei Vorliegen eines zweiten definierten Ereignisses das Aktivieren der zweiten Funktionalität gesperrt wird und das Busgerät die dritte Funktionalität ausführt.

4 shows an exemplary flowchart for a method for operating a bus device of a bus-oriented programmable electrical installation, the bus device comprising a processor and a memory,

• (VS1) wherein the bus device is set up to implement a first functionality assigned to the bus device;
• (VS2) wherein the bus device is set up to implement a second functionality assigned to the bus device, whereby in the presence of a first defined event, activation of the first functionality is blocked for a user and the bus device executes the second functionality.
• (VS3) Optionally, the bus device is set up to implement a third functionality assigned to the bus device, whereby in the presence of a second defined event, activation of the second functionality is blocked and the bus device executes the third functionality.

Optionally, each functionality is assigned a unique identifier, which can be forwarded to other devices via an interface.

Optionally, each functionality is assigned a unique identifier that can be set on the bus device.

Optionally, each functionality is assigned a unique identifier, which can be set via a configuration device (ETS).

Optionally, each functionality is assigned a unique identifier that can be displayed and/or queried on the bus device.

The method can be carried out using hardware (communication bus, bus devices, configuration devices (e.g. ETS) with appropriate software that is usually present in a bus-oriented programmable electrical installation.

The method is particularly advantageous for KNX products (actuators, sensors, etc.).

5 shows an exemplary object model OM for an exemplary central management of error messages FEM1 - FEM2 in a bus-oriented programmable electrical installation.

In a bus-oriented programmable electrical installation (e.g. KNX system) there are devices (actuators, sensors, controllers, etc.) (e.g. a JSS blind switch) that can report malfunctions and error states. The message is sent via an ID (e.g. 16-bit integer) which is sent via a group address. The ID (e.g. a uniquely assigned identification number) can be set for each device or function module. When message IDs are received, corresponding error messages FEM1 - FEM3 (e.g. error texts and/or graphic symbols (e.g. corresponding error icons) can be assigned to an output unit AE' (e.g. display). These error texts may have to be made available in different languages If this process is to be carried out in an office building with 1000 identical offices, this can be done by creating a sample office configuration and copying this sample configuration. The copies then have to be individualized (e.g. marking message IDs as unique (i.e. as unambiguous)). However, if something changes, the sample office configuration will be changed and 999 configurations will have to be deleted, copied again and individualized (Alternatively, the change can also be made manually in the 1000 offices). This process is necessary for every change (show a new problem PR, correct a typographical error in a message, an assignment error, an additional language, ...) is required.

If the problems PR only need to be displayed in the same room R (of a building GB) in which they exist, the IDs do not have to be unique across rooms. If it is to be displayed on a building visualization, the IDs in the system must be unique and additional text is required for each message.

Example of a problem display in the room: “Blinds are jammed”.
Example of a problem display on a list of all problems in the building: “Blinds in office 537 are stuck”.

According to the invention, a central tool (e.g. configuration device or a dedicated bus device with appropriate hardware equipment) is proposed for managing PR problems and corresponding error messages that can be assigned to the respective problems. In this tool, all detectable errors (problems) are collected in a list. This is the problem list. Every sample At least one text (per supported language) and/or one symbol is assigned to lem. This is the problem text or icon. A second text can, for example, contain a placeholder for the room R. Additional texts can be assigned for additional applications (e.g. with placeholders for room R and building GB).

Another application would be, for example: Printout with all jammed blinds on the factory premises. To repair these blinds it is of course necessary to know the room R and the building GB. Now the PR problems are linked to the FM'' function modules with problem detection in the bus devices that have the corresponding functionality. This is the problem association. In the object model OM as in 5 shown, a problem association between the object symbols (shown as rounded rectangles) is marked as a connecting line with a light diamond at one end. A connecting line with a black diamond at one end represents a “consists of” relationship between two objects. For example, a building GB consists of several rooms R.

The displays AE' are then assigned to the function modules FM'', which are supposed to display the respective error message FEM1 - FEM3.

If the devices have been linked to rooms and there are placeholders in the messages, the error texts can be supplemented with further information (room, building, ...). The error texts with or without placeholders are assigned to the display AE'' manually or the assignment is carried out automatically. When assigning automatically, it depends on whether the display is in the same room (without room and building information), in the same building (with room and without building information) or in another building (with room and building information).

When parameterizing the devices (e.g. with the ETS as a configuration device), a separate unique ID is generated for each association (problem association). This ID is then assigned to the function module FM'' (with problem detection) in the device and this ID is linked to the corresponding problem text in the display AE', which is supposed to show this message. The process of ID generation and linking in the device and in the display can be automated. An appropriate interface is advantageously provided for defining and linking the elements. The interface and functionality can be made available, for example, as part of an ETS app. If the text is changed, only the corresponding text is changed and the generation process is restarted. Finally, the configuration data is loaded from the ETS into the devices.

According to the invention, only an association between problem detection, error message and display element is configured. The unique IDs are generated in a separate automated step. This separation makes it possible to copy devices including the link to the problem description. Since the problem, including the error message, is only described once for several devices, it is easy to adapt or expand this data for any number of devices in one place (e.g. configuration device, dedicated bus device) with suitable hardware equipment (i.e. with appropriate processor performance and memory capacity). language). It is advantageous for the position to have a database or a database connection.

It is advantageous to automatically select the error text for display (e.g. for output and/or display on an output unit (e.g. display), which is made depending on the spatial installation situation.

Reference symbols

G1, G2

Bus device

B1, B2

bus

SP

Storage

AP1, AP2

application

GBS

Building automation system

BK

Bus coupler

SS

interface

MK

processor

L.S

Guidance system

KG

Configuration device

KV

Communication link

AE, AE'

Output unit

EE

Input unit

FM, FM', FM''

Function module

WS, WS`

Wind sensor

L.S

Light sensor

AK, AK'

actuator

BAS, BAS'

User control

ESW, ESW'

Input signal evaluation

WAA, WAA'

Automatic wind alarm

VFS, VFS'

Travel protection

VSA, VSA'

Activate travel protection

AJ, AJ'

Control of blinds

JS

Blind control

JM, JM'

Blind motor

PI1, PI1', PI2

Problem identification

FATHER'

Problem display

B.S

Calculating the position of the sun

AS

Output control signal

USL

Override logic

Clock

Clock

VS1 - VS3

Procedural step

DB

Database

OM

Object model

GB

Building

R

Space

FEM1 - FEM3

Error message

JSS

Blind switch

PR

problem

Claims (17)

Method for operating a KNX bus device (G1, G2) of a KNX bus-oriented programmable electrical installation (GBS), the KNX bus device (G1, G2) comprising a processor (MK) and a memory (SP), wherein the KNX bus device (G1, G2) implements a first functionality assigned to the KNX bus device (G1, G2), wherein the KNX bus device (G1, G2) implements a second functionality assigned to the KNX bus device (G1, G2) if activation of the first functionality is blocked for a user in the presence of a first defined event, and the KNX bus device (G1 ,G2) then executes the second functionality, wherein a reason for executing the second functionality is detected by means of a problem identification function module. Procedure according to Claim 1 , wherein the KNX bus device (G1, G2) is set up to implement a third functionality assigned to the KNX bus device (G1, G2), whereby in the presence of a second defined event, activation of the second functionality is blocked and the KNX bus device (G1 , G2) carries out the third functionality. Method according to one of the preceding claims, wherein each functionality is assigned a unique identifier which can be forwarded to further devices (G1, G2) via an interface (BK, SS). Method according to one of the preceding claims, wherein each functionality is assigned a unique identifier that can be set on the KNX bus device (G1, G2). Method according to one of the preceding claims, wherein each functionality is assigned a unique identifier which can be set via a configuration device (KG). Method according to one of the preceding claims, wherein each functionality is assigned a unique identifier that can be displayed and/or queried on the KNX bus device (G1, G2). Method according to one of the preceding claims, wherein each functionality is assigned a unique identifier, which is determined and assigned via a central location. Method according to one of the preceding claims, wherein the first functionality assigned to the KNX bus device (G1, G2) corresponds to normal operation of the KNX bus device (G1, G2); wherein the second functionality assigned to the KNX bus device (G1, G2) is a first exception functionality for the KNX bus device (G1, G2); and whereby the third functionality assigned to the KNX bus device (G1, G2) is a second exception functionality for the KNX bus device (G1, G2). Method according to one of the preceding claims, wherein in the presence of the first defined event, the activation of the first functionality for a user is also blocked for further KNX bus devices (G1, G2) of the same type and these further KNX bus devices (G1, G2) the second Execute functionality. Method according to one of the preceding claims, wherein in the presence of the second defined event, the activation of the second functionality for a user is also blocked for further KNX bus devices (G1, G2) of the same type and these further KNX bus devices (G1, G2) the third Execute functionality. Procedure according to Claim 9 or 10 , with an identifier assigned to the respective functionality on the other KNX bus devices (G1, G2). can be set and/or displayed and/or queried on the respective KNX bus device (G1, G2) or by a central location. Computer program for operating a KNX bus device (G1, G2) of a KNX bus-oriented programmable electrical installation (GBS), with instructions for carrying out the method according to one of the Patent claims 1 until 11 . Computer-readable medium that has instructions executable on a computer for carrying out a method according to one of the Patent claims 1 until 11 for a KNX bus device (G1, G2) of a KNX bus-oriented programmable electrical installation (GBS). KNX bus device (G1, G2) of a KNX bus-oriented programmable electrical installation (GBS), suitable for carrying out a method according to one of the Claims 1 until 11 . KNX bus device (G1, G2) of a KNX bus-oriented programmable electrical installation (GBS), the KNX bus device (G1, G2) comprising a processor (MK) and a memory (SP), and wherein the KNX bus device (G1, G2) is set up to implement a first functionality assigned to the KNX bus device (G1, G2); wherein the KNX bus device (G1, G2) is set up, a second functionality assigned to the KNX bus device (G1, G2) is to be implemented and, in the presence of a first defined event, the activation of the first functionality for a user is to be blocked and then the second functionality to carry out, and the KNX bus device (G1, G2) has a problem identification function module that is designed to detect a reason for executing the second functionality. KNX bus device (G1, G2). Claim 15 , wherein the KNX bus device (G1, G2) is set up to implement a third functionality assigned to the KNX bus device (G1, G2), whereby in the presence of a second defined event, activation of the second functionality is blocked and the KNX bus device (G1 , G2) carries out the third functionality. KNX bus device (G1, G2) according to one of the Claims 15 or 16 , whereby the KNX bus device (G1, G2) is set up to receive an identifier that is uniquely assigned to a respective functionality from a central device or a configuration device.

Images