RPI4 8Gig RAM running HA Supervised (connected by etherent only)
Network has a ton of devices
In maturing my situation, biting the bullet and putting the IOT devices one by one on a separate vlan I just set up. I am leaving the RPI on the original vlan because I am also using adguard hoime on t as my dns server to remove all ads from our web browsing. The additional VLAN I gave an ID of “10”
Issue with WEMO smart plugs I have moved over to the other vlan - HA is not able to see the smart plugs on the other vlan.
resolution - just update the ethernet interface on the RPI to connect to BOTH vlans!
SSH into the RPI.
cd /etc/network/interfaces.d
sudo nano eth0
the file originally had:
auto eth0
iface eth0 inet dhcp
iface eth0 inet6 auto
I updated it to instead be (just adding a section):
auto eth0
iface eth0 inet dhcp
iface eth0 inet6 auto
auto eth0.10
iface eth0.10 inet dhcp
vlan-raw-device eth0
In this case, the sub-interface of the new VLAN is tagged with VLAN ID 10, and the vlan-raw-device line specifies that this sub-interface is associated with the main eth0 interface.
Don’t even need to reboot the RPI, just at a command line then issue the command:
sudo systemctl restart networking
VOILA! Instantly HA can see all the devices on both VLANS!
You would need to set up a men’s forwarder on your router, but I think it would be easier to move the HA server to the IoT network and open port 8123 for TCP to access HA and open port 53 for UDP and TCP to access the DNS service.
I was thinking of doing that eventually, but I do use the RPI for several things as well as HA - so it would be a pretty big disruption - I would need to know ahead of time everything I need to do, and I am not an expert in this area (networking) but have learned alot by painful trial and error over the years. (It has to be something I can do fairly quickly without a lot of hours-long troubleshooting because whenever there is a hiccup, the WAF seems to go instantle 0% - and only increases by 10% or so every full month without any mishaps!) I don’t get “fix it RIGHT NOW!” - I get “I’ve told you a million times to get rid of it!” One issue is the IP address for the RPI is several places in python code and on other machines as well, I need to chage that to a URL wherever I can. Thanks for the tip for the DNS.
I do have 8123 forwarded and do login with a 30 digit password but am also looking for a different secure way to connect to the HA RPI instance from the outside world without additional software to run on the outside devices to be able to get in -
This sounds simple enough. However when I SSH to my RPI there is no /etc/network/interfaces.d directory let alone no eth0 file. There also is no systemctl executable file. What am I missing? Do I need to add some type of integration to HA first?
For a variety of unrelated reasons, I have decided to undo exposing the RPI to the IOT vlan and instead set up firewall rules to allow HA to connect to each of the sensors individually. This is easier than it sounds: I set up rules to allow groups of devices to communicate across vlans. Then I have HA, one PC and a few other select items in one group, and they can communicate with a separate group that of the iot devices.
@WallyR This is an issue I have with a couple Matter based IOT devices, I am unable to get them onto the IOT VLAN they have to only work on the regular internal subnmet that also houses HA, how come and what can I do to resolve that?
IPv6 is a whole other beast to tackle than IPv4.
You will on an interface have multiple networks and each network might have multiple IP addresses.
The IPv6 app will on the fly have to figure out when to use what IP address.
When you then add multiple interfaces, then the thinking of IPv4 cause issues, because then you will have some networks that have the same ID, but they are not the same.
In IPv4 that would be equal to have 192.168.1.0/24 on two different interfaces/VLANs.
This can be done in IPv6, because you have global routable networks, local routable networks and non-routable networks.
When the app then is just left to decide on its own, then these non-routable networks that exist on multiple interfaces can cause issues and the wrong one is chosen for the job.
This is why IPv6 also have an interface ID as part of the address, so you might see %59 in the end of an address, which means it has to use a specific ID to access that address.
HA has no control to handle these issues, so there are no way to deal with it.
Because IPv6 runs on the docker containers on HAOS and HA Supervised installations, then turning off IPv6 on specific interfaces in HA will not work either, because it will only turn it off on the HA container and not on the Matter containers.
HA core installations are probably the only ones may be able to deal with this issue.
Only solutions is to make a feature request for a full IPv6 support.
What is funny is that ESPHome have a good and really feature-full implementation of IPv6 made by HeMan, so the bottleneck is now really H itself.
