On the Sonos remote control, if you press the cog/gear icon (typically lower right corner) and then select the last menu option, it will give you the IP address of the Sonos.
As long as people have “locked” the Sonos to an IP, they’ll be set to use that. If they’re purely DHCP, with no locking then of course we’ll need to do discovery… or get MiOS to fix their stuff in this space (likelihood ~ 0)
[quote=“guessed, post:315, topic:169644”][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]
With this Web radio and this URL: http://mp3.live.tv-radio.com:80/scooplyon/all/scooplyon-128k.mp3
I was able to make it work with URI x-rincon-mp3radio://mp3.live.tv-radio.com:80/scooplyon/all/scooplyon-128k.mp3
When you say, I have to experiment to find the URL for tunein radios, what do you mean exactly ? How do to it ?
Do I need in using Device Spy or Device Sniffer ?
In Device Spy, it looks like I can’t get values of state variables. For all state variables, I get a in front of last known value. Is it normal ? For example, I would like to check the value of AvTransportURI state variable.
On the Sonos remote control, if you press the cog/gear icon (typically lower right corner) and then select the last menu option, it will give you the IP address of the Sonos.[/quote]
You’re right, I finally found it using menu Help => About my Sonos System… 8)
I even imagine that all Sonos devices are listed when you have more than one.
That is probably something to add in the wiki page.
[quote=“lolodomo, post:322, topic:169644”]With this Web radio and this URL: http://mp3.live.tv-radio.com:80/scooplyon/all/scooplyon-128k.mp3
I was able to make it work with URI x-rincon-mp3radio://mp3.live.tv-radio.com:80/scooplyon/all/scooplyon-128k.mp3
When you say, I have to experiment to find the URL for tunein radios, what do you mean exactly ? How do to it ?
Do I need in using Device Spy or Device Sniffer ?
In Device Spy, it looks like I can’t get values of state variables. For all state variables, I get a in front of last known value. Is it normal ? For example, I would like to check the value of AvTransportURI state variable.[/quote]
I have a Mac, so there are probably better techniques using Windows, DeviceSpy (etc).
On my Mac, I’ve use Wireshark to capture the packets and see what’s going on. Whilst running Wireshark, I use the Mac/Desktop version of the Sonos control program to activate various things. Since the Mac/Desktop app uses UPnP calls, you see all the requests and responses, along with the async notification stuff (handled in the other thread).
From time to time, I use the command-line Lua engine with the raw version of the Library ([tt]L_Sonos1.lua[/tt]). I can then test certain functions prior to implementing them in Vera. Right now, this mechanism doesn’t have a good way to return results from those calls… this is probably my next TODO item, since some of the UPnP calls are going to require Lua scripting to work correctly (due to return results). This is best done by calling the library directly, instead of attempting to use luup methods to invoke them.
Examples include saving/restoring playlists… since these calls have return results (playlist id’s)
For tunein radio, finally I found the solution 8)
For example, after selecting a radio, you will find in variable AvTransportURI: x-sonosapi-stream:s9948?sid=254&flags=32
but as weel in variable TrackURI: x-rincon-mp3radio://mp3.live.tv-radio.com/franceinfo/all/franceinfo.mp3
This variable is set by the plugin through a call to GetPositionInfo.
So you have to use the value from TrackURI.
Nevertheless I noticed a difference in the Sonos control application. When I select the radio from the Vera, no logo is loaded for the radio.
Loading a m3u playlist file is working too 8)
For example with such a URI: x-file-cifs://FREEBOX/Disque%20dur/Musiques/Auf%20der%20Maur/Auf%20der%20Maur/Auf%20der%20Maur.m3u
I would like first to solve the problem with the device not correctly initialized in the dashboard after a lua reload. The problem is similar in IE9 and Firefox. It looks like the json file is not correctly loaded because when I open the Control tab, I only see a label “Device settings”, a label not defined in the json file !
To get again a correct display of the device, you systematically need to reload the web page.
It could be a bug due to the firmware, but I don’t see such a problem with other plugins, so there is certainly a way to avoid that problem.
[quote=“lolodomo, post:327, topic:169644”]I would like first to solve the problem with the device not correctly initialized in the dashboard after a lua reload. The problem is similar in IE9 and Firefox. It looks like the json file is not correctly loaded because when I open the Control tab, I only see a label “Device settings”, a label not defined in the json file !
To get again a correct display of the device, you systematically need to reload the web page.
It could be a bug due to the firmware, but I don’t see such a problem with other plugins, so there is certainly a way to avoid that problem.[/quote]
I found and fixed the bug.
In the JSON file, you must replace the line at the end
"DeviceType": "generic_device"by
"DeviceType": "urn:schemas-micasaverde-com:device:avmisc:1"Doing that, the device is now ok after each reload.
Note that redefining the device type in the JSON file is something I never understood why it is required…
Regarding the type of the device, why this choice of “urn:schemas-micasaverde-com:device:avmisc:1” ? We should not define a specific type for Sonos ?
Regarding UI, we may start from the UI already implemented by for other AV control devices.
Which one has a good look & feel, with play/pause and mute/unmute buttons, …
Guessed, maybe a little bug in that line ?
or setIfChanged(UPNP_AVTRANSPORT.sid, "CurrentTrackMetaData.DIDL-Lite", didl or "", PARENT_DEVICE)didl variable is not defined.
I was not understanding why it takes so much time to refresh data on the dashboard while a refresh of data is done every 15 seconds.
Finally, I understood that the way it is coded can not work.
changed = changed or ...As soon as a condition is true, I believe the other conditions are not run.
We have to do it in another way to be sure that all calls to setIfChanged will be run each time (every 15 seconds).
Please find attached the fix for the variable updates and the fix for the JSON file.
As a consequence, the dashboard is now refreshed every 15 seconds as expected.
These fixes are based on files from tag 0.21.
I made this change, using the newer Unix-format version of the file, but a word of warning… This puts us squarely into Bug 1501 territory.
Anyone attempting to use the Sonos plugin that already has any of the other AV Plugins using avmisc1 (Onkyo, Denon, etc) will find that the UI changes to one that breaks them.
You may want to chime in with commentary on that bug directly.
This is a device type, which a lot of the Control points key off of for one reason or another. When you define custom device-types it means that they often don’t see you (as an AV-Device, for example) since they’re keying off this (instead of say, the services used).
What tends to happen is that you define a new type, and then a lot of other things break. Either way, Bug 1501 should never happen since it ties all devices of a given Device Type to a single Device’s UI (as defined by the device-specific JSON file). Then, at runtime, it “picks one” (seemingly randomly) of those UI’s and uses it.
FLORIN: Can we get Bug 1501 fixed once and for all? We see repeated cases where the implemented-behavior is not the desired-behavior.
[quote=“lolodomo, post:328, topic:169644”][quote=“lolodomo, post:327, topic:169644”]I would like first to solve the problem with the device not correctly initialized in the dashboard after a lua reload. The problem is similar in IE9 and Firefox. It looks like the json file is not correctly loaded because when I open the Control tab, I only see a label “Device settings”, a label not defined in the json file !
To get again a correct display of the device, you systematically need to reload the web page.
It could be a bug due to the firmware, but I don’t see such a problem with other plugins, so there is certainly a way to avoid that problem.[/quote]
I found and fixed the bug.
In the JSON file, you must replace the line at the end
"DeviceType": "generic_device"by
"DeviceType": "urn:schemas-micasaverde-com:device:avmisc:1"Doing that, the device is now ok after each reload.
Note that redefining the device type in the JSON file is something I never understood why it is required…
Regarding the type of the device, why this choice of “urn:schemas-micasaverde-com:device:avmisc:1” ? We should not define a specific type for Sonos ?[/quote]
[quote=“lolodomo, post:332, topic:169644”]Please find attached the fix for the variable updates and the fix for the JSON file.
As a consequence, the dashboard is now refreshed every 15 seconds as expected.
These fixes are based on files from tag 0.21.[/quote]
@lolodomo,
I made fixes to the problem with the short-circuit eval, but in a slightly different manner. Both should net the same effect.
If you want to make changed, it’ll be easier if you use the trunk versions of the files, since they’ve moved on somewhat since the tag that I made for general consumption.
The latest version of the files are also now in Linux format, instead of DOS format, so they’re easier to diff.
Thanks for finding these issues!
[quote=“guessed, post:333, topic:169644”]I made this change, using the newer Unix-format version of the file, but a word of warning… This puts us squarely into Bug 1501 territory.
Anyone attempting to use the Sonos plugin that already has any of the other AV Plugins using avmisc1 (Onkyo, Denon, etc) will find that the UI changes to one that breaks them.
You may want to chime in with commentary on that bug directly.
This is a device type, which a lot of the Control points key off of for one reason or another. When you define custom device-types it means that they often don’t see you (as an AV-Device, for example) since they’re keying off this (instead of say, the services used).
What tends to happen is that you define a new type, and then a lot of other things break. Either way, Bug 1501 should never happen since it ties all devices of a given Device Type to a single Device’s UI (as defined by the device-specific JSON file). Then, at runtime, it “picks one” (seemingly randomly) of those UI’s and uses it.
FLORIN: Can we get Bug 1501 fixed once and for all? We see repeated cases where the implemented-behavior is not the desired-behavior.[/quote]
That’s a problem I already encountered when I had to add an alarm partition device in the RFXtrx plugin. I finally decided to use a new specific device type. That’s probably what we should do if MCV does not fix the bug.
I just checked how is handled this type by AutHomation and Home Buddy. These 2 applications don’t yet managed this type, so using another type will change nothing.
[quote=“guessed, post:334, topic:169644”][quote=“lolodomo, post:332, topic:169644”]Please find attached the fix for the variable updates and the fix for the JSON file.
As a consequence, the dashboard is now refreshed every 15 seconds as expected.
These fixes are based on files from tag 0.21.[/quote]
@lolodomo,
I made fixes to the problem with the short-circuit eval, but in a slightly different manner. Both should net the same effect.
If you want to make changed, it’ll be easier if you use the trunk versions of the files, since they’ve moved on somewhat since the tag that I made for general consumption.
The latest version of the files are also now in Linux format, instead of DOS format, so they’re easier to diff.
Thanks for finding these issues![/quote]
Is the trunk version working ?
This is now fixed in trunk. It fell out after I did some code restructuring a while back. Note that the DIDL-Lite code here is a simplification of the DIDL-Lite itself, so it’s kinda experimental. Not sure if we’ll keep it that way in the longer term, but it gives us a pseudo-readable version for the moment.
[quote=“lolodomo, post:330, topic:169644”]Guessed, maybe a little bug in that line ?
or setIfChanged(UPNP_AVTRANSPORT.sid, "CurrentTrackMetaData.DIDL-Lite", didl or "", PARENT_DEVICE)didl variable is not defined.[/quote]
@lolodomo,
For you, yes. It’s not for general purpose use, unless people like getting “cut” periodically by my coding mishaps 
I’ll try to keep it functional, but there are times I use trunk without fully testing the changes. There’s a lot of stuff in here now, so it takes me a while to do the full pre-flight checks prior to making a tag for general use.
There will be a bunch of problems in the overall code that need to be addressed. For example, when a Sonos is down, I’m not updating the status appropriately at the moment, but those changes will come in time.
Thanks for spending the time to go over this stuff, it really helps having extra eyes looking at the innards.
Ok, in upload trunk version and it works well. 8)
x = a, bWhat’s the result of such a line code ?
Is it different from
x = a or bIn the Say action, I think you forgot to define the Volume parameter.
Then, in the code of the action, you are using lul_settings.Volume which is I think always nil.
Best Home Automation shopping experience. Shop at Ezlo!
© 2026 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules