Happy to be included in testing…
Have tested it for a week or so, with a few container restarts, and it seems solid. Thanks!
Hi all,
Does anybody know if it is possible to “reassign” the knob with fast forward/rewind for a track instead of volume control. Otherwise an incredible overwhelming project, amazing how seamlessly the integration is working out of the box. Yeah!
Thanks for the kind words!
Does anybody know if it is possible to “reassign” the knob with fast forward/rewind for a track instead of volume control.
I have a spike (alpha mentioned a few posts back) that makes the knob fully configurable, different buttons per zone, even per song, actuator ring can do different things, change layout. Right now it requires a good LLM to configure it.
To be transparent: I was heading towards a paid (with trial) model to support that + firmware for a handful of other ESP devices as a subscription (I have it working on a color eInk, RLCD, a waterpoof device, iPhone, Apple Watch). I am reluctant to proceed because if it’s a paid offering I am unsure it’ll make much, but I worry it’ll take a non-trivial amount of time to support any one of those surfaces.
I am leaning towards keeping it free and open, but coming up with a different way to configure the device(s) that’s less powerful, but that don’t require an LLM (which I’d need to cover costs for). In the meantime I got busy with other things (mostly AI coding tools for myself and some clients I work with) and only tackling bugfixes on the current version of the firmware and server.
Would be happy to join your alpha tester group. Other than that, I could understand your thoughts about getting a “subscription”, to get something back for your amount of time for development.
Br
Hi,
I just received and flashed my knob to 2.5.0, installed the Unified Hifi Control 3.3.1 (UHC) and saw the magic happen: I can control my LMS players from the knob.
But I have one concern with the volume level not syncing correctly from LMS > UHC > knob which makes the volume behave erratically.
LMS is connected but states “CLI: inactive (polling only)•Poll: 2s” which may explain why the volume applied in LMS is not updated back to the knob UI. Is there anything I miss or is this a real issue. How can I help troubleshooting or reporting my issue?
Hi Yann,
Thanks for trying it out!
Sounds like there’s a bug with the polling path for retrieving the volume from LMS. I’ll take a look.
CLI is a listner mode: LMS sends UHC all the events (including volume as they happen). The polling path has UHC ask LMS for status every 2 seconds. Polling isn’t ideal, just good for fallback/catching up when there’s a network hiccup, so for your LMS server’s sake, you should try to fix it. If you’re using it specifically for LMS, you proobably want to try it in LMS plugin mode which should support CLI mode even if there’s a network issue (it then runs on the same machine as LMS).
There is an LMS forum where they might be able to help with why the CLI is unreachable: https://forums.lyrion.org/forum/user-forums/3rd-party-hardware/1804977-roon-knob-includes-lms-support .
I still need to fix the polling for volume retrieval, will update you when I figure it out!
LMS polling returns wrong volume when mixer value is non-integer · Issue #299 · open-horizon-labs/unified-hifi-control · GitHub ← I think this is the bug.
I have a fix and would like to get you a test build to check. What did you use to run UHC? Docker?
Yep I am “LMS exclusive” for music
I hadn’t figured out there was a LMS plugin for it. I just set it up and it fixes my volume update issue! Thank you for this ultra-fast answer!
By the way, my media setup relies on a Linux hardware running Kodi for all-except-music (TV, PVR, movies, replay, streaming) and Squeezelite + Lyrion UI for “high-end music”, and camilladsp using a customized ALSA cdsp driver. Not forgetting streaming platforms running on Android TV.
Over this mess, I setup a kind of integration in Openhab consisting in “room active devices” which exposes one single virtual audio/video device so controllers (remote, keyboard, tablet UI) send commands seamlessly while Openhab takes care of routing them (UI navigation, transport and volume control) and configuring the physical underlying hardwares and softwares (DAC, avr, preamps and amps),.
So this knob which only controls LMS is currently disrupting my logic. Or said differently; knob control is dedicated to high-end music and is more exclusive
![]()
I will try interfacing the knob with OpenHAB “virtual layer” using UPNP tomorrow but not sure it will handle video medias properly.
More ahead, extending the use of the knob to home automation with ESPHome would be nice (for light control, thermostat or any interaction).
Hi @Muness, I’ve flashed the new firmware. run bridge via extension manager and authorized in roon, but I’m having a problem setting up the 2.4GHz WiFi It won’t connect displaying “Wrong Password”
The password is copied and pasted from my password manager and is used on other devices, so I know it’s correct. Are there any symbols it will not accept? Or maybe it cannot cope with the 63 characters password length.
As a test I set up an access point with a simple / fairly short password and it connects and works fine with that, but I would obviously like to be able to connect to the same access point as all the other devices Thanks
Thanks for the bug report. I’ll check but it’s probably password length that’s the issue, I’ll check the spec and bump it up if that’s the issue.
WiFi passwords with special characters silently corrupted during setup · Issue #179 · muness/roon-knob · GitHub so it’s big enough, but I wasn’t handling special characters (that get URL encoded) correctly.
New firmware coming.
Flash Roon Knob Firmware - PR #180 Preview has the firmware with the fixes to handle special characters to fit within the 64 characters. Would love for you to test and let me know if this fixes the issue. Note that I haven’t had a chance to test this, will do this weekend.
Hi Muness,
Unfortunately it didn’t work.
On my main 63 character wifi :
After reflashing, the knob screen showed “Testing Bridge Attempt 1 of 5” etc
Bridge unavailable update at http://…..
On the simple wifi setup it showed the same.
Logs show:
[10:39:27]I (313505) wifi:[ADDBA]RX DELBA, reason:39, delete tid:0, initiator:0(recipient)
[10:39:29][RK-I] UDP unavailable, falling back to HTTP
[10:39:29][RK-I] manifest_parse: JSON parse error
[10:39:39][RK-I] UDP unavailable, falling back to HTTP
[10:39:39][RK-I] manifest_parse: JSON parse error
[10:39:50][RK-I] UDP unavailable, falling back to HTTP
Reflashed with the normal firmware -
Simple wifi - connected and works
63 character wifi - Displays “Wrong Password”
Thanks for the test. That indicates the new firmware was able to connect to the wifi network. But that when on that network it wasn’t able to reach the bridge.
- Do you have VLAN setup that might be segregating the wifi devices from where the bridge is running?
- Can you check if the device is reachable when it should that Bridge is unavailable info dialog?
Oh! When I compiled this build I had errors from the new compiler about using strncpy and I swapped them out in what I thought was a clean refactor. That probably broke the new firmware and it’s no longer storing some of the config data properly. So ignore the questions above, checking that.
Flash Roon Knob Firmware - PR #182 Preview .
Apologies for the confusion, I’d merged what was supposed to be experimental work into the main branch and sent you a build based on that.
The above is working correctly for me, and hopefully will fix the issue you are seeing. LMK!
Unfortunately it didn’t work for me.
It goes to Testing Bridge Attempt 1of 5 etc, but this time on the simple and the 63 character wifi.
Going back to the stable firmware version and the simple hifi setup works.
I sent you the wrong link yesterday ![]()