Network Design Guide for Shelly Gen2+ Devices

For Installers, IT Professionals, B2B Partners & Advanced Home Users

[BREAKING - FW 1.8] Firmware 1.8 enforces HTTPS, adds a 15-minute setup window, and hardens Bluetooth. Full details in Firmware 1.8 / EU RED Compliance Changes.

How to Use This Guide

This is a network guide. It explains what a network needs to look like so that Shelly Gen2+ devices work reliably. Start by finding your profile. Each profile section is self-contained - read yours and skip the rest.

Callout icons: ℹ = note · ⚠ = warning · [BREAKING - FW 1.8] = behaviour changes in firmware 1.8, action required before updating.

Find Your Profile

Profile 1 - Basic Home: No VLANs, no broker, no firewall rules. You need: a home router, the Shelly app, and about 15 minutes.

Profile 2 - Advanced Home: Shelly VLAN, Home Assistant, WebSocket/MQTT, WireGuard VPN, mDNS relay. You need: a managed router/AP, Home Assistant, Mosquitto, and Avahi.

Profile 3 - Small & Medium Business: Corp/Guest/Shelly VLANs, Fleet Manager SaaS, MQTT, VPN jump host. You need: Shelly Fleet Manager (SaaS), a managed firewall, and a VPN.

Profile 4 - Enterprise / Multi-Site: Standardised builds, change control, RBAC, SIEM, MQTT cluster. You need: MQTT cluster, Shelly Fleet Manager with RBAC, per-site Shelly VLANs, campus mDNS relays, and SIEM integration.

Profile 5 - Hotel: Per-room VLAN isolation or basic client isolation depending on AP platform, central staff control, PMS integration, optional Matter + Echo per room. You need: Shelly Cloud or Fleet Manager, Shelly Integrator API, BLU Assistant, and an AP platform with client isolation support (Variant A) or DPSK/iPSK + RADIUS (Variant B).

ℹ Not sure? If you know what a VLAN is and have more than 15 devices, start at Profile 2.

Network Foundations for Shelly Devices

2.1 Protocol Support by Generation

*Check the CSA certified product list for Gen3 Matter-capable models. **In Zigbee mode the Gen4 device leaves Wi-Fi entirely - no IP address.

2.2 Control Planes - HTTP, WebSocket, MQTT

Per-device limit: 6 simultaneous non-persistent RPC channels - per the Shelly RPC Channels specification.

• HTTP - right for simple commands or debugging. Not for reactive state without polling.

• WebSocket - right for real-time state without a broker.

• MQTT - right when devices need to dial out through a firewall, or fan state to multiple consumers. QoS fixed at 1 (at-least-once delivery), not configurable.

ℹ A device can have MQTT and WebSocket active simultaneously. No Shelly documentation specifies a device-count threshold for switching protocols.

2.3 mDNS, DNS-SD, and Bonjour

• mDNS (RFC 6762) - UDP 5353. Link-local only - TTL=1, never leaves the local L2 segment.

• DNS-SD (RFC 6763) - naming layer on top of mDNS. _service._protocol format.

• Bonjour - Apple's name for the combined stack.

Shelly service types: _shelly._tcp (Gen2+-specific) · _http._tcp (port 80) · _matter._tcp (Matter operational) · _matterc._udp (Matter commissioning, active pairing window only).

⚠ mDNS never crosses a VLAN boundary on its own. Configure an mDNS relay for segmented setups.

ℹ Client isolation architectural implication: When client isolation is enabled on the Shelly SSID, all device traffic, including multicast, must traverse the L3 gateway rather than being switched at L2. This is intentional: it forces mDNS through the relay and ensures all inter-device and device-to-controller traffic passes through the firewall policy. A relay is always required when client isolation is on, regardless of VLAN configuration.

mDNS relay by platform:

• UniFi (IoT Auto Discovery)

• Meraki MX (Bonjour Forwarding)

• Catalyst 9000 (DNA Service for Bonjour)

• MikroTik RouterOS 7.16+ (/ip dns set mdns-repeat-ifaces=)

• pfSense/OPNsense (Avahi)

• Omada 5.9+ (Settings -> Services -> mDNS)

• Linux/HA OS (Avahi, enable-reflector=yes)

