NextForGen is a smart home and building automation company based in Maltepe, Istanbul. For villas, offices and residential projects it handles everything from site survey to handover; lighting, climate, curtains and security come together in one place in the NextForGen hub and app.
How does a KNX installation connect to an app?
KNX devices mostly communicate over a twisted pair (TP) data line. For an app or an automation system to reach this line, the line has to be connected to the local network (IP). The chain usually looks like this:
- The KNX TP line. Switches, sensors and actuators.
- A KNX IP interface or IP router. Connects the TP line to the local network (KNXnet/IP).
- A hub or server. On the local network, it sends commands to group addresses and reads their status.
- The app. Control at home and away through the hub.
In this setup, the KNX installation's own programming doesn't change. The hub joins the line as a new participant and uses the existing group addresses.
KNX IP interface or KNX IP router?
Both connect the KNX line to the local network; they are used in different ways.
| KNX IP interface | KNX IP router | |
|---|---|---|
| Main job | Point-to-point connection of a client to the line (tunneling) | Forwarding telegrams between lines and areas (routing); also used as a line coupler |
| Connection type | Tunneling | Routing (IP multicast); most models also support tunneling |
| Simultaneous connections | A limited number of tunneling connections, depending on the model | No limit in routing; the number of tunneling connections varies by model |
| For integration | One free tunneling connection is enough | Can be connected through tunneling or routing |
If the installation already has an IP interface, we check whether a free connection remains besides its other users, such as ETS and any existing visualization. KNXnet/IP uses UDP port 3671 on the local network; the standard multicast address for routing is 224.0.23.12.
Connection counts and features vary by model; check the manufacturer's documentation for exact details.
What is a group address and why does integration need it?
In KNX, devices send commands to each other through group addresses. Group addresses are usually written in three levels (e.g. 1/2/3: main group / middle group / sub group). For example, "living room ceiling light on/off" is a group address; the actuator linked to that address carries out a command sent to it.
Every group address has a data type (DPT, datapoint type). The app can send the right command only if it knows the right data type:
- DPT 1.001: on/off (switch)
- DPT 5.001: percentage (0-100), e.g. dimmer level or curtain position
- DPT 9.001: temperature (°C)
That's why the first step of an integration is getting the installation's group address list together with its data types.
Why do status addresses matter?
When a light is switched on from a wall switch, the actuator has to report its state to a separate group address for the app to see it. This is called a status (or feedback) address.
For functions with a status address, the app shows the device's real state. For functions without one, the app can only know the last command it sent itself. Missing status addresses can be filled in with a small addition in ETS by the company that programmed the installation.
What should you get from ETS?
- The ETS project file (.knxproj) or a group address list exported from ETS (CSV or XML).
- The security key file (.knxkeys). Only for installations that use KNX Secure.
- The IP interface's network details. Its address on the local network and its available connection.
These files are usually held by the company that installed the system, and you can ask for them to be handed over to the homeowner at completion. If there is no project file, group addresses can be worked out by inspecting the installation; that takes longer.
What changes for installations that use KNX Secure?
KNX Secure is the security layer that encrypts and authenticates KNX communication. It comes in two forms: KNX IP Secure protects the IP side of the connection (tunneling and routing); KNX Data Secure protects telegrams on the line end to end.
To connect to an installation that uses Secure, you need the security key file (keyring) exported from ETS and the related passwords. This file and these passwords are among the most sensitive information about the installation; share them only with the team doing the integration.
How do you get secure remote access to KNX?
Exposing a KNX IP interface directly to the internet through port forwarding is not recommended: KNXnet/IP is designed for use on a local network. The safer way is for a hub or server on the local network to open an outbound encrypted connection to the cloud, and for the app to work over that connection.
The NextForGen hub works this way: it starts the connection itself, encrypted. So you don't need port forwarding, a static IP or a VPN; the KNX IP interface stays on the local network.
Details: KNX integration
What is the pre-integration checklist?
- IP interface. Does the installation have a KNX IP interface or IP router, and is there a free connection left?
- Group addresses. Do you have the group address list with its data types?
- Status addresses. Are status addresses defined for the functions whose state should be visible in the app?
- KNX Secure. Does the installation use Secure and, if so, is the keyring file available?
- Local network. Can the IP interface and the hub connect to the same local network?
- Scope. Which functions will come into the app, and which scenes will be set up?
We check this whole list together during the site survey; anything missing is noted in the written quote.