shub.hu — building automation
We design, install and program KNX systems, run structured cabling and mains wiring, and sort out existing Home Assistant setups. Control runs locally, so the switches keep working when the internet drops. We work on site anywhere in Hungary, and remotely for troubleshooting and consultation.
Not sure whether you need wired or wireless? Part of the survey is telling you what is not worth doing in that particular building.
This is how a mixed-protocol system is usually built — a general reference architecture, not a specific completed installation. At the top, the separated IoT network segment; below it, the locally running controller, which reaches the field level through four gateways: a KNX IP router to the TP1 bus (lighting, blinds, heating), a Zigbee coordinator to the 2.4 GHz mesh (sensors, buttons, relays), a Z-Wave stick to the 868 MHz mesh (blind motor, lock), and Modbus RTU to the RS-485 plant (heat pump, inverter, meter). The point is in the KNX branch: the bus switches independently of the controller, so a controller outage does not leave the house dark.
at a glance
what we do
From the physical layer up to the logic. We do not subcontract the part we are answerable for in the end.
Topology design, bus cabling, ETS programming. We also take over existing installations, even when the ETS project is missing.
Details 02Structured cabling, mains electrical and the camera network, installed under our own electrical qualification.
Details 03Stuck on your own system? Most faults can be measured and fixed remotely.
Details 04For a finished, occupied home: modules behind the existing switches and wireless devices, no wall chasing.
Detailswho we work with
You know what is installed and what you want from it — you are just stuck: something does not behave as it should, or you want to extend it and the documentation is missing. Survey, fix and handover, with one point of responsibility.
What we fixYou run your own system, but it has hit its limits: an unstable Zigbee network, unreliable automations, things breaking after updates. We can help remotely too.
Home Assistant troubleshootingKNX programming, commissioning or a second opinion as a subcontractor, on your project.
Get in touchEarly involvement, design documentation, multi-unit and apartment-building projects.
Talk to us about the projecthow the system is built
Devices rarely fail on their own. What fails is the way the layers fit together. From here on, this colour code runs through the rest of the page.
On a KNX bus the switch talks directly to the lamp actuator. The controller and the internet sit above it, for the logic and for remote access. That is why switching keeps working when the network or the provider goes down. The figure is a general reference architecture, and the latency shown is illustrative, not a measurement of a specific installation.
what people call us about
It is the way the layers fit together. These are the situations that come up most often — each with the symptom, the usual cause and what we do about it.
It works for a few days after re-pairing, then drops off again.
The automation runs sometimes, and sometimes it does not.
It works, but nobody can touch it.
the difference
Most faults show up where the electrician hands the job over to the system integrator, and from then on each points at the other. We have no such handover: the bus cable, the mains wiring and the structured cabling are done by the same team that does the programming.
process
Four steps, each listed with what you actually receive. The documentation and the project files are yours — we do not lock you in by making the system unworkable for anyone but us.
We go through what is installed today, what the goal is, and what is physically achievable in that particular building. If you already have a system, we look at that first — in many cases the answer is not a new system but fixing the existing one.
We design the topology: which layer controls what, where the bus lines and the structured cabling run, where the wireless segments sit, and what happens if the controller goes down. In a new build this is produced together with the electrical design.
Mains electrical work, bus cabling and structured cabling carried out under our own electrical qualification — we do not subcontract it. Programming follows: ETS for KNX, and the automation logic on the controller.
At handover you get the documentation and the credentials — the system is yours, not ours. We stay reachable afterwards for extensions, for troubleshooting after an update, or for a one-off consultation.
handover
A system is finished when you can see what is happening inside it — and when someone else can work on it after us. A documented device list, measured values, a backup policy.
| Device | Protocol | RSSI | Response | Status |
|---|---|---|---|---|
| Living room thermostat | Zigbee 3.0 | −58 dBm | 41 ms | OK |
| Outdoor camera — entrance | PoE / ONVIF | — | 12 ms | OK |
| Bedroom blind motor | Z-Wave 800 | −79 dBm | 318 ms | WARNING |
| KNX gateway — expansion | KNX TP1 | — | timeout | ERROR |
| Sauna temperature sensor | Matter / Thread | — | — | OFFLINE |
This is the kind of data a properly handed-over system gives back: protocol, signal level, response time and status per device, alongside the age of the backup, the Zigbee mesh router ratio, automation errors over 24 hours and the number of cloud-dependent devices. Every status carries a text label, not colour alone. The values shown here are illustrative — they are not data from a specific, completed installation.
frequently asked
It depends on where the building is. If the walls are open right now, a wired bus — KNX, DALI, structured cabling — beats wireless on lifetime and reliability, because it does not depend on batteries, radio noise or a vendor cloud. In a finished, occupied flat, wireless and behind-the-faceplate modules are the realistic route, and for lighting, shading and heating that is no longer a compromise. Most real systems are mixed: a wired backbone, with wireless filling in where cable is not worth it.
This is not an either/or, because they are not the same layer. KNX is the field bus: switching keeps working even if everything else is down, because the logic sits in the devices. Home Assistant is the controller: complex automation, the user interface and the meeting point of several protocols live there. Many systems are built so that KNX carries the basic functions on its own, with Home Assistant adding logic and interface on top — so a controller outage does not leave the house dark.
Zigbee is mature with an enormous device range; Matter/Thread is newer, IPv6-based, and pushes towards vendor independence. The practical point: both live on 2.4 GHz, so if they run alongside each other the channels and the Wi-Fi have to be planned together, or they degrade one another. Replacing a stable existing Zigbee network with Matter is not worth it today; in a new installation, though, it is worth designing in a Thread border router.
Z-Wave runs at 868 MHz in Europe, so it does not collide with Wi-Fi and penetrates walls better, at the cost of lower bandwidth and more expensive devices. Zigbee is 2.4 GHz, cheaper, with a far wider device range, but it shares the band with Wi-Fi and is therefore more sensitive to planning. If the house has a lot of reinforced concrete, Z-Wave usually means less pain.
[TBD: remote consultation pricing and billing unit]
We take on on-site work across Hungary, and occasionally in other EU member states. Remote consultation and troubleshooting are location-independent, so those are not limited to Hungary at all. The whole engagement — survey, design, documentation and handover — can run in English.
We build systems so that day-to-day operation runs locally: the bus and the local controller keep controlling without an internet connection. The internet is there for remote access and updates. Where a device can only be controlled through a cloud, we say so up front, and if there is a local alternative we recommend that instead.
At handover you get full access, the documentation, and for KNX the ETS project file as well. The system is yours — the fact that we built it does not stop anyone else working on it. An undocumented system that cannot be reverse-engineered is one of the most common problems people call us about.
compatibility
Organised by layer rather than by vendor — because the question is always which layer a given function is best solved in. A single system usually runs several of these side by side.
Control over dedicated cabling, independent of the network. The backbone in new builds and full renovations.
| System | Bridge | What it is | What we do with it |
|---|---|---|---|
| KNX (TP1 / IP / RF) | KNX IP router | Standardised building automation bus (ISO/IEC 14543). Runs on twisted pair, vendor-independent, and works without a central controller. | Topology design, terminal and cabling work, ETS programming, taking over and extending an existing system. |
| DALI | DALI gateway | Lighting control bus (IEC 62386). Addressable per luminaire for brightness, colour and fault feedback. | Designing and wiring DALI lines, fitting a gateway to KNX or the controller, addressing and scene setup. |
| Modbus (RTU / TCP) | RS-485 / TCP | Industrial protocol. Heat pumps, inverters, energy meters and ventilation units typically speak this. | Reading the register map, building the RS-485 segment with proper termination, wiring the data into the controller. |
| BACnet | BACnet/IP | Building management protocol (ISO 16484-5), typically found on larger mechanical plant. | Discovering and wiring existing BACnet points, fitting them to apartment- or office-level control. |
| 1-Wire | 1-Wire master | Simple, inexpensive sensor bus — typically temperature and humidity, where there are many measurement points. | Building the sensor network, matching long runs, wiring the data into logging. |
Retrofittable without opening walls. Requires network planning and a coverage survey.
| System | Bridge | What it is | What we do with it |
|---|---|---|---|
| Zigbee 3.0 | coordinator | 2.4 GHz mesh network. Battery devices are end nodes; mains-powered ones act as routers and forward traffic. | Channel selection to avoid Wi-Fi collision, planning router coverage, surveying and fixing an unstable network. |
| Z-Wave | controller stick | Sub-GHz mesh (868 MHz in Europe). Does not collide with Wi-Fi, lower bandwidth, good wall penetration. | Building the network, rebuilding routes, sorting out coexistence between older and 800-series devices. |
| Matter / Thread | Thread border router | IPv6-based mesh (Thread) and the device standard built on it (Matter). Multiple border routers can run redundantly. | Placing border routers, sorting out coexistence between Thread and existing Zigbee on the same 2.4 GHz band. |
| Wi-Fi | IoT VLAN / SSID | High bandwidth, but a separate IP and cloud dependency per device — not suited as an automation backbone. | Separate IoT SSID and VLAN, AP placement, moving cloud-dependent devices to local control where possible. |
| Somfy / Velux (RTS, io) | RTS / io gateway | Shading and roof window control on a proprietary radio protocol. io is bidirectional, RTS is transmit-only. | Wiring and configuring motors, fitting a gateway to the controller, end-stop and scene programming. |
The link between layers, and the high-bandwidth devices. Gets its own VLAN.
| System | Bridge | What it is | What we do with it |
|---|---|---|---|
| PoE / ONVIF | PoE switch | Power and data for cameras and indoor units on a single cable. ONVIF is the vendor-independent camera standard. | Structured cabling, sizing the PoE budget, local camera recording without cloud. |
| MQTT | broker | Lightweight message bus. Most protocol gateways hand their data to the controller over this. | Running the broker, designing the topic structure, setting up authentication and TLS. |
Where the logic lives: automations run here and every protocol meets here.
| System | Bridge | What it is | What we do with it |
|---|---|---|---|
| Home Assistant | — | Open-source controller that runs locally. Needs no cloud connection, and has an integration for nearly every protocol. | Setup, wiring in integrations, writing automations, backup and update policy, remote troubleshooting. |
| Loxone | Tree / Air | Closed vendor controller with its own bus system. Strong built-in logic, but vendor-locked. | Taking over and extending an existing Loxone system, bridging it to other protocols through a gateway. |
| ESPHome | native API | Local firmware for ESP32/ESP8266 devices. No cloud, declarative configuration. | Building custom sensors and controllers where no good off-the-shelf device exists; reflashing existing devices. |
Specific vendor ecosystems that we fit into the layers above.
| System | Bridge | What it is | What we do with it |
|---|---|---|---|
| Shelly | local API / MQTT | Relays and meters that fit behind a wall box. Fully functional over a local API, without cloud. | Fitting behind existing switches without opening walls, energy metering, wiring into the controller over the local API. |
| Sonoff / Tasmota | MQTT | Inexpensive devices, often reflashed to open firmware (Tasmota) to remove the cloud dependency. | Firmware replacement, switching to MQTT, organising and monitoring an existing Tasmota fleet. |
| Philips Hue | Hue Bridge (Zigbee) | Lighting ecosystem running its own Zigbee network on a dedicated bridge. | Wiring the bridge into the controller, resolving channel collisions between Hue and the other Zigbee network. |
| Aqara | Zigbee | Wide sensor range at a good price. Some devices show non-standard Zigbee behaviour. | Pairing directly to our own coordinator, bypassing the vendor hub; stabilising devices that keep dropping off. |
| Sonos | local network | Multiroom audio system with local network control. | Wiring into the controller, automating announcements and scenes, sorting out the network requirements. |
The list is not closed. If you have a system that is not on it, tell us — we will check whether there is a bridge for it, and say so if there is not.
contact
Describe what is installed today and where you got stuck. You do not need a finished plan — the point of the consultation is to work out what is realistic. The more specific you are (protocols, devices, controller), the more precise an answer we can give, even without a site visit.