New version on HPM should respect mute when sending normal priority TTS.
2 Likes
Doesn't appear to be working as planned, if I play a TTS using the speak command it still plays on a muted speaker regardless of mute state. I've also noticed on occasion messages seem to get stuck in the "queue" until a high priority message is sent then they come through in succession.
Interesting perspective 
Ugh.
The whole reason I have a few thousand dollars worth of Sonos is the ease of use and slick form factors. Previously I had random DIY speakers connected to Raspberry Pi running SnapCast. It was super fiddly, required reboots frequently, but it worked "ok".
I'll Ebay my Sonos before I pay them $80/yr. I bought speakers that don't need a subscription. It should be illegal to sell a product then years later revoke access to parts of that product people paid for and make it a subscription.
Sonos needs to fulfill their promises of a proper LOCAL API so stuff like Sonos Advanced doesn't require 3 different undocumented APIs to work, and people don't need some stupid $80 a year subscription just to access features of a product they already paid for.
4 Likes
That article isn't properly sourced and sounds suspect to me for a number of reasons.
To begin with, rather than "struggling," Sonos has recently reported reasonably strong earnings. Yes, the market is shrinking, but Sonos has been gaining market share and will be releasing new products in 2024.
Secondly, if Sonos' plan was to start charging for SonosNet, why was SonosNet removed from the new Era 100 and 300 speakers? And what exactly is the "proprietary app?" The one we already use to operate our system?
I realize subscriptions are all the rage right now, so its possible there's a tiny grain of truth in this story. But if I buy a car, use it for years, and then the dealer calls me up one day and tells me I have to start paying for the right to turn it on and drive it, that dealer and that car company are going to be out of business in no time.
3 Likes
I could not agree more with you @daniel.winks .... my 12+ year Sonos investment of 15 S2 devices is substantial.
When I invested in these expensive speakers, it was with the understanding that that revenue from the sales would be depreciated to allow for playing S/W and compatibility and feature updates. I don't know where that article got the $80/year (According to several sources), but that annual figure would make me potentially explore the following:
- Stay with my current S2 version of Sonos devices and curtail any new speaker purchases and/or legacy hardware discounted upgrades.
- Explore alternative means to play streaming music like Spotify directly (airplay/bluetooth) options if these still worked.
Perhaps that $80/year is the premiere audiophile tier level for delivering super high fidelity media/output. Our household mainly plays streaming audio from Spotify and Apple all day long?
Let's hope Sonos can figure out their sales of new hardware & products to keep their s/w included as in the past or a merger with JBL, Bose, Yamaha, etc...
1 Like
@daniel.winks, @bthrock, @KurtSanders
I couldn't agree more with all of you! When I read it, I couldn't help but laugh out loud. Hence, my polite comment, 'Interesting perspective.' Thought I'd share it with fellow Sonos aficionados like us. Cheers to finding humor in the little things!"
2 Likes
Let's face it Sonos have form for upsetting people. When the new S2 products and app were released..."Here have a 30% discount on a new Amp and throw the previous one in the bin as it'll not work anymore". That did wonders for their stock price at the time and they had to backtrack and change the plan. Surely they wouldn't be dumb enough to try a similarly controversial subscription model. I never updated and I have 8 or 9 old Zone Players installed and another 4 or 5 sat gathering dust (as they're worth so little). All I'm missing on them really is Airplay so I can play direct from Apple Music without their app.
4 Likes
Not sure on that SAX error... it basically says that whatever your speaker sent to Sonos Advanced wasn't proper XML. I'll wrap the parsing in a try/catch to silence these, as they really don't affect anything.
As for the 3rd error... click on "initialize()" on each speaker device (or reboot Hubitat, it does initialize() on them on boot up). I took that subscription out entirely since I found it wasn't actually needed. Initialize() will remove the recurring schedule for resubscribeToGMEvents.
Yeah, SonosNet is really not something to be concerned about... It's nothing special. A $10 bargain bin WiFi router from WalMart could do the same thing. If I really wanted a dedicated 2.4GHz network it's not hard to get that.
$80 is also about what it'd cost to get a cheap fiberglass fish rod set and some cheap Cat5 and just hard-wire all my speakers. I'd hard-wire everything out of spite before I paid them anything.
Now, $80/yr is almost exactly what Sonos' current price for their streaming radio thing costs. I'm wondering if the author on that article is just all sorts of confused.
2 Likes
Bah, I put in the if(getIsMuted()) but forgot to put in a return to bail out of the method it it's muted... just added it.
It'll be on next release. Sorry.
Taking a look to see what might cause the queue to get stuck.
2 Likes
SonosNet doesn't even exist on some newer devices. WiFi and/or Ethernet only.
I think that's the answer.
1 Like
0.4.4 out.
Actually put in a return statement to properly 'bail out' on TTS messages sent to muted speakers.
Wrapped parse() in a try/catch, and added a 'bail out' return for messages that occur when Sonos is doing an update check. These update checks send a couple of lines of "not XML" in the middle of the XML and it causes SAX parser to fail. Sonos Advanced doesn't need anything out of these messages, so I'm just going to ignore them and silently drop any error they cause.
Re-worked the TTS queue dequeuing code a bit. Hopefully it's a bit less likely to get 'hung up' now.
3 Likes
Not showing on HPM for me?
I forgot to click 'merge' on my pull request on GitHub... coding while feverish and loaded up on Nyquil is hard, lol.
1 Like
After install got an elevated load alert, rebooted, and then got these. Still monitoring...
Edit: Hasn't thrown the warning since then...
That's only Roam and Move though as the SonosNet mesh would be no good if the speaker moved about all the time. This sounds like another push to get rid of the older devices that don't support wifi that only just made the Gen2 grade, Play:1 etc.
This is worrying though, it doesn't just say SonosNet, it says the app and updates
According to several sources Sonos is looking to charge $80 a year subscription basically to get updates and access to their app which is essential when you buy a Sonos speaker
Nobody else it reporting this though, only that website 
Eh? My PLAY:1's (Not the later "One") are WiFi --- so is my PLAY:3 (which has long been gone in production terms).
But to support your other point, I actually saw an article last night in my news feed that sort of countered the article linked previously by @DGBQ : "https://www.barrons.com/articles/sonos-earnings-stock-price-44a18217" & Sonos stock climbs after Q1 earnings beat
If they have strong earnings, and a stock jump, this seems like a company that is not "troubled" and about to commit sepukku in terms of their customers....
S
Ugh, I'm so tired of trying to figure out what causes these 120 second timeout warnings. 
parse() just takes an incoming JSON or XML object and parses through it. There's absolutely nothing that should take more than a few milliseconds here, and 99.99% of the time it does just take a few milliseconds. Then randomly it times out at 120 seconds like this. I really think this is some issue with Hubitat platform itself that my code triggers sometimes.
My best guess is that it's somewhere it tries to do a driver -> parent app -> sibling driver call, which I'm working on eliminating in the next few releases.
And that idea seems to line up with your warnings here, since you have 2 parse functions hanging and a call to updatePlayerCurrentStates() which is indeed a function on the parent app meant to update sibling (follower) devices with the states from the coordinator device.
Now, while I think it's driver -> parent app -> sibling driver type stuff that causes it... there's no reason it should cause it. I've got my money on that being an actual issue with Hubitat itself.
