Music Server Interface

[Prof.Mobilux]

hismastersvoice Sounds good. Setting the number manually is the best way from my point of view. Everything else will be confusing. So in the "Music Server Interface Plugin"-Config you just have to set the IP of the Gateway?

[hismastersvoice]

The IP an hopefully in the next version also the port.

I just created this commit https://github.com/mjesun/loxberry-m...e5b2fa5b1adbf8, which sets the outport to 6091, and the inport to 7091. So:

* Miniserver-> Music Server uses 6091 TCP
* Miniserver -> plugin uses 6091 UDP, and
* plugin -> Miniserver uses 7091 UDP

In addition, you can also configure a custom IPort pair on the extra field. Would that cover all use cases?

[madito]

Hello,

I have created some small diagrams to explain the current situation (configuration) and a proposal for improvement that I think can be interesting for everyone and will allow a flexible configuration.

I also include a capture with the final "objective" which I think would be quite interesting to consider.

[Gast]

What madito showed is correct. Both no.1 (current version) and no. 2 (proposal) can already be achieved (except for the port setup, which I'm working on right now). It is now optional to decide to send (or not) the commands to the Miniserver, so someone using MS4L can deactivate this option, but someone using its own setup (e.g. Sonos, Roon or existing setups, like @TomekWaw) can still cable it and reuse all their former work.

[madito]

What madito showed is correct. Both no.1 (current version) and no. 2 (proposal) can already be achieved (except for the port setup, which I'm working on right now). It is now optional to decide to send (or not) the commands to the Miniserver, so someone using MS4L can deactivate this option, but someone using its own setup (e.g. Sonos, Roon or existing setups, like @TomekWaw) can still cable it and reuse all their former work.

Hi!

In the proposal, I suggest that the actions of the plugin, instead of being messages sent by UDP, be customizable actions. Furthermore, these actions could be grouped by templates, for example;

Template MiniServer (sending UDP commands);

play_zone1: "/dev/udp/MINISERVER_IP/PORT 1:lay"
play_zone2: "/dev/udp/MINISERVER_IP/PORT 2:lay"
...

Template CasaTunes (HTTP REST):

play_zone1: "http://CASASERVER:8735/api/v1/zones/1/player/play"
play_zone2: "http://CASASERVER:8735/api/v1/zones/2/player/play"


And even in a generic way

commands_zone: "http://CASASERVER:8735/api/v1/zones/{ID_ZONA}/player/{COMMANDS}"

[Gast]

I'm taking a look right now to how favorites, room favorites, playlists, and library are internally managed, and it's becoming more and more evident to me that the UDP inputs / outputs fall short. While I think it's great to provide the ability for the basic player to be used, I think the plugin will cover at most the generic inputs for the room favorites (up to 8). But for a deeper integration, I think a closer collaboration with a real player is needed.

Something like madito idea about generic HTTP/UDP input/output is great, and would alleviate part of the problem. However, that implies that the format returned by e.g. CasaTunes player related to favorites needs to match with the plugin format, which may not be an issue but if needed will add yet another layer in the stack.

I'm also unsure who should be managing favorites (and, in general, state) at all: if it is the plugin, or the underlying music server. I assume that for instance CasaTunes player can do all of the tasks by itself, but I'm unsure about Logitech Media Server, and definitely if you're re-using an existing setup (like the ones mentioned above, using the virtual UDP inputs), then it has to be the plugin the one managing them. This problem becomes even worse if we expect the underlying player to always keep the right sync state with the Loxone UI, a piece of work that the Loxone folks don't even have to worry about as they don't let you communicate with their internal LMS instance.

In short, it looks like it's a bit hard to expose all existing functionality from the Loxone UI while at the same time provide a generic interface. These folks have done a really good jobs with all the options they added to their UI

I'm more than welcome to get some suggestions and see if that clears my mind

Some pictures about additional APIs I'm working on (that I can expose once we conceptually agree on how to do so):

[hismastersvoice]

Without a full integration I have also to think about to sync the commands when used 3rd party app that the Player in Lox-App has the same status when changes in the 3rd party app happens.

I still looking forward...
Maybe a gateway can also save settings from the app and give it back if needed.

[hismastersvoice]

Gast

I just created this commit https://github.com/mjesun/loxberry-m...e5b2fa5b1adbf8, which sets the outport to 6091, and the inport to 7091. So:

* Miniserver-> Music Server uses 6091 TCP
* Miniserver -> plugin uses 6091 UDP, and
* plugin -> Miniserver uses 7091 UDP

In addition, you can also configure a custom IPort pair on the extra field. Would that cover all use cases?

Don´t work with IP:UDP-PORT
If I put an fixed Port into it I get the msg, if I configure it in the UI it don´t work.





*plugin -> Miniserver uses 7091 UDP*
MiniServer get still at 6091 msg back
Also the VI Template creates still 6091

Oh that's not released yet, I just put it in a separate branch. Will try quickly building a ZIP.

[hismastersvoice]

Oh, no problem at all. That was a misunderstanding from my side.

[madito]

Indeed I believe that a good baseline must be created to create a product that meets the greatest needs, it is true that some cannot be covered (at least directly).

What I had in mind in my proposal is to create a daemon for Casatunes that is the one in charge of feeding the information data to the plugin, this daemon will execute the necessary queries.

The proposal that the plugin allow to send the actions through HTTP, will allow to obtain a direct control over the music server (be it casatunes, MS4L and many more).

The work on obtaining information from those devices and sending it to the plugin to update the loxone interface is more complex and I think we must do it in parts (for example hismastersvoice can do it for MS4L and I for Casatunes).

Currently my script passes all the supported data to the plugin and are obtained from casatunes.

Attachd the Casatunes API on web version (is a one documment HTML).

[hme0354]

Is there anything new on the project?

[Prof.Mobilux]

Since no one has posted something new here nor in the wiki - obviously not...

[hismastersvoice]

Be patient, I think it a hard work and the weather is like in summer

[Gast]

Hi all!

I've been thinking over the last week about how to organize the current project, and I came to the conclusion that it's better to split it in two parts: the music server interface (MSI), which is the current plugin, and the music server gateway (MSG), which would enable others to implement over a common, well documented API, their own services (e.g. hismastersvoice with MS4L).

Regarding MSI, I think the current features will remain as they are today, with minimal changes to the track selection (rather than having a queue index, to be more transparent with how the interface works); and a new feature to be able to configure favorites per room (up to 8, what is supported by their interface). But further developments, like integrating a library, music services, global favorites, etc; -which are supported by Loxone-, are left out of this project. The reason is that it's way too hard to support those without having a deeper integration with a real music player, and the plugin (MSI) aimed to be since the beginning a drop-in replacement for existing setups, nothing more complicated.

Now, regarding MSG, the idea is to create a generic plugin that performs as a gateway of the Loxone interface, to enable full support of all the features present in it. Based on what people have said so far in the forum, I can see multiple other plugins coming to life and interacting with the gateway, like deep integrations with MS4L, Sonos, Spotify, etc. For instance, someone could decide to show, in the Library section (which is used by Loxone Music Server for your local files), your own list of favorites from Spotify. This is a different usage of the default expected experience, but it provides a richer interface for someone looking for a deep integration with Spotify - and the gateway would make this possible.

Architecturally, the idea is that the gateway is an HTTP client (not an HTTP server!), and will connect to a server to fetch the required information. You'd be able to point it via configuration wherever you want. For the (rare) cases where information needs to be pushed to the player (actually, only time and track updates), an SSE connection would be used. Those are easy to implement over existing HTTP libraries / servers, and well supported by proxies, etc.

Now, if Loxone already has its API, why not just expose this API as-is and avoid MSG? Here are a few reasons I thought, that make me think this is the best approach:

• Obscure handshaking: there is a handshaking process that involves calls to a bunch of "methods" and "hello" messages that need to be responded in particular ways. It's not super hard to make, but it is already an additional layer for something that should be able to get easily connected.
• Lack of documentation: the API is (obviously) undocumented, and there are no references to it anywhere. While i'd be technically possible to document it, it looks more robust to have a well documented, OSS gateway, and base all different child plugins into this API. If Loxone changes something, no adapting is needed to any plugin besides the MSG.
• Stateless API: despite all calls made by the interface are stateful -in the shape of request-response (give me your favorites, add a favorite, list me the library, etc)-, their protocol is stateless and works over WebSockets. It's conceptually much easier to use an existing technology that has a request-response model baked in, like HTTP, and you achieve the same parallelization by using multiple HTTP connections. Also, as stated before, the rare use cases where pushing information is needed can still be handled via SSE.
• Consistent API: having a predictable API (the ability of knowing how a new part of the API works based on previous knowledge) simplifies working with it. Their API is not very consistent in how requests are managed when e.g. a new request of the same type happens while there is a previous one in-flight. Some parts of the API use a counter, some others do not and use all results every time a new one comes, etc. This is another implementation detail that shouldn't really be needed and that MSG would hide from the consumer.

So I wanted to know your thoughts about the potential split and future plans!

[madito]

Good news!

It is something similar way of my proposal, only that you separate into two plugins, it is not very clear to me how the communication between plugins.

I think it is interesting to try to include the majority of options that the original Loxone interface allows, such as favorites, sources, etc. since this is quite common in any music system that we place behind, the response of each one can be different, but it would be necessary to establish a unique way of working. An example; If you have a list of sources in Loxone, you also have it in LMS or in Casatunes, since the concept is general, for music servers.

[TomekWaw]

Yeah, it's not very clear to me also what would be exact roles of MSI and MSG.
MSI is to talk to Miniserver and MSG is to talk to Music Servers and then MSI and MSG will talk to each other?

Update: nevermind, I've already figured it out out of your comment below next message:
"MSI is a Loxone Music Server protocol <-> UDP input/output bridge, while MSG is a Loxone Music Server protocol <-> Standardized HTTP API (to be created and documented)" -- this is pretty clear now, thanks

[hismastersvoice]

Here is the most important thing for me with a MSG-Plugin.
The MS4L is a standalone solution, and work without any Loxberry beside, and that is what I still what to keep.
If the MSG i build in way that it works for me I´ll integrate it for sure.
So as long I can use the MSI in the actual way, it works for me to integrate it in MS4L-Gateway.

The biggest thing for me at the moment is that there is no sync if I change something in a 3rd Party-App. So if I stop the Player there in the MSI it still shows play, volume etc.
So therefor you should also do push msg back to the MSI.

[hme0354]

That would be great. I would Like to be one of your first Tester!

[TomekWaw]

Yeah, embeding MSG to MS4L would be a great idea. No separate LoxBerry plugin would be required then and MS4L would just behave like a Loxone Music Server (most probably: better)

[TomekWaw]

BTW, hismastersvoice if you'd had any new version of MS4L with external zones enumeration to be tested by users before MSG is created, I'm here for you

[Prof.Mobilux]

Gast Do you think there's a change to switch over from Node.js to PHP or Perl for the interface? This way there are maybe a lot more people who could contribute.

[Prof.Mobilux]

I played a little bit with Christian Fenzl squeezelite Plugin over the last 3 days, which also provides a LMS2Loxone Gateway like hismastersvoice MS4Lox. And as hismastersvoice already said the interface is OK at the moment. We can "talk" via UDP to MSI and that's pretty fine for a MSG implementation. And for all others, I would let the MSI<->MS interface with VIs and VOs as is. This way all options could be used.

[Prof.Mobilux]

We will have a first beta for the squeezelite Plugin, which natively will work with the MSI Plugin (without LoxConfig VIs/VOs), in the next few days. It already works here with Cover, Play, Stop/Pause.

hismastersvoice I used the following cover URL:

http://lmsip:lmsport/music/current/cover.jpg?player=<playerid>

and recognized that sometimes the Loxone app did not update the cover (at least the older version 8) until I added a randomely part to the URL:

http://lmsip:lmsport/music/current/cover.jpg?player=<playerid>&id=<random>

[hismastersvoice]

I must correct myself...
Whenever I play music from the HDD (mp3) the cover is not updated properly.
With a Ramdom ID, it works.
Thank you.

[hismastersvoice]

I have integrated the MSI (I call it Alpha) Plugin in my Gateway for testing, but it make no sense until we don´t have something like a beta version of it.
That is to early... The reason is, there is no (psuh) update in the App if something has changed from a 3rd Party-App like Volume etc.

So I have a bit of patience, didn't have it for so long time, one week more or less don´t matter.

I read the Artwork-URL from "songinfo", works with LMS 7 and 8

I have just posted in #68 about this. I hope I will be able to send you a full server working (and documented) with the full player API, the queue, and favorites working. Fingers crossed I get the time.

[Prof.Mobilux]

Haven’t had a deeper look into it but with Christians gateway at least volume was synced between third party app and Loxone during my first tests.