Is anyone updating the Sonos plug-in to support their new multi zone amplifier. It uses one IP address and different ports for the zones.

50 minutes ago, Howard said:

Is anyone updating the Sonos plug-in to support their new multi zone amplifier. It uses one IP address and different ports for the zones.

Not at this time.

I attempt to maintain both the Sonos and ST-Sonos plugins but I don't have any Sonos equipment. That makes attempting to support new features difficult.

Both plugins are based on external libraries so if those libraries add support for the this, it may be possible to update the plugins to take advantage of it. I'd really need to know what support for this means. Is this something that would only change the way the plugin internally address zones or is there some external/visible change to the configuration and/or nodes themselves?

Hi Bob. Thanks for the plugin and responding to my post.

My coding is rusty but I can act as a testbed for your plugins. I have an Amp, Amp Multi and Sonos One. There is also an updated plugin on HA which works with Amp Multi.

The library being used for the sonos (udi-sonos-poly) plugin was updated a couple of weeks ago to add support for Amp Multi, but I don't really know what that means.

I can attempt to update the plugin to use the latest version of the library.

That's great. They changed the way they address the speakers so discovery doesn't work. The Amp multi uses one IP address and different ports for the speakers. The attached may be helpful.

ha-to-eisy.zip

Yes, that's very helpful. But it raises some questions on what's the best way forward. I see a couple of options.

1. I can try and update the existing sonos plugin. It seems possible, at least the discovery of zones part looks pretty easy. But the existing sonos plugin also allows for manually specifying the zone in the config parameters. Converting that to work with Amp Multi looks to be more of a challenge. There are also other areas of this plugin that could/should be updated as well.

2. Use the generated plugin from ha-to-eisy.zip to create a new Sonos plugin (possibly replacing both ST-Sonos and Sonos). I do see some issues in the plugin that would need to be corrected and it seems to be based on outdated PG3 plugin designs.

I'm leaning toward option 2, simply because it seems like the work needed is less and it already has the missing features from the Sonos plugin.

Where did ha-to-eisy come from? I can't find anything in the .zip file that lists the license, author, or url to find out more about this. I'd like to make sure that it's ok to modify and re-distribute the code.

I asked Muse to look at HA and create an EISY version of it. I was thinking of my early days programming and thought it could create a wrapper of sorts. This is the result. The good news is below.

Apache License 2.0 — with one layer worth knowing about, since you're building on it:

The Sonos integration doesn't carry a license of its own. It's part of Home Assistant Core, and the Home Assistant project's governance sets Apache 2.0 for all of its code projects, so the integration inherits that. Apache 2.0 is permissive: you can use, modify, and redistribute the code, including commercially, as long as you keep the copyright/license notices and note changes. It also includes an explicit patent grant from contributors.

Underneath it, the library the integration actually talks to the speakers with — SoCo, the same one your Eisy plugin's backend uses — is MIT licensed, which is even lighter: essentially just keep the copyright notice.

So for your porting work, both layers are permissive and compatible: nothing copyleft, nothing that forces you to open-source the PG3 plugin you derived from them, just attribution obligations if you redistribute their code.

A note about my set up; the AMP is configured as the rear speakers for the Arc Ultra.

You can see from the attached that Amp Multi speakers have a Port assigned and the One: Spa does not. The One: Spa is found by the current plugin.

@Howard Will you please explain (for dummies like me) what the multi zone amplifier does? I know that the ST-Sonos plugin had a problem with the various speakers joining the wrong zones. Does the amp solve this issue? What are the advantages of the amp?

@bpwwer I can't migrate the ST-Sonos plugin to eisy-UI. I've read in these forums that it's not ready to so yet. Are you involved with moving it and, if so, is there a timeline?

Thank you both,

Ross

Hi Ross.

It's very new and just being introduced in Canada. It's essentially four AMPs in one. One IP address and individual ports for each zone. It has audio enhancements and some minor limitations like lack of HDMI and inability to use a zone as rear speakers for an ARC Ultra.

Sonos Amp Multi—The Multizone Amplifier

4 hours ago, Ross said:

@bpwwer I can't migrate the ST-Sonos plugin to eisy-UI. I've read in these forums that it's not ready to so yet. Are you involved with moving it and, if so, is there a timeline?

Thank you both,

Ross

No, I'm not really involved with migration issues unless it's something I encounter personally and work with UDI to resolve. I'm not sure of the state of migration for javascript based plugins. Since I have no Sonos devices, it's very hard for me to test/debug issues. Best to submit a ticket when you have migration issues.

@Howard I've got something at appears to be working. I'll try and get it published to the beta PG3 store today so you can try it out.

I'm still a bit concerned about the licensing and copyrights

From what I can tell, no code from the HA integration was used so their license/copyrights aren't relevant.

However, the plugin files: sonos.py, controller.py, and device.py are based on template/boiler plate code in the script. The copyright/license for the code the template/boiler plate was copied/derived from should be passed down to those files. If I understand correctly, it was an AI that created the script and we don't know what files it referenced to do so.

Who created the backend.py file? Is that something you created or was it also created by AI.

It's probably safe to license it under MIT as most other plugins are but it would be nice to have proper copyright info for the files.

Hi Bob,

So I went to the Wizard of all real and imagined and asked "Who owns the copyrights to the code you gave me for the HA Sonos to UD EISY port?"

Short answer: nobody owns most of it — and I checked the actual files I gave you before answering, because the wording in them matters.

Here's what's in the package at ~/workspace/your_files/ha-to-eisy/ and who holds what:

The code I wrote for you — no copyright attaches to it. The converter (ha2pg3.py), the sonos.json descriptor, and the Sonos backend (sonos_backend.py) were written fresh in that session, at your request. Copyright requires a human author. I can't hold copyright (I'm not a legal author), and neither Meta nor I claim any rights in output I generate for you. The US Copyright Office's position is that purely AI-generated material isn't copyrightable by anyone — so practically: it's yours to use, modify, sell, or give away with no license needed from anyone, but symmetrically, there's no copyright in the AI-written parts that you could enforce against someone else using identical code. Copyright would attach to creative edits and additions you make yourself.

No Home Assistant code is in it. Despite the "ported from the Home Assistant sonos integration" wording in the generated header, nothing was copied from HA's source. The backend is original code written against SoCo's public API; what it borrows from HA is the model — media_player service names like media_player.media_play and the shuffle/repeat decomposition. identifiers and functional behavior aren't protected expression, so HA's contributors (Apache 2.0) have no claim on it. If actual HA code had been pasted in, those portions would still belong to their authors under Apache 2.0 — that situation just doesn't arise here.

The only real third-party copyrights are the libraries it calls, not code in the plugin. Your requirements.txt pulls soco>=0.32.0 (MIT, © the SoCo contributors) and udi_interface (Universal Devices' PG3 library) at install time. SoCo's MIT terms oblige you to keep its copyright notice if you redistribute SoCo itself — merely using it via pip doesn't put conditions on your plugin.

One caveat: I'm not a lawyer. If you end up selling the plugin through the PG3 store, a one-time legal opinion is cheap insurance — mainly for the AI-authorship point, which is settled guidance in the US but still lightly tested in Canadian courts.

---

---

It's pretty impressive and it seems like you are right on the mark about MIT.

Ok, we'll go with that. It should be in the non-production store now (or refresh the store listing to see it). It's called SonosV2

Thanks Bob. I'll try it out tomorrow. My wife doesn't like Black Sabbath when she's sleeping (or ever).

Hi Bob,

It looks promising and I had some success with the new version. I could control Kitchen through the mobile app (stop, play, volume) but I couldn't do it for the Family Room. I couldn't select a command from a program. I restarted the plugin and attached the debug log and a copy of the nodes.

I'll continue to try things and let you know.

Thanks,

Howard

Node Details V2.pdf SonosV2_10-29-2026_83659_AM.zip