Home Assistant on Docker with Tapo/Matter, IoT VLAN networking, and wall panel... looking for setup steer

Configuration
1

Hi all. Totally new to the forum so please let me know if I'm breaking any rules with my post! I'm planning my first Home Assistant setup and want to get the architecture right before I start. I've done a fair amount of research and had some useful pointers already, but I'd like to consolidate everything into one proper thread before I dive in.

My existing setup

I run a home server (Dell OptiPlex 3000 SFF, i5-12500, 24GB RAM, Ubuntu Server 24.04) with a Docker stack covering Emby, Sonarr/Radarr, Calibre-Web, and various other services. The network is reasonably well thought out: IoT devices are on a segregated VLAN 20 (192.168.20.0/24), main LAN is 192.168.8.0/24, router is a GL.iNet Flint 2 running OpenWrt. I also have a couple of spare Raspberry Pi 3Bs.

My motivation for Home Assistant is primarily reliability. My Tapo devices drop offline every time there's an internet blip, which is frustrating. Local control is the goal.

1. Docker Container vs dedicated hardware

My plan is to run HA in a Docker container on the main server rather than on dedicated hardware or HAOS. I understand the Supervised install method is where things get complicated and fragile, but that Container mode (standard homeassistant/home-assistant image) works fine as long as you don't need the add-ons supervisor (correct me if I'm wrong!)

I've had confirmation from someone who's run it this way for three years without issues, and the general view seems to be that anything you'd use an add-on for can just be run as a separate Docker container anyway (ESPHome was given as a specific example). That approach suits me fine since I already manage a compose stack.

The Pi 3Bs in my plan would be used purely as dumb kiosk terminals running Raspberry Pi OS Lite with Chromium in kiosk mode pointed at the HA dashboard. They wouldn't run any HA processes.

Is there anything I'm missing about Container mode that would push me towards dedicated hardware? Any Container-specific system-breakers worth knowing about?

2. Tapo devices and the Matter/H200 approach

My Tapo kit:

  • P100 and P110 smart plugs
  • L510 and L430C bulbs
  • H200 hub
  • C560WS outdoor camera
  • D100C doorbell
  • Two Alexa Echo devices (on the same IoT VLAN, not Tapo)

I've had two different approaches suggested and want to understand the tradeoffs:

Option A: Standard Tapo integration with local control Enable third-party compatibility in the Tapo app per device, then use the built-in Tapo integration with local polling via the KLAP protocol. Someone mentioned this works fine for their L530 bulbs. The obvious downside is polling rather than push, which apparently matters a lot for anything sensor-based.

Option B: Enable Matter on the H200 hub Someone suggested enabling Matter support on the H200 hub rather than using the Tapo integration at all. The benefit is local push instead of local polling, which is more responsive and more appropriate for sensors. I haven't done much research on this yet. I also imagine that for my devices that don't connect to the hub at all this just wouldn't work?

A few questions here:

  • Which approach is actually recommended for a Tapo-heavy setup? Is Matter on the H200 stable and well-supported in HA?
  • Does Matter via the H200 cover all the device types I have, or only some of them? I'd assume the cameras and doorbell won't be covered? And any devices that connect directly to my router rather than the hub?
  • If I go the Matter route, i guess the Tapo integration doesn’t redundant, I need both?
  • For devices the H200 doesn't cover (camera, doorbell), what's the recommended approach?

I'm not looking to replace anything with Zigbee or Thread right now. I want to get what I have working properly first. Open to switching over time but would rather not replace dozens of devices (at a hefty cost no doubt...)

3. IoT VLAN networking

This is the bit I'm least sure about. My IoT devices are on VLAN 20 and HA will run on the main server at 192.168.8.10. HA needs to reach the IoT VLAN to control devices, not just receive traffic from it.

Someone suggested an approach I found interesting: rather than setting up cross-VLAN firewall rules, they gave their HA host a second IP address on the IoT VLAN by creating a VLAN subinterface. That way HA has an address in both networks and can talk to IoT devices directly.

On Ubuntu 24.04 this would be done via Netplan rather than nmtui. A few questions:

  • Is the subinterface approach actually better than cross-VLAN firewall rules, and if so why?
  • For Netplan on Ubuntu 24.04, what does the config for a VLAN subinterface look like in practice?
  • If HA gets an address on VLAN 20, what's the correct way to ensure that IoT devices can only reach HA and not anything else on the main LAN? I don't want to undo the VLAN isolation I've worked to set up.

4. Wall panel

The centrepiece of this setup is a kitchen wall panel that my partner can use day-to-day. Requirements:

  • Full device control via a Lovelace dashboard
  • Multi-room music control via WiiM (I have a WiiM Pro and a couple of their cheaper devices; I understand there's a native HA integration)
  • Access to my Emby server and live TV channels (I run ErsatzTV feeding into Emby as Live TV)

I'd like to expand to smaller terminals in other rooms over time, all pointing at the same HA instance.

A few questions:

  • How good is the WiiM integration in practice? Can you control playback and grouping properly from a Lovelace dashboard?
  • Is inline Emby or HLS live TV playback within a Lovelace dashboard actually usable, or is it more realistic to have buttons that open Emby in a separate browser tab?
  • Is a Pi 3B adequate for a kiosk browser panel, or is 3B vs 4 a meaningful difference for this use case?

Backup approach

I've been told that for Container mode, backups are essentially just the /config directory, and that HA's built-in backup tool also works and produces a restorable snapshot. I'd integrate this into my existing Backblaze B2 rclone backup setup. Anything else worth knowing here?

Thanks in advance. Happy to provide more detail on the network setup if it helps.

2

Be VERY careful about Vlans. HA is designed to work on a flat network. While you can make things work, you need to be on your networking game to make it happy. That's more trouble than I want to deal with. Plus if you ever want Matter devices, they require IPV6 and a flat network as well for less hassle.
Container install that uses Docker sounds like a good path for you. If you want to run stuff like Apps (Add-on's no longer exist and are called Apps now) there is this site to help you find something. GitHub - awesome-selfhosted/awesome-selfhosted: A list of Free Software network services and web applications which can be hosted on your own servers · GitHub

1 Like
3

Thanks for the heads up on the VLAN complexity. A bit of context on my setup that might be relevant:

I already have Avahi running as an mDNS reflector on the router (OpenWrt, GL.iNet Flint 2) to bridge VLAN 1 and VLAN 20, which I put in place for other cross-VLAN discovery needs. So mDNS reflection is already handled.

The Matter/IPv6 point is the one I'm less sure about. I've been advised to enable Matter on my Tapo H200 hub rather than use the standard Tapo integration, specifically because it uses local push rather than local polling. But if Matter requires IPv6 multicast to work reliably across VLANs, that's a pretty serious limitation that I need to understand before committing to that approach.

So a specific question: with mDNS reflection already in place, what specifically breaks with Matter on a VLAN setup? Is it purely the IPv6 multicast for device discovery, or are there other failure modes? And is there a known working configuration for this (IPv6 multicast forwarding on OpenWrt, for example) or is it genuinely unsolved territory?

If the answer is that Matter across VLANs is just too painful, I'd want to understand what that means for the Tapo integration path instead and whether local push is achievable without Matter.

4

Matter & Thread Deep Dive.

Enterprise Smart Home Syndrome.

5

Thanks for both links, the Frenck piece especially made me smile because he's not wrong. But I want to give some context for why the VLAN exists, because it's not really an enterprise-brain thing.

Earlier this year my TerraMaster NAS was compromised. It had been internet-exposed via a port forward before I set up WireGuard for remote access, and during that window an automated scanner found it and exploited a known command injection vulnerability in the TOS web UI. The attacker injected shell commands via the shared folder user permission fields, which the NAS backend executed without any sanitisation.

They planted a fully functional PHP file upload web shell at /usr/www/upp.php, a ransomware binary, and an RSA public key to pair with it. The ransomware failed to execute only because it was compiled for x86-64 and the NAS is aarch64. The web shell was confirmed fully functional by nginx's PHP-FPM configuration, but showed no evidence of ever being called. Two separate strokes of luck prevented data loss.

Fixing it involved SSHing into the NAS, deleting the artefacts, and editing the TOS SQLite config database directly to remove two malicious entries that had been injected as fake usernames and were being regenerated from the database on every boot.

The IoT VLAN came out of that incident. TOS 4 runs a 2019 kernel and will never receive security updates, so the NAS is permanently unpatched. The VLAN means that even if something on the IoT network is compromised, it cannot reach the NAS directly. That felt like a non-negotiable precaution given the history.

So the complexity isn't there because I enjoy complexity. It's there because I had a real incident, did a proper post-mortem, and implemented mitigations that made sense given the residual risk.

With that context: I take the point about HA wanting a flat network. The subinterface approach (giving the HA host an address on VLAN 20 via Netplan) seems like the right middle ground. HA gets direct access to IoT devices, multicast works, and the rest of the network segmentation stays intact. Does that hold up for WiFi-based Matter devices via the H200, or is there still a gap I'm not seeing?

6

Same can be done with firewall rule.
Basically block all connection into Terramaster from all devices except whitelist devices on specific ports. Ultimately this is more secure and should be done regardless of using vlan or not

I think the only real point of vlan is simplifing firewall rule application using dhcp (basically each SSID has different firewall rule). Outside of that I’m not sure vlan has purpose on home
Network. Maybe prevent listening to some
Device but if https does it matter? Maybe broadcast and multicast listening is issue?

Docker macvlan may also interest you. That may be the sub interface your referring to

7

On the firewall rules point, I do have rules in place and agree they should exist regardless. But I'd push back a bit on VLANs being mainly about simplifying firewall rule application. The segmentation works at layer 2, so IoT devices can't see main LAN traffic at the Ethernet level at all. No ARP spoofing, no rogue DHCP, no broadcast bleed. Firewall rules on a flat network are better than nothing but they're not the same thing, because all devices are still on the same L2 domain. Given my NAS runs an unpatched 2019 kernel and always will, keeping it off the same L2 segment as the IoT devices felt worthwhile.

The macvlan suggestion is interesting though, hadn't considered that approach. My understanding is it gives a container its own MAC and IP directly on a physical network segment, so the HA container could sit natively on VLAN 20 without needing a host level subinterface. Is that right? Only limitation I'm aware of is that macvlan containers can't communicate back to the Docker host on the same interface. Is that a problem in practice for a typical HA setup, or is HA's traffic mostly outbound to devices?

8

I have similar setup.
Opnsense as gateway and openwrt running batman-adv for local wifi and local net.
I use vlans, that are configured on opnsense and distributed across all local network using bamtman-adv,
I also use server with docker compose running ha and other addons aka docker containers.
Setting is totally doable. Yes, I might take a bit time to figure everything out but there is no rush.
Take your time.
I don't use matter so I don't know will you have problems with it.

9

I understand this but question was is this really needed on residential network. Are there not other methods that can be used for for rouge dhcp and arp spoofing? In a commercial environment managing vlans is a team effort but in residence this becomes a long term pain so in a perferct world you could use flat network and apply rules as devices join by dhcp. But yes, for your concerns vlans may be only way. for my concerns dhcp/rules are the holdback.

yes. but i created 2 specific docker networks for my containers to communicate. network 1 has access to internet and local lan. network 2 has no internet access and can only reach containers within the network. Network 2 also cannot reach local lan.

for example
homeassistant is on network 1 as it needs internet access for downloads
i have a home budget container that is on network 2 because it is self contained
I also have containers I dont fully trust on network 2 to limit its access on local network

i have a caddy reverse proxy that sits on both docker network1 and 2. I access most containers through caddy. I have a local only domain name and caddy pulls certs to provide https to all sites.

Container to container connections use docker hostnames and docker network. macvlan containers function like a true separate server/host in my experience and also can be assigned a static IP on your network. My HA container has IP on both my matter vlan and server vlan. It also has separate docker IPs on the network 1 and 2 (docker Ip doesnt matter as hostname is used). only concern here is rouge container but that exists regardless of this setup.

10

Good to hear it's working well for someone with a similar setup. The "no rush" point is well taken, I'm planning this out properly before touching anything. If you do ever venture into Matter territory I'd be curious to hear how it goes with that network topology.

11

That's a really clear explanation, thank you. The two Docker network approach makes sense and is actually close to what I already have, with Caddy sitting in front of everything. The key bit I was missing is that macvlan containers can hold IPs on multiple networks simultaneously, so HA gets an address on both the IoT VLAN and the main server VLAN without needing a host level subinterface at all. That's cleaner than what I'd been planning.

On the residential VLAN point, yeah for sure. In most home setups the overhead probably isn't worth it. My specific situation is that my NAS runs permanently unpatched firmware and always will (well, until I build myself a new NAS myself...), so I wanted hard L2 separation between it and the IoT devices rather than relying on rules alone. If the NAS were running something with an active security update cycle I'd probably agree with you.

One follow up: with HA on macvlan holding IPs on both networks, does mDNS and Matter multicast just work as expected, or did you need any additional configuration to get multicast traffic flowing correctly across both interfaces?

12

Mdns/multicast works on respective vlans if I remember. I don’t believe there are any issues. I still have mdns reflector and such running on firewall/router.

1 Like
13

Coming back with an update since I got it all working tonight.

Architecture: Container on the existing server, exactly as planned. No issues, no regrets. Anything that would normally need an add-on just runs as another container.

IoT VLAN: went with macvlan via Docker rather than a Netplan subinterface. HA gets its own IP on VLAN 20 (192.168.20.10) and also sits on the default Docker bridge for main LAN access. Had to tag VLAN 20 on the server's switch port and write a small systemd service to recreate the VLAN subinterface on boot. Also needed a couple of iptables forwarding rules on the router so devices on the main LAN and WireGuard can actually reach the HA dashboard.

Tapo/Matter: running both. H200 via the Tapo integration pulled in all the child devices automatically which was a nice surprise. Matter is parked for now, it turns out Container doesn't ship with a Matter server so you'd need to run python-matter-server as a separate container and wire them together. On the list.

WiiM: works fine once connected. Lost a solid 20 minutes convinced there was a routing problem, turned out the IP had shifted in DHCP. Set static reservations for everything after that.

Emby: has to be done via configuration.yaml rather than the UI, which isn't obvious, but works fine.

Cameras: C420s don't do persistent RTSP so live streaming in a dashboard isn't really on the cards. They show up as entities but the Tapo app is still the right tool for actually watching them.

Still to do: Tuya for a dehumidifier, the wall panel, and properly testing the Lovelace controls. But the core is all there.

14

You can use ingress integration if you are not already. it will give you the same look and feel for containers running as you are using haos.

15

A fine example of careful strategic planning and an understanding of how the issues interrelate, required for a truly functional network.

Too bad your bad experience has driven it. Digital terrorism is still terrorism, and should be met with appropriate measures, including kinetic ones.

Your final two dragons may be IPv6 functionality and bandwidth capacity.

Slay away!

16

I do what you are proposing. Docker is great. Couple deets

a) use version specific file mounts. For example, when running 2026.4.3 I have a local folder (ha_prod_2026_4_3) mapped into the containers config directory. Whenever I upgrade I copy the local folder to the new versions folder and update the .env. This allows for easy rollback to a prior version. I use MariaDB for the recorder and I do the same thing for it as sometimes HA version updates change the SQL schema.

b) You want HA on the IOT VLAN with an ip address. There are many things that use broadcasts and it is much easier to have it on the IOT vlan than deal with all the nuances. You'll also want to run the container in Host Mode vs bridged mode. MACVlan could work also but I haven't tried it.

17

SO, since a few of you put real time into helping me think through this, i wanted to let youse know what i ended up doing. The tl;dr is that it's all running, it's solid, and I'm genuinely chuffed with how it turned out.

What I actually ended up doing

HA Container on the existing Docker stack, exactly as planned. No dedicated hardware, no HAOS drama. The macvlan dual-network approach worked first time (HA sits on VLAN 20 at 192.168.20.10 with a host shim at .11 for debugging, and it can still reach Emby and WiiM on the main LAN via a bridge network). For anyone who finds this thread later: yes, macvlan + VLAN is a bit fiddly to get your head around, but it works and I haven't had a single issue with it.

The switch VLAN tagging was the step I was most nervous about. Turned out completely fine. I had a keyboard and monitor next to the server and a rollback plan ready and didn't need either of them.

Tapo/Matter

Ended up running both integrations in parallel exactly as Riley suggested. Matter via the H200 for control and state, standard Tapo integration alongside for the extra attributes. The local push via Matter is noticeably snappier than polling ever was. The devices that drove me insane dropping offline every time the internet hiccupped? Haven't seen that problem once since. Absolute night and day.

The wall panel

Got a Samsung Tab A8 running Fully Kiosk Browser pointed at a Lovelace dashboard. My partner uses it in the kitchen for lights, music, checking the TV, all of it. WiiM integration is great for music control. Emby is a button that opens in the browser rather than an inline embed (inline playback was clunky as predicted so that was the right call).

One thing I didn't plan for

Ended up going down a Zigbee rabbit hole a few weeks in. Got a Sonoff Zigbee 3.0 USB dongle, added Zigbee2MQTT and Mosquitto as additional containers, and started adding proper sensors around the house. Contact sensor on the front door, temperature and humidity sensors, motion sensor for automated night lights. This wasn't in the original plan at all but once HA was running and stable it was the obvious next step and adding containers to an existing compose stack is trivial. I'm going to ikea tomorrow to buy up a load of their budget smart stuff...

To IOT7712 you called IPv6 and bandwidth as the remaining dragons. IPv6 hasn't bitten me yet but I know it's lurking. Bandwidth hasn't been an issue for local use. Slay away indeed.

To PeteRage the versioned config folder tip is genuinely good practice, I've adopted a version of it. Haven't needed to roll back yet but I'm glad the structure is there.

To tmjpugh the macvlan insight was the most useful concrete thing in this whole thread. Cheers for taking the time.

Anyway. If anyone finds this via search and wants more detail on any of it, feel free to ask. Happy to share configs.

2 Likes