• eero (not available).

ℹ For a live example of Shelly mDNS advertisements including IPv6 address behaviour by generation see Discovering Shelly Devices via mDNS in the Shelly KB. That article also links to an open-source Python discovery script which scans for _shelly._tcp and prints a table of all discovered devices with generation, firmware, and IP addresses - useful for auditing a site before and after deployment.

2.4 IPv6 and Matter

Matter (CSA standard) uses IPv6 for all post-commissioning communication. IPv4 alone is not enough.

IPv6 support follows the generation boundary: Gen3 and Gen4 devices support IPv6 and are the only generations that support Matter. Gen2 Plus devices support neither - if you are deploying Matter, your devices must be Gen3 or Gen4. Gen2 Pro devices support IPv6 inbound (fw 1.4.0+) but do not support Matter.

Inbound only: All Shelly outbound connections - cloud, MQTT, NTP, OTA, DNS - use IPv4 regardless of network IPv6 configuration. You do not need IPv6 egress firewall rules for Shelly devices. IPv6 is used for inbound control only: device web UI, RPC, and Matter hub-to-device traffic.

• SLAAC (RFC 4862) - devices obtain an IPv6 address from Router Advertisements. Every Shelly VLAN SVI must send RAs. Requires fw 1.4.0 or later - earlier firmware supports link-local IPv6 only and will not obtain a routable address.

• RA (Router Advertisement) - if blocked, devices never get a routable IPv6 address. Most common cause of Matter failures on segmented networks.

• ULA (RFC 4193) - private IPv6 (fd00::/8). Matter works fine with ULA - no public IPv6 required.

Matter ports: IPv6 TCP/UDP 5540 (bidirectional, hub ↔ device) · UDP 5353 -> ff02::fb (mDNS, must not be blocked).

ℹ Only relevant if IPv6 is enabled on your network or you are deploying Matter. If IPv6 is enabled, ICMPv6 must not be blocked at the Shelly VLAN boundary - specifically ICMPv6 type 134 (Router Advertisements) inbound on the SVI, and Neighbor Discovery (types 135/136) bidirectionally. Many enterprise firewalls block all ICMPv6 by default. Also check: RA Guard must not be active on Shelly-facing switch ports - it drops Router Advertisements at L2 before they reach devices, causing identical symptoms to a blocked RA firewall rule.

⚠ Most common Matter failure: "No Response" after pairing. Check: IPv6 on router? Shelly VLAN SVI sending RAs? ICMPv6 blocked at firewall? RA Guard on switch ports? ff02::fb blocked? On UniFi: IGMP Snooping on? Disable it. See Vendor-Specific Configuration.

2.5 Wi-Fi Optimisation

Signal targets: RSSI ≥ −67 dBm · SNR ≥ 25 dB. RF interference: co-channel (use RF scan tool) · adjacent-channel (use only 1/6/11) · metal back boxes (move AP or use Shelly Pro Ethernet) · high BLE density (use SNR as placement metric) · Zigbee on wrong channel (use Zigbee ch 25, see Wi-Fi Settings and Zigbee Coexistence).

2.6 Bluetooth - Three Jobs

Provisioning (BLE): Shelly app sends Wi-Fi credentials. No network impact after setup. BLU Gateway: Wi-Fi Shelly device forwards BLE advertisements from BLU sensors over Wi-Fi. BLU sensors don't appear on your network. Range ~10 m per gateway. BLU Assistant: pre-configures devices via BLE before installation. No network impact.

[BREAKING - FW 1.8] From firmware 1.8, BLE is disabled after provisioning (EU RED). Re-enabling opens a 15-minute window only.

2.7 DHCP and Device Naming

• Add a DHCP reservation (MAC -> fixed IP) after a device joins the network.

• Controllers and MQTT brokers: static IP or reservation + DNS A record.

• Don't set static IPs directly on device settings without excluding from the DHCP pool.

Naming pattern (Settings -> Device Name): Basic Home: room-function-## · Advanced Home: floor-room-function-## · SMB: site-area-room-function-## · Enterprise: site-bldg-floor-room-function-## · Hotel: property-floor-room-function-## (e.g. h1-02-214-light-01).

[BREAKING - FW 1.8] From firmware 1.8, the device's friendly name becomes its mDNS hostname.

