Roon Extension: Roon Web Controller v1.2.0

This would require interaction with libsensors, which is out of scope for the Roon Web Controller project because it is hardware specific.

Additionally, because it is hardware specific, it would only be able to show the temperature of the system running the backend application. So if you are using a Raspberry Pi as a client in a web browser, the hardware temperature absolutely cannot be displayed.

Thanks @Jan_Koudijs!

I will hold off doing a PR on the repository update until the the 2.0.0 series is ready. I have an alpha image out on Docker Hub (pluggemi/roon-web-controller) which I will be keeping current with development.

The Dockerfile that I wrote to build the container is a 2 stage Dockerfile - one to webpack/compile the web application, the second to take that compiled web application and publish it. This is to keep the published container as small as possible - stage one has a LOT of dev dependencies that are not required at runtime.

The first stage generates architecture neutral html, css, and javascript. Only the second stage would need to be tweaked to support different architectures…

I am not sure how well Docker manifest will handle a two stage Dockerfile, but I also have very little experience with Docker manifest since it is a relatively new feature. So if you have any pointers on that, it would be appreciated!

I discovered a very useful Web controller 1.2 option that I didn’t know about. These are notifications. It works great and now I know at the beginning of the song who is playing and what the title is. Maybe it will be a whining but if the notification was not include the name of the browser and the website address in my case ( Google Hrome localhost: 8080) it would be more than excellent. This probably cannot be changed because the browser is already responsible for displaying notifications. Anyway, it’s a very nice option, especially when I start playing a larger collection of artists selected, e.g. by genre.
Regards Robert

Interestingly, the browser title updating with the song name is already implemented in 1.2.13. If you open http://localhost:8080/nowplaying.html, the browser title will update with the song name.

But, you will lose the link to the library browser if you do that. It does not work with the full page because of the way the full page is implemented.

I had already toyed with the idea of doing this with 2.0.0 and it is actually rather simple to do. I will add it to the list.

Changing the address bar to show the song name would break a lot of things

Hi Mike,

just would like to say thank you for the great work with the web controller!
I just installed it few weeks ago and did some adjustments to the layout of “nowplaying” screen for my needs. I use it mainly as display in the living room and the position is about 3.5m away from the sofa. So, more focus on readability of the album info :slight_smile:

It looks like this now:

I’m not yet very happy with the control area on the right hand side. So just showing track time and volume level would be good enough for my purpose, and maybe time and date. Something to work on when I find some time again …

Thanks again and looking forward to your new controller 2.0.

Best regards

Not sure if you have seen screenshots of the 2.0 alpha.

On one hand, the controls are simplified, so less space is taken by them. But on the other hand, the text for the song names does not scroll - all of it is displayed - and right now it is a little bit smaller.

There may be minor tweaks to the text size, but Now Playing screen is pretty much done.

Not sure if you will like it, but you can always tweak your copy to your needs.

1 Like

Yes, I’ve seen the pictures. I like the new design. I will try it, once you have released it.

One question to version 1.2.13, which I‘m using: the screen saver activate as soon as nothing is playing, as it should. But once activated, because music was stopped, it doesn’t switch on again when music starts again. I need to touch the display, then it stays on as long music is playing, as it should.
Is this the expected behavior?


An application in a web browser cannot “wake up” a screen from sleep or a screensaver. Only a hardware event can wake up a screen - tap the screen, keyboard, or mouse movement.

The way 1.2.x keeps the screensaver from starting is by looping a 1px video - video playback can prevent a screensaver from starting, but cannot “wake up” from a screensaver.

So yes, what you described is the expected behavior and there is nothing I can do to change it.

Okay, understand. Thanks for the explanation Mike!

I run web controller by extension manager in docker on Synology NAS.
The volume is controlled by another extension with harmony hub.
On web controller the volume is not working.
Can you help ?
Thank you

In your device setup screenshot, you have min and max set to 0.

That will prevent the volume from being changed.

I would recommend increasing the max to 50 or 100 based on what you are comfortable with. Once you do that, the slider in web controller will get the correct values and should start working.

It can’t be changed.
Se attached Photo - device limits, any value is overridden to 0

Check if the device is set to “use device volume” or “volume control disabled”.

But an extension cannot set those values. If you are still seeing issues you will want to open a new thread in the Roon Support area.

Anyone want to help a guy out and let a newbie know how to install this in Manjaro KDE Plasma Linux?

I get this far:

nevermind, I got it. Using it now.

Glad you got it working.

Is there an area of the installation documentation that needs improvement? I thought I had it pretty documented on the installation section of the readme page…

1 Like

I’m not sure, I am an ultra noob and am using Manjaro linux, so I had to figure out how to get NPM and Node.JS packages installed. Once I got that sorted the rest was easy

Ahh gotcha…

Glad you got it working!

There seems to be a bug in the zone data for zones that have a volume control of type ‘incremental’. The correct volume control information is missing, so to a web control UI, it would seem the volume control type is fixed (due to being missing).

There is nothing you can do about this in your UI.

Hopefully this will be fixed in the future (in Roon server), in which case you just need to make sure you correctly handle type ‘incremental’ as describe in the roon api documentation (the rest of the volume block will be empty, so no min, max or step). Incremental needs a slightly different UI - just up//down buttons instead of a slider as well, and the volume adjust commons to roon are sent as relative 1 or relative -1.

Thanks for the heads up on this. I won’t make any changes to v1.2.0, but I will add it to my list of things on Version 2.

If someone can get me a snippet of the JSON payload on a zone that has incremental volume controls, that would definitely help. All of my devices are either fixed or number. And the docs for the Output payload here just shows that the incremental looks like this:

{ "type": "incremental" }

This is correct.

When you see a volume block of type = ‘incremental’, then you can only send the following:

Volume up:

transport.change_volume(output, 'relative', 1, (status) => { /* ... */ };

Volume down:

transport.change_volume(output, 'relative', -1, (status) => { /* ... */ };

There is no other information in the block as none is needed.