Multi-residential KNX: where shared services start and tenant boundaries end

A multi-residential project is two systems in one. The shared services (corridor lighting, lifts, heating plant, common area HVAC, parking ventilation, security) need their own line, addresses, and visualization access. The tenant apartments each need their own KNX line and a guarantee that one tenant's bus traffic cannot reach another.

The topology that works well: an IP backbone connecting an area per floor or per stack. Each apartment is a single line with its own KNX-IP router or area coupler at the boundary. Filter tables on the couplers ensure that only the group addresses that should leave the apartment do so. Common-area devices live on a dedicated services line.

Filtering is the security boundary. Set every coupler's filter table to forward only the explicitly allowed group addresses. The default-allow stance leaks tenant telegrams onto the shared backbone, which is both a privacy issue and a needless source of bus load. ETS6 makes filter table management easier than it used to be, but it is still on the engineer to set up correctly.

Visualization. Tenants get a per-apartment login on the visualization, with no visibility into other apartments. Building management gets a separate login that sees only the shared services. Mixing these in a single account is a common mistake; separate them from day one.

Metering and billing close the loop. Each apartment should have at least one KNX-readable energy meter so consumption is reported per tenant. Tariff group addresses, billing-period resets, and historical archiving belong in the visualization, not in the bus traffic. Plan a recurring data export to whatever billing platform the property manager uses, so the data leaves KNX in a clean machine-readable format.