Profile 1 - Basic Home

No VLANs, no broker, no firewall rules. Everything on the same home network. The Shelly app and Shelly Cloud handle remote access, automations, and firmware updates, no additional software needed.

Your router assigns IP addresses automatically via DHCP, no configuration needed. Most home routers default to 192.168.1.x or 192.168.0.x.

A single router comfortably handles a typical home Shelly deployment. If you have more than 30-35 Shelly devices on one AP, see the Wi-Fi Optimisation section.

Most dual-band consumer routers support multiple SSIDs, including budget models like TP-Link Archer, ASUS RT series, Netgear Nighthawk, and mesh systems like Deco and eero. See the Vendor-Specific Configuration section for platform-specific steps.

Wi-Fi Setup

Create two SSIDs on your router:

Shelly devices are 2.4 GHz only. A dedicated SSID prevents your router from steering them to 5 GHz or dropping them during band-switching.

Home-Shelly SSID settings:

• 2.4 GHz only

• Ch 1, 6, or 11

• 20 MHz channel width

• WPA2-PSK

• Client isolation: OFF

• Band steering: Disabled

• 802.11r: Disabled

Adding a Device

1. Create the Home-Shelly SSID as above.

2. Install the Shelly app and sign in (or create a Shelly Cloud account).

3. Tap + -> choose model -> follow the in-app guide, select Home-Shelly when prompted for Wi-Fi.

4. Device reboots and joins. The Shelly app discovers it automatically.

5. Optional but recommended: add a DHCP reservation in your router so the device keeps the same IP.

[BREAKING - FW 1.8] From firmware 1.8, the setup window is 15 minutes from first power-on. Don't power a device up until you are ready to add it.

Matter (Gen3 supported models and Gen4 only)

Gen4 devices include Matter natively - scan the QR code on the device label directly in your Matter-compatible app. No enable step required.

Gen3 does not include Matter by default and not all Gen3 models support it. Check the CSA certified product list for your model. If supported: update firmware to version 1.6 or later, then go to Settings -> Matter -> Enable and reboot. The device generates a QR code and numeric setup code. See Enabling Matter on Shelly Gen3 Devices for the full walkthrough.

A Matter-compatible hub is required. Common options: Apple TV (4K), Amazon Echo (4th gen+), Samsung SmartThings Hub, Google Nest Hub (2nd gen). The hub, your phone, and the Shelly device must all be on the same network during commissioning.

IPv6 must be enabled on your router - check your router admin panel for an IPv6 or Internet settings toggle.

⚠ Commissioning fails? Confirm: IPv6 is on · phone is on Wi-Fi (not cellular) · phone and device are on the same network · Gen3: firmware is 1.6 or later and Matter is enabled in settings.

Profile 2 - Advanced Home

Segmented network with a dedicated Shelly VLAN, Home Assistant for local-first automation, and optional MQTT for scale. VPN for remote access.

Admin LAN (e.g. 192.168.1.0/24)        Shelly VLAN (e.g. 10.40.0.0/22)
┌──────────────────────────────┐        ┌──────────────────────────────┐
│ Home Assistant (TCP 8123)    │        │ SSID: Home-Shelly (2.4 GHz)  │
│ MQTT Broker (TCP 8883 / TLS) │─L3 FW─│ Client isolation: ON         │──[Shelly]
│ mDNS Relay (Avahi)           │        │ VLAN tag: 40                 │
└──────────────────────────────┘        └──────────────────────────────┘
             │
     [WireGuard VPN] ← remote admin only

Control plane: WebSocket is Home Assistant's default - real-time, no broker, no polling. Requires TCP 80 (or 443 from fw 1.8) from HA host to device. Add MQTT when you need devices to dial out through the firewall (TCP 8883 TLS).

mDNS relay (Avahi): enable-reflector=yes in /etc/avahi/avahi-daemon.conf. Restart Avahi. Verify: avahi-browse -alr from the Admin network should show _shelly._tcp entries. For non-Linux platforms (UniFi, MikroTik, pfSense, Omada), see Vendor-Specific Configuration.

Firewall policy:

