Era does not have SonosNet, either. As I understand it, SonosNet is not the way forward.
Same. My OG S1-only Play 5 has WiFi.
1 Like
Good news, no recurring error after the what I posted, and I didn't get the error during the update check either. Also, the mute state is being respected for TTS now. Waiting to confirm the queue getting stuck issue is resolved too.
Assuming nothing goes sideways from here, this build is pretty solid for me. Thanks again for all your efforts...
1 Like
Queue is still getting "stuck" unfortunately, playing a high priority TTS clears it as usual.
I'll take a double check on the queue/dequeue code and see if there's somewhere else they might get stuck.
Does the first one play, then after that they get stuck? Or does it not play even the first message sent? I'm wondering if you're losing the websocket subscription for AudioClip namespace and not getting the notification that the first message finished.
If that's the case, then I can add a second check to dequeue a message when it's been, say, message length + 10 seconds since the previous one was sent, and see if there's some better logic I can put in to help maintain the websocket connection.
Seems to just randomly get hung up on various speakers. The state variable "audio clip playing" shows true even though nothing is playing. I can't play a normal TTS when this happens, but if I send a high priority to the "stuck" speaker then all of the queued messages starting playing. I haven't "caught" it happening it's not until I expect a message to play and it doesn't that I notice it.
I agree, flushing the queue after a period of time is probably the way to do it, but I'm not sure?
Edit: on a positive note, none of the errors I saw at the release of this build have reoccured👍🏼
Another queue "hang", this time it was after a group message. Both of "followers" got stuck with the variable state "audio clip playing - true" even though nothing was playing, however the "coordinator" didn't..
I've just noticed 'Get Favorites' is no longer working, I've not used it for a while. I've tried it on several players. No errors are showing in the logs. 'Load Favorites' is working though.
Do you have at least one device with the favorites child device on it? I'm moving away from having the code in the app, because I think that's (at least partly) what's causing some of the issues I'm seeing. As such, the favorites matching now requires a child device on at least one player for it to work. I put mine on my Arc, since it's hardwired and has more CPU (I think) than my Ikea Sonos speakers. But it really has very little impact on anything, so any speaker works fine. There's no need to run it on more than one speaker.
One of the benefits of moving it onto a child device is that it can be subscribed to the Favorites namespace, which means any time you change your favorites it's automatically updated now, no need to click on getFavorites() to update the list.
1 Like
I must have missed this above, it's working now, thanks
Some, but it's hard since I'm not really able to replicate it.
The high priority ones don't use a queue but otherwise function the same, so in the meanwhile you can use those as they'll never get stuck. Tho they will 'clobber' each other, which stinks.
I did notice that if I set up 2 back-to-back low priority messages in a rule it would play like 1 second of the first message then move on to the next, so that's at least something I need to figure out and fix, and possibly fixing it will fix the stuck queue issue too. If I put a 3 second delay between them (which is much shorter than the length of the messages) it works fine, so it's as if there's somehow a race issue on the concurrentQueue object, which shouldn't be possible, since that's the entire point of the concurrentQueue, it's supposed to be thread-safe.
I think having it resubscribe to audioClip namespace right before queueing up messages might be part of the issue. I had it do that since I didn't see if causing any issues, and it would help ensure it's subscribed. I'm going to pull that out and instead focus on improving any places where it might fall out of subscription without Sonos Advanced knowing and resubscribing properly. I've got that in place already for the XML side of things, but the websocket stuff works a bit differently.
Actually I've started using the high priority option for a few of my less frequent TTS messages, this seems to help make sure the queue is flushed. Thanks again for your efforts.
Not sure if am missing something here, but when I attempt Sonos discovery nothing happens.
In the first paragraph of the "Near Release" introduction it states there is no need for a Sonos Developer account. Yet, in the very first reply @KurtSanders says, "Created the Sonos developer account, keys and authenticated as you stated:"
What's up with that?
Was I supposed to first have the native HE Sonos app installed? Sorry to be such a NOOB, but that's what I am...
I have Sonos Port and HE installed on the same subnet. I also have Sonos and HE apps installed on a iPhone on that same subnet, so I know both are correctly installed.
No need for developer account. And you can have both native and this app installed, however from a resource standpoint you'll likely want to choose one or the other.
@daniel.winks will likely chime in shortly to help you diagnose your issue with discovery, it works perfectly for me
A Sonos developer account is NOT needed for the Sonos Advanced Control... @daniel.winks improved this app to discover and control the Sonos devices locally.
Here's where I'm apparently stuck:
- Installed Daniel's rep link to HPM as custom; did Match-Up > Repair > Un-Match > Match-Up > Repair (I did this over a few times just to make sure everything stuck. I show the App, Drivers, and Libraries all installed.
- Fumbled around until I finally added User App and was able to select Advanced Sonos Controller.
- Click on Sonos Virtual Player Devices button and it states "Discovery Started!" Nothing happens even after extended wait time. Log shows the following with debug enabled:
Is there something I need to be doing on the Sonos end? I was looking at his GitHub and see Sonos Cloud Controller, though didn't install since the I'm taking the hint there is no cloud needed. I just don't have any historical experience on Hubitat to know what's preceded this integration, as I'm about a month into HE.
Anyway, Daniel is a busy guy right now so if one of you other guys could get me going...
This is on HPM proper now, no need to add a custom repo. But assuming you're on the latest version, you should just need to click on the app, then discovery and it should find your devices.
Do you have a 'normal' router? Some people get UniFi routers and turn on every option without really knowing what they do and break things like SSDP and UPnP. 'Discovery' utilizes both. At some point I'll probably add a 'manual device creation' page where you can specify IP addresses, but until then it needs SSDP working.
That was my first foray into this app. Initially I used the Sonos Cloud API, but after a few weeks of deep diving I found ways to do everything the cloud API does 100% locally. Rather than gut and re-write the first app, I just did a copy/paste on its code, left the old Cloud app alone, and put everything in what's turned into an entirely different app. You don't want or need anything from that old app. I just left it alone since technically it worked "ok" for what it did, and changing it to the 100% local version would entirely break things for anyone still using it. It's abandoned at this time and you definitely don't need anything from it for Sonos Advanced to work.
So yes, I have the UDR. UPnP was turned off. I appreciate that UniFi has this to enable per VLAN.
That alone didn't solve it. IGMP Snooping was turned on for my IoT VLAN and I had to disable it.
UDM Pro here with a flat network. No need for UPnP to make this app work for me. VLANs on any network equipment are notorious for interfering with Sonos
That's interesting. I read that SSDP is only enabled via UPnP on UniFi.
