Closed StijnWolf closed 3 months ago
Currently using a multi-homed network setup is something that's rather unsupported in HA, and enabling configurability of the default network adapter is something that would need changes in multiple layers of the stack. We might consider it in the future but it's not a viable solution for your issue.
On the other hand, the way around it could be adding option to specify interface where the magic packet should be sent from. This is something that is available in the underlying wakeonlan library used by the integration so if the integration allowed to specify it, it could be a solution to your problem. So I rather suggest opening an issue in the Core repository asking for this feature.
I made an attempt to write a custom_component to add this feature to the existing wakeonlan integration. Sadly I couldn't get the interface parameter in the wakeonlan library used by the integration to work. It'd succesfully execute the command but my target machine would still not receive a magic packet. I succesfully added a copy of the integration to my home assistant instance inside the custom_components folder, so I was able to add custom logic to the existing integration locally. Sadly the wakeonlan integration just didn't want to recognize my second network interface. I tried passing a hardcoded value for this parameter to no avail.
AFAIK this issue can't be supported by home assistant. I would've loved to make a merge request with my fix but the problem doesn't seem to be fixed by adding the interface parameter to the wakeonlan calls within the wakeonlan home assistant integration.
I confirmed my suspicions by writing a python script which uses wakeonlan on the server which runs the home assistant vm, and that worked as expected; the target machine receives the magic packet, but only if I add the interface parameter. This made me give up on the wakeonlan integration because I just couldn't figure out another probable cause than adding the interface parameter after this test.
I instead opted for a custom switch with very similar behavior using a custom binary sensor. My HA vm uses SSH to connect to the server hosting the HA vm, and then the server itself sends the magic packet to my target machine. This gives me the desired behavior for a wakeonlan switch. I'm happy I was able to build a solution myself, but am disappointed that it doesn't make use of the seemingly fitting wakeonlan integration.
I added my configuration as a file should it be of any use
I suppose this issue can be closed since I don't think this issue can be resolved within the wakeonlan integration and I've provided an alternative for my use case.
Describe the issue you are experiencing
I've been using home assistant for the past few years and love it. I use the Wake On Lan integration daily with the following configuration:
This has been working perfectly fine, but I recently introduced an extra router to my setup, specifically for VR streaming. So the server is still connected to the other router, while the new router is connected to the old one and my gaming pc is connected to the new router; I put a new router between the gaming pc and old router. This broke my WOL integration in HA since the gaming PC is now connected to a different subnet. As a countermeasure I decided to buy a USB Wi-Fi dongle and pass it to my HAOS VM. I'm able to connect my HA instance to the same router as my pc via the Wi-Fi dongle, but here's the kicker. Home Assistant doesn't seem to send the WOL packet to all network adapters, but only the default one.
This means that while I've configured everything correctly, the package won't get sent to the right adapter. I searched around for changing the default network adapter using nmcli (like in this thread), but was then greeted with the following error:
I also tried using the Wi-Fi adapter as the only network interface in HA, and low and behold, the magic packet gets sent properly! Unfortunately I need the other network adapters so this solution isn't viable for me, but simply confirmed my suspicions.
There are two possible solutions to my problem as far as I'm aware:
What operating system image do you use?
generic-x86-64 (Generic UEFI capable x86-64 systems)
What version of Home Assistant Operating System is installed?
Home Assistant OS 12.4
Did the problem occur after upgrading the Operating System?
No
Hardware details
HAOS vm running via QEMU/KVM with virt-manager.
Specs:
CPU: Intel I5 6600k RAM: 16gb DDR4@2400mhz Storage: 1TB m.2 ssd GPU: none PSU: 650W silverstone (don't know the model)
OS: Ubuntu Desktop 22.04
Steps to reproduce the issue
Anything in the Supervisor logs that might be useful for us?
Anything in the Host logs that might be useful for us?
System information
System Information
Home Assistant Community Store
GitHub API | ok -- | -- GitHub Content | ok GitHub Web | ok GitHub API Calls Remaining | 4996 Installed Version | 1.34.0 Stage | running Available Repositories | 1385 Downloaded Repositories | 6Home Assistant Cloud
logged_in | false -- | -- can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | okHome Assistant Supervisor
host_os | Home Assistant OS 12.4 -- | -- update_channel | stable supervisor_version | supervisor-2024.06.2 agent_version | 1.6.0 docker_version | 26.1.4 disk_total | 30.8 GB disk_used | 5.8 GB healthy | true supported | true host_connectivity | true supervisor_connectivity | true ntp_synchronized | true virtualization | kvm board | ova supervisor_api | ok version_api | ok installed_addons | File editor (5.8.0), Advanced SSH & Web Terminal (18.0.0), Glances (0.21.1)Dashboards
dashboards | 2 -- | -- resources | 3 views | 5 mode | storageRecorder
oldest_recorder_run | June 22, 2024 at 11:02 AM -- | -- current_recorder_run | July 1, 2024 at 12:54 PM estimated_db_size | 165.14 MiB database_engine | sqlite database_version | 3.44.2Additional information
HA runs in a VM on a server running Ubuntu Desktop 22.04. My gaming PC and server are both hardwired to the same router. The gaming pc has a Windows (11) + Linux (Manjaro) dual boot, this doesn't seem to matter but should be mentioned nonetheless.
The most frustrating part of this is knowing that this can work, but doesn't. Other devices (such as my smartphone) are able to send a WOL packet just fine to my gaming pc, so I know that this issue boils down to HA not sending the packet to the right destination.