MQTT TLS: See Shelly TLS: Supported Certs and Config. Supported: TLS 1.2, PEM/DER, RSA-2048, ECDSA P-256/P-384/P-521. Not supported: TLS 1.3, PKCS#12/PFX, Ed25519, encrypted private keys. ⚠ TLS significantly reduces battery life on battery-powered Shelly devices.

Remote access (VPN): The VPN must provide L3 routed access to the Shelly VLAN - the Home Assistant host and any management workstation must be able to reach Shelly device IPs directly across the tunnel. For VPN platform setup, refer to your router or firewall vendor's documentation.

Profile 3 - Small & Medium Business

Corp (10.20/24)    Guest (10.30/24)    Shelly VLAN (10.40/22)
      |                  |                       |
     [APs]──────[L3 Firewall / Router]──[Switches + IGMP snooping + querier]
                         |
              Admin/Mgmt (10.10/24)
                         |
              [VPN/Jump Host]─[MQTT :8883]─[Fleet Manager Connector]

What you need: Shelly Fleet Manager (SaaS) · Managed firewall with VLAN support · mDNS relay with service filtering · VPN -> jump host · IGMP/MLD snooping + querier on Shelly VLAN (the querier must be configured on the Shelly VLAN L3 interface, not on a switch port - without it, snooping tables age out and multicast reverts to flooding).

Commissioning at scale: Stage devices with BLU Assistant over BLE before installation. After installation: verify in Fleet Manager within 2–3 min, add DHCP reservation, update inventory CSV (see DHCP and IP Addressing Template).

[BREAKING - FW 1.8] Unauthenticated setup limited to 15 minutes from first power-on. BLU Assistant provisioning before power-on avoids this. See Firmware 1.8 / EU RED Compliance Changes.

VLAN layout:

DHCP relay: If the DHCP server runs on the Admin VLAN (recommended), configure a DHCP relay agent on the Shelly VLAN L3 interface pointing at the DHCP server IP (ip helper-address on Cisco IOS/Catalyst, dhcp-relay on MikroTik, DHCP relay service on pfSense/OPNsense). Without this, Shelly devices on the Shelly VLAN will not receive an IP address and will never join the network.

Firewall policy:

VPN / jump host: The jump host must have L3 routed access to the Shelly VLAN to reach device web UIs and run diagnostic commands. All management traffic flows through the VPN - no direct WAN exposure to Shelly devices at any point. For VPN platform setup, refer to your firewall vendor's documentation.

Profile 4 - Enterprise / Multi-Site

┌──────────────── Core / Data Centre ─────────────────┐
│  MQTT Cluster (HA, TLS, per-device certs)            │
│  Shelly Fleet Manager (SaaS) + RBAC                 │
│  IPAM / DNS / NTP              SIEM / Log Aggr.      │
└─────────────────────┬───────────────────────────────┘
                      │ VPN / SD-WAN
       ┌──────── Site A ──────────┬──────── Site B ────────┐
       │  Corp/Guest/Shelly/Admin │  same structure        │
       │  APs + switches          │  per site              │
       │  IGMP/MLD + querier      │                        │
       │  mDNS relay (ACLs)       │  mDNS relay            │
       │  Jump host / change ctrl │  Jump host             │
       └──────────────────────────┴────────────────────────┘

Non-negotiable standards: Identical SSID names at every site · Client isolation ON everywhere · mDNS relay with service ACLs (_shelly._tcp only) · IGMP/MLD snooping + querier on every Shelly VLAN (querier on the L3 SVI) · Shelly VLAN subnets must be advertised across the WAN fabric (BGP, OSPF, or static routes) so the central MQTT cluster and Fleet Manager connector can reach device IPs at remote sites · Change windows for firmware updates (Fleet Manager, 48-hour soak) · Break-glass procedure per site.

MQTT cluster: Active-passive minimum. Topic naming: shellies/{site}/{device-name}/status and shellies/{site}/{device-name}/command. TLS 8883 with CA validation. Test failover quarterly.

Fleet Manager: RBAC - roles per site, 2FA required. OTA policy: 48-hour test group soak, then production. Weekly inventory reconciliation against IPAM.

SIEM: Forward MQTT broker auth logs, Fleet Manager event logs, firewall deny logs. Alert on: unexpected disconnections, failed auth, devices silent > 5 min, MQTT topic anomalies, unexpected firmware downgrades.

[BREAKING - FW 1.8] Audit before rolling out: (1) All HTTP/WS connections must switch to HTTPS/WSS. (2) Check HA and integration tool compatibility with wss://. (3) Update commissioning runbooks for 15-minute setup window. (4) Update monitoring for exponential backoff. (5) Flash encryption means reflashed devices lose factory provisioning permanently. Full change list: Firmware 1.8 / EU RED Compliance Changes.

Monitoring SLOs:

Profile 5 - Hotel

Variant A — any AP platform              Variant B — DPSK/iPSK capable platform
─────────────────────────────────        ────────────────────────────────────────
Single IoT SSID + client isolation       Hotel-IoT SSID (one broadcast, 2.4 GHz)
         │                                             │
    [All rooms]                       ┌───────────────┼───────────────┐
         │                        PSK-201          PSK-202         PSK-203
   Shelly Cloud                        │ RADIUS         │ RADIUS         │ RADIUS
   Integrator API                  VLAN 201         VLAN 202         VLAN 203
                               [Shelly+Echo]    [Shelly+Echo]    [Shelly+Echo]
                                             │
                                 Mgmt VLAN (10.1.1.0/24)
                        [Shelly Cloud / Fleet Manager · MQTT · PMS]

Which variant? Variant B if your AP platform supports DPSK/iPSK + RADIUS (Meraki, Aruba, Ruckus, UniFi Enterprise). Variant A otherwise. Room count and retrofit vs new build do not determine the variant - AP platform capability does.

Variant A — Basic isolation (any AP platform)

What you need (Variant A): Any AP with client isolation · Shelly Cloud · Integrator API · BLU Assistant.

Retrofit (Variant A): Existing AP placement may mean multiple rooms share a radio - client isolation blocks L2 between devices on the same AP but rooms sharing that AP remain on the same subnet. Acceptable where each room has a dedicated AP or where per-room subnet isolation is not required. Use Shelly Pro (Ethernet) where Wi-Fi coverage is poor - metal back boxes and thick walls are common in retrofit properties.

New build (Variant A): If DPSK hardware is not in scope, plan AP placement so each room has a dedicated AP - client isolation then provides equivalent per-room isolation in practice.

SSID settings (Variant A): 2.4 GHz only · Ch 1, 6, or 11 · 20 MHz · WPA2-PSK · Client isolation: ON · Band steering: Disabled · 802.11r: Disabled.

Management (Variant A): Shelly Cloud + Integrator API. PMS check-in triggers a welcome scene; check-out turns all devices off. On/off control only - complex scene logic requires Fleet Manager scripting or MQTT automation. Guests have zero IP access to device web UIs at any time.

Commissioning (Variant A): Stage devices with BLU Assistant before installation. Name devices using the hotel convention (e.g. h1-02-214-light-01). After installation: verify in Shelly Cloud within 2-3 min, add DHCP reservation, update inventory CSV (see DHCP and IP Addressing Template).

[BREAKING - FW 1.8] Unauthenticated setup limited to 15 minutes from first power-on. BLU Assistant provisioning before power-on avoids this. See Firmware 1.8 / EU RED Compliance Changes.

Variant B — Per-room VLAN isolation (DPSK/iPSK + RADIUS)

What you need (Variant B): Meraki, Aruba, Ruckus, or UniFi Enterprise with DPSK/iPSK + RADIUS · Shelly Cloud or Fleet Manager · Integrator API · BLU Assistant.

Retrofit (Variant B): Existing AP infrastructure can be retained if the platform supports DPSK - a firmware or licence upgrade on Meraki, Aruba, or Ruckus is often sufficient without changing cabling or AP placement. Use Shelly Pro (Ethernet) where Wi-Fi coverage is marginal - structured cabling already exists in most retrofit properties.

New build (Variant B): Plan VLAN architecture, AP placement, and PSK generation together before any device is ordered. Generate all room PSKs from a CSV and configure RADIUS mappings before commissioning starts - all PSKs must be VLAN-mapped before any device is powered on.

Wi-Fi isolation: One SSID across the property, unique PSK per room, each key RADIUS-mapped to a per-room VLAN at the AP. From the Shelly device side: standard WPA2-PSK - RADIUS and VLAN assignment are invisible to the device.

