I have committed new changes:
I have not changed parameter name or action name.
Here are the available enqueue modes:
New action Allert added (in trunk).
Sonos1.Alert(URI, Volume, Duration, GroupDevices)
[quote=“guessed, post:838, topic:169644”]I think that something like the following could cover most of the bases:
[ul][li]MiOS.Play()[/li]
[li]Sonos1.PlayURI(uri, volume)[/li]
[li]Sonos1.Say(text, language, volume, groupDevices)[/li]
[li]Sonos1.Alert(uri, volume, groupDevices)[/li]
[li]Sonos1.Enqueue(uri, mode)[/li]
[li]Sonos1.SaveContext()[/li]
[li]Sonos1.RestoreContext()[/li][/ul][/quote]
Here is the current list:
[ul][li]Sonos1.SetURIToPlay(URIToPlay)[/li]
[li]Sonos1.PlayURI(URIToPlay, Volume)[/li]
[li]Sonos1.EnqueueURI(URIToEnqueue, EnqueueMode)[/li]
[li]Sonos1.Alert(URI, Volume, Duration, GroupDevices)[/li]
[li]Sonos1.Say(Text, Language, Volume, GroupDevices)[/li]
[li]Sonos1.SavePlaybackContext(GroupDevices)[/li]
[li]Sonos1.RestoreContext(RestorePlaybackContext)[/li][/ul]
@guessed: I let you rename what you want.
SetURIToPlay could probably be suppressed.
Please keep optional parameter GroupDevices for SavePlaybackContext
I have not yet added action GroupZones… I am waiting for your thoughts first.
[quote=“lolodomo, post:840, topic:169644”]
Folks wanting multiple Sonos units to play in unison, for long-term play, would [effectively] do something like the following snippet.I’ve represented it textually, but I’m intending it to mean the Advanced Scene UI.
x.AVTransport.SetAVTransportURI("x-rincon:RINCON_000E5...Y..01400") y.Sonos1.Play("SQ:Morning playlist")It won’t be one step, but each component will have recognizable parameters, and parameter values.
In my opinion, it is not user friendly, too much difficult,
But we could add a new action:
Sonos1.GroupZones(groupDevices)
In this case, the scene would become more clear:
x.Sonos1.GroupZones("38,45") y.Sonos1.Play("SQ:Morning playlist")[/quote]
I did think about that, but here’s why I’d discarded it…
When Say, or your newly added Alert, is called we need to gather all of the parameters in order to be able to autonomously save-execute-and-restore across a set of Sonos units in unison.
To do this, I added a CSV of MiOS deviceId’s to use to contact the various devices. This programming model is consistent with what’s done elsewhere in MiOS… albeit a brittle and unfriendly model. In hindsight, I regret using MiOS deviceId’s as the keys, instead of a more native key (like SonosID’s)… but that’s another story.
In this case, all the parameters must be provided “up front”, and we don’t have a choice to composite the functionality.
In regular UPnP it’s common to make a set of discrete calls to establish context and cause actions to occur. Sometimes you’re lucky, and doing something simple, so you make one call. In other cases, you need to make a set of calls to establish the correct context.
The Sonos CP does this all day long, with various “UI” actions being bound to one-or-more UPnP calls behind the scenes in order to achieve the desired effect.
Where a reasonably simple “standard” option exists for doing something, I have a preference (bias?) towards doing it with the common building block pieces.
In the case of standard grouping, there are a series of calls that can be done that achieve that effect[sup]*[/sup]. Since these calls are standard, and can be made using the built in Advanced Scene editor (no Luup required). It also means that people can sequence them in any combination.
eg. start the music, then issue all the “join” commands, for an expedited startup.
[sup]*[/sup]The missing link?
The missing information here is the string to pass in. We cannot LoV within the Advanced Scene editor, so we’d just need to put something into the UI that showed the “x-rincon:” string, and it’s lineIn counterpart, so they’d know the formal name for their device.
Anyhow, my bias towards the standard stuff is that there is Documentation/Examples (etc) out there that use it. Esp on the Sonos site, which is where I first found out about a bunch of these options. The more standard items that are exposed/usable, the more examples people can get their hands on to do far more elaborate things (some with Advanced Scenes, some with Lua)
As a side-note, I don’t believe that the internal UI needs to replicate all of the Production Sonos UI. With MiOS as the framework that would be a loosing battle. In this case, I think the primary use-case is for scene creation, and anything we can do to assist that process (doc, screenshots, sonosId printouts etc) will be the best use for our end users.
Wasn’t planning on renaming stuff, was using a pseudo-list to illustrate what we had (syntax-aside) 
As a compromise, I will:
1 - add an extra URI for PlayURI, something like “GZ:” to request playing the same thing as another Sonos zone; of course, the user will still have the ability to use the “standard” URI with x-rincon-… and the MAC address.
2 - add a new (Javascript) tab containing a table of usual URI. This table will contain the following columns:
This will be a new step but the ultimate step is to explain to the user what calls he has to do to achieve a function, with the different possible alternatives. I think that would be difficult to do that inside the UI but we can add that in the Wiki.
New enhancements committed in the trunk:
Warning: the JSON files have been updated, so don’t forget to upload the new version.
Please give me a feedback about the new help tab. And tell me if I have forgotten useful URI.
The URI table is built dynamically and you should get more information than me if you have more than one Sonos zone.
I think i might have found a bug, when i group a device in the playuri action and set a volume, the volume is only adjusted for the master device… I have not tried the latest trunk files.
In recent versions, after guessed’s request, group stuff has been suppressed from PlayURI action. But at the same time, a new action named Alert was created. I could easily modified Alert to allow the same behaviour as the old PlayURI with group management. I will do it later.
Regarding the bug with the volume, it was mentioned by guessed few messages before. If confirmed, it concerns Say and Alert actions.
Can you group 2 Sonos and then try the SetVolume action to confirm that the problem is due to the SetVolume call that does not change the volume for all the group ?
Idea: by default, SetVolume is using channel “master”. It may be that another channel has to be used to modify the volume for all the group ?
New version in the trunk:
I cleaned up the code to handle all the actions Say, Alert, PlayURI and EnqueueURI. The code is no more duplicated; internal functions have been added: decodeURI, enqueueURI, sayOrAlert. playURI is now a more basci function.
Trick: users wanting to play a URI on several Sonos zones using only one action call can now use Alert action; just set Duration parameter to 0 to discard the alert mode (save-play-restore model).
Thanks @lolodomo, Alert was exactly what I wanted!
Good haxxing!
[quote=“hek, post:851, topic:169644”]Thanks @lolodomo, Alert was exactly what I wanted!
Good haxxing![/quote]
Thanks from me, too!
I just updated to the new beta firmware 1.5.622 there seems to be an issue now :-s
When I play a MP3 via a scene ( see attachment) , it plays an mp3 of 11 seconds, but afterwards there is a silence now of about 27 seconds !!?!? just silence before it starts doing what it used to do :-s
There used to be always a very short silence, max maybe 5 seconds, but ca 27 soconds is a bit long.
Anyway to change this?
Thanks,
Cor
Please note that GroupDevices parameter has now been suppressed from PlayURI.
I understand that what takes time is the resume (restore).
Can you tell us what has to be resumed ? MP3 file ? Tunein radio ? Other media ?
Can you check if it is due to the fact that you are using group feature ? Is it faster if you address one unique sonos zone ?
@ lolodomo:
What happends is … music is playing ( internet radio) , someone presses the doorbell and a doorbell.mp3 (11 seconds) is played. Thereafter the music (internet radio) resumes. There is now a gap between the end of the 11th second mp3 file and the internet radio, of about 27 seconds, which wasn’t there before.
I just deleted the “group device” number and indeed , the recovery is almost instantly now, I also notice the start is much faster of the doorbell.mp3… When I inserted again the “group device” the delays where there again…
Anything to do about it , an option would be to not to synchronice the doorbell sounds, but let the run independently … or is there a better option?
Thanks,
Cor
It may be relative to the order of things we are doing. The way we are managing group is maybe not the efficient one.
Sorry, I have only one Sonos zone so I cannot investigate.
But why is it slower with the new firmware, I have no idea too.
I just released a new version in the trunk:
New little change committed:
It should make resume faster for Say and Alert actions.
Please note that there is a potential problem with queue containing more than 100 items. I consider only 100 items in the queue. I am not sure what is the behaviour if you have more than 100 items in your queue.
Hello Folks !
someone knows if the new SONOS BAR will comunicate with actual sonos devices series 3, 5 ?
can I use sonos bar like sonos 3, 5 ?
someone testing sonos BAr ? quality sound ? etc ?
thanks !!!
[quote=“Piwtorak, post:859, topic:169644”]someone knows if the new SONOS BAR will comunicate with actual sonos devices series 3, 5 ?
can I use sonos bar like sonos 3, 5 ?
someone testing sonos BAr ? quality sound ? etc ?[/quote]
My understanding is that it works just like any other Zone Player, with the added benefit it can be paired with e.g S3s for a surround sound set up.
Quality wise, I heard from a friend it’s very good, but benefits from the Sonos sub, but he says that about every Zone Player now he has the Sub…
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules