(You will note I am speaking as someone with networking knowledge only obtained through years of trial and error, so bear with me and PLEASE correct me where I may be wrong - that would asctually be very helpful to me.)
@SophieO and @WallyR I mentoned my setup above but that is really buried so I’ll briefly repeat it here. I have HA on my primary vlan and all of my IOT devices on a different VLAN (except for my 3 matter devices which I kept on the same VLAN as HA so the would work through the matter integration). My ISP only provides IP4 so I just have that turned off everywhere internally as well. As a fix to have all IOT on the same VLAN, I did have this for a short time (two ethernet interfaces (one on each vlan) with the same RPI4 physical ethernet NIC connection) - but the issue I then ran into was that my router can only reserve one IP per mac address (as it actually had two). This is back when I was running HA Supervised so I could set up the networking that way at the OS level. Since then I switched to HAOS (and now it’s on an RPI5 as a VM under QEMU/KVM).
In any event, I backed away from the dual IP address interface on HA Supervised as a solution when I discovered my router can only reserve one IP per MAC address (as HA Supervised had a reserved IP). While I have HA Supervised and had control over the OS, that may have been a silly reason to not continue in that direction - as linux in general sometimes does ignore IP assignments but also does allow you at the OS level to force the host to have a specific IP address.
Assuming I can force With HAOS which I now have to have HA to have two IP addresses (or maybe at the QEMU/KVM level) - is this possibly in my current setup to then have my 3 matter devices on the IOT VLAN work with my HAOS which would then be on (both?) VLANS?
I followed the discussion with great interest and the points, that matter-over-wifi will not work across VLANs.
In my home I also have a segmented network with my HA living within one VLAN (a DMZ which is partly reachable from outside the homenetwork) and all my smarthome wifi components in a dedicated IoT-VLAN. I’m using an OPNSense firewall for the network segmentation and have full IPv6 in all of my VLANs. All devices are getting a LLA, an ULA and a GUA and I have mDNS reflection enabled on the OPNSense. Since today I had now matter devices, just a couple of “normal” wifi devices sitting in the IoT-VLAN with proper firewall rules to enable communication with HA.
Since my Shelly devices in the IoT-VLAN also support pairing over matter, I though why not just try it. So I moved my phone to the IoT-WiFi and tried adding two of my shelly plugs to HA via matter with the compagnion app by scanning the QR-code. And it just worked without any hassle.
Is this just a speciality with the Shelly devices? Or could this be an indicator that it is indeed possible to get matter-over-wifi working across VLANs?
I seem to remember reading reports that pairing (i.e. commissioning) might work across vlans with proper ipv6 addressing and mDNS reflection (it uses bluetooth and ULA apparently), but that at some point the server switches over to using the LLA found in the mDNS announcements so, unless your reflector is filtering these out of the packets (or the device doesn’t include them for some reason), it would stop working.
Keep us updated. If it continues working, I wonder if you can determine which of the above reasons applies — the HA zeroconf browser will show you the IP addresses in the _matter._tcp.local announcements received at the Matter server (on my server, WiFi devices have LLAs but Thread devices do not, because they are filtered by the TBR). You can run an app on your IoT VLAN (such as Discovery or Flame for iOS) to look at the announcements prior to their being reflected to see if the device is hiding its LLA, or if the reflector is modifying/filtering the packets (i.e. whether it’s a Shelly or OPNsense thing).
I will further observer the shelly devices if they keep working within matter. The mDNS reflector within the OPNSense has rather limited options and therefore, I’ve actually no idea at the moment what it is doing exactly. You basically can only define the interfaces which it is supposed to work on and nothing else.
But when I look at the device info of the Shelly device in matter, there is just an IPv4 adress listed. Is there a chance that shelly uses IPv4 for matter? This could be a reason why it is working?
Where do I find the HA zeroconf browser?
For a long time the IPv6 address configuration in HA was missing the option to add more than one IPv6 address, which made it hard to set up IPv6 properly.
It seems that it is now possible to add multiple IPv6 addresses, so that hurdle is now gone.
I am not really sure when that feature was added.
The next part is a still not solved and that is the discovery services connected to multiple NICs.
I think this can be solved by controlling the IPv6 addresses on all NICs manually, so no subnet use the same subnet ID, but I have not tried that.
Last time I played much with IPv6 was when I tried to switch to a IPv6-only network and I found that many things do not support this at all, especially the addons.
I do not want to do a dual stack setup internally, so someone else must do the work with static IPv6 addresses to test that.
For a long time the IPv6 address configuration in HA was missing the option to add more than one IPv6 address, which made it hard to set up IPv6 properly.
It seems that it is now possible to add multiple IPv6 addresses, so that hurdle is now gone.
I am not really sure when that feature was added.
Not sure what you mean by that. I’ve always hat a proper IPv6 configuration of HA since I’ve started using my segmented network with OPNSense about a year ago. But I never tried to set IPv6 adresses in HA manually. I’ve always let OPNSense do it’s job and my HA was always getting a LLA, an ULA and a GUA from OPNSense.
I see multiple IPv4 addresses are allowed - but only on the same vlan? For instance would I be able to put 192.168.0.1 and also 192.68.10.1 as gateways (maybe separated with comas or semicolons)? I don’t want to try it and then get locked out -
What you are asking about is what I know as “multinetting” (multiple IP subnets on an interface, and in the Ethernet world, multiple IP subnets in a broadcast domain). I recall there are a few drawbacks with multinetting (DHCP is one of them), but nevertheless it may work out for you.
nmcli is a tool in HA that can be used for network configuration, but I’m less clear about how persistent nmcli settings are in HA. Some settings persist, while others tend to get either overwritten or cleared by HA.
nmcli can be used to add a secondary IP address (using a “+”) to an interface using the connection profile associated with that interface. Something along the lines of nmcli con mod <CONN-PROFILE-NAME> +ipv4.addresses <secondary_address/bitmask>.
As for a secondary gateway address, I’m less certain how nmcli will behave… but… a gateway address is just another term for a “default route”, and you probably don’t need multiple default routes, as when there are multiple default routes, generally one of them will get assigned a costlier metric and thus is never chosen anyway.
To use nmcli, I would try to use the system console as that always provides you a way to not get locked out.
If you have multiple routes, then only one of them, can be a default route and the other must have a range set.
I do not think HA can do that.
Your setup suggest you have two different routing devices on your network.
Little Update from my side. The shelly devices are still working in matter and additionally, I’ve picked up a switchbot plug on sale and after a little bit of hassle (seems to be normal with the device, according to some other users) I could add it via matter in a different VLAN as well. So somehow it seems to be working.
mDNS reflaction on the router along with firewall rules (first to block vlans from each other, then overriden for specific groups of IP addresses allowing copmmunication between specific IPs members of said groups)
Really I don’t - in an ideal world I would like to have my matter devices on the IOT vlan, currently I have to have them on the same internal private vlan as HA and our more secure devices (cell phones, PC’s etc.). That is my only end goal. It would be better to not have the HA also interfaced onto the IOT vlan, it shouldn’t have to be on both.
So I am currently trying to move all my IoT devices from the main subnet to a vlan subnet. (please excuse my lack of proper terminology)
I have 2 routers.
My main router with a port set up as a vlan that is connected to my second router
My home assistant is “dual homed” with a network interface on my main subnet (connected to the main router) and a network interface on my IoT subnet (connected to the second router).
I have both network interfaces set up in the Network > Network Adapter
Both are checked with my main subnet adapter showing as “default”
I have successfully connected Tapo matter over wifi smart switches to home assistant with the normal connection process on the IoT subnet.
They work perfectly and show up like the ones connected on my main subnet.
The only exception is that when you are in an automation you cannot select the switches as a matter device. You can only see them as an “entity”
I would love to get them showing their, but they currently work correctly other than that one issue in all my automation and dashboards.
I am not really sure what you mean with a Matter device in automations.
Anyway devices/device IDs should be avoided and entities/entity IDs are highly recommended.
There is a thorough explanation for this in the cookbook in the community guide section.
Hard agree with Wally on this. You’re way better off using entity IDs in automations anyway. In a nutshell, if you ever replace the device, you can name the new one the same entity ID as the old one and you won’t have to make changes to the automation. Device IDs are unique to the device, so you’d have to update any automations/scripts if you replace a device later on.
In other news - Matter uses ipv6, so if you don’t have that setup correctly in the routers, that could explain why you’re not getting the behavior you’re expecting. 1st gen Matter devices may connect using ipv4 to the router and may be able to send commands using ipv4, but newer firmwares and tech really rely on ipv6 and you’ll notice odhcpd releases ipv6 addresses to your Matter devices, even older ones, as long as ipv6 is setup correctly.
Thank you, Wally. That is a very helpful explanation. I just didn’t want to lose a feature/ability that would make me wish I weren’t moving my devices.
What I meant by a “matter device in automations” can be shown in this example:
In the “Then do” section of an automation you add an “Action” called “Light: Turn off”
Choose “Add target”
Click on “Devices”
Select the Office Lights “Matter device”
This was no longer available after moving Office Lights to my new vlan subnet
Update:
As I show this for an example these matter light switches have now shown back up as a selectable device since the time I posted my original issue.
