Support IPv6 and hostname addressed devices for UPnP eventing

[markfrancisonly]

What this enables: a WiiM device reached over IPv6 can receive UPnP events. Today it cannot — and neither can a device addressed by hostname rather than a literal IP. In both cases eventing is silently disabled, so the device reports no title, artist or artwork and its transport state never updates, while otherwise appearing to work.

Why it fails today

The notify server port is derived from the device address, assuming an IPv4 literal:

last_octet = int(device_ip.split(".")[-1])
assigned_port = 50000 + last_octet

Two hosts it cannot parse:

• an IPv6 address — int("2001:db8::5") raises ValueError
• a hostname such as wiim.local — int("local") raises ValueError

ip_address comes from urlparse(device_url).hostname, so either reaches this line. The broad except Exception around the block catches the ValueError, logs Eventing will be disabled and leaves _notify_server as None. Nothing else surfaces the failure.

Reported as

• Device initialisation fails when UPnP device URL contains a hostname #11 — the SDK-side issue for exactly this: direct instantiation with a hostname in the device URL.

• WIIM integration: Using a hostname instead of IP address breaks state updates home-assistant/core#168047 — the downstream report, carrying this traceback verbatim:

  Device Wohnzimmer: Failed to initialize AiohttpNotifyServer or UpnpEventHandler:
  invalid literal for int() with base 10: 'wiim-pro'. Eventing will be disabled.
    File ".../wiim/wiim_device.py", line 210, in async_init_services_and_subscribe
      last_octet = int(device_ip.split(".")[-1])
  ValueError: invalid literal for int() with base 10: 'wiim-pro'
  

  The integration builds WiimDevice straight from the user-provided host, so any hostname config lands here. The issue asks for the fix upstream in this library rather than resolving the hostname in the integration.

Fixes #11.

What changes

• Take the last byte of the parsed address. For IPv4 that is the same value, so existing port assignments do not move; for IPv6 it yields a valid port; for a hostname it falls back to 0.
• Bind the wildcard matching the device family. An IPv6 device reached through a 0.0.0.0 socket cannot deliver a callback.

Nothing else on the SDK side needs to change: AiohttpNotifyServer already brackets the callback URL when the listen address is v6, and the existing 256-port retry is untouched and still applies.

Testing

Parametrised over IPv4, IPv6 and a hostname, asserting the source tuple handed to AiohttpNotifyServer. They fail on current main with the two ValueErrors above.

Not verified against a real IPv6 device — I have no IPv6 segment to test on, so the hardware path is unproven.

Not fixed by this

home-assistant/core#177517 is a separate failure with the same symptom — eventing silently dead, no metadata — but it is not this bug. There the address parses fine; the callback host advertised to the device is simply unreachable, because get_url falls back to the first enabled adapter when the routed source address is not itself an enabled adapter. That is a core-side fix (home-assistant/core#177667), not an SDK one. Flagging it so the two aren't conflated: applying this PR will not resolve that report.