If what has done guessed is working well for Say action, we could use the same principle for the general save/restore context.
In addition, it would be cool to be able to ask "all’ devices rather than specifying the id of each device.
@Guessed,
Did you make the change you mentioned a few posts back? Understanding it will result in re-creating scenes already in place, I agree with @lolodomo in “wearing the hurt now”.
[quote=“big517, post:22, topic:173594”]@Guessed,
Did you make the change you mentioned a few posts back? Understanding it will result in re-creating scenes already in place, I agree with @lolodomo in “wearing the hurt now”.[/quote]
That change, to alter the ServiceId’s to the standard for ACTIONs, has not been done. I only got one reply to that issue, from @Brientim, and I needed more positive confirmation before I made the change.
I believe we need to make it now, but it will break EVERY scene that anyone has defined, once it’s rolled in.
What would be the SID you will prefer ?
The Variables all consistently use:
38 local SONOS_SID = "urn:sonos-com:serviceId:Sonos1"
The actions all use:
39 local SONOS_ALT_SID = "urn:micasaverde-com:serviceId:Sonos1"
I’d like the [tt]sonos-com[/tt] version, but clearly making that change will break existing scenes. Having “both”, for ACTIONS, would result in dual entries in the LoV and folks would still get confused.
I plan to redo all my scenes when this is implemented anyway because it is more useful feature for people with multiple devices.
Maybe implement this is a “paging” function that does all the work of saving vol/group/playback behind the scenes, and for ease of use make whichever sonos device is being used for the page feature be the main one.
Master device: Page (global sonos save then tune all slave devices into master’s playback)
Master device : Specify playback for page duration
Pause duration in seconds
Master device: EndPage (restore all settings across sonos network prior to page function)
For advanced usage the line in now has auto detect on signal. Can you call the voltage level from sonos and have it (endPage) when there is no more voltage sensed on the master device input? I
Seems to be that there are 2 major features here that revolve around a big piece of the Sonos software which is group / party mode.
This an line level detection I just thought of would be a real nice function in this plugin especially utilizing the absence of the line in to determine when the page is finished as that could trigger the (EndPage). Function and this would be separate from party mode.
Another feature for ease of use would be in advanced tab when selecting party or page you have a drop down to select the slave devices you want included if not (all).
Just to clarify, the “End Party” function is called when all the girls at the party voluntarily leave and that is the users problem to fix.
This all looks like a lot of work but I really like the ‘page’ concept. To make it more complicated I would like to be about to assign a switch to the power supply of each Sonos box. ie I don’t want them running all day waiting for a page. Just power them up when needed and noting which one’s were already running, so the correct ones can be powered down again. Doing so would require a (settable) delay while the units power up and join the Sonos network. Clearly paging on regular basis would make this a bit silly but for say, for less frequent announcements, such as a “Fire”, it would make sense.
You can accomplish the power management outside of this plugin and the time it takes to start this up/connect and execute the grouping just to send a page defeats the urgent nature of paging.
I’m hoping they can get this basic functionality in place first… It may take a little extra work to fix some scenes, but what’s hard in the beginning is always easy in the end.
I have done few changes that should clearly help, I hope.
Please see an example of scene (image attached=. This example saves the playback context then play one of my favorite radio setting the volume to 50; 30 seconds later, the previous playback context is restored.
What is interesting for you is the new parameter GroupDevices for the SavePlaybackContext and PlayURI actions. You can use it to group additional Sonos devices. Sorry I am not able to show you an example or even test the code as I have only one Sonos, but it should be ok. You have to set a comma separated list of device id.
All this is mainly an extension of what guessed done with the Say action.
I am waiting for your feedback.
And if you are interested, I could easily add a new parameter to PlayURI action to make all this possible just calling PlayURI.
The parameter would be named CxtRestoreDelay. If set, the current playback context would be first saved and then automatically restored when the delay expires. If not set, we would have the current behaviour (no save/restore of the current playback context).
Another possible enhancement would be to let the user specify “all” in the GroupDevices parameter. This will automatically group all Sonos devices (the ones defined in the Vera). That would avoid to have to set a list of devices.
[quote=“lolodomo, post:30, topic:173594”]And if you are interested, I could easily add a new parameter to PlayURI action to make all this possible just calling PlayURI.
The parameter would be named CxtRestoreDelay. If set, the current playback context would be first saved and then automatically restored when the delay expires. If not set, we would have the current behaviour (no save/restore of the current playback context).
Another possible enhancement would be to let the user specify “all” in the GroupDevices parameter. This will automatically group all Sonos devices (the ones defined in the Vera). That would avoid to have to set a list of devices.[/quote]
These enhancements would be great. Can you set this p to specify ALL in the group devices? will that restore previous groupings after the delay?
I’ll test when I get home tonight, just want to be sure I know what to expect and how to do it for testing.
Not something I can do in five minutes. But it can certainly be implemented later if you confirm that what I have implemeted is working well.
will that restore previous groupings after the delay?
Sorry, I don’t know… To be verified.
If it was previously working for Say action, it will work for PlayURI action.
I'll test when I get home tonight, just want to be sure I know what to expect and how to do it for testing.
You have my scene screenshot as example. In another topic, guessed explained how to use the GroupDevices parameter. It is a comma-separated list of device id.
Guessed’s explanation is at the bottom of the first page of this topic: http://forum.micasaverde.com/index.php/topic,12860.msg96511.html#msg96511
When units are grouped in the way we are now doing it, I have no idea whether the volume is still managed unit per unit or global to all grouped units ?
If it is still individual to each unit, another easy enhancement could be to change Say and PlayURI actions to make the volume set globally for all the devices (the main one + the ones mentioned in the GroupDevices parameter).
If it is managed globally, then the volume I set should already affect all the units and nothing more needs to be done.
Do I only need to replace the I_Sonos1.xml and S_SonosAVTransport1.xml files?
I updated last week and pushed the png files via WINSCP so I have the icons, and i’ve uploaded those 2 files, but i’m not seeing the SavePlaybackContext - GrouipDevices action…
S_Sonos1.xml bas been updated toi.
updated all again to be safe, context menu is there. I only have 2 sonos’s plugged in right now but I noticed that when I do
luup.call_action("urn:micasaverde-com:serviceId:Sonos1", "Say",
{Text="Welcome Home", Devices="399,163"}, 163)
This ONLY plays on the 163 unit… Does this code REQUIRE 3 sonos systems, or is this a bug? I’ll test with 3rd hooked up tonight.
Testing the Saveplayback / PlayURI, PAUSE RestorePlaybackContext now…
Hoping that both devices will resume what they were playing previously.
Seems to Work, but refreshing looks buggy when testing remotely
1st test appeared to work by looking at status of devices.
2nd test did not reflect grouping playback or volume adjustment in non-master, it remained playing same
3rd test did not relfect gouping playback or volume again…
… Will resume test tonight when i’m home, and with 3 sonos’ hooked up.
Findings of Grouping with SAY function
Testing “SAY” function in advanced scene setup and grouping 2 other sonos systems (399,485);
While playing 3 separate Streaming Radio Stations via TuneInRadio
Sending text “Testing 1, 2, 3, 4” takes roughly 7 seconds to play, then another 15-20 seconds to resume previous playback of streaming radio.
Pre-existing groups before the Say command are returned to their pre-existing groups (great job).
Same tests done with Local Media files had a different results
3 to 5 seconds to speak the words which is better BUT only the Master Sonos device that executed the command would resume playback, the others sat with no queue and no music playing when they should be resuming!
Interesting to find this did not resume playing local music. So I tested with all 3 Sonos’s playing from 3 different Network Attached Storage Devices. Same Result… Only Master resumed playing, and other 2 lost all playback info except volume.
Summary-
Speed / Response time is lagging, not acceptable for instant feedback, or if you are playing from more than one network file source.
Will test Saveplaybackcontext, and restore respectively next.
Findings of Testing SavePlaybackContext, PlayURI of local file and Grouping 2 additional Sonos’s, then RestorePlaybackContext.
Same findings as above except much faster response time. Works flawlessly with Streaming Radio. however the same bug exists using 3 sources on “Music Library” will only resume playback on the Master Sonos that executed the scene.
I think that is definitely a bug.
Off topic a bit, but how to we play the “Line In” from a device? That would be my next test…
This requires guessed for testing and enhancing.
I have only one Sonos unit and so I cannot really help.
I started looking at this first for where all the time was going, given the comments about lag - something that’ll benefit all users.
Here’s a fairly typical log output showing the low-level timings of the various “parts” of the Say command executing.
For this test, I turned off Verbose logging, as well as Debug logging from within the Plugin itself. This isn’t the way we currently distribute it, but it was done to eliminate the costs of Vera’s logging functions (and we can turn off our debugging in the Checked in version as needed)
For the purposes of the test, I added a few log lines to show where we’re at in the execution of the Say command. Since the logs has finer timing granularity than os.time(), I’m using it to get an idea of the larger consumers. I also print the os.time() diffs at the bottom, but you can see they’re not as accurate overall.
The run below was a typical run. There are typically only minor variations across runs, but occasionally it takes a few seconds more. I’m attributing that to “other things” running in the Vera at that time (eg, our own cyclic refresh of the state, for example).
For the test, I used the TTS of “This is a test”.
Overall, the Plugin’s contribution to the lag is nearly 2s. The rough timing for the key contributors…
[ul][li]Google TTS: ~840ms[/li]
[li]Save Context: ~270ms[/li]
[li]SetAVTransport: ~480ms[/li]
[li]Group: ~240ms[/li]
[li]Play: ~100ms[/li][/ul]
We may be able to shim some time out of this by looking at our UPnP calls, but we’re not likely to see large savings there.
The biggest savings would come in having the MiOS UPnP routines works correctly, esp the [tt]NOTIFY[/tt] stuff, since we could completely avoid [synchronously] calling the device to get it’s “current” context. After that, a little resequencing may also help, since the Sonos must be losing some time before it starts playback also. (so tell it to Play, then tell it to Group)
If I get some time with both Sonos units, I’ll look at the other problem.
[tt]08 02/24/13 15:58:08.039 Scene::RunScene running 104 Say Guest+Master <0x2f8ba680>
08 02/24/13 15:58:08.039 JobHandler_LuaUPnP::HandleActionRequest device: 295 service: urn:micasaverde-com:serviceId:Sonos1 action: Say <0x2f8ba680>
50 02/24/13 15:58:08.041 luup_log:295: Sonos: Say: Start <0x2f8ba680>
50 02/24/13 15:58:08.486 luup_log:295: Sonos: Say: After Concat <0x2f8ba680>
50 02/24/13 15:58:08.487 luup_log:295: Sonos: Say: After File size <0x2f8ba680>
50 02/24/13 15:58:08.687 luup_log:295: Sonos: Say: After save context <0x2f8ba680>
50 02/24/13 15:58:09.143 luup_log:295: Sonos: Say: After SetAVTransportURI <0x2f8ba680>
50 02/24/13 15:58:09.319 luup_log:295: Sonos: Say: After Group Devices <0x2f8ba680>
50 02/24/13 15:58:09.368 luup_log:295: Sonos: Say: After Play <0x2f8ba680>
50 02/24/13 15:58:09.369 luup_log:295: Sonos: Say: totalTime=1 <0x2f8ba680>
50 02/24/13 15:58:09.369 luup_log:295: Sonos: Say: googleTime=0 <0x2f8ba680>
[/tt]
Glad to see some progress on this. I’m interested to see what your findings are with multiple units.
Can you also show the logs with the restore context? Thx
Sent from my SCH-I535 using Tapatalk 2