I don’t have speaker pairs, only a single Amp player and Move. If I group them, I don’t see consistent volume tracking between ST and the Sonos app, regardless of which I use to change volumes.
Okay, that may be related to the driver disconnect issue, because I’ve seen that from time to time as well. It was worth a try. Thanks.
Good shout 
Will be keeping my fingers crossed for this. Would be good to have the option to make sure a playlist plays on shuffle, and not having the same songs playing in the same order. Would eliminate the need to use virtual switches/Alexa routines, which is what I currently do.
1 Like
A new version of the driver posted on 3/7/2023.
Yes, I hadn’t mentioned it already because there is one other bug related to driver switching that they are fixing. It won’t impact anyone already using the current beta, but it showed up in testing after the last merge as I was moving between public and non-public versions of the driver.
FWIW, the preference setting for replacing the queue is in settings, is per device, and not available via the Rules API (most people would rarely change this setting anyway, I think). All the groupMedia (mute and volume controls) show up in routines and are also available via the Rules API.
I’m going to work on a PR to add the playModes setting, but it’s a bit more complicated because that definitely needs to be accessible to routines and rules. Alphabetizing favorites in the driver presentation shouldn’t be too hard, but it’s not really a priority for me, either.
Create/Join/Leave groups is complicated for a variety of reasons and probably isn’t going to happen unless somebody a helluva lot smarter than me gets involved.
Anything related to the AMP and Move you’d like to see?
The queue preference seems to be the only setting 
I saw the groupMedia options as both Triggers and Actions in the Routines.
The Port and the AMP have the line-in jacks and it would be nice to be able to change the line level. The Port also has a line-out with adjustable line level. Not sure if it’s possible to change from BT to Wi-Fi programmatically on the Move, but that could be useful as well I suppose.
1 Like
At first glance, I don’t see anything specific to these in the Sonos Control API, but that doesn’t mean it’s not there.
Hi all,
Driver seems very responsive so far. However I have a few observations/niggles that could do with being addressed (don’t think raised here, apologies if they are):
-
Requesting a favourite through a routine does not seem to work - favourite is not played
-
On scanning for new devices, paired speakers are identified with a status of offline. I have seen this with both a stereo pair and with surround rear speakers but not with a surround sub.
-
On scanning in ST for new devices, previously added Sonos speakers that have been renamed revert to the Sonos name
I am using fully updated v2 hub, driver and android app, any thoughts/observations?
#1. Ah, I hadn’t tried this in routines, only via the device presentation. This is actually working; the problem is the favorite field is looking for the favorite’s ID number and not the name. I don’t know if this can be called a bug exactly, but since most people have no idea what the ID numbers of their individual favorites are, it’s definitely an issue.
#2. Known issue. SmartThings is aware.
#3. I’ve seen this, but it’s not been an issue for me as I typically don’t rename my speakers. But this is something that should be corrected.
1 Like
Hi @bthrock ,
The favourites issue is very frustrating and I went through the number vs. text issue with schwark helping him debug his driver which now works with favourites very well. Really wanted to use the ST driver to keep my queues clean and because it has immediate status updating. Really hope ST can address this as number referenced favourites are next to useless, specially as it is dynamic within Sonos and not visible in the interfaces!
Renaming I can live with I guess but it is very annoying, again something schwark handles fine…
Really need a hybrid of the two but for the moment I’m running the two side by side, which is messy and should be unnecessary 
Hopefully ST will address these issues before coming out of beta as, for me, #2 is the least worrysome🤞
(a leaf could be taken from Ikea’s book, thier favourites integration is very good. Selection by name, with graphics and allows grouping)
1 Like
This is due to how the preset capability is built as @bthrock mentioned. You are entering the “name” of the preset, and they want the “ID” of the preset. I had to write something special to accept presets by name for Hue. The implementation of the capability is not fully baked yet.
The actual name of the device is changing on the device tile itself? That isn’t supposed to be changeable via code, so that would be interesting.
I was thinking about writing a sonos driver soon. I’ll have to check this out first and see how well it works. It may be worth writing my own just to get the presets working.
2 Likes
I understand, although to be fair, this is a Beta driver still very much in its infancy. Issues such as this are to be expected.
The Sonos Control API uses the favoriteId exclusively with good reason and, as @blueyetisoftware notes, it’s up to the developer to put a pretty face on it for the UI. It’s not terribly difficult; a Replica (ST mirroring) driver I recently wrote for Hubitat allows favorites to be loaded by name (either exact, case-insensitive, or partial match) or by Id with relatively few lines of code.
From my perspective, this should be something of a priority, because only a tiny minority of users have any idea that there even is an favoriteId number, and even fewer know how to reference it, meaning most won’t be able to request favorites by routine as intended. However, as the device presentation in the app already has a dropdown for favorites name that works fine, this shouldn’t be too terribly difficult to fix.
I have some other projects on my desk, but after seeing your post this morning I thought I might try to find time this weekend to look at what would be involved in creating a pull request for this one. However, given my still somewhat limited grasp of Lua, perhaps @blueyetisoftware could get this done quicker. If he’s interested, perhaps we can discuss it by DM.
3 Likes
@bthrock amd @blueyetisoftware that would be great! May be worth looking at @schwark 's driver too as he already handles favourites by name although, from a routines pov, not in a list.
Anything I can assist with around running a test install just shout 
That is how the Hue driver works as well. It is a text entry. The capability doesn’t currently allow a list in the routines. If this was ever added by ST, we wouldn’t need the workaround.
2 Likes
I wondered if that might be the case. 
I’m Alejandro from developer support team
For 1 and 2 the corresponding team are working on it, for 3 Did the device add using driver or DTH?
@TheHundredthIdiot @blueyetisoftware
Just FYI, I was advised today by SmartThings that the “requesting a favorite through a routine” issue is actually a platform bug upstream of the edge driver, but they are aware and will be working on it.
2 Likes
Yes. There’s a fairly easy workaround in the drivers though. It wouldn’t take much to make the driver appear to work.
2 Likes
Hi @AlejandroPadilla thankyou for the update. My Sonos devices are all on the edge driver. The initial scan creates devices with the Sonos assigned names. Rename some or all of these devices in ST:
and they work and function as expected. Subsequently rescan for devices and any renamed Sonos device reverts to its Sonos assigned name:
without any intervention. Just to remove any room for doubt I am replicating this at will and the driver details are:
1 Like
Hi @TheHundredthIdiot
Can you check if by renaming the device from the Sonos app and then re-scanning for the devices, the name was changed to the Sonos app name?