Shouldn't use IP address to identify speaker

[dhylands]

I think that showing the IP address as a property is fine, but it shouldn't be the way to identify the speaker. If the IP address changes, then I need to remove and re-add the speaker.

I think that it should use the serial number or Mac Address of the speaker as the unique identifier.

[freaktechnik]

I chose the ID initially since it was the most consistent identifier in the API at that time. It should use the UPnP ID though. Migration is mostly why I haven't attempted that

[dhylands]

Currently, whenever the IP address changes, I have to remove and re-add the speaker, and go and update the rules. Personally, I've had to do this twice so far, so I'd be be happy even if there was no migration. Perhaps create a new adapter with a slightly different name so it doesn't break any existing users?

[freaktechnik]

You'd likely still have to run discovery to get them back every time the IP changes. Communication to the speakers is hard-bound to the IP, so once a speaker's IP doesn't work any more, the adapter doesn't know how to reach it anymore. The only solution is to re-run discovery. There's a similar issue with the Chromecast adapter and I'm not sure what the best solution is, since most of the time you'd want to wait for about a minute or so to give the devices a chance to get back into the network.

[dhylands]

The devices are on the network, but with a new IP address, so it won't matter how long I wait, it won't find them under the old IP address except by fluke.

If the adapter used some other unique ID and just stored the IP as an attribute, then the adapter would need to determine the new IP address when it changed, but these changes are announced, and in the worse case I'd only have to wait a couple of minutes and things would work again without having to remove and re-add the speakers and fix all of my rules.

The adapter should do the discovery behind the scenes. But if the IP address is used as the unique ID then it can't.

[freaktechnik]

I know the limitation with the IP as ID and I'm not arguing that it's a good solution. However I am not aware of anything in the Sonos protocol that would tell me about the IP changing (since the mesh doesn't use the external IPs). That's entirely in the discovery layer. What I was trying to say is that even then it's still a question of timing.

[dhylands]

From a wireshark trace, I see an MDNS broadcast go out every 300 seconds, and SSDP broadcasts every 900 seconds. The MDNS requests include a DNS update (for hostname which includes the MAC address) and the SSDP broadcasts appear to contain the uuid of the speaker (and the uuid appears to contain the MAC address along with some other text).

I'd suggest that anytime a command fails, the adapter should just automatically do a discovery.

[freaktechnik]

Just got a new router, so all my speakers changed IP and the gateway can still identify them. Success.

[dhylands]

Yes - I noticed that the speakers are now showing up using the MAC address as their ID. Thanks very much.