Willkommen im Loxone Community Forum. Um alle Funktionen nutzen und sehen zu können, registriere dich bitte zuerst. Dies gilt auch für das herunterladen von Dateien.
Bitte im Titel immer zuerst den Namen des Plugins hinschreiben
To keep it updated you should check the LMS every X seconds in case it has changed from another third-party application and update the MSI, this is the only way to control the status by modifying it from any point.
I think an interval of 5/7 seconds may be acceptable.
Just checked and hismastersvoice is right: If you change e.g. Volume in LoxApp, the third party app is updated via the gateway. But the other way round does not work: If you change Volume in the third party app, LoxApp isn't updated.
We need VOs / UDP commands for the controlls, too.
BTW hismastersvoice Is there a reason why you only provide 10 Zones for each music server in MS4Lox? As far as I can see biggest MS Loxone provides has 20 Hardware-Zones + 10 Remnote Zones, so in total 30 Zones?
If we want all the changes to be executed in "real time", the possibilities would be the following;
- Loxone Original Option; Do not allow direct access to the LMS, so all requests would be made to the MSI.
The role of the MSG in this case would be two;
1. Allow requests to control the LMS and notify the MSI.
2. Obtain information from the LMS and send it to the MSI to keep the information updated.
Example: The MSI should be updated when a song is finished, interacts with any button of the application, etc. Most of these actions can be "controlled".
- Monitored Option; As far as possible, we should proceed as the original Loxone option, but to solve updates from third-party applications, it should be monitored more continuously than in the first case, since updates can be carried out at any time.
Example: In addition to "controlled" updates, we must carry out checks every few seconds to check the interactions of third-party applications.
- Radical option: Modify the LMS to create triggers and that every time it is updated that the LMS itself updates the MSI (there would be no need for MSG, since it would be part of the LMS).
Realistically, I think the second option is the most appropriate, as it is the most flexible option. If we use the first one we will get a clone of the Loxone Music Server, but we will lose the option of using other applications, while with the second option we get the best of both worlds.
I have already created the entries to connect LMS4 + Squeezelite and they work. But how do I create virtual outputs for the covers?
Thank you very much for this wonderful work.
- Radical option: Modify the LMS to create triggers and that every time it is updated that the LMS itself updates the MSI (there would be no need for MSG, since it would be part of the LMS).
.
That is what we do with our Gateways, we listen to the CLI Port and if there is an Event we act.
So if there is a change of volume or state etc. from a player we send if direct to the MiniServer and later to the MSI.
For me this makes sense to have at all Interfaces (Lox-App/3rd App/ WebUI) the same values.
As written we have to push back the infos to the MSI like CoverArt-URL etc.
If it´s not possible to bring all functions into the MSI we need the 3rd Party App and it necessary to interact between the Apps
Hey, sorry I've been missing for the last few days, lots of work and stuff and I can't really focus right now. But i've made some progress and I have HTTP calls for:
* All player state
* Playing queue
* Favorite managements
I will see if I can get some time this weekend to polish it a little bit more and release it.
Regarding updates, this is exactly what the SSE interface is for: the plugin will be able to get informed at any given point in time of an update, and it will fetch the corresponding data required. This will enable the LMS inside the MS4L to also be accessible from the outside and keep the whole status (Loxone UI, LMS, and other clients) updated at the same time.
the Logitech Media Server Gateway from Squeezelite Plugin is now ready for alpha testing with MSI Plugin (as MSG). It's all alpha state at the moment - so you have been warned :-)
Currently we have implemented all Push-VOs of the MSI. So no need to import the VOs in LoxConfig anymore. VIs will follow soon, but are currently not implemented. Also there's no WebGUI at the moment for configuring the LSG. You have to edit the config file by hand.
HowTo test:
Be sure that you know what you are doing! This is alpha state and only for experienced people!
The plugin supports up to 5 fake music servers and up to 30 zones for each music server. You have to "connect" each MSI zone to one of your LMS players (mac address only, currently no names are supported).
Turn on debug logging.
Restart
Check the logfile if the MSI interface was loaded correctly:
Add your Fake Music Server to LoxConfig as described in the Wiki and connect the VIs of the MSI Plugin to the VOs of the Squeezelite Plugin. We will implement the VIs also in the Gateway, but currently this work is in progress. No need to import the VOs of the MSI Plugin.
That's all.
Known Bugs:
Running time of songs is not updated each second but each 3 or 4 seconds only
Implement MSI VOs
Zuletzt geändert von Prof.Mobilux; 10.05.2020, 12:18.
Good afternoon, Prof.Mobilux
How much is left for the new version of Squeezelite + MSG?
If I can collaborate on something let me know, I could translate into Spanish.
A great job!!
I thought you already implemented to define also the port and not only the IP to which all UDP packets should be send to? This seemes not to work at the moment for me. Additionally, the MSG also has to know for which fake music server the command was send. Currently you send zone and command only:
Code:
1::play
But the gateway has to know on which music server the zone in configured. So maybe we can change the syntax to
All of this is fixed in MSG You will be able to point it to your preferred host and port. Through an HTTP server you will be able to get all actions that are produced in the music server. For instance, a quick grep of my logs right now:
I would wait a little bit so that you can integrate with MSG rather than MSI, because the former is much more powerful than MSI (it provides a full layer of compatibility with the music server interface, rather than just a view UDP virtual inputs)
Ah, ok. I just thought that you will provide MSI, and the MSG are the existing gateways (e.g. from MS4Lox or Squeezelite Plugin). I was not aware of that you also will provide the MSG. If I understood that correctly, the existing gateways like MS4Lox or Squeezelite Plugin then will communicate with the MSG rather than the MSI?
Yes, I will be providing the MSG (In fact I'm close to releasing something already!)
The MSG will perform HTTP calls to a provided host/server informing about all the actions that happen in the UI. A **lot** of boilerplate from the Loxone UI is hidden by the implementation, so the implementer of the server (the one receiving the actions) has maximum flexibility while not becoming crazy about the dozens of different commands they implement for the same action.
That part of the Squeezelite gateway is the one you'll have to provide to correctly communicate with it. MSG is also made in a way that if you decide to not implement fragments of it, it will gracefully handle that lack of implementation for you (for instance, if you do not handle favorites, an empty list will be rendered; if you provide no player status it is optimistically computed for you, etc.).
In my case I am testing the whole thing with a Spotify "gateway", so my setup looks like this:
Loxone UI <-> MSG <-> Spotify Gateway
But I also expect other MSG connectors like for CasaTunes, Roon or MS4L (in this one I think the gateway will be embedded _inside_ the final image, but that's OK too, the plugin is made in a way that this can easily be achieved).
In short, MSG opens up a world of endless possibilities by letting the user implement whatever (s)he wants to easily interact with the Loxone UI.
Sorry for interrupting - as Michael currently is updating my plugin, I just want to understand.
I haven’t got the difference of MSI and MSG yet. I think Michael has implemented MSI.
From your log output, the Squeezelite Player plugin - additional to an udp in socket, an udp out socket, a tcp socket, the http rest interface, and the WebIf, we now need another http server?
If so, I would prefer an udp or Linux socket with json data exchange, where the I think MSG sends it’s data to.
MSI was my initial plugin and it just bridges basic UI actions from Loxone UI <-> UDP inputs.
MSG on the other hand performs a full bridging between Loxone UI <-> HTTP server. MSG does not use any UDP outputs or inputs, nor raw TCP sockets. It just does plain HTTP calls, and acts as a middleware between the Loxone UI and your player (of course you need to make the player understand the calls).
The choice of HTTP is explained in #54; in short all calls (except a few) are stateful calls (get favorites, get queue, get player state from a given point in time, etc), and a stateless interface wasn't going to be the best choice. In fact, although Loxone implements their interface through WebSockets (which are stateless), they need in many places to add a "request identifier" to know which response are they getting for which call.
In MSG, these are the whole set of calls that it makes:
* /library (List interface)
* /favorites (List interface, global favorites)
List interfaces:
* GET /:position (retrieve elements starting from position)
* POST /:position (add elements in position)
* PUT /:position (replace elements starting from position)
* DELETE /:position/:length (delete length elements starting from position)
The MSG is necessary because there is a ton of variability within their protocol. An example are the operations for playing a context: depending if you play from the main button of the interface, you play a favorite, you play a playlist or you pick a track from a list their calls are different.
As said, you do not need to handle all of these calls, if you do not implement one of them it'll be gracefully handled. Hope this clarifies the vision of the plugin!
I understand.
And the MSG also has an EventSource http server open where we push the changes?
I’m just thinking of, we replace Loxone Websocket - that is hard to implement in Perl and PHP - with another interface EventSource, that is hard to implement in Perl/PHP.
Correct. The cool thing about the MSG's EventSource is that you do not need to do anything special. You push the HTTP call and MSG will process it. So for instance, to send a player state update for e.g. zone 1, because the track changed, you would just push:
GET /zone/1/state
Then the server knows how to handle this. Same thing applies for lists (queue, favorites changed from another place, etc). For instance, to update the queue from position 0 because new tracks got added (or the user selected a different context that starts playing) you would push:
GET /zone/1/queue
MSG will also periodically query the state too if it sees you cannot push, as a way of gracefully handling the lack of EventSource (for instance, if your backend is a plain PHP server, which is possible to do!). It also handles gracefully drops from the server where calls are pushed; if that one dies and comes back to life later, MSG will ensure to update the player as soon as possible to the right state.
At the end, pretty much all calls and configuration are optional to ease progressive adoption while not crashing the whole UI.
Maybe you can just commit the code you have - even if not everything is working perfectly. We then could start to implement the communication layer in our gateways.
Zuletzt geändert von Prof.Mobilux; 10.05.2020, 15:50.
Wir verarbeiten personenbezogene Daten über Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen, Werbung zu personalisieren und Websiteaktivitäten zu analysieren. Wir können bestimmte Informationen über unsere Nutzer mit unseren Werbe- und Analysepartnern teilen. Weitere Einzelheiten finden Sie in unserer Datenschutzrichtlinie.
Wenn Sie unten auf "Einverstanden" klicken, stimmen Sie unserer Datenschutzrichtlinie und unseren Datenverarbeitungs- und Cookie-Praktiken wie dort beschrieben zu. Sie erkennen außerdem an, dass dieses Forum möglicherweise außerhalb Ihres Landes gehostet wird und Sie der Erhebung, Speicherung und Verarbeitung Ihrer Daten in dem Land, in dem dieses Forum gehostet wird, zustimmen.
LoxBerry - Beyond the Limits
You will be able to point it to your preferred host and port. Through an HTTP server you will be able to get all actions that are produced in the music server. For instance, a quick grep of my logs right now:
Tweet
Kommentar