[govee] Thing discovery not working

[andrewfg]

During testing #17812 I discovered that thing discovery is not working.

2024-11-30 19:02:05.127 [DEBUG] [govee.internal.GoveeDiscoveryService] - starting Scan
2024-11-30 19:02:05.264 [DEBUG] [govee.internal.GoveeDiscoveryService] - Discovering Govee devices on name:eth7 (Realtek PCIe GbE Family Controller) ...
2024-11-30 19:02:05.268 [DEBUG] [govee.internal.GoveeDiscoveryService] - Discovery with IO exception: Cannot assign requested address: bind
2024-11-30 19:02:05.269 [TRACE] [govee.internal.GoveeDiscoveryService] - After try
2024-11-30 19:02:05.269 [DEBUG] [govee.internal.GoveeDiscoveryService] - Discovering Govee devices on name:eth18 (Hyper-V Virtual Ethernet Adapter) ...
2024-11-30 19:02:05.270 [DEBUG] [govee.internal.GoveeDiscoveryService] - Discovery with IO exception: Cannot assign requested address: bind
2024-11-30 19:02:05.270 [TRACE] [govee.internal.GoveeDiscoveryService] - After try

It fails at this line:

openhab-addons/bundles/org.openhab.binding.govee/src/main/java/org/openhab/binding/govee/internal/CommunicationManager.java

Line 133 in 5cf6fea

try (MulticastSocket sendSocket = new MulticastSocket(socketAddress)) {

Note: the PC has two network interfaces (running on Windows 10).

Signed-off-by: AndrewFG software@whitebear.ch

[andrewfg]

@stefan-hoehn ping..

[stefan-hoehn]

I am actually pretty limited in time currently and I already put like more than an hour into it to find out what root cause might be. The problem is that I cannot reproduce it on my side as it works well. It might be related that you have a windows 10 setup that I don't have (I am on Linux) with multiple interfaces (which I rather tend to avoid).

It seems it is trying to bind 239.255.255.250 to multiple interfaces but in your case it isn't working. I have no clue why even though the code already does the right thing to "joinGroup".

My research finally led me to this thread which also seems to be related to Windows users.
... and all other searches at least point to some wrong network setup with servers being configured incorrectly configured when running multiple interfaces...

I wished I could help more 😩

[andrewfg]

Yeah. I will do some tests. The addon suggestion finder did discover the light and suggest the given binding, but the binding did not discover the light thing. So I will look into the suggestion finder code to see if we can learn from that.

[maniac103]

Maybe an IPv4/IPv6 thing? Found something similar here.

[andrewfg]

Thanks guys for the googling; but you know I did do that already myself...

[andrewfg]

@maniac103 it is indeed an ipv4/ipv6 thing .. on Windows it is possible to have both on the same network interface, and indeed possible to have multiple such interfaces. The solution is to filter on ipv4 addresses only. I have developed a fix that I will add to the current open PR (as soon as my broadband starts working again.. )

[morph166955]

Not sure if this is helpful or related. Just added the Govee binding and I'm seeing the same issues. I too have IPv4 and IPv6 on my system. Only difference is, I'm on Ubuntu (native not in a docker) not Windows. I get this when I hit the scan button. I can open a separate bug if unrelated, just seemed very similar.

2024-12-06 04:05:21.369 [WARN ] [.govee.internal.CommunicationManager] - exception when receiving status packet
java.net.SocketException: Socket closed
        at sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:252) ~[?:?]
        at java.net.DatagramSocket.receive(DatagramSocket.java:710) ~[?:?]
        at org.openhab.binding.govee.internal.CommunicationManager$StatusReceiver.run(CommunicationManager.java:204) [bundleFile:?]
Caused by: java.nio.channels.AsynchronousCloseException
        at sun.nio.ch.DatagramChannelImpl.endRead(DatagramChannelImpl.java:523) ~[?:?]
        at sun.nio.ch.DatagramChannelImpl.trustedBlockingReceive(DatagramChannelImpl.java:677) ~[?:?]
        at sun.nio.ch.DatagramChannelImpl.blockingReceive(DatagramChannelImpl.java:635) ~[?:?]
        at sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:240) ~[?:?]
        ... 2 more

[andrewfg]

@morph166955 many thanks for reporting; it is both helpful and related. The socket closed error is 'normal" during discovery, and is properly handled in #17812 -- perhaps you can try the Jar from that PR to confirm?

[stefan-hoehn]

to add to the IPv6 thing: I had the same issues with Nanoleaf which made the binding totally unstable until I did the same there: filtering out IPv6. However, my solution in NanoleafMDNSDiscoveryParticipant seems to be much simpler and yours more elegant.