I’m having trouble figuring out what you’re saying here. Anyway, if your Say actions in scenes aren’t working, go find them in the LuaUPnP log file and see if there are any messages logged with them. That’s always a go-to.
Looks like you have extra spaces in the code, although I can’t tell because you’re not using the forum formatting, either. When you post code, you can post short bits by putting a single back-tick ` before and after the string so `text like this` will look like this. For longer strings or multi-line code blocks, put three backticks ``` together on a line by itself, followed by your code, followed by three backticks again on a line by themselves, so:
Aha… I found the url we used back in the day to check UPNP logs.
‘’’
luup.reload()
‘’’
Then went to
‘’’ http://my vera ip/cgi-bin/cmh/log.sh?Device=LuaUPnP
‘’’
Attached are the files. Can somebody tell me why my codes not running?
The Scene is sayin “Success” when I run it.
I do notice my #298 sonos connect zone has RV as the TTS choice …in Advanced Settings. But
Azure on ther TTS page and my TTS code is asking #298 to be coordinator for the 4 other zones wfich by the way don’t have that TTS Server Box on their advanced Variables page…
When I try to delete the RV choice on #298 Advanced Variables page it says “I can’t leave it blank.”
Again all TTS Pages Engine Default and Master have Azure listed on the TTS default.
Onlt the 298 device has the option on it’s Advanced Variables page…and it says RV…
Hope this helps to fix it!
I’m not sure what to fix. If it works when you use the TTS tab on the device, it’s working. It uses the same action that your scenes would/should. The state variables on old adopted devices don’t matter–they’re abandoned and have no effect on 2.0’s TTS.
Your posted log doesn’t have a “Say” action in it, so there’s nothing useful there. You need to capture a log. My intent, by the way, is that you look for yourself at the log file, find the “Say” action (using your browser’s in-page search on the log display for exactly that string) and see if you can identify any messages that may help you troubleshoot it.
Just to be clear…
I have attached the Adavnced Variables page from my updated Sonos Connect. After the update to 20072.1815 I noticed this “original numbered 298” device is the only one of the Child Devices to have RV as an option on that advanced Paramiters page.
Last time I updated I had all new device numbers and Advanced pages all looked a like.Sonos Advanced Paramaters page.pdf (3.3 MB)
The plugin is not looking at the variables on device 298. The TTS config for 2.0 comes only from the Sonos System master device that are set on its Settings tab.
Good Morning
I’m way out of my comfort zone here so please be patient with me…
Attached are 2 upnp log files for today 3.14.20 and as instructed I searched for “say” commands in both after running a few scenes.
One from around 9am with is showing no “say” commands hilighted from my search
Also rebooted and ran some more scenes at @ 11am. Both upnp log files used the luup code below which show “Success”.
In the second file Pages 33 & 34 show a found Say command with the correct device numbers requested by the code.
But we still do not here the house talking.
We do hear the house when I do a TTS command from child devices. We here the chime then the TTS.
Here is the code I copied from an earlier thread above.
‘’’
luup.call_action(“urn:micasaverde-com:serviceId:Sonos1”, “Say”,
{ Text=“Door Open. Basement Door Open”, Volume=55,
GroupDevices=“298,642,643,644,646”,SameVolumeForAll=“1” }, 298)
‘’’
Tried to use proper format for posting code.
Hope you can help!
Version 20073.2230 is now posted. This pretty much cleans out my to-do list for this release.
Reduce network traffic in systems with more than a couple of zone players. A carry-over from the old single device model (1.5 and earlier) is that every zone device would subscribe to UPnP events that were system-wide, such as zone topology changes and content (favorites, saved queues, etc.) changes. Each device would then store its own copy of this data, even though it’s actually the same for every single device. This was hugely wasteful in memory and contributed substantial network traffic for even modest-sized networks (5 or more zone players and satellites). The system now designates up to two zone players to be “masters” for this data. The master(s) exclusively subscribe to the system-wide datasource events and store a single copy of it on the Sonos master device for all zones to share. This removes the SavedQueues, FavoritesRadios, Favorites and ZoneGroupTopology state variables from all zone devices; they now appear only on the Sonos master device.
A new UnMute parameter has been added to Say and Alert actions to force the unmuting of muted zones involved in the action. This parameter is boolean (0 or 1), and defaults to 1 (force unmute).
Spent some serious time figuring out, refactoring and testing the decodeURI() function. All documented URI forms have been tested and work as advertised (the Help tab on any zone device lists example URIs for the current configuration, e.g. how to play a saved queue, etc.).
The TTS cache is pruned of speech audio files unused in 90 days or more. This frequency is controlled by the TTSCacheMaxAge state variable on the master device (unit is days; if 0, cache pruning is disabled). See further notes/recommendations below.
The new UseTTSCache boolean state variable (default 1) can be used to disable the TTS cache system-wide. When disabled, all TTS actions will require contact with the configured engine on each action. This may slow TTS performance, and disable it when Internet access is unavailable.
The TTS Language parameter is now deprecated and will be removed from a future release. There is a natural close coupling between the selection of the engine and the language in TTS configuration. Azure uses voice rather than language alone to determine language, gender, and other qualities of the generated speech audio, and the keys for selecting voice are not ISO language specifications as the Language parameter requires. Since I believe actual changes of language in TTS configurations (especially at runtime) are rare, I think deprecating this parameter is a valid and simplifying choice.
A Note About TTS Caching
Some of you use Reactor and similar tools to produce “dynamic” messages for TTS, including dates, times, weather, lists of low-battery devices, etc. Clearly, there is no need to cache these speech audio results, as they are unlikely to ever be repeated exactly as first presented. To avoid filling the TTS cache with these “zombie” speech audio files (waiting to die at the hands of the cache pruner), I highly recommend adding UseCache=0 to your TTS actions when using dynamic/on-the-fly text. If you don’t do this, since the default cache age-out is long (90 days), if you speak a lot of dynamic phrases, the cache could become quite large and have a negative impact of available storage on your Vera. You can alternately either (a) set master device state variable UseTTSCache to 0 to disable the cache system-wide, or (b) reduce TTSCacheMaxAge (unit: days > 0) to purge cached phrases more frequently. (Don’t do both–that’s nonsensical because cache aging doesn’t apply if the cache is disabled.)
In contrast, users who tend to speak only a limited number of fixed phrases may want to set their Sonos master device state variable TTSCacheMaxAge to 0 to disable cache pruning completely, so that no generated speech audio is ever discard, and once generated is re-used forever more without access to the remote engine. This would be very desirable for such systems that routinely have inconsistent Internet access. But is only recommended when both (a) you only speak a limited number of fixed phrases, and (b) your Internet access is unreliable. If you disable cache pruning, you must manage the cache yourself.
If you need to remove the cache to reclaim partition space, you can:
openLuup: remove the subdirectory ttscache from your openLuup install directory.
A Note About TTS Resume
In order for audio play to resume after a Say or Alert action, the media playing prior to the action must be either a queued form (e.g. current queue, saved queue/playlist) or a reproducible streaming URI. In the case of streaming sources, such as Pandora or Spotify, it may not be possible for the resume to continue from the point at which it was interrupted–it will play the next song the streaming source decides to play. This is a limitation of using streaming sources, and will not be fixed. Further, it is often the case that the manner in which media plays when driven by Alexa voice commands makes it unresumable. If that changes in future, it’s likely to just start working on its own, but I’m not going to spend any more time chasing it now.
The first log file is showing that you’ve got some junk in scene Lua for one of your scenes, so it isn’t compiling. On Vera, if you have a syntax error in any scene Lua or the startup Lua, none of the scenes or startup Lua will/can be compiled and thus will not work. So you need to fix that, and then check the log for similar errors to make sure you don’t have the same problem in another scene. Until you get that squared aware none of your scenes will/can run. You probably have an “Error in Lua for scenes” message on the dashboard UI as well? Here’s what it shows in that log:
01 03/14/20 11:12:59.235 LuaInterface::LoadCode: [string "function scene_27()..."]:74: unexpected symbol near '�' <0x7766f000>
It’s hard to interpret these error messages, because the function name mentioned in the error message is a red herring–it’s just the first few dozen bytes of the code block, not the actual location of the error. The line number “74” shown, however, is very telling. It suggests the error is further down the code, and it turns out, is the last line of the code block. There’s a garbage control character at the end of scene 72’s Lua. I can see it by copying the whole PDF contents into my text editor. I suggest using LuaView if you’re not already using it.
(The “SOH” is the garbage control character: ASCII 0x01, aka CTRL-A)
On the second log file, the GetBass UPnP errors are benign. You have a device that doesn’t support that query in the service. No harm. It’s not worth anybody’s time or trouble to figure out what every different Sonos device and firmware supports and try to skip unsupported queries–since they are constantly changing firmware and constantly changing the product lineup, we’d never get it right/complete, in fact. We just make the query and let the device tell us it doesn’t want to answer, and leave it at that.
Researching Luaview
As usual thank you.
Am I correct that we could test lua code via :
Vera, Apps, Develop Apps, Test Luup Code?
Where do you suggest I start?
Sonos wise the code you corrected in an earlier thread is saying Success when I run a Scene.
Are we talking I need to find an error in any scene scripting or Sonos?
Also
Should I wait to fix this until I upgrade to that awesome post for Version 20073.2230 that you just wrote!
You have an error in the Lua that’s in scene 72. It’s got an extra garbage character at the end of the code, after the closing parenthesis. You need to go in to the editor for scene 72, and where it says “Also execute the following Luup code” click the array to go into the Lua for that scene, find and remove the garbage at the end. If you can’t find it, start over: clear it out to blank (select all, delete), then save the scene. Then go back into the scene and repaste.
Alternately, once LuaView is installed, go in to LuaView and look at scene 72. If you make any kind of small change and then exit the code field, it will test-compile the code and flag any errors. Fix. Then reload Luup.
Once the scene can compile, your are ready to run the scene. Not before.
