Backup controller

With this function a controller can be configured as a backup controller. If the primary controller fails, the backup controller automatically takes over all functions. The backup controller synchronizes itself daily with the primary controller, so that all data such as temperatures, scenes or recorded data are immediately available again.

Introduction as a presentation: Backup controller - simply explained - function and benefits on a few slides, easy to follow for non-technical readers too. How the backup controller works together with several controllers is shown in the presentation Distributed project (arrow keys to browse, F for full screen).

The backup controller runs with the project of the primary controller. Two ways of detecting a failure are available; they can be used individually or together:

KNX trigger address: A trigger address is defined which the primary controller sends cyclically via the Clock generator function block. The backup controller monitors this address. If the telegram does not arrive, it takes over. As soon as the trigger address is received again, it withdraws. This way requires a KNX system.
Network: The backup controller logs on to the primary controller at short intervals - just as the Studio does - and then queries its state. This checks not only whether the controller can be reached, but also whether its program is still running. A controller that answers but whose function blocks have stopped is just as dead to the installation as one that is switched off. This way does not require a KNX system.

If both ways are used, the backup controller only takes over once both have failed. A single fault - a switch rebooting or a problem on the KNX line - therefore does not cause a takeover. Conversely it is enough for one of the two ways to report again for the backup controller to return to standby.

Detection via the network requires the same software version on the primary controller. An older controller does not answer the query; this is reported as a configuration error and explicitly does not cause a takeover.

To open the settings dialog, select Control - Backup control in the Studio.

In this dialog the backup function is configured. Since the project is synchronized from the primary controller, the settings are not saved in the project but in a separate area.

Use as backup control	Use the controller as a backup controller. This may only be active on the backup controller; on the primary controller this setting must remain deactivated. When it is switched on, the controller immediately fetches the project of the primary controller. Failure detection only starts after this initial synchronization, so that the backup controller cannot take over with an outdated project.
IP address	IP address of the primary controller. The project data is fetched from this address.
Phys. address	Physical address of the backup controller. It is used as soon as "Use as backup control" is active - that is, also while the primary controller is still running. It replaces the address set in the KNX block and must differ from the address of the primary controller.
Password	Password of the primary controller. It is only needed for failure detection via the network: the backup controller uses it to log on to the primary controller. If the logon is rejected, the controller reports this in plain text and sends a mail - no takeover takes place in this case, because it is a configuration error and not a failure.
Show password	Shows the entered password in plain text so that it can be checked during commissioning.
Test synchronization	Immediately starts a synchronization with the primary controller. "Use as backup control" must be activated for this, otherwise the studio points this out and does not start the test. The status is shown below it: "Synchronization running", "Initial synchronization running", "Synchronization Ok" or the reason for the abort in plain text - for example a missing or invalid IP address of the primary controller, or an ongoing takeover. If the transfer itself fails, the error number is shown as well. After the synchronization the services are restarted and the project is reloaded, during which the backup controller is briefly interrupted. This test does not send a daily Ok message.
Detect failure via	Defines which monitoring is used: "KNX trigger address", "Network" or "KNX and network". The entries of the way that is not used are disabled. With "KNX and network" the backup controller only takes over once both ways have failed.
Trigger address	Here the address to be monitored is set. This must be a KNX address. Without a valid address no takeover happens; in this case the controller writes an error message to the log.
Timeout	Time in seconds for the monitoring, adjustable from 60 to 65535 seconds. The value must be clearly above the send interval of the clock generator so that a single lost telegram does not trigger a takeover. If the telegram does not arrive, the backup controller takes over all functions. As soon as the telegram is received again, the backup controller becomes inactive again.
Network timeout	Time in seconds for monitoring via the network, adjustable from 60 to 65535 seconds, default 300 seconds. The check runs every 10 seconds. If the primary controller does not report even once within this time, the network way is considered failed. The value should not be chosen too small: while a project is transferred to the primary controller its program briefly does not run, and that must not cause a takeover. After a restart of the backup controller, monitoring only starts after three minutes so that the starting primary controller is not immediately considered failed.
Reference address	IP address of a device that can always be reached - usually the router. If the primary controller cannot be reached and this address cannot be reached either, the fault lies in the backup controller's own network. In this case no takeover happens, because the primary controller is probably still running - two controllers sending at the same time would carry out every command twice. The field may be left empty, then no check is performed.
Test network connection	Immediately performs a check via the network. The result is shown below in plain text, for example "Network Ok, the primary controller is running", "The primary controller cannot be reached", "Logon rejected" or "The program of the primary controller is no longer running". The remaining time of the network timer and the software version of the primary controller are shown as well.
State	Shows whether the backup controller is in standby or has already taken over.
Send push notification to the app	Additionally sends the same messages as a push notification to all apps that have logged on to this controller. Note: the device list is part of the stored data and only reaches the backup controller with the synchronization. If no synchronization has ever run on the backup controller, no device is known and nothing is sent.
Pushover key	User key of the Pushover account. If it is filled in, the same messages are additionally sent via Pushover. Several keys can be separated by a semicolon ";", empty = no Pushover. An own application token is not needed, one is already built in. For the backup controller this is the most reliable way, because unlike the push notification it does not depend on an app being logged on.
Email notification	Email address for notification. Multiple recipients can be specified separated by a semicolon ";", empty = no email. A message is sent when monitoring fails, when the primary controller reports again, when an error occurs during synchronization, or when the network check detects a configuration error.
Send daily Ok message	With this option a daily Ok message is sent by the backup controller over all enabled ways as soon as the daily synchronization was successful. This ensures that the backup controller is also operational. On the main controller the function block "Monitor network devices" can additionally be used to monitor the backup controller as well.
Trigger Timer Status	Shows the remaining time in seconds until takeover. The value is reset to the configured timeout with every trigger telegram received. When it reaches 0, the backup controller takes over.
Apply	Saves the settings on the controller, the dialog stays open.
Cancel	Closes the dialog. Settings already saved with "Apply" are kept.
Ok	Saves the settings on the controller and closes the dialog.

KNX connection of the backup controller

Both controllers run the same project. If the KNX interface is set to TP-UART onboard, each controller has its own terminal on the bus and is independent of the other.

With an external KNX-IP gateway this is not the case: without further details both controllers access the same gateway. If this gateway fails - or if it is connected to the same power supply, the same switch or the same network segment as the primary controller - the backup controller does take over, but reaches the KNX bus just as little.

For this case the block KNX interface provides the parameters IP address backup controller and Port backup controller. A second gateway is entered there which is used exclusively by a controller on which "Use as backup control" is active. The address is always used, that is also while the primary controller is still running: the connection is therefore already established before a takeover and the second gateway is continuously checked. If the field is left empty, everything behaves as before.

Three points have to be observed during commissioning:

Both gateways must be connected to the same KNX bus. If the failure is detected via the KNX trigger address, the telegram of the primary controller runs onto the bus through the first gateway and back to the backup controller through the second one. Line couplers with filter tables must let this address pass, otherwise the trigger telegram does not arrive and the backup controller takes over without reason.
The physical addresses must remain different. The field "Phys. address" in this dialog is still responsible for that.
The second gateway should be connected to a different power supply and a different switch than the primary controller - otherwise nothing is gained.

Behaviour in standby

As long as the primary controller sends its trigger telegram, the backup controller is in standby. The project runs there completely: all values are kept up to date, recording continues and devices are still polled. After a takeover all data is therefore available immediately. Only the effect to the outside is suppressed, because the primary controller already performs the same action.

The same lock applies as for a disabled block or a disabled page. The difference: a disabled block does nothing at all, whereas in standby it keeps working internally and only sends nothing to the outside.

Blocked in standby are:

Sending on the KNX bus
Outputs of the IO modules (LAN, CAN and Modbus IO)
Write accesses of the Modbus master
Shelly, NUKI and all other MQTT commands
Sonos (local and Cloud)
Alarm systems (Guarto, Jablotron, ABI) and door station (Doorbird)
Wallboxes (OCPP, go-e, Keba, EASEE, NRGKick) and Marstek battery storage
Home appliances (Home Connect), robotic mower (Husqvarna), sauna (Sentiotec) and VELUX KLF 200
Philips Hue and DMX via Art-Net
Messages via Pushover, NTFY, Push and IFTTT as well as sending email
System command and FTP upload
Writing HTTP requests from Lua scripts (POST, PUT, PATCH, DELETE); reading requests (GET, HEAD) remain allowed
Voice assistants: the Alexa bridge does not answer discovery requests and the Matter bridge is not started, so that two bridges with the same devices do not appear on the network
Portal connection: no data is published

Blocks that hold a permanent connection to the target device do not even open it in standby - many devices allow only one connection. Commands issued during standby are discarded and are not carried out later.

On every change - on takeover as well as on the return of the primary controller - the program is restarted completely. All blocks are recreated and rebuild their connections to the devices, or leave them closed. This takes a few seconds, during which the program does not run. Values that must survive a restart come from the persistent storage as usual.

Not blocked are polling and measured values, the recording, and settings that only concern the controller itself (for example the system clock).

Sequence of the takeover

If monitoring is missing for longer than the configured timeout, the backup controller takes over: sending is enabled, the KNX gateway and the Modbus master are restarted, the program restarts and a mail is sent. If the primary controller reports again - via the trigger address or via the network - sending is switched off immediately, the program restarts once more and a mail is sent as well.

Failure detection via the network

Every 10 seconds the backup controller briefly opens a connection to the primary controller, logs on with the configured password and queries its state. The connection is closed again immediately. The network timer is restarted with every successful check.

Only three cases count as a failure: the primary controller cannot be reached, it does not answer within the time limit, or its program is no longer running. All other results are configuration errors and explicitly do not cause a takeover - but they are shown in plain text and reported once by mail:

The logon was rejected, the password is wrong.
No IP address or an invalid IP address is configured.
The IP address points to the backup controller itself.
The remote station is itself set up as a backup controller.
The primary controller runs older software that does not know the query.
The reference address cannot be reached either - the fault then lies in the backup controller's own network.

To check the program, the primary controller reports how long its program has not progressed. If this time exceeds 30 seconds, the program is considered stopped. This also detects the case in which the controller still answers but the function blocks are no longer processed.

Synchronization

When "Use as backup control" is switched on, an initial synchronization starts immediately. While it is running, failure detection is suspended and the trigger timer stays at the configured timeout. Only afterwards can the backup controller take over. If the transfer hangs, failure detection starts after 15 minutes at the latest, so that a takeover is never blocked permanently.

Synchronization then runs once a day and only while the backup controller is inactive. During an ongoing takeover no synchronization is performed so that the running project is not replaced. After a successful transfer the services are restarted and the project is reloaded. If the transfer fails, the previous state stays active and a mail is sent.