Two-tier management: Staff control on the Management VLAN via Shelly Cloud or Fleet Manager reaches all rooms centrally. PMS check-in triggers a welcome scene; check-out turns all devices off via the Integrator API (on/off only - complex scene logic requires Fleet Manager scripting or MQTT automation on the Management VLAN). Guests have zero IP access to device web UIs or APIs at any time.

Voice control — Matter + Echo per room (Gen3/Gen4 only): One Amazon Echo (4th gen or later) per room, provisioned with the room PSK. mDNS is link-local (TTL=1) - the Echo on VLAN 201 can only discover devices on VLAN 201 and cannot see other rooms. Installer commissions each room's devices to the Echo via Matter once during property setup; nothing resets at check-out. Do not use the Shelly Cloud Alexa skill - it routes cloud-to-cloud and exposes every device on the account, destroying per-room isolation. Gen4: Matter enabled by default. Gen3: fw 1.6+, Settings -> Matter -> Enable, model must be on the CSA certified list. Both: IPv6 SLAAC on every room VLAN SVI, ICMPv6 types 134/135/136 unblocked at the VLAN boundary. If IPv6 is not supportable on the property network, drop the Echo path and use Shelly Cloud + Integrator API only.

ℹ Zigbee mode (Gen4) is not viable in hotel deployments. In Zigbee mode the device leaves Wi-Fi entirely - no IP address, no Shelly Cloud, no Fleet Manager. Zigbee OTA is not supported; devices must switch back to Wi-Fi/Matter mode to update firmware.

Commissioning at scale (Variant B): Generate all room PSKs from a CSV and import via AP platform API before any device is powered on. Stage devices off-site with BLU Assistant - load room PSK and device name (h1-02-214-light-01). Create Fleet Manager groups by floor and wing before devices arrive. Matter commissioning must be done physically per room during the installer walkthrough - allow 5-10 minutes per room, cannot be done remotely.

[BREAKING - FW 1.8] Unauthenticated setup limited to 15 minutes from first power-on. BLU Assistant provisioning before power-on avoids this. See Firmware 1.8 / EU RED Compliance Changes.

⚠ mDNS must not be relayed between room VLANs. Configure the relay between each room VLAN and the Management VLAN only, filtered to _shelly._tcp. Cross-room mDNS is a security violation in this profile.

VLAN layout (Variant B):

DHCP relay (Variant B): Each room VLAN needs a local DHCP scope or a relay agent on its L3 SVI pointing at the DHCP server on the Management VLAN (ip helper-address on Cisco IOS/Catalyst, dhcp-relay on MikroTik). Without this, devices on room VLANs will not receive an IP address and will never join the network.

Firewall policy (Variant B):

VPN / jump host (Variant B): The jump host must have L3 routed access to all room VLANs to reach device web UIs and run diagnostic commands. All management traffic flows through the VPN - no direct WAN exposure to Shelly devices at any point.

Wi-Fi Settings and Zigbee Coexistence

Zigbee Channel Coexistence (Gen4 Zigbee Mode)

ℹ Recommended: Shelly SSID on Wi-Fi CH 1, main Wi-Fi on CH 6, Zigbee coordinator on channel 25.
⚠ Zigbee OTA firmware updates are not supported. To update firmware on a Gen4 device in Zigbee mode, switch back to Wi-Fi/Matter mode first (Settings -> Firmware -> Alternative Firmware), update, then switch back.

Ports, Flows, and Outbound Hostnames

Traffic Flows and Ports

Outbound Internet Hostnames - Gen2/3/4

Use FQDN-based rules only. Do not use IP addresses - Shelly services use CDN and load-balanced infrastructure that changes without notice.

⚠ Shelly does not currently publish an official firewall allowlist. These hostnames are confirmed from official Shelly API documentation and device configuration responses.

ℹ Local-only deployment: Disable Shelly Cloud + run MQTT/WebSocket locally + internal NTP = block all outbound except TCP 443 to updates.shelly.cloud for OTA. Fleet Manager self-hosted (github.com/ALLTERCO/fleet-management) eliminates fleet.shelly.com.

Matter Network Checklist

DHCP and IP Addressing Template

