| | |
Backups of tests and configuration | Local PC or server usually holds the only copy of settings and test records. Backups depend on site IT or manual exports, with a risk of losing years of data. | Configuration, device locations and emergency test results stored centrally in the cloud. Backups and retention managed by zencontrol, with tools to restore sites and roll back unwanted changes. |
| Rebuilding after corruption or loss can require reprogramming from scratch; downtime measured in days or weeks. | Cloud-stored configuration and controller-based storage allow rapid restoration, often in hours. Controllers continue to operate locally even if the internet is unavailable. |
User access control (UAC) | Single shared logins or basic roles. Limited control over who can see or change what. | Fine-grained roles and permissions. Users are assigned to specific sites and tenancies with view, maintenance or admin rights as required. |
| Hard to separate base building from tenant areas; reports are “all or nothing”. | Built-in tenancy and grouping model. Each tenant or department can see only their devices, tests and reports, while owners and FMs see the entire portfolio. |
Test manager vs simple test trigger | System sends a test command and reads a result. Repairs and re-tests are poorly linked or not tracked at all. | A true test manager: schedules tests, tracks execution, manages repairs and re-tests within a defined test window, and links all activity to that test cycle. |
Device locations vs devices | History is tied to the current fitting. When a luminaire is replaced, its test history is effectively reset. | Tests and compliance linked to fixed device locations (required emergency points), maintaining a continuous history even as fittings are replaced over the life of the building. |
Full traceability / audit trail | Change logs are basic or missing. Difficult to know who changed settings or removed devices from tests. | Detailed field-level audit trail: time, previous value, new value, result and the named user or system action. Every configuration change is recorded. |
| When something goes wrong, it is hard to prove whether a contractor, tenant or owner changed or disabled the system. | User-specific logging supports investigations and clarifies operational responsibility for missed tests or configuration changes. |
| Reports may be editable or regenerated in ways that overwrite previous results; spreadsheets are common. | Emergency test outcomes stored as immutable records. New reports can be created, but past results cannot be altered. |
| May implement only parts of DALI or local standards, or rely on proprietary behaviour. | Test process built around IEC 62034 and DALI emergency standards, with independent testing (e.g. TÜV) of the test engine and support for AS 2293 requirements. |
| Often just reads duration or a basic status flag, ignoring many DALI emergency features. | Performs proper DALI function and duration tests, uses full DALI status and test flags, enforces time windows and fails incomplete tests. |
Change control during tests | Devices may be removed from groups or disabled without clear visibility; they simply stop appearing in reports. | Removing devices from tests, changing groups or editing schedules is logged and surfaced by the test manager, making gaps in coverage visible. |
Portfolio and multi-site support | Each building tends to be a separate island, with cross-site reporting done manually. | Cloud platform aggregates many sites, providing portfolio dashboards, filters by region or owner, and central policy control for tests and alerts. |
| Basic passwords and on-premise security; patching and hardening depend on each site. | Modern security practices, role-based access, encrypted connections and continuous platform updates delivered centrally. |
Onsite vs cloud operation | Either purely local (no remote access) or cloud-only, where loss of connectivity can halt visibility or control. | Hybrid design: DALI-2 application controllers run local logic and tests; the cloud adds backups, analytics and portfolio management without being a single point of failure. |
| Faults and test failures are loosely connected; follow-up relies on manual work orders. | Faults, repairs and re-tests are linked to the relevant device location and test window, making outstanding work and proof of rectification easy to see. |
Vendor and device flexibility | Often tied to a proprietary ecosystem and limited device options. | Based on open DALI / DALI-2 standards, allowing compliant multi-vendor emergency devices within the same system. |
| Larger networks require separate servers and duplicated configuration; upgrades can be disruptive. | Designed to scale from single buildings to large portfolios, with cloud services handling growth and updates with minimal disruption. |
Reporting for stakeholders | One-size-fits-all reports that do not reflect how buildings are managed. | Reports tailored by site, tenancy, floor, zone or portfolio so owners, tenants, FMs and contractors each get the view they need. |