Sounds like a worthwhile update, especially if it is as straight forward as you say. While no where near as nowlegable on such things as you, I’ve added my support.
It’s a shame MCV do not invite their ‘users’ to contribute more (visually) by voting on what bugs should be addressed in future releases. Although I guess, such a display of openness would open them up to criticism if they didnt deliver.
[quote=“parkerc, post:293, topic:169644”]@bobemorgan
I had the same thing a while back, and it turned out (i think) to be due to the fact I was downloading the files individually rather than as the available zip file with them all in. Once I used the zip file I could see the other services.[/quote]
Where is this zip file? following the link to trunk 18 brings up 4 separate files. I am having the same problem as boemorgan. I’ve tried several times and cannot get the control options.
edit…there’s a zip download at the bottom of this page.
http://code.mios.com/trac/mios_sonos-wireless-music-systems/browser/trunk?rev=18
I guess that’s it.
Also, another stupid question. I assume I am setting up the device IP for the ZP (player) address, not the ZB (bridge), correct? I still can’t get anything in the scene options.
Never mind, it is working!!!
Very nice. I have a scene called ‘sonos play’ and ‘sonos stop’. this starts and stops my currently-selected selection, a radio station in my case.
I assume there’s no way to select a sonos playlist yet? What about an amazon match/cloud file?
My tunes are stored on a synology NAS. Anyone know the correct url for a synology shared music folder?
For the most part, it’s about passing in the right type of URL to the functions that are already exposed.
The trick is knowing what to pass.
The Sonos forum has some clues… Thing like passing “SQ:…” And other pre-built fns to the calls result in the playlists being activated.
I haven’t play with this much yet though.
Not sure how the Amazon stuff works.
Hi, If you’re using Tunk 18, have a look at the post I did a couple of months ago - it’s the x-file-cifs:::*, protocol, used to point to the file/folder location on your server/folder. (This works for my ReadyNAS) http://forum.micasaverde.com/index.php/topic,8505.msg75764.html#msg75764
[quote=“guessed, post:304, topic:169644”]For the most part, it’s about passing in the right type of URL to the functions that are already exposed.
The trick is knowing what to pass.
The Sonos forum has some clues… Thing like passing “SQ:…” And other pre-built fns to the calls result in the playlists being activated.
I haven’t play with this much yet though.
Not sure how the Amazon stuff works.[/quote]
Thanks. The ability to play sonos playlists will be huge. I use my sonos 99% of the time to stream radio or play sonos playlists.
Hi Guessed.
I am in the starting blocks to test the plugin 8)
In tag 0.21, I see a sub-directory named services with lots of XML files. Do we already need to load all these files ?
The directory is for files that I haven’t yet implemented the action handlers for. When I implement them, I’ll promote them up a level.
First results with a Connect:Amp: it is working 8)
What is clearly missing is some basic controls on the Sonos device. We have none and everything has to be done through scenes.
I tested with successl in scenes: Mute (Sonos1 service), UnMute (Sonos1 service), SetVolume (Sonos1 service), Pause (AvTransport service), Next (AvTransport service), Previous (AvTransport service).
What could be difficult, even very difficult, for normal users, IMHO:
Identified problems:
Guessed, do you want some help ? I would like to add some basic controls in the control tab. Is it in your TODO list ?
I will start looking the code to see if I understand it ;D
When I am listening a WEB radio (tunein), the variable AvTransportURI has this value for example: x-sonosapi-stream:s2339?sid=254&flags=32
Is it the value I have to put in the field URIToPlay for the SetURIToPlay callback ?
Because it is not working.
If not, what is the procedure to get the URI of each tunein radio ?
[quote=“lolodomo, post:309, topic:169644”]Identified problems:
After opening the json file, I understood that “Currently playing…” is only a label ;D
So forget this remark.
We should add a field based on variable CurrentTransportState or TransportState (don’t know what is the difference) to show the current status.
Other problem solved after looking inside the XML files. The speed value must be set to 1.
I see now in the I_Sonos1.xml file that InstanceID is systematically forced to “0”, meaning the value entered in the scene is not important.
What’s the idea ? Is it to have a unique Vera Sonos device for all the Sonos network and then control each Sonos unit with the InstanceID ? Or is it to have a Sonos Vera device for each Sonos unit ?
[quote=“lolodomo, post:313, topic:169644”]I see now in the I_Sonos1.xml file that InstanceID is systematically forced to “0”, meaning the value entered in the scene is not important.
What’s the idea ? Is it to have a unique Vera Sonos device for all the Sonos network and then control each Sonos unit with the InstanceID ? Or is it to have a Sonos Vera device for each Sonos unit ?[/quote]
The newer S_ files that have been added have all been extracted from the Sonos device itself. They’re all Sonos’s “adaptations” of their standard UPnP counterpart files.
As a result, they have the InstanceID variables, and other similarly “unused” parameters in the case of the Sonos devices.
[Over time] I intend to “default” the values of these parameters to some sort of internal/reasonable default value for the Sonos. In the case of the Sonos, it only understands “0” as a value, so the internal default will be “0”… but I will eventually let people override that should they wish to use the code to apply to other UPnP devices… @Ap15e made a side-request for me to do something along these lines at one point.
Similarly, for some of the other values that can be passed, I need to setup reasonable defaults. The goal would be that, most parameters would have some sort of default value, so that the overall ACTION had a default behavior when no parameter values were spec’d… even if that means that any “URL” like parameters left out would internally default to the TTS to “say” something to the user about what’s missing.
[quote=“lolodomo, post:310, topic:169644”]When I am listening a WEB radio (tunein), the variable AvTransportURI has this value for example: x-sonosapi-stream:s2339?sid=254&flags=32
Is it the value I have to put in the field URIToPlay for the SetURIToPlay callback ?
Because it is not working.
If not, what is the procedure to get the URI of each tunein radio ?[/quote]
When I’ve done this with non-TuneIn URLs in the past, the display has matched. Not sure how the TuneIn integration works, so you may need to experiment with it to work out the right thing to pass.
Over time, you should cutover to using the UPnP call directly. The UPnP-standardized version of the [tt]SetURIToPlay[/tt] call is:
<serviceId>urn:upnp-org:serviceId:AVTransport</serviceId>
<name>SetAVTransportURI</name>
[quote=“lolodomo, post:311, topic:169644”][quote=“lolodomo, post:309, topic:169644”]Identified problems:
After opening the json file, I understood that “Currently playing…” is only a label ;D
So forget this remark.
We should add a field based on variable CurrentTransportState or TransportState (don’t know what is the difference) to show the current status.[/quote]
There is, but it’s likely that the value isn’t being populated for the specific use-case that you’re running. I have a simple bit of code that’s parsing the DIDL-Lite (XML) that outlines what’s currently playing. This should work for regular radio stations and MP3’s, but it hasn’t had a lot of testing, so it probably needs to be augmented for extra use-cases.
This will give you “what’s playing”.
Since we have an extremely limited UI to put all the data, my longer-term intent was to use the Templating stuff to let the user pick what to display out of the overall “set” of variables that could be displayed.
Congrats! I was thinking about a Connect Amp at some point, for another room, so let me know how well it works for you.
What is clearly missing is some basic controls on the Sonos device. We have none and everything has to be done through scenes.Yeap. Making the UI pieces, and ensuring they work under both UI4 and UI5 is quite an art. My focus for the moment is on getting the API's in, and cleaning up the code.
If folks want to revamp the UI, then I’m sure @anker would be up for providing access to do that.
I tested with successl in scenes: Mute (Sonos1 service), UnMute (Sonos1 service), SetVolume (Sonos1 service), Pause (AvTransport service), Next (AvTransport service), Previous (AvTransport service).Most of the Sonos1 services now have standard UPnP counterparts. It may be worth using them in some of the cases. Longer term, with @anker's approval, I'd like to put some of the Sonos1 services on an obsolescence track - mostly where they have a direct overlap with a standards-based API call.
This would likely start by simply making them in the UI, so that people know not to use them.
What could be difficult, even very difficult, for normal users, IMHO: - how to get the IP address of the Sonos device, I don't think it is written somewhere in the Sonos control software. You need a network sniffer to identify it...Agreed. Not sure how to do that just yet, at least not without implementing my own device discovery... which seems a little wasteful.
- There are a lot of actions available (are they all already implemented ?), some have the same name but are available in different services. How to know which one to choose ? - The wiki page should be updated to list all the available callbacks, whether they are implemented or not, and what they do.The MiOS UI's drive off the information described in the service files, without consideration for what's actually implemented (action-by-action) within the Implementation file. This is unfortunate, as many of the routines cannot be implemented.
eg. The “Get*” methods cannot be implemented as MiOS has provided no way for UPnP Actions to return values (as would be required by a UPnP-compliant device) from it’s Lua stuff.
In general, the Get calls have been internally implemented in Polling calls, so that the data is available for people to use. Some of the UPnP calls for “setting” things (like saving the Playback list) also return values. Currently these are thrown away as again, there’s no way in MiOS to return the values. This part will have to be thought out more when we get to using those particular calls.
The “what they do” part is for folks to determine. There’s very little doc on any of them, so they’re going to need some experimentation. My goal was to get them all exposed, in some form, so that people could start to experiment with them.
The Sonos forum does mention quite a few of them, through use, but that information is spread widely across that forum.
Once people discover their true usage, it can be converted into appropriate sections on the code.mios.com wiki pages for the Sonos Plugin.
Identified problems: 2) After a lua engine reload in Firefox, the device does not initialize correctly: generic icon, nothing displayed in the dashboard and only the label "Device settings" in the Control tab. A Control+F5 is required in Firefox to restore icon and information.Yeah, that "icon" is loaded from a remote site. There's a 50% chance it won't actually load. Don't know what that's about.
Guessed, do you want some help ? I would like to add some basic controls in the control tab. Is it in your TODO list ? I will start looking the code to see if I understand it ;DIf you're up for it, the UI needs the most work, and it's definitely not my focus. I would ask that anything we do in this space is done for both UI4 and UI5 users, as we still have both (I use UI4, for example, and only code-test against UI5)
This will be limiting in some ways, but we do have some control. For example, we could use the Toggle-action on the icon to do something meaningful (like toggle Play/Pause, or Mute/NoMute, or External Input) without consuming any additional space.
Anyhow, this is probably the area with the most immediate need… unless you wanted to play with UPnP disco, which would definitely make things easier for folks to install.
Why not keeping and adding simplified callbacks in Sonos1 service that would internally use the new UPnP service ?
For the user point of view that’s not a good idea for a Pause action to ask him entering an InstanceID. Everybody, starting by me, will ask what is InstanceID and what value shall I enter ?
This would likely start by simply making them in the UI, so that people know not to use them.
What do you mean exactly ?
What could be difficult, even very difficult, for normal users, IMHO: - how to get the IP address of the Sonos device, I don't think it is written somewhere in the Sonos control software. You need a network sniffer to identify it...Agreed. Not sure how to do that just yet, at least not without implementing my own device discovery... which seems a little wasteful.
Normally everyone owns a software for their router that can display the IP of each network equipment.
If you're up for it, the UI needs the most work, and it's definitely not my focus. I would ask that anything we do in this space is done for both UI4 and UI5 users, as we still have both (I use UI4, for example, and only code-test against UI5)This will be limiting in some ways, but we do have some control. For example, we could use the Toggle-action on the icon to do something meaningful (like toggle Play/Pause, or Mute/NoMute, or External Input) without consuming any additional space.
Anyhow, this is probably the area with the most immediate need… unless you wanted to play with UPnP disco, which would definitely make things easier for folks to install.
Ok, I will take this part.
Why not keeping and adding simplified callbacks in Sonos1 service that would internally use the new UPnP service ?
For the user point of view that’s not a good idea for a Pause action to ask him entering an InstanceID. Everybody, starting by me, will ask what is InstanceID and what value shall I enter ?[/quote]
In fact, I realize we have already what users need in service MediaNavigation1.
I wasn’t planning on removing Sonos1, that would stay for truly unique functionality (eg TTS). It’s just where there is major overlap between either of the standards (either native UPnP or the MiOS-specific AV functions) then we’d lean towards obsoleting the Sonos1 version.
At least, that was my thought.
There are other problems with the various state variables allocated against the Sonos1. They’re not done against the [tt]:serviceId:[/tt], they’re done against the [tt]:device:[/tt]. You’ll see that I now bubble them up as their native [tt]:serviceId:[/tt] counterparts from the UPnP set of variables.
The ACTIONS themselves don’t have this problem, just the state that was captured as variables.
In the UI Dropdown for ACTION Selection for Scenes, for any obsolete service I was thinking that we could put some extra text next to the label for anything being retired…
eg. “Mute On (obsolete)”
as this would help the user differentiate the ones that are going away (etc). Again, nothing set in concrete at this time, but I have a bias towards using the built-in ones, vs custom ones, for as much functionality as possible.
The reasoning here is simple. If we use standard Services, then any Control Point that wants to implement AV functionality just implements against the standard. If we don’t do that, then each control point would need to implement for each AV device (Sonos, Squeezebox, etc, etc)
BTW: I haven’t done any of this, as I wanted to discuss it with @anker and get approval before I did.
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules