Managing an ETS project as a single installer is already a discipline in itself. Bring two, three, or more professionals into the same KNX installation, and the complexity multiplies fast. Files get duplicated, group addresses get overwritten, and nobody is quite sure which version of the project is the one that actually reflects what is installed on site. For KNX system integrators working on larger residential or commercial builds, getting ETS project revisions under control is one of the most practical challenges of the job.
This article walks through the common failure points in multi-installer ETS workflows and offers concrete strategies for keeping KNX project management clean, collaborative, and traceable from first commissioning to final handoff.
Why ETS revision control breaks down on multi-installer jobs
The root problem is simple: ETS files are not natively designed for real-time collaboration. Unlike cloud-based platforms where multiple users can work simultaneously, an ETS project lives as a local file that gets passed around by email, USB drive, or shared folder. When two installers open and edit the same project independently, you end up with competing versions and no straightforward way to reconcile them.
On larger sites, this creates a cascade of issues. One installer updates the lighting group addresses while another is commissioning the HVAC section using an older project copy. Neither knows what the other has changed. When the files are eventually merged, inconsistencies surface during testing that are difficult to trace back to their origin. The result is wasted time on site, frustrated clients, and a project that is harder to hand over cleanly to whoever handles future maintenance.
Structuring your ETS project for collaborative handoffs
A well-structured ETS project is the foundation of any multi-installer workflow. Before the first device is commissioned, it is worth investing time in a logical, consistent project architecture that every team member can navigate without confusion.
Start by dividing the project into clearly named building areas or functional zones, and assign each zone to a specific installer or team. Group addresses should follow a consistent naming convention agreed upon before work begins. When every installer works within a defined scope and uses the same naming logic, the risk of overlapping edits drops significantly. It also makes it far easier to identify where a change came from when reviewing revision history.
Consider using ETS’s built-in comment and description fields actively. Devices, group addresses, and parameters can all carry notes that explain intent, installation date, or the name of the person who made a change. These annotations cost nothing in commissioning time but pay dividends when a second installer picks up where the first left off.
Version control strategies that work with ETS files
Since ETS does not offer native version control, the discipline has to come from the team itself. The most reliable approach is to treat the ETS project file like source code: every meaningful change results in a new saved version with a clear filename that includes the date and a brief description of what changed.
A simple file naming convention goes a long way. For example: ProjectName_v1.2_2026-03-14_LightingZoneA.etspz. This tells anyone picking up the file exactly when it was saved and what was touched. Storing these versions in a shared folder with write access restricted to one person at a time prevents simultaneous edits from creating conflicts.
For teams that want more structure, a lightweight version control tool such as Git can be used to track changes to the exported ETS project file over time. This is more technical to set up but gives a full audit trail of who changed what and when, which is particularly valuable on long-running commercial projects where the installation spans months.
Defining roles and access rules across your installer team
Clear role definitions reduce the chance of accidental overwriting and help everyone understand their boundaries within the shared project. On a multi-installer job, it is worth designating one person as the ETS project owner, responsible for maintaining the master file, integrating changes from other team members, and releasing updated versions to the group.
Other installers work on exported sections or local copies, then submit their changes to the project owner for integration. This single-point-of-integration model adds a small coordination overhead but eliminates the chaos of multiple people editing the master file independently. The project owner becomes the quality gate, checking that new entries follow the agreed naming conventions and do not conflict with existing group addresses.
- Designate one project owner who controls the master ETS file
- Restrict write access to the shared folder to the project owner only
- Require all installers to submit changes with a brief description of what was modified
- Schedule a regular sync point on longer projects to integrate and distribute the updated master
How xxter simplifies multi-installer KNX deployments
Keeping the KNX installation itself well-managed is only part of the picture. The interface layer, where the KNX system connects to apps, voice assistants, and automation logic, needs to stay aligned with the ETS project as it evolves. This is where xxter adds real value for teams managing complex, multi-phase installations.
The xxter controller sits at the heart of the KNX installation and provides a stable, app-based control layer that does not require reconfiguration every time the ETS project is updated. When group addresses are revised or extended, the xxter platform product information and features can be updated independently without disrupting the broader installation. This separation of concerns means that one installer can be refining the KNX programming while another configures scenes, schedules, or automation logic through the xxter environment online portal, without the two workflows colliding.
- xxter’s app-based interface decouples the control layer from the ETS project, reducing coordination friction
- The xxter controller supports KNX alongside Modbus, BACnet, and EnOcean, making it suitable for mixed-protocol installations common on larger builds
- No license fees or per-device costs mean the platform scales with the project without budget surprises
For teams working on energy-intensive builds, xxter’s Smart Energy Manager integrated KNX solution integrates directly into the KNX environment and can be configured alongside the main installation, giving clients intelligent energy control without adding a separate system for the team to manage.
If your team is looking for a KNX control platform that fits naturally into a professional multi-installer workflow, xxter is worth exploring. Contact the xxter team directly to review the technical documentation and see how the controller and app can be integrated into your next project.
Häufig gestellte Fragen
What is the safest way to merge two independently edited ETS project files without losing data?
There is no native merge tool in ETS, so the safest approach is to treat one file as the master and manually cross-reference the second file’s changes against it before integrating them. Export a full group address and device list from both versions, compare them side by side (a spreadsheet works well for this), and have the project owner apply non-conflicting changes one section at a time. This is time-consuming but far more reliable than copying and pasting between files blindly, which can silently overwrite parameters or duplicate group addresses.
How should we handle a situation where two installers have already edited the master ETS file simultaneously and created conflicting versions?
First, do not discard either file — both contain potentially valid work. Identify the timestamp of the last agreed-upon master version and use it as your baseline. Then audit each conflicting file against that baseline to isolate exactly what changed in each one. Assign the project owner to reconcile the differences manually, prioritizing changes that have already been physically commissioned on site. Going forward, implement the single-point-of-integration model described in this post to prevent the situation from recurring.
Is Git actually practical for ETS project files, and what are the limitations?
Git works well for tracking ETS project files at the file level, meaning it can tell you when a file changed, who committed it, and what the commit message says — but it cannot show a line-by-line diff of what changed inside the file the way it does with plain text code. The .etspz format is a compressed archive, so internal diffs are not human-readable without extraction. The practical value of Git for ETS is in the audit trail and rollback capability, not granular change inspection. Teams that find Git too technical can achieve similar benefits with a disciplined shared folder structure and strict file naming conventions.
How do we establish a group address naming convention that works across a large team and a complex installation?
Define the convention before any commissioning begins and document it in a shared reference sheet that every installer has access to. A common structure is: Main Group / Middle Group / Sub-Group mapped to Function / Area / Device (for example, Lighting / Floor 2 / Office 4 Dimmer). Agree on abbreviations, capitalisation rules, and numbering ranges for each installer’s assigned zone to prevent overlaps. Review adherence to the convention at each integration sync point so deviations are caught early rather than discovered during final testing.
What should a project handoff package include to make future maintenance as straightforward as possible?
A complete handoff package should include the final versioned ETS project file, a printed or exported group address list with descriptions, a topology diagram showing device locations and physical addresses, and any installer notes captured in ETS comment fields. If the installation uses a control platform like xxter, include the configuration export and login credentials for the relevant environment. The goal is that a maintenance technician who was not involved in the original installation can understand the system’s structure and make changes without having to reverse-engineer anything.
How often should the project owner distribute an updated master ETS file to the rest of the team on a long-running commercial project?
A regular sync cadence depends on the pace of the project, but a practical rule is to distribute an updated master at the start of each new work phase or at least once a week when active commissioning is underway. Ad-hoc distributions should also happen immediately after any significant structural change, such as a group address reorganisation or the addition of a new building zone. Keeping the team working from a stale master is one of the most common sources of conflicts, so erring on the side of more frequent updates is almost always the right call.
Can the xxter platform be configured before the KNX installation is fully commissioned, or does it need a complete ETS project first?
xxter is designed to be configured independently of the ETS commissioning timeline, which is one of its key advantages in multi-phase projects. You can set up scenes, schedules, and the app interface in xxter using the group addresses that have already been defined and commissioned, while other parts of the KNX installation are still being programmed. As new group addresses come online, they can be added to the xxter configuration incrementally. This parallel workflow means the client-facing interface can be ready and tested well before the final ETS project is signed off.