Version 1.4.3 (development)

OK. I touched base with the original author, and we’re good to go.

I’ve rallied all of the various code bits I can find, including my own recent fixes for TTS, and posted them on Github: GitHub - toggledbits/Sonos-Vera: lolodomo's Sonos plugin for Vera, updated, enhanced, public domain and community-supported

I am calling the current repository version a development version, not an official release, numbered 1.4.3.

Please try this version out if you are so inclined, but please be aware of the following:

  1. I have no way to be sure that every change that has ever been published has been incorporated. The project became very fragmented since its last official release, and I’ve run across one complete ZIP file and several single-file updates with a lot of non-overlapping changes. I’ve tried to make sure that this version incorporates (at least in intent) all of the changes I know about, but I suspect there have been some that I haven’t yet found. It’s not easy sleuthing this stuff out of the considerable volume of two sets of forums. :slight_smile: It’s therefore reasonable to expect bugs and missing features/fixes. Don’t panic. Just bring it to my attention and we’ll figure it out.

    You would do well to back up your Vera and/or scp a copy of the plugin files you are currently using to a safe spot, if only because they may be helpful to me in getting my hands on a version of the code I didn’t yet find that contains some feature/fix you needed.

  2. I wasn’t happy with the way changes to TTS support for openLuup were made in the versions of code I found (they seemed to break Vera), so I revised them into something that works for both. openLuup users will need to set the TTSBastPath and TTSBaseURL variables. See the “Special TTS Configuration for openLuup” section of the README in the Github repo for details.
  3. ResponsiveVoiceTTS is working again. It was broken because RV started redirecting to an HTTPS endpoint, and it seems current versions of wget on Vera firmware don’t like that. I just changed the code to use curl and it’s much happier now. I also changed the default URL (now https://code.responsivevoice.org) to remove the extra step of following a redirect.
  4. GoogleTTS is effectively well and truly dead. The reason it’s unreliable is that Google is blocking the service after a few queries with a very low periodic limit. The service being used isn’t being used as Google intended–it’s part of Google Translate, not a public service (at least, as now intended). Google has a replacement service, so maybe we’ll get around to that at some point.
  5. I fixed the UI deadness. The UI JavaScript is written for the old JS API, and as firmware evolved some of these interfaces stopped working as before. I fixed it in place (minimalist) and the UI is again working, but it will probably need an upgrade/rewrite to use the newer JS API before too long.
  6. The use of the UPnP Event Proxy with this plugin is highly recommended. When not installed, this plugin will poll the zone player(s) and generate extra load and network traffic trying to keep up-to-date on the current state of the player. I’ve had versions of code that polled out of control–continuously (that was interesting). This version polls every 15 seconds, hard-coded. I’ll work at making that configurable, and maybe dynamic (e.g. faster when it knows the player is doing something, slower when it’s idle).
  7. I only have one old ZP100 in my network, so I’m not a great test case. Would appreciate anyone with multiple units testing, particularly the group behaviors. I have no idea what state these are in.

Please report successes and failures in this category, preferably in this very topic until the release is made “official”.

2 Likes

A question about this; is this the reason that also vera-alerts TTS is very unreliable? And is for that reason not an issue of the app and also not something which can and will be fixed on short notice?

Thanks,
Cor

That would depend on what the author used for TTS there. But if the same translate.google.com service is being used, then yes, it’s probably being aggressively rate-limited as well.

The fix is to use Google’s new service. That introduces the kind of subtle complexity you had/have with things like weather APIs, Rachio irrigation APIs, etc. Each user has to have an account registered, auth tokens need to be generated and stored, and all the necessary auths have to be added to the queries. Maybe a credit card required because it’s a free-tier service that graduates to paid (without warning). It takes 10 lines of code and turns it into 200 plus UI, and adds to it the support complexity of managing the user trying to get it configured, putting all the right keys in the right locks, etc… Yeah. Not impossible, but as they say “probably not today; tomorrow’s not looking good either.”

Hi Patrick,
Testing it out and so far so good. It works from the TTS page on the device as well as a action in Reactor. Also works from the Test Luup code window. Don’t usually send to multiple speakers but will test it out see if it is working. Really appreciate your looking into this.

Roger

Group behavior appears to be working, at least for the Say command in Reactor. I was able to broadcast to three different systems simultaneously. Tested joining to devices together from the Group section and that works.
Did find an issue with the Player section. I can kick off a Sonos Favorites selection from the app and it will start to play, however it never updates the status in the Player section or the devices main page.
Roger

OK. I’ll poke at that. Do you have the UPnP Event Proxy app/plugin installed, or are you operating in polling mode? If you are not sure, go to the “Settings” tab. It will tell you there if the proxy is being used (right above the “Debug logs” controls near the bottom).

UPnP proxy is in use.

Roger

Thank you Patrick for looking into this! :+1:
This might be a bit OT, but is it possible to have the Sonos play a mp3-file from the SSD-drive that´s connected and is a part of my Extrooted Vera Secure? Today I have the soundfile on a NAS, but doesn´t seem reliable, not longterm as least.

1 Like

If you can get the file to /etc/cmh-ludl/ on the Vera, you should be able to play/PlayURI http://vera-ip/port_3480/filename.mp3

1 Like

I have not had a chance to test this yet but will be nice to have some support for this top tier app. Thanks for your efforts Rigpapa

1 Like

I have some newer play 1’s and they have a different hardware revision which means they are not recognized with the correct icon. So i modified the I_sonos1.xml file a year ago to fix that.

I did that by adding the following in the corresponding section:

elseif (values.modelNumber == “S12”) then
model = 6
end

(The S12 is the play 1 with the newer hardware revision, the S1 is the other one)

Maybe you can add that to the repository.

Will be testing more with my Sonos setup…

Thanks @rigpapa for the work on this.

I will try to do the same thing as you, hoping it will work for me

Appvalley TutuApp Tweakbox

I made an update today in the stable branch on Github with several tweaks, particularly handling of icons and improvements with respect to the timing of polling (used when UPnP Event Proxy is not installed).

Testing and feedback appreciated as always.

I have 4 Sonos devices (from the app store plug-in) that work sporadically.
Do I need to uninstall the old plug-in before using this from github?

At this point, I think that’s probably the best course of action. Start with a clean slate.

Worked like a charm, thanks for great work!

Do you support responsive voice tts with this new Sonos plugin?

That’s the reason I got involved with it. RV was broken, I could see how to fix it. At least for the moment. These things are moving targets, you know.

My RV has been working fine for quite some time now.

You’re welcome.