Tweet
Currently all audio/music extensions (except the Loxone Music Server) are integrated in Loxone using virtual inputs and outputs. Of course this is functioning fine, especially since there are other audio apps to control the multi-audio system, but there are also disadvantages 1) Quite some programming overhead and clutter in Loxone Config to control all functions, 2) sub-optimal integration in Loxone App and GUI control and 3) Difficult to combine audio control with the growing number of central control blocks in Loxone Config.
In order to resolve this, the proposal is to implement our own version of Loxone Music Server websocket for the control of non-standard audio extensions. Unfortunately the API of the Loxone Music Server websocket is not publicly available, so it requires some reverse-engineering and trail-and-error to get this API defined and implemented. If we succeed, we can run this piece of software on e.g. LoxBerry in addition to MusicServer4Lox, Sonos4Loxone, HEOS2Lox, etc. and we can use the standard building blocks in Loxone Config to control our audio system.
Any thoughts if this could work? Are there sufficient people interested in helping developing this?
In order to resolve this, the proposal is to implement our own version of Loxone Music Server websocket for the control of non-standard audio extensions. Unfortunately the API of the Loxone Music Server websocket is not publicly available, so it requires some reverse-engineering and trail-and-error to get this API defined and implemented. If we succeed, we can run this piece of software on e.g. LoxBerry in addition to MusicServer4Lox, Sonos4Loxone, HEOS2Lox, etc. and we can use the standard building blocks in Loxone Config to control our audio system.
Any thoughts if this could work? Are there sufficient people interested in helping developing this?