Ahmed Al Badawy logo

Networking

Building a network your automation can actually rely on

By Ahmed Al Badawy · 11 October 2026 · 4 min read

A neatly organised equipment rack with labelled patch cabling, in cool navy tones

The network is infrastructure, not an accessory

A lighting or AV fault can turn out to be a network problem, so I check the network early. A control system that has to share an overloaded, unmanaged household network with streaming boxes, guest Wi-Fi, and every new IoT gadget in the house will eventually behave unpredictably — not because the control brand is unreliable, but because the foundation underneath it was never designed to carry it. If I'm specifying or reviewing a project, the network gets treated as core infrastructure, planned before the control system goes in, not retrofitted once something starts misbehaving.

Why I segment automation traffic onto its own VLANs

Virtual LANs (VLANs) let a single physical network be split into separate logical networks, so that, for example, guest Wi-Fi, household devices, and automation/control traffic can't see or interfere with each other unless you deliberately allow it. Ubiquiti's own documentation describes VLANs as a way to segment networks to improve performance and security, and to isolate devices so a problem or security incident in one segment doesn't spread to others — which is exactly the property I want in a home where a control system, a NAS, security cameras and general household devices all share one physical cabling plant [1].

In practice I keep a dedicated VLAN for core control and automation hardware (controllers, gateways, touch panels), a separate one for security/surveillance, another for general household devices, and a guest network that's isolated from all of them. Where devices on different VLANs genuinely need to talk to each other — a touch panel reaching a media player, for instance — that's handled deliberately through inter-VLAN routing and firewall rules, not by putting everything on one flat network for convenience [2].

  • Give control/automation hardware its own VLAN, separate from general household and guest traffic.
  • Put security and surveillance devices on their own segment too, rather than mixed in with everything else.
  • Use wired connections for anything that has to be reliable — primary controllers, gateways, and access points — and reserve Wi-Fi for client devices.
  • Only allow the specific cross-VLAN traffic that's actually needed, via explicit firewall rules, rather than leaving everything open by default.
  • Keep the guest network fully isolated from automation and security segments.

Backups: assume hardware will fail eventually

Every controller, gateway, or network appliance will eventually need replacing — through failure, end of life, or an upgrade. A configuration backup turns that into a routine task; without one, it turns into a full re-commissioning project, often at the worst possible time. I keep this simple and non-negotiable:

  • Export and store a current configuration backup for every controller, gateway and network device, immediately after commissioning and after any significant change.
  • Keep at least one copy of backups somewhere other than on the device itself — local storage failing alongside the device it was backing up defeats the purpose.
  • Label backup files clearly with device, location and date, so a future engineer (possibly not me) can identify the right one quickly.
  • Re-export backups after firmware updates, since a restored older backup may not be compatible with newer firmware.

Handover documentation: what I leave behind

A system is only as maintainable as the documentation left with it. I hand over a written record for every project, and I'd encourage any homeowner to insist on the same from whoever installs their system, regardless of who that is.

  • A network diagram showing every switch, access point, gateway and VLAN, with IP ranges and VLAN IDs noted.
  • A device list with make, model, firmware version, physical location and IP or hostname.
  • Login credentials, stored securely and handed over through a proper channel — never left as factory defaults.
  • A plain-language description of what each automation scene or rule is supposed to do, so a future engineer isn't reverse-engineering the logic from scratch.
  • Contact details for the installer, and a note of what's covered under warranty or support versus what would need a new engagement.

Where qualified trades take over

Everything here is network design, configuration and documentation work. Any new mains power circuits for network cabinets, PoE switches, or rack equipment must be installed by a qualified, licensed electrician in line with local regulations, and I always check the specific power and environmental requirements published by the equipment manufacturer before specifying a rack location — ventilation and power needs vary noticeably between switch and controller models.

More insights

Free consultation

Got a project?
Let’s figure it out.

Book a free 30-minute consultation with me.

  • 30 Minutes
  • Free
  • No Obligation
Or WhatsApp me
Chat with me