LAN Device Discovery & Homey Pro Network Logic

Developers
1

Hey everyone! I’m working on a small project and got stuck with some network stuff—hoping someone here can share insights!

Here’s the situation: I want to find supported devices in the LAN via UDP broadcast first, then connect to them and control them using UDP/TCP.

When testing with a Python script on my PC, I ran into a problem: If I bind the socket to 0.0.0.0 (listen on all network cards), the UDP broadcast might go through the wrong card (like VMware virtual cards instead of my WiFi). But if I hardcode my PC’s local IP (e.g., 192.168.3.53) in the script, it works perfectly—no wrong-card issues.

Now I’m thinking about adapting this to Homey Pro (since the end goal is to run it there). But I have two big questions:

  1. Does Homey Pro have multiple network cards like a PC?
  2. What’s the correct logic here? If Homey Pro has multiple cards, do users have to manually configure their Homey Pro’s IP (like I did on my PC) to avoid wrong-card issues? Or is there a smarter way for Homey Pro to auto-pick the right network card for LAN UDP broadcasts?

Thanks in advance for any tips or experiences you can share!

2

Can you explain a bit more? I don’t understand how a broadcast can “go through the wrong card”, or why it matters. I mean: if a broadcast reached your PC through a particular interface, you should be able to send out messages (I assume that this is what your actual issue is?) through that same interface.

Alternatively, you can probably use one socket to bind to 0.0.0.0 to listen to broadcasts, then use another socket (bound to the interface you want the responses to go through) for sending out responses.

To answer your big questions:

  1. Homey Pro 2023 has two relevant interfaces, Ethernet and WiFi, and both are active when there’s an Ethernet cable plugged in (otherwise only the WiFi is active)
  2. See above.
1 Like
3

Thanks so much for your patient explanation! I might not have fully clarified my scenario earlier, but your advice has helped me sort out many details. Let me supplement my original core pain point:
I need to discover Marstek devices in the LAN via UDP broadcast (they only exist on the user’s home WiFi network segment). However, during testing, I found that if I used a single socket bound to 0.0.0.0, the broadcast would be sent to all interfaces of my PC (WiFi, VMware virtual adapters, etc.). Although the target devices could receive the broadcast, their responses often “could not find the correct IP to send back to” (e.g., responses were routed to the virtual adapter), resulting in the program failing to receive them. Later, I fixed this by hardcoding the WiFi’s local IP, but I was worried it wouldn’t be flexible enough when adapting to Homey Pro’s dual-network interface setup.

It wasn’t until I saw your suggestion of “separating sockets for sending and receiving” that I realized the right design:

  • The sending socket is specifically bound to the “IP of the network interface connected to the target segment” (e.g., the user’s WiFi IP), with a random port (automatically assigned by the system). This ensures the broadcast is sent only through WiFi, without being wasted on other interfaces;
  • The receiving socket is bound to 0.0.0.0 + a fixed port (e.g., 30000) to listen for responses from all interfaces, avoiding missing return data in edge cases.

After modifying the code according to this logic, I could stably send broadcasts and receive responses during testing! However, I have one small follow-up question: if this solution is used on Homey Pro (which may be connected to both Ethernet and WiFi), do users need to manually tell me “what their current WiFi IP is” so the program can bind to the correct sending interface? Or does Homey have a way to automatically identify the “IP of the interface connected to the target device’s segment” without manual configuration by the user?

Could you please clarify this a bit more? Thank you very much!

4

Ah okay, I misunderstood: I thought that the devices that you were trying to discover were broadcasting, but it’s your computer (and eventually Homey) that is doing the broadcasting. In that case I understand why the interface that you use to send out the packets matters.

But as long as you bind your socket to a particular interface, you should be able to reuse it for both sending and receiving, since the devices will use the IP-address of the interface that you used (in other words, there shouldn’t be a necessity of having a separate receiving socket bound to 0.0.0.0).

Homey only really works if both the Ethernet and WiFi interfaces are on the same network segment. If not, things like mDNS discovery, which is important for a lot of apps, stop working. So theoretically, it doesn’t matter from which interface you send your packets.

That said: I don’t think it’s trivial to determine which interface (Ethernet or WiFi) to use on Homey, at least not without using the Web API, which requires additional permissions for your app. So I would just try and see what happens if you just don’t bind the sending socket to a particular interface at all. I assume Linux (which Homey is running) will then do an implicit bind on the primary interface.

5

Thanks a lot for your help! I followed your suggestion to set up and test the project these day, and it really worked—turns out I don’t need to explicitly specify the network interface like I did on my PC. Homey automatically handles binding to the primary interface when I don’t set one, which saved me a bunch of hassle. Really appreciate your tips!

1 Like