DHCP lifecycle: New device -> dynamic DHCP, short lease (1–4 hours). Production device -> DHCP reservation (MAC -> fixed IP), longer lease (7–30 days). Controllers/brokers -> static IP or reservation + DNS A record; exclude from DHCP pool.

CSV/IPAM template columns: name, mac, ipv4, vlan, site, room, function, generation, firmware, fleet_group, install_date, notes.

Vendor-Specific Configuration

Platform-specific steps for the most common network vendors. Use these alongside the profile firewall rules above.

Ubiquiti UniFi

Shelly SSID: Networks -> Create New Network -> name it, set VLAN ID (e.g. 40), subnet (e.g. 10.40.0.0/22), DHCP enabled. WiFi -> Create New WiFi -> name clearly -> Security: WPA2-PSK -> 2.4 GHz only -> VLAN: Shelly -> enable IoT Auto Discovery (mDNS). Advanced: Channel width 20 MHz -> Channel 1/6/11 -> disable Band Steering -> disable 802.11r -> disable Hi-Capacity Tuning on this SSID.

mDNS: Settings -> each relevant network (Shelly VLAN + Admin VLAN) -> enable IoT Auto Discovery. mDNS Proxy sidebar -> add service filter: _shelly._tcp. Add _matter._tcp and _matterc._udp only if using Matter.

⚠ UniFi + Matter: Settings -> Networks -> Multicast Settings -> Multicast Filtering -> select NO networks. Also: Shelly SSID -> Advanced -> Hi-Capacity Tuning -> Multicast to Unicast = OFF. Both are required for Matter to work reliably on UniFi. Reference: UniFi: Multicast and IGMP Snooping.

Zone-Based Firewall (UniFi OS 4.x+): Settings -> Policy Engine -> Policy Table -> Internal Zone. Create Return Traffic rule (Connection State = Established and Related -> Allow) at top. Create Shelly -> Trusted default block, add exceptions: MQTT TCP 8883 to broker, DNS 53, NTP 123, HTTPS 443.

Cisco Meraki (MX + MR)

Shelly SSID: Wireless -> SSIDs -> rename -> Security: WPA2 -> disable band steering. Access Control -> VLAN tagging: Custom VLAN (e.g. 40) -> enable Layer 2 LAN isolation.

Bonjour Forwarding (MX): Configure -> Firewall -> Bonjour Forwarding -> Add rule. Service VLAN: Shelly (40). Client VLAN: Corp/Mgmt. Services: _shelly._tcp. Add reciprocal rule. ⚠ If MR Bonjour forwarding is also enabled, disable it - running both causes forwarding loops.

MX Firewall Rules: Allow Shelly -> DNS 53, NTP 123, HTTPS 443, MQTT broker TCP 8883. Deny Shelly -> RFC 1918 (log). Allow Admin -> Shelly TCP 80, 443 from jump host alias.

Cisco Catalyst 9000 and 9800 WLC

Use the DNA Service for Bonjour built into Catalyst 9000 for policy-based, unicast mDNS routing.

mdns-sd service-definition shelly
 service-type _shelly._tcp.local
 service-type _matter._tcp.local
 service-type _matterc._udp.local
!
mdns-sd service-list SHELLY-IN IN
 match shelly
mdns-sd service-list SHELLY-OUT OUT
 match shelly
!
mdns-sd service-policy SHELLY-POLICY
 service-list SHELLY-IN IN
 service-list SHELLY-OUT OUT
!
interface Vlan40
 mdns-sd gateway
 service-policy SHELLY-POLICY
 active-query timer periodicity 60

MikroTik (RouterOS 7.x)

Shelly SSID and VLAN:

/interface wifi configuration
add name=iot-cfg ssid=Home-Shelly \
  security.authentication-types=wpa2-psk \
  security.passphrase=YourPassword \
  datapath.client-isolation=yes \
  channel.frequency=2412 channel.width=20mhz
/interface vlan
add name=vlan-shelly interface=bridge vlan-id=40
/ip address
add address=10.40.0.1/22 interface=vlan-shelly
/ip pool
add name=pool-shelly ranges=10.40.0.100-10.40.3.254
/ip dhcp-server
add name=dhcp-shelly interface=vlan-shelly address-pool=pool-shelly

