[miele] Add auto-detection of network interface for multicast events

[jlaur]

This replaces the multicast IP address configuration parameter with auto-detection of the multicast network interface.

Previously it required a managed Thing with ThingID XGW3000 for the discovery to automatically update the configuration (see openhab/openhab-core#5093). Since this logic is based on the gateway IP address rather than mDNS information, there is no reason for MieleMDNSDiscoveryParticipant to be the provider of that, so this is now handled by MieleBridgeHandler directly when setting up the multicast listener.

The motivation for this change is that multicast events for some time haven't been working for me. I never actually looked into it, since the default polling interval is 15 seconds anyway, so it was only a minor annoyance. After upgrading to 5.0.2 I randomly discovered this in my logs:

2025-10-19 20:26:45.791 [WARN ] [.internal.handler.MieleBridgeHandler] - Unable to find network interface for address 192.168.0.236

I then found that this IP address was for my old Raspberry Pi 3, and since upgrading to a Raspberry Pi 5 more than a year ago, the IP address changed, and I didn't notice this hidden warning until now. Since my Thing configuration is unmanaged (and my ThingID is not XGW3000), the discovery logic for determining the multicast IP address was not able to update my configuration.

The changes were tested on both Windows and Linux successfully.

[jlaur]

I'm currently investigating an issue where a missing Thing configuration value seems to be replaced by a value from discovery. I believe this is unexpected, and I'm therefore keeping this as a draft until further investigated and tested.

[jlaur]

I'm currently investigating an issue where a missing Thing configuration value seems to be replaced by a value from discovery.

I can reproduce this by triggering mDNS discovery, even from my phone. Right after the bridge is discovered again, thingUpdated will be called in the bridge handler, parameter is set from discovery and a new dispose/initialize flow is triggered as a consequence. So the created DiscoveryResult affects the existing Thing directly. This only happens when discovery generates the same ThingUID as the existing Thing.

I could not reproduce this in 5.0, only in 5.1 latest snapshots. I will need to study recent PR's, including openhab/openhab-core#5032.

[jlaur]

I can reproduce this by triggering mDNS discovery, even from my phone. Right after the bridge is discovered again, thingUpdated will be called in the bridge handler, parameter is set from discovery and a new dispose/initialize flow is triggered as a consequence. So the created DiscoveryResult affects the existing Thing directly. This only happens when discovery generates the same ThingUID as the existing Thing.

I could not reproduce this in 5.0, only in 5.1 latest snapshot. I will need to study recent PR's, including openhab/openhab-core#5032.

I could reproduce this also with the existing binding in 5.1 snapshots, and all parameters from discovery are overwritten. I was able to reproduce this with the Hue binding as well. It seems rather critical to me, but since it's not related to this PR, but rather a general issue in 5.1, I will publish this PR for review after running a few last checks.

I will put on my TODO to create an issue in the core repository regarding the discovery results overwriting configuration parameters for existing Things. FYI @Nadahar since you recently did some work in the discovery area.

[Nadahar]

That's undesirable, yes, but I can't quite understand how openhab/openhab-core#5032 could have impacted that, as it only modified "who" does the registration, not the registration itself. But, never say never, it needs to be investigated regardless.

I'll have to try to find a way to reproduce it. Does it seem like an mDNS issue only, or is that just a "random factor"?

[jlaur]

That's very undesirable, yes, but I can't quite understand how openhab/openhab-core#5032 could have impacted that, as it only modified "who" does the registration, not the registration itself. But, never say never, it needs to be investigated regardless.

The only reason for mentioning that PR was that it had something to do with discovery, and the reason for pinging you, because you have recent experience with the discovery code. So I'm not saying at all the PR is the cause, it needs to be further investigated. I have a lot of snapshots downloaded, so at first I can attempt a binary search to narrow down an approximate date when this behavior was introduced. Then it might be easier to find relevant PR's for further investigation.

I'll have to try to find a way to reproduce it. Does it seem like an mDNS issue only, or is that just a "random factor"?

I think it's random, but I don't know for sure. The discovery result needs to be created with the same ThingUID of an existing Thing, and the result should contain properties with values that are different than existing Thing configuration parameters, in order to cause a change. For example, I changed the IP address in my Hue API v2 Thing to something invalid, then triggered mDNS discovery. And then it was initialized and brought back online with the correct IP address.

I will try to create the issue tonight to document this behavior, so we can continue discussions there and not "pollute" this PR any further with this finding.

[Nadahar]

I will try to create the issue tonight to document this behavior, so we can continue discussions there and not "pollute" this PR any further with this finding.

Ping me as soon as the issue has been created, because I'm sure I'll have more to say by then 😜

[Nadahar]

Interface names tend to be more stable across reboots/hardware changes, whereas static IPs may change.

Unfortunately, Windows has a tendency to change them when the driver is updated by forced, automatic updates.

I'm not sure that I understand the need to configure the interface in the first place. I mean, as long as you have the bridge IP, you can always figure out the interface to bind to automatically, either using my "new" NetUtil method, or using the "Socket hack" as a fallback.

What happens today if you don't configure it? Is multicast events disabled, or is it resolved for you?

[jlaur]

I'm not sure that I understand the need to configure the interface in the first place. I mean, as long as you have the bridge IP, you can always figure out the interface to bind to automatically, either using my "new" NetUtil method, or using the "Socket hack" as a fallback.

That's a good point. And ironically, the experience with openhab/openhab-core#5093 demonstrates that I wouldn't have had an issue in the first place, if my Thing had been managed, and if I had kept/used ThingID XGW3000. So that actually proves that there probably is no special need for users to be able to override anything. I also can't see any real use case where one would want or need to use a different network interface for multicast events from the bridge, than the interface used for connecting to the bridge. Only users, such as myself, that uses file-based configuration or provided a different ThingID would keep the interface IP address as configured, and in my own case that was undesired.

So in other words, I agree there is no need for any configuration, and I will do another round of refactoring.

[jlaur]

@openhab/add-ons-maintainers - ready for review. I'd appreciate if the three commits can be merged without being squashed, since they represent quite distinct steps taken.

[Copilot]

Pull Request Overview

This PR removes the requirement for users to manually configure the multicast network interface IP address for the Miele binding. Instead, the binding now automatically detects the appropriate network interface based on the gateway's IP address.

Key changes:

• Auto-detection replaces the manual interface configuration parameter
• Bridge handler directly determines the multicast interface using a DatagramSocket connection test
• Discovery service no longer attempts to determine or update the interface configuration

Reviewed Changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
xgw3000.xml	Removes the interface configuration parameter and simplifies other parameter declarations
miele.properties	Removes i18n strings related to the interface configuration parameter
MieleBridgeHandler.java	Implements auto-detection logic and refactors configuration handling to use typed configuration class
MieleMDNSDiscoveryParticipant.java	Removes interface detection logic from discovery
XGW3000Configuration.java	New configuration class for type-safe bridge configuration
MieleBindingConstants.java	Removes the INTERFACE constant
README.md	Updates documentation to remove interface configuration references

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Nadahar]

I don't know the binding, so I can't evaluate all details, but the things I can evaluate LGTM.