Block Fault messages

The block collects the fault messages of the whole project in one place. Many devices already report a fault through an address of their own, such as temperature sensors, weather stations, actuators or pumps. These addresses are combined in a list here; the block derives a common fault, an output of its own per class, and a message.

A fault is latching: it stays visible even after its cause has gone, until someone acknowledges it in the visualisation element. A short fault during the night is therefore not lost. This can be switched off for individual rows ("Self-resetting").

Each fault passes through these states:

OK – no fault.
Fault – the fault is present and not yet acknowledged.
Fault acknowledged – the fault is still present but has been noticed. When it goes, the row returns to OK without further acknowledgement.
Gone, unacknowledged – the fault has gone but has not been acknowledged yet. Only acknowledging returns the row to OK.

Every row belongs to a class: alarm, warning or hint. All three count towards the common fault but have an output of their own. Above all the class decides whether and when a push notification or a mail goes out: push and mail are set per class, and each class has an input that releases the notification. An alarm therefore goes to the phone at once, a warning only during the day (release from a time switch) and a hint only appears in the list.

Coming, going and acknowledging are recorded with the time in the log. State and log survive a restart of the controller.

On start-up the block takes the initial state from the addresses of the project; every further change reaches it through the telegrams. It does not request any reads itself – if the state of a bus address is not known on start-up, set "read on start" at the address or use the block "KNX read trigger". Faults that come within the first 10 seconds after the start are only sent as a message after that.

The matching visualisation element is Block Fault messages. It shows the list of faults and the log, and faults are acknowledged there. It must be linked to this function block.

Inputs
QI	Acknowledge row	The visualisation element acknowledges through this input. The value 1 acknowledges the first row of the list, 2 the second and so on, 255 (or more) acknowledges all. Every write telegram takes effect, even if it carries the same value as before; the value does not need to be reset. 0 does nothing. Not connected: the visualisation element cannot acknowledge and latching faults remain. The address is created with "Generate variables" at the block.
FA	Release notification alarm	Releases push and mail of the class alarm: other than 0 releases, 0 blocks. A fault is detected, shown and logged even while the class is blocked – only the message is held back. Depending on the setting "Blocked alarm" it is sent later, as soon as the class is released again. Optional. Not connected: the class is always released.
FW	Release notification warning	The same for the class warning.
FH	Release notification hint	The same for the class hint.
Outputs
SS	Common fault	1 as long as at least one row is not OK – that is, a fault is present or has not been acknowledged yet.
AL	Alarm	Like SS, but only for rows of the class "Alarm".
WA	Warning	Like SS, but only for rows of the class "Warning".
HI	Hint	Like SS, but only for rows of the class "hint".
AN	Number active	Number of faults currently present.
UQ	Number unacknowledged	Number of faults not yet acknowledged, whether still present or already gone.
NE	New fault	Pulse of 2 seconds as soon as a fault comes, e.g. for a buzzer.
ME	Message	1 as long as an unacknowledged fault exists. The output is usually connected to a message block.
TX	Text last fault	Room and name of the fault that came last, e.g. "Bathroom - Temperature sensor". The address holds 14 characters, longer texts are cut off.
ST	Status	Status number for the visualisation. The number is the sum of the applicable states: 1 = a fault is present, 2 = a fault is unacknowledged, 4 = an alarm is not OK, 8 = a warning is not OK, 16 = a row has no valid address, 32 = a hint is not OK.
Parameters
	Fault messages	Opens the dialog with the list of fault messages. It is described further below under "Fault message list".
	Log size	Number of entries in the log, at most 500. When the log is full, the oldest entry is dropped.
	Push alarm Push warning Push hint	When switched on, the controller sends a notification to all registered uni-PRO APPs for every new fault of that class. The subject is the comment of the block (without a comment, the "Text title"), the text names class, room and name. In the visualisation element the user can mute all notifications of the block; that applies to the mail as well.
	Mail alarm Mail warning Mail hint	When switched on, a mail is sent to the given address for every new fault of that class. Mail sending must be set up in the controller.
	Address	Recipient of the mail, common to all classes. Only visible when one of the three classes is to send a mail.
	Subject	Subject of the mail. If empty, the "Text title" is used.
	Blocked alarm Blocked warning Blocked hint	What happens to a notification while the class is blocked by its input or the visualisation element is muted: Send later, once released: The fault is noted. With the release one collected message goes out that names the time each fault came. The note survives a restart of the controller. Default for alarm and warning. Discard: Nothing goes out, the fault only appears in the list and in the log. Default for the hint.
	Text title Text alarm Text warning Text hint	The fixed words of the push notification and the mail, default "Störmeldung", "Alarm", "Warnung" and "Hinweis". The controller has no language: the push notification, the mail and the output TX are created in the controller and go out exactly as they are written here and in the list. Enter these texts in the language of the installation.

Fault message list
The dialog is opened via the parameter "Fault messages". It stays open and usable while you work on it – this allows addresses to be dragged in from the variable window. Adding a fault message: Drag the fault address of a device from the variable window into the list. A row is created for every dragged address; the comment of the address is taken as the name. A multiple selection creates several rows at once. Addresses already in the list are not added again; the status line names them. Name and room are edited by double-click, address and comment cannot be edited. Dropping onto an existing row replaces its address. Clicking an address jumps to it in the variable window. The "Add" button does not create a row but shows the variable window: a fault message is always created from its address. "Up" and "Down" change the order. If a row is moved, inserted or renamed, the stored states start afresh with the next transfer. Translation: Name and room are shown in the visualisation element in the selected language. For this they appear in the language table of the project (Project → Language) as soon as a visualisation element is linked to the block.
Columns of the fault message list
	Address	The group address of the fault message. How its value is evaluated is set in the column "Trigger"; the data type does not matter, a fault code also works. Without a valid address the row remains unknown and is not evaluated.
	Comment	The comment of the address from the variable window. For orientation only, it is not stored.
	Name	Name of the fault, e.g. "Temperature sensor". This name appears in the visualisation element, in the log, in the message and at output TX. When dragging in, the comment of the address is used.
	Room	Room or trade, e.g. "Bathroom" or "Heating". It is placed in front of the name.
	Class	"Alarm", "Warning" or "Hint". All three count towards the common fault; in addition an alarm switches AL, a warning WA and a hint HI. The class also decides about push and mail: both are set per class and released through the input of that class. In the visualisation element an unacknowledged alarm is red, an unacknowledged warning orange and an unacknowledged hint blue.
	Trigger	Determines when the address raises a fault. By state – the fault comes and goes with the value: State (not 0 = fault): default, suits most fault objects. State inverted (0 = fault): for devices that report "in order" with 1. As an event – the fault has no going. It is logged and reported and then remains as "gone, unacknowledged" until it is acknowledged (with "Self-resetting" the row is OK again at once): Rising edge: change from 0 to not 0. Falling edge: change from not 0 to 0. Change: every change of the value. At 1: every write telegram with a value other than 0, even if the value does not change. At 0: every write telegram with the value 0. Telegram: every write telegram, whatever the value. Edges and change also evaluate read responses, the three telegram types only write telegrams. The value at controller start-up does not trigger an event.
	Delay	The fault must be present without interruption for this long before it is reported. If it goes earlier, nothing is reported or logged. Going always takes effect immediately. 0 = report at once. Only applies to triggering by state; an event is always reported at once.
	Self-resetting	The row returns to OK as soon as the fault goes, even without acknowledgement. Useful for messages that are only meant to inform while they are present.

Block Fault messages

Inputs

Outputs

Parameters

Fault message list

Columns of the fault message list