mDNS Repeater - RouterOS 7.16+ (added October 2024, see MikroTik changelog):

/ip dns set mdns-repeat-ifaces=bridge,vlan-shelly

Note: Max 16 interfaces. No per-service filtering in the built-in repeater. For service filtering, run Avahi in a container instead.

pfSense and OPNsense

mDNS Relay (Avahi): pfSense: System -> Package Manager -> install avahi. OPNsense: System -> Plugins -> install os-avahi. Services -> Avahi -> Interfaces: select Shelly VLAN and Admin interface. Enable Reflector mode.

⚠ pfSense/OPNsense does not enable an IGMP querier on VLAN SVIs by default. Configure Services -> IGMP Proxy, or enable a querier on your managed switch's Shelly VLAN SVI. Without a querier, snooping tables age out and multicast reverts to flooding.

TP-Link Omada (Business Platform)

Wireless -> SSIDs -> Add SSID -> 2.4 GHz only, WPA2-PSK, bind to VLAN (e.g. 40), Wireless Isolation: On. Advanced: disable Band Steering, disable Fast Roaming (802.11r), Channel Width: 20 MHz. Settings -> Services -> mDNS -> Enable mDNS Relay -> select Shelly VLAN + Admin VLAN. Firewall: Allow DNS 53, NTP 123, HTTPS 443, MQTT 8883 from Shelly VLAN. Deny Shelly -> RFC 1918.

Amazon eero

⚠ eero does not support LAN-side VLAN segmentation - confirmed platform limitation. The VLAN option in the eero app (ISP Settings -> Uplink VLAN) is a WAN/ISP tag only. Reference: eero support: VLAN tagging on eero.

For Basic Home use, eero works well - Shelly devices on the main eero network, mDNS native, Matter works if IPv6 is on (eero app -> Advanced Settings -> IPv6 toggle). For segmentation: put eero in bridge mode behind a capable router. Note: eero Secure and HomeKit Secure Router features stop working in bridge mode.

TP-Link Consumer (Archer / Deco)

Deco: Deco app -> Home -> More -> IoT Network. Creates a 2.4 GHz SSID with device isolation. mDNS relay works by default. No VLAN support - for real VLAN segmentation, put Deco in AP mode behind a capable router. For VLAN support on Archer, check your specific model - higher-end models support 802.1Q on LAN ports.

Firmware 1.8 / EU RED Compliance Changes

[BREAKING - FW 1.8] Expected in firmware 1.8 - not yet released as of firmware 1.7.5 (March 2026). Source: Shelly official KB - What you need to know: Shelly and EU RED standard EN 18031-1.

Applies to ESP32-based devices (Gen2/Gen3/Gen4). Implements compliance with EU Radio Equipment Directive (RED, 2014/53/EU), cybersecurity standard EN 18031-1, mandatory from August 1, 2025. Some changes are breaking - plan your migration before rolling 1.8 to production.

Migration Checklist

Installer Deployment Checklist

A single-page reference for on-site deployment. Complete each phase before moving to the next.

⚠ This checklist covers network and device readiness only. Electrical installation must follow local regulations and be performed by a qualified electrician.

Phase 1 - Network Readiness (before devices arrive)

Phase 2 - Device Staging (before installation)

Phase 3 - On-Site Installation and Verification

Phase 4 - Handover

ℹ Quick fault reference: Device not on network -> check SSID/password, RSSI, DHCP lease on AP (and DHCP relay if VLAN-segmented). Device on network but not in app -> check mDNS relay, check _shelly._tcp with avahi-browse. Matter not working -> Gen3/Gen4 only; Gen3: fw 1.6+ and Matter enabled?; check IPv6 on Shelly VLAN (SVI sending RAs?), fw 1.4.0+?, ICMPv6 not blocked?, RA Guard off?, check port 5540, check UniFi IGMP snooping. MQTT not connecting -> check broker TLS cert, port 8883 firewall rule, broker log. Automation not firing -> check controller has current state (WebSocket connected?), check schedules and timezone sync.

Shelly Group Knowledge Base | Partner & Installer Technical Documentation | kb.shelly.cloud · shelly-api-docs.shelly.cloud

Author: Simeon Marinov