Thanks @Muness - will be interested to see what you develop. The frame isn’t inexpensive, so for me would need a bit of thought as a potential purchase, but I can imagine it being well received. Good luck with the development 
Looks excellent
Have 2 knobs already tempted to order one of these…..
1 Like
I noticed that the bridge opens port 9003, which I assume is related to Roon’s autodiscovery feature. Is there a way to disable this functionality?
I’m running the bridge on the same server as Roon itself. A few days ago, Roon’s autodiscovery stopped working when I tried to connect via Tailscale. Even manually entering the server’s IP address in the Roon client didn’t work.
Today I had the opportunity to investigate the issue and discovered that when the bridge starts before Roon, it opens port 9003 (a port that would normally be opened by Roon). After stopping the bridge and restarting Roon, autodiscovery worked again.
As far as I can tell, the bridge continues to function even without using port 9003. For now, it’s manageable to simply make sure that Roon starts before the bridge. However, after occasional reboots, I always need to double-check that port 9003 is actually opened by Roon. Otherwise, if I’m away from home, I won’t be able to connect via Tailscale.
Do you have any advice, how to handle that in a better way?
1 Like
With every device I’m building more shared infrastructure and learnings that make the next device cycle better.
Let me know the use cases you have and I’ll look for dev boards that suit them! 
Ah, I wonder if this is related to the discovery problem some of us have hit. Thank you for the lead, maybe addressing this will fix the issue.
Looks like you uncovered a bug in the Rust port of the Roon API client. fix: Add SO_REUSEADDR to SOOD recv_sock to match Node.js reference · Issue #1 · open-horizon-labs/rust-roon-api · GitHub to address and submit to the Roon API client repo.
What do you run your bridge on? I’d love to give you a test build to confirm the fix. 
1 Like
Glad I could help with that
I’m running the bridge as a Docker container on an Ubuntu host.
Do you need any additional information to prepare the test build?
1 Like
Nope, that’ll do. But I had to remind myself how to test a PR build in Docker. 
When I got the QNAP builds working I just switched to testing via qpkg.
muness/unified-hifi-control:pr-268 should be up soon with the build that I think will fix the issue. 
Hopefully it also fixes disovery for other folks.
1 Like
1 Like
Thanks
would the device below be possible for roon controller i know its a device requiring usb power not battery but would be great as a screen i think ?
Asking about this one because it’s meant to be mounted? I think there’s a similar one with an ESP32-S3 which is the chip I’ve targeted so far.
Thanks for your fast response and the test build! I switched to the new image and now all three applications (RAATServer, RoonAppliance, unified-hifi-co) listen on port 9003. Discovery of the Roon server over Tailnet works again, even when the bridge started first. Autodiscovery of the bridge by the knob during knob setup also worked fine. I think, this build fixes all problems that I’m aware of 
I didn’t know that multiple applications can share the same UDP port. Learned something new today!
1 Like
I think that multiple can ask to receive but I thought only one actually gets the data - so would be interested to know how this works in practice.
Can a receiver filter the content and ignore it if not wanted and then have it flow to another listener for it to try?
My understanding is that Linux and Windows do different things with UDP ports by default:
- Linux: The second process gets
EADDRINUSE: whichever starts first claims the port. socket(7) - Linux manual page. - Windows: Both bind succeeds, but packets are delivered unpredictably between them. Instead of failing or neatly mirroring the multicast packets to both processes, Winsock enters a non-deterministic state. Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSE - Win32 apps | Microsoft Learn
1 Like
Hi Chris - pushing out v3.3.1 with the fix for the issue @Foo_Bar mentioned. I suspect this will also fix this discovery issue. Would you be able to test it out and let me know?
1 Like
Just chiming in here to say that I have just set this up myself. I initially thought I had a completely dead device (bought directly from waveshare - apologies for not using the referral link but I’m in the wrong country!). However I took it apart to check, following instructions on how to add a lithium battery despite having bought it with one pre-installed. After reseating all connectors, it sprang into life. I guess something got knocked out in transit.
I got the bridge up and running easily enough using docker compose on my home unraid server.
It’s a really nice application, I’m very impressed with what you’ve done here. Thanks!
Paul.
1 Like
With the warmer weather, I found the Amazon.com: M5Stack Official M5Stack Tough ESP32 IoT Development Board Kit : Electronics so I can have one outside on the deck. Excited to give it a firmware.
On a different note, I have the experimental firmware, fully configurable, at runtime like so. Some dev screenshots:
The idea is that for different zones/artists/(other rules here) you use a chat interface to build the interface you want, and the knob transforms automatically to match the rules you’ve put in place. And yes, the vol indicator and rings (width, presence, colors) are all configurable too.
No ETA, am exploring usability paths for this radically different interface paradigm. Anyone interested in Alpha testing?
4 Likes
@Muness - I’ve just noticed that all the sleep settings for my knob have reset. I had to restart the bridge quite recently, so perhaps related to that? Are they meant to persist? Thanks!
Those should persist across bridge restart as they’re meant to be saved in the knobs.json settings file. I’ll take a look to see if there’s a bug there. Thank you for the bug report!
1 Like
No worries, thanks for looking into it.