VLANs, MQTT and Energy Optimization

Most smart homes fail for one reason:

they are built like consumer products, not like systems.

A reliable smart home must be engineered like infrastructure:

  • Clear network segmentation

  • Deterministic communication

  • Local-first control

  • Measurable energy logic

  • Failure tolerance

This is how I structured mine.

1. Network Architecture: Isolation First

If all your devices sit in one flat LAN, you don’t have a smart home — you have chaos.

Network segmentation strategy

I split my infrastructure into:

  • Main LAN → Workstations, servers, NAS

  • IoT VLAN → Shelly, Zigbee gateways, sensors

  • Management VLAN → Controllers, automation servers

  • Guest VLAN → Completely isolated

Why this matters

  • Broadcast containment

  • Reduced attack surface

  • Predictable latency

  • Clean firewall policies

IoT devices should never initiate connections to your main LAN.

IoT VLAN → Allow to MQTT Broker (port 1883)
IoT VLAN → Allow to Home Assistant
IoT VLAN → Block to Main LAN

 

Deterministic access only.

2. Local-First Control Plane

Cloud-only automation is fragile.

I run a local controller layer (e.g., Home Assistant or similar orchestration engine) that:

  • Hosts all automation logic

  • Subscribes to device states

  • Executes rule evaluation locally

  • Works offline

Cloud APIs are treated as:

  • Non-critical

  • Optional enhancement layer

If the internet dies, lights and heating still work.

That’s non-negotiable.

3. MQTT as the Backbone

MQTT is the nervous system.

Why MQTT:

  • Lightweight

  • Event-driven

  • Decoupled

  • Scalable

Instead of polling devices, everything publishes state changes.

Example:

topic: home/livingroom/motion
payload: ON

Controller reacts only when state changes.

No constant REST polling.

No unnecessary traffic.

4. Zigbee + Z-Wave + WiFi Strategy

Mixing protocols blindly is a mistake.

My approach:

  • Zigbee → Sensors (motion, temperature, door contacts)

  • WiFi (Shelly etc.) → Actuators (relays, power monitoring)

  • Hardwired where possible → Critical components

  • Z-Wave → Sensors (motion, temperature, door contacts)

Zigbee/Z-Wave advantages:

  • Low power

  • Mesh-based

  • Stable for sensors

WiFi is used only where:

  • Power monitoring is required

  • Relay control is necessary

IoT WiFi devices must sit in isolated VLAN.

5. Heat Pump + SG-Ready Optimization Logic

Energy logic is where automation becomes engineering.

Instead of:

“If PV production high → turn on heating”

I use condition stacking.

Example logic:

IF

  • House unoccupied

  • PV production > 4 kW

  • Buffer tank < 50°C

  • Outside temperature > -5°C

    THEN

  • Activate SG-Ready boost mode

  • Raise target temperature

  • Log event

This turns excess PV into thermal storage.

6. Energy Monitoring & Data Logging

No optimization without telemetry.

I log:

  • PV production (kW + cumulative kWh)

  • Heat pump cycles

  • Defrost events

  • Power draw per phase

  • Buffer temperature trends

  • Outdoor temperature

  • Network latency

Data stored in:

  • Time-series database (InfluxDB or similar)

  • Visualized via dashboards (Grafana / custom)

Once you see:

  • Defrost frequency vs humidity

  • COP vs outside temperature

  • Standby losses overnight

 

You stop guessing.

 

7. Automation Design Philosophy

Automation should be:

  • State-driven

  • Context-aware

  • Failure tolerant

  • Observable

Bad automation:

IF motion → light ON

Good automation:

IF motion
AND illuminance < 40 lux
AND presence = true
AND time between 18:00–23:00
THEN dim light to 60%

Even better:

Include fallback state recovery if device offline.

8. Resilience & Failure Scenarios

Engineering means planning failure.

Questions I always ask:

  • What happens if MQTT broker crashes?

  • What happens if controller reboots?

  • What happens if Zigbee mesh collapses?

  • What happens if one Shelly freezes?

Critical systems:

  • Must fail safe

  • Must default to manual override

  • Must never block heating or lighting

Physical switches remain functional. Always.

9. Observability > Convenience

Most people want convenience.

I want observability.

If something behaves unexpectedly, I can:

  • Inspect logs

  • Replay state changes

  • See exact trigger chain

 

That’s the difference between hobby automation and engineered automation.

 

Final Thought

A smart home is not about gadgets.

It’s about:

  • Deterministic design

  • Clean architecture

  • Measurable performance

  • Energy efficiency

 

If you treat your home like a distributed system,

it behaves like one.