Reverse engineering the API

[scottgerring]

Hello! I've been hunting around for a way of bridging external audio players, decently, into Loxone. As far as I can see there is very little action in this space apart from mediaserver4home, which is quite complicated, difficult to get going, and seems to work with the older "music server" interface. Your repo here is the closest i've found to someone getting it going against the newer interface, and running it against my miniserver, it seems like it would work if I had the appropriate bang & olufsen equipment!

So, the questions:

• How did you reverse engineer this - do you have an API reference or something somewhere, and if so, could you share it?
• How do you feel about the state of this project? I can't get it going the whole way, as I lack the equipment, but if I were to take it and reimplement the backend against e.g. Sonos, would that be time well spent?

Thanks!

Scott

[rudyberends]

The basic idea came from this package; https://github.com/mjesun/loxberry-music-server-gateway

You might be interested in this. However it emulates an older version of the audioserver (different ui).

There is a fork specifically for lms integration that does emulate the latest audioserver; https://github.com/Gagi2k/loxberry-music-server-gateway/tree/lms-integration.

There are also a couple of demo Loxone setups available on the internet which I used to reverse engineer the protocol.

I wrote this for personal use and I am probably the only user of this code, but it does run extremely well. I don't think you would be able to tell that it is not an original audioserver that is running in the background. It's also very stable.

How well it works for you depends on the options you have to control and monitor your SONOS devices. These B&O devices have the possibility to subscribe to a notification stream. This way you get all the updates from the player. If you have to poll your devices to get updates it would probably be less successful.

[scottgerring]

Hey @rudyberends thanks for taking the time to write back and to publish this! It is supremely helpful. I've started hacking away and hope to have something to show for it soon.

I don't suppose you have any captures of the conversations on the two different HTTP servers handy still?

These B&O devices have the possibility to subscribe to a notification stream. This way you get all the updates from the player. If you have to poll your devices to get updates it would probably be less successful.

The Sonos local API has a mechanism for this; you send a HTTP SUBSCRIBE to the speaker you're interested in, with a Callback header with your own HTTP endpoint in it, and it calls you back with status updates. It certainly works but it is a fairly unique solution to the problem!

[rudyberends]

Hi,

Not sure if you are still interested, but I redid the audioserver and decoupled the B&O stuff from the server, as to make it more flexible. It relies on backends which can be set per player. As of now, only BeoLink backend is functional, but there is a (dummy) Sonos and Example backend. If you are interested, you might be able to get a Sonos backend up and running.

[scottgerring]

Hey @rudyberends - cool! Have you pushed it?

I rewrote a good chunk of this in rust for shits and giggles around sonos; the lox side works (e.g. presents properly to MS and can feed back info to it), the sonos side was surprisingly more of a pain. I got reasonably frustrated as their local APIs are all-but-undocumented and don't feel like something that are going to be around for long. I've ended up in a situation where i'm not really happy with sonos in general and hesitant to spend much time building things around their ecosystem.

BUT - I will end up with something, at some point, that I want to integrate with Lox. So i'd love to see your latest work - and thanks for pinging me :)

[rudyberends]

No problem. Here is the new code

https://github.com/rudyberends/loxone-custom-audioserver.git