The OH server can easily participate in more than one VLAN (just tag multiple VLANs on its NIC). That way you don’t need bridges etc., but OH itself becomes a “security weakness” in the separation between the VLANs. I’d still think that’s the easiest way to do it in most cases. Alternatively, you need a firewall/router to manage access across the VLANs, so it will say what traffic is allowed and not.
However, using routing has one significant downside - multicast (/broadcast) packets don’t traverse routers by default (in theory it’s not true for multicast, but I’ve yet to see that actually work out of the box). Multicast packets have a TTL value that is supposed to be decremented by one for each router it traverses, so that you can decide when the packet is created how many routers it will traverse. Everything using multicast is then supposed to allow the user to configure the TTL value and in that way control how long it travels.
This must have been a pipe-dream by those who designed multicast, because the TTL is rarely configurable by software and devices using multicast, and most cheap routers don’t forward the packets at all.
So, in reality, it’s most practical to just see it as if “multicast doesn’t traverse routers”.
This matters because several discovery mechanisms used by OH relies on multicast, things like mDNS, UPnP, SDDP and probably also more binding specific “discovery protocols”. Having a router between OH and your devices thus means no autodiscovery for the devices, which, depending on the binding, might pose some challenges. If a binding is “properly made”, you can configure all the information acquired automatically yourself, but from what I’ve seen, this isn’t always the case.
If you instead let OH’s NIC be tagged on multiple VLANs, OH will have multiple IP addresses, one for each network in which it participates. This will allow things like mDNS etc. to function, but it undermines some of the “security” that the VLANs are supposed to provide, because I’m sure there are multiple ways to abuse the OH installation (either through OH or throught the underlying OS) to access the other VLANs. It’s still much better separation than no separation though.
Even if you go down this route, you will probably have some challenges. The Shelly binding comes to mind, where I have pointed out (and created a PR that addresses a little part of the problem) that it’s not really written to handle multiple subnets. In particular, it has the concept of “callback IP” that it sends to Shelly devices so that they should know how to contact OH. This system only allows having one “callback IP” for all devices, which means that it’s impossible for the binding to work with Shelly devices on multiple networks. Even if the binding can see them, they can’t contact OH from more than one of the networks.
My guess is that there are other, similar, limitations in other bindings. Most people just aren’t very good at understanding networking, or at bothering to do the extra work required to make it work in anything but the must simplified scenarios.
I would therefore perhaps “start small” and just create two VLANs, where you put the things you “trust less” on a dedicated VLAN. By moving one type of device at a time, you have the chance to experience whether the binding can handle it or not.
