For years you have operated the house through its push-buttons, and that works. Now an interface is to be added: the house at a glance, scenes, schedules, access while away. The real decision is not which device goes on the wall, but what the visualisation should be able to do — and what stays on the push-buttons. That decides whether a lean IP interface with an app is enough or whether it becomes a visualisation server with its own logic. We plan both manufacturer-independently on the basis of the existing ETS project, with remote access without open port forwarding — and we tell you beforehand what a visualisation cannot deliver.
Is a window open, is the heating running in the guest room, is the gate closed? The wish behind this is first of all an overview: all the states of the house in one place. Technically the lean route is enough for that — an app via an IP interface shows what the system reports. Whether it reports everything you want to see is the first check in the project.
The evening lighting at a single touch, the roller shutters by time of day, the temperature lowered at night. A KNX system can do much of this without an interface; changing it then takes the ETS or the device itself. On a visualisation server you create and adjust scenes and schedules yourself, without anyone having to come out for it. If that is what you want, you choose the server.
Raising the heating before you return, checking from the office whether everything is off, receiving a notification when something is wrong. The secure route there can be planned — via a VPN or a manufacturer's maintained solution. The second question is scope: from afar you see what the system at home reports; a window contact only reports if it exists.
A panel in the hallway or by the entrance makes the interface part of the house: everything off when you leave, a look at shutters and lighting when you arrive, usable by guests without explanation. At its position it needs a power supply and a route into the network — what form these take is decided by the device, and both belong in the planning before one is chosen; it is mounted on the wall by our own electricians from elektrofabrik or by your own contractor.
Which rooms, which trades, who operates it — you, the family, guests? What does the interface take on, what stays on the push-buttons? From this follows the route: the IP interface with an app for overview and control, the visualisation server as soon as scenes, schedules, logic or notifications are added. The two routes answer different wishes. Whether values from the energy systems appear depends on their integration — our extension page describes that.
Three things need to be in place: access to the bus — an IP interface or the server itself —, the ETS project with comprehensible group addresses and a home network that holds up where the system is to be operated. We use an existing interface, though it only serves a limited number of simultaneous connections; if one is missing, we plan it in — it is fitted in the distribution board by our own electricians from elektrofabrik, our sister company, or by your own contractor.
Whether a light appears as on or off in the interface depends on the status feedback from the actuators. If these objects were never linked to group addresses in the project, the visualisation shows assumptions instead of states — then we amend the ETS project, and every affected device receives a new download with a brief interruption to its function. We bundle such downloads and announce them in advance.
A visualisation does not make an untidy system better, it displays it — room by room, on every tile. If the group addresses carry no comprehensible names, naming them belongs at the start of the undertaking, otherwise the interface inherits the disorder of the project. And if the ETS project is missing entirely, the system readout belongs before the visualisation — the route there is shown in our KNX service overview.
For access from outside there are two clean routes: a VPN into your home network or the maintained remote access solution from the manufacturer of your visualisation. We do not plan port forwarding straight to the KNX interface, because classic communication with the bus is unencrypted. If the ETS project is protected by a password or the system runs KNX Secure, the password and keyring belong in the planning from the start — and in the documentation you receive at the end.
At the end you receive the updated ETS project, the visualisation project and the documented access credentials — complete enough that you are not tied to us. And because a visualisation server, like any device on the network, needs updates, we clarify before the decision who will maintain it in future. The push-buttons keep their role: the visualisation complements the operation of the house, it does not replace it.
In commercial properties too: there the interface is less a comfort than an operational tool — fault messages that reach someone, schedules per zone and tiered user rights, so that building services see everything while an individual tenant area sees only itself.
Which visualisation suits your system is decided by the ETS project, the IP connection and what you actually want to operate day to day. Four questions, then we sort it out together.
Even "in your case this is not worth doing" is a result we will tell you. Both cost you nothing.
Rather talk straight away+49 211 838 66 870If three foundations are in place, yes: access to the bus via an IP interface or a server with its own bus connection, the ETS project and a home network that is reliable where the system is operated — the Wi-Fi for a tablet, the connection at its position for a panel. The bus itself stays as it is: the visualisation joins as a further device and works with the group addresses your push-buttons already use — supplemented by status feedback where it is missing from the project. The age of the system matters less than its condition — a well-kept older project is a better foundation than a young one in which nobody understands the addresses any more. Without an ETS project the undertaking starts one step earlier, with reading out and documenting the existing system; there is a separate page for that.
In the scope of functions, not in quality. The IP interface with an app shows what the system can do today: switching, dimming, moving blinds, viewing states. The visualisation server adds a layer of its own: scenes and schedules you change yourself, logic, notifications, recording of values, depending on the solution also maintained remote access. Which route fits follows from the decision on the scope of functions — and it may turn out small: if the interface with an app is enough, we do not recommend a server, even though it would be the larger order. Manufacturer-independent here means: there are several providers for both routes, and we only commit once the scope of functions is settled.
As secure as the route it runs over. An interface exposed to the internet through open port forwarding is reachable by anyone who finds it — so we rule that route out. Instead we plan a VPN into your home network or the remote access solution from the manufacturer of your visualisation, provided it is maintained and receives updates. If the ETS project is protected by a password or the system runs KNX Secure, we take the password and keyring into the planning; the access credentials are documented and handed over to you. And an honest limit: absolute security does not exist here either — which is why remote access nobody needs is simply not set up.
Yes — and that is not a fallback answer, it is the concept. The push-button beside the door works for everyone immediately: for children, for guests, and even when the tablet is flat or the Wi-Fi is down. The visualisation takes on what a push-button cannot do well: the overview of the whole house, scenes and schedules, access while away. If a push-button is to be reassigned in the course of the project because a function moves into the interface, that is parameterisation in the existing project — feasible, but a conscious decision: what happens daily and in passing is better left on the push-button.
We do not quote a flat rate, because it would say nothing: the effort depends less on the device than on what it is meant to show — how many rooms and trades appear on the interface, whether the status feedback in the project is already connected, whether scenes and schedules are created and whether remote access is added. Only once this scope of functions is settled can the question of price be answered seriously. The roles remain clearly divided: planning, programming and documentation come from us; the interface in the distribution board and the connection of the panel are handled by our own electricians from elektrofabrik — our sister company — or by your own contractor. The project, the documents and the access credentials are handed over to you.
The visualisation is one of several routes for a system that is already in place. The overview sorts by your starting point — from extension through modernisation to the system readout.
To the KNX service overview →smartfabrik is a smart home planning practice based in Düsseldorf (Reisholzer Werftstr. 31A). We plan for private clients and companies in Cologne, Düsseldorf and across North Rhine-Westphalia — and, where wanted, nationwide and internationally. A selection of the places we have already planned and delivered in:
You are currently viewing a placeholder content from Facebook. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou need to load content from reCAPTCHA to submit the form. Please note that doing so will share data with third-party providers.
More Information