How to edit advanced control system settings

To access advanced control system settings from grid view, first enable them in the site Settings section. Warning: Once enabled, this option cannot be disabled, and any user with appropriate privileges will be able to modify these settings. Only enable this feature if you understand the risks, as users could potentially set a mode that does not actively manage lights (monitor mode, for instance).  

Most of these features have been part of the control system for many years. While user access to modify them is new, the features themselves are not. Keep this in mind when you find a setting that isn't at its default value - it may have been intentionally adjusted to ensure the system works properly with the specific devices on that bus.

A dialog will appear advising you of the risks involved with this process. Once you read it all, understand it and still want to continue, accept the dialog and save the site settings. This will then cause a new view to appear in grid view.

You will see all available advanced settings in this view. If you're not sure what you need to change here, then it might be best not to touch the settings that you're unsure about.  

Seconds to unoccupied

The delay in seconds before occupancy sensors consider a space unoccupied after the last detected movement.  By default, this is 30 seconds.  This will affect BACnet, MQTT and sequence related designations for unoccupied.  

System failure delay seconds

On a wired controller, a DALI short causes each device to go to its system failure level (or ignore it if set to do nothing).  Wireless controllers cannot detect DALI short circuits.  There is no indication when the bus is in fault. To address this, the controller sends commands to restart a countdown timer on each device. If the controller fails to restart the timer (if it is unplugged, damaged etc), the device timer will reach zero and trigger it configured system failure mode. Note that if system failure is enabled, you may need to manage system failure responses of devices during controller bootloads to prevent unwanted activation, or manually restore the lights after a bootload completes. The valid range for this delay is 2-254 seconds with 255 meaning disabled

Addressing

When disabled, Automatic addressing of any additional devices will not occur, which works around non compliant DALI devices which may have issues with addressing or poor or bad support of the DALI standard.

Enabled command type

If Control gear only is set, no control device packets (ECD) will be sent by the controller.  This is intended to work around issues where some non compliant DALI devices cannot work with ECDs on the line.

Enabled polling

When polling is disabled, the system be much quieter but will not update many values such as arc level, emergency values. This is typically used when non complaint DALI fittings are used and this is disabled to mitagate the issues caused by non compliant products.

Monitor mode

In monitor mode, a control system is purely a listening device for the bus.  It cannot send DALI.  This is handy for diagnostic situations but will completely disable any functionality associated with switches, sensors, triggers, etc.  Use only if your intention is solely to connect to the controller with the DALI monitor.  

Identification mode

DALI devices must have a unique combination of EAN, serial number, and logical index. As long as they differ in any way, they can be uniquely identified and recovered / asset tracked.  

In early non complaint DALI Devices, this requirement was often not met, and even in 2025, non-unique devices are still frequently installed onto new sites.  A common misconception is that certification of a DALI device implies that they are fully DALI compliant.  DALI certification does not test two of any product to verify that they have different identification values.  Therefore, certification of DALI devices does not cover their adherence to being unique. The manufacture to get DALI certification agress that they are unique.

This setting controls how the control system handles identification / asset tracking of these devices. 

Note that this only affects ECG devices - ECD devices must always be unique and will not be scanned into the system if they aren't unique (we have never encountered a non-unique ECD).

All devices must still have given a unique serial/ean/logical index number combination OR have taken unique scenes/OEM bank values to get into the database. 

We do not have a mode that allows devices into the database that cannot fulfil that requirement.  

By default, our system operates in Simulated unique device mode, meaning it can handle non-unique devices. While you might be tempted to use DALI compliant mode, be aware that the prevalence of low cost devices with made up EANs / serial numbers of all zero or a very specific random number is common.  You may also encounter controllers that already run in an escalated mode - more than likely, this was set by zencontrol at a request from the commissioning agent, therefore, modification of this may be risky!

The additional modes are only used when non-unique devices cannot retain the unique values we've stored on them. For example, an ECG might misinterpret an ECD command, crash, and restart with reset scenes. The device then appears as new, and we add it to the database accordingly.  This can eventually fill up the database and then there will be a mixture of newly created database entries and comms errored previous database entries.

DALI compliant Only devices with unique identifiers will be added to the control system.

Simulated unique device (Default) Non-unique or non-compliant devices receive simulated EAN/serial numbers by storing unique values in scenes 12, 13, and 14 (zero-indexed). As a fallback, unique values are stored in the device's OEM bank if supported.

Using the further modes of conditional at address / all at address compromises the ability for the system to recover devices at their address as it no long fixes up devices and puts them back to their allotted addresses, if there is something already there. 

Conditional at address Non-unique devices often have additional bugs that can affect our fallback identification methods. These devices may lose the unique scenes we've assigned and get re-added as new devices. This setting tells the controller to identify any device at a specific address using fallback methods as the correct device, regardless of its current scene values.  If two non unique devices lost their address and are addressed randomly as each others address, they will not be correctly returned to their values.

All at address All devices at their assigned addresses are considered the correct device, including those with valid EAN and serial combinations, as long as they are present.