svrooij
commented
3 years ago Two versions (S1 and S2) means two instances of this app. Since a lot depends on the speakers talking to each other there is no other way. The app starts by asking which speaker the current speaker knows. The JoinGroup command also uses that endpoint.
You're right that there will be some issues with the events. Take a look at the getting started and the sonos event listener configuration
| My guess that if you use these settings, you'll get a working solution. You create 2 instances of this app with these environment variables: | Setting | Instance 1 | Instance 2 |
|---|---|---|---|
SONOS_LISTENER_HOST |
{ip-of-docker-host} |
{ip-of-docker-host} |
|
SONOS_LISTENER_PORT |
6239 or not set |
6238 |
|
SONOS2MQTT_DEVICE |
{ip-of-v1-speaker} |
{ip-of-v2-speaker} |
|
SONOS2MQTT_PREFIX |
sonos or not set |
sonosv2 |
You then expose port 6239 to instance 1 (as in the example docker compose) and port 6238 to instance 2.
This will have all the messages from/to the v1 system starting with topic sonos/ and sonosv2/ for the v2 speakers.
Would you care to send a PR with your findings? this file could be improved for this exact situation.
I also own some old play5 speakers, but I don't see the point in splitting my system so I cannot test this out.
jmerifjKriwe
github-actions[bot]
Hi, I have to Sonos networks. One with old Play 5 players (controlled via Sonos S1 app) and newer Play 1 players (controlled via 'normal' Sonos app). Depending on the setting of SONOS2MQTT_DEVICE I can control the old players or the new players but not both at the same time. Is there any hack to control both together? Currently I'm thinking about using two Docker container (one for the old players, one for the new players) but it feels like overkill. And I don't have an idea if node-sonos-ts (SONOS_LISTENER_HOST) is able to work with two containers.
Best regards