I am currently developing a SMAPI service. I registered a customsd with my PLAY:1 speaker and I can see the PLAY:1 communicating with my service. I can see a 'getLastUpdate' request and my response, but on the Sonos Control (PC) I just see "Unable to browse music - there was a problem connecting to ." Is there any way to view more detailed diagnostics?
A big of digging revealed the following useful endpoints:
http://<PLAY:1 IP>:1400/support/review
http://<PLAY:1 IP>:1400/status
It seems that the log of interaction with my customsd service can be found here:
http://<PLAY:1 IP>:1400/status/controllers -> ControllerConsoleLogInfo
Related
I have been struggling with connecting to Tuya cloud API. Testing in postman gives me this result:
enter image description here
The things I have done:
I conntected the device to Tuya developer account.
I configured my developer account and have acccess to tuya IOT service.
I set up testing enviroment as shown in this link: https://developer.tuya.com/en/docs/iot/set-up-postman-environment?id=Ka7o385w1svns
I made sure that i have turned off the cloud IP Allow list.
Yet still that error occurs although when I send a request through API Explorer on the tuya site everything works correctly. Can someone know the origin of this error?
I’m currently developing a music service and testing it via customsd. The integration in the controller app is working (iOS App & Windows Desktop App) - so I can browse - but I can’t get a Player to play any track. I keep receiving ‘unable to connect’ errors once I hit the ‘Play’ button in the controller. I can see on the service side that the Player sends a getMetadata and a getMediaURI request, and the SOAP responses delivered by the service are identical to working examples from another source; however, the Player seems unable to process them. I am kind of stuck, and I guess what would help me are the Player logs. Is there any way to get them?
Or, does anyone have any other idea about the root cause of the issue?
EDIT: More or less accidentally, I came across the reason of my problem. Whereas in general, Sonos can handle arbitrary IDs, getMediaURI only seems to work when it requests the URI for an ID of the form track:something. I don‘t remember seeing this as a requirement on the developer pages.
Anyway, got it working now.
If you're getting a getMediaURI request and responding to it with a valid response, then most likely the player is failing to process the media file itself. Are you seeing the media file being downloaded? You could host the media file locally and include the URI to that in the getMediaURI response to check.
Note that the <mimeType> included in the metadata is used to inform the player of the type of media the URI in the getMediaURL response points to.
So if you were to return <mimeType>audio/ogg</mimeType> for track123, but getMediaURI's response contained the URI https://something.xyz/track123.mp3, playback would likely fail due to the mismatch.
Have you seen bonob? Someone made a music service emulator for navidrome (self-hosted music library, a la spotify). It should be a great resource to get you started.
He wrote that your music service has to be available at https for it to even start functioning.
Note, I'm the developer of sonos-ts a library to control sonos speakers from typescript and node. And the external music services are documented here
I am trying to get a list of music services to which the Sonos household has a subscription. Is it possible to obtain such information from HTTP API or from any other source? If yes, then under what conditions?
I have analyzed the traffic between the Sonos Connect and Windows Sonos Controller. I discover, that information about music services is transmitted from Connect to Controller inside the ThirdPartyMediaServersX tag of the NOTIFY HTTP request. But this content is encoded in the base64-like cipher.
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<ThirdPartyMediaServersX>
2:oZoYgaU5pqEq6IauQ1hYVS0oCUJnqbCkJL1vXP/DoeijejEwUBQT8UG0CksUG9VcarvLhCyElhKTUjfhQt0SAcV2oBOyLJ5BCmjd7TcJfPrVuTGHczd5/AS2tgj85n0U9yU9EwwHROFb5uV09syZNLVaZuJnENCWRKatIq1SNMm1SE4tHneLG6ULQoDOR50nf7TwyRQbkit8Bvy+kZyNPlrgBZFGmizoRmYjW8COFvHJpZhREEGruhQ2J6A8gnQOWyFzstAyHNZeLqp2xcNGnts6f2DQ56r/ducstbibFH0SZOZC0XM/BB4DvOT8UalezPL0R9/s8Jibm5T6mS1FWk14GWg2RMmRBIVE5G/gG2c=
</ThirdPartyMediaServersX>
</e:property>
</e:propertyset>
I expect to obtain list of music services, but the actual list were hidden.
As you figured out, Sonos disabled this functionality some time ago.
I've spend a lot of time figuring out how it works, and I now have a "work-a-round". External music services describes what to do.
And sonos-ts has support for external music services. If you read my first link and check the code in this library you should probably be able to figure out how to do that in your programming language.
I know this is no access to the list that is kept by Sonos, but this work-a-round also saves the tokens on the device for every client application to use.
Recently I've found someone who build an music service emulator. So that are both sides of external music services.
This is not supported by the Sonos API.
I am using MobileFirst CLI 8.0.0-2016070716, Java 1.8.0_91 (on Mac OS X 10.11.6 if it matters). I have been working through this tutorial on creating Java adapters using MobileFirst CLI.
After following the steps on creating, building, and deploying the adapter, I open the operations console and select the adapter I just deployed --> Resources --> "View Swagger Docs". When I press "Try it out" on any of the operations, I receive a "401 - Unauthorized" response code.
Any idea what problem might be?
"To add a Test Token to the request, so that the security framework skips any security challenges protecting your resource, click the on/off switch button on the right corner of an endpoint's operation.
You will be asked to select which scopes you want to grant to the Swagger UI (for testing purposes, you can select all). If you are using the Swagger UI for the first time, you might be required to log in with a Confidential Client ID and Secret. For this, you will need to create a new confidential client with * as its Allowed Scope."
Documentation regarding this is located here in our getting started tutorials.
https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/8.0/adapters/testing-and-debugging-adapters/#using-swagger
Up to this point, I had a functioning Azure Mobile Service with service-directed OAuth working nicely for Google. I tried to rehost the mobile service as an app service since mobile services are deprecated. I also have an HTML/JS web app that accesses my service through the MobileServiceClient JS client. This is where the fun starts.
After changing the redirect address to the appropriate app service address in the Google API manager, I get a message saying I'm successfully logged in in a new popup window: .
Clicking on "Return to Website" takes me to the address of my app service, not the app that initiated the OAuth request, and if I close this window, the MobileServiceClient throws a "cancelled" exception and I don't get my credentials.
What am I missing or what changed that I need to account for?
Thanks!
It turns out that this particular behavior happens when using an older version of the MobileServiceClient JS library. Replacing the 1.2.7 version with the 2.0.0beta version fixed this. To get the whole OAuth flow working, I also needed to add the appropriate addresses to the allowedExternalRedirectUrls node of the config/authsettings node through the Azure Resource Explorer. If there is a nicer way to do it than through the resource explorer, I don't know what it is.