I just purchased Nucleus with solo purpose – integrate my Roon system with Crestron. Indeed, it’s much slower than my original Roon core running on Linux in a virtual machine on my 2-processor 16-core Xeon server, but I had no other option, since Roon doesn’t support Crestron integration on anything but Nucleus… The problem is, my brand new Nucleus doesn’t see my Crestron system. I uploaded Demo program to my Crestron controller and… nothing. Nucleus doesn’t show Crestron extension at all, and I have no idea how to teach Nucleus to talk to my Crestron controller. Probably, the problem is that my Crestron devices and my Audio devices (including Nucleus) are located on different subnets (for security reasons), although the routing between these subnets is explicitly defined. I even added Nucleus IP to Crestron’s Roon program IP table, but it didn’t help. Please advice.
Everything else in Roon is purposely designed to work on the same subnet. I presume Crestron is the same so try that as a starting point.
As Henry mentioned, I would try connecting the Nucleus to the same subnet that your Crestron processor is on as the first troubleshooting step here, Roon is designed to work on one flat subnet. Once we confirm that everything works as expected one one subnet only then should you try and add complexity.
As for the extension itself, does it show up in Roon Settings -> Extensions? You will need to Pair and Authorize the Crestron extension there when it shows up prior to first use and configure the zones:
If it still does not show up as expected when everything is on the same subnet, I would try a reboot of the Nucleus and Crestron processor, perform a recompile all on the sample project in SIMPL and upload the code again to your processor. Please let me know if that helps.
Thanks Noris. I moved Nucleus to Crestron Subnet, added roon app to my Crestron Administrator PC for testing, and after changing IP address and reboot, it found Crestron extension, so I could pair and authorize the plugin, and then the demo app successfully found two fake audio zones I created (one on the PC used to control the Crestron installation locally, and another the Nucleus itself. But I obviously lost connection to all my real endpoints, and to my music library (which are on the Main subnet). So, from the Main subnet Nucleus can’t see Crestron controller, and from Crestron subnet Nucleus can’t see the data NAS and endpoints. Obviously, the change of the network topology is out of question. So, how can I teach Nucleus to look for Crestron from the main subnet? Of course, I can wireshark the traffic between Nucleus and Crestron, then create a virtual interface on the firewall between the subnets, translating IP address and a few corresponding ports from Crestron to Nucleus and back… but I would rather have a single simple control on the nucleus itself Something like your “subnet for Linn streaming” (I do not have Linn devices, and don’t care for one… but I like the idea). Obviously, in the final configuration Nucleus should get back to Main subnet (where NAS directories and players can be changed almost daily, while my Crestron controllers were set up several years ago, and do not plan to move anywhere any time soon). So, the question now is – can Nucleus be configured to talk to Crestron on a different subnet (with known static IP addresses, ports and protocols), or I need to do network surgery on my routers and firewalls myself (really hate doing that ) . I’d rather listen to music instead of editing IP tables and firewall rules…
Thank you for confirming that everything works as expected if the Nucleus is on the same subnet as the Crestron processor. It does indeed seem that the subnet plays a role in this issue and unfortunately, Roon is only designed to work on one subnet at the current time.
If you enable authentication on your processor and touchpanels, would that not be sufficient to resolve the security concerns you have and make it one flat subnet? I know that Crestron recently released firmware updates to disable CTP and force SSL authentication to resolve some security concerns in their 1.503.0070 firmware release for CP3 and 1.004.0007 firmware version for TSW touchpanels.
If making the networking into one subnet is still not ideal, it looks like you will have to go ahead with the network surgery and configure the subnets to talk to each other. I can answer any questions you may have along the way to the best of my ability, just let me know what you decide and how it goes.
My subnets are “talking” to each other, in a sense that IP packets are routed from one to another. But this “talk” is limited to known protocols and hosts. In principle, communications to Crestron (Control 4 or any other management system) has absolutely nothing to do with communications with Rood devices and NAS – so you COULD make Nucleus crestron module configurable to work with Crestron controller on ANY IP address. But it can be done only by you, not me. I hope you will choose this way eventually…
At the moment, however, it looks like your Crestron module can’t do that. So I will try to do the NAT between Nucleus and Crestron controller, so the Nucleus will be fooled to think it’s talking to Crestron controller on its own subnet. To do so intelligently, I need to know protocols (and ports) you use to discover Crestron controller and control the Nucleus. I hope you do discovery on IP layer and don’t use broadcasts… So please advice.
So, I created virtual IP server on my Main subnet, pointing to my Crestron controller. So everything (except broadcasts, of course) going to that address, reaches my Crestron controller but… Nucleus can’t see the controller. It still can see the “authorized” controller at its Crestron subnet address (since I have set up routing without NAT, too) and display it in the list of “Extension Authorizations” saying that it was seen “just now” – but the Crestron program does not see the Nucleus, and nothing pops up in the “Discovered Roon Extensions” list.
I just wanted to update you here that I have taken you feedback into account and I will be discussing with the tech team later this week to see what else can be done here to make a similar setup work.
You mention that everything except broadcasts are reaching the Crestron controller, Roon works through multicast for device discovery, I am wondering if this could be part of the puzzle for making it work across multiple subnets for your Crestron gear.
Do you by any chance know if IGMP is active in your current setup? We have sometimes seen the need to disable IGMP Proxying and enable IGMP Snooping for connections to successfully occur on a few routers.
As soon as I discuss your case with the team and I have some additional feedback for you, I’ll be sure to let you know, I appreciate your patience here.
Thanks for the attention to my problem. No rush, I can definitely wait a few weeks
I had IGMP disabled throughout the system. Just to test, I enabled IGMP snooping on IPv4 level (I guess you use IP multicast, not L2) on my router and all involved switches… but Nucleus still can’t find Crestron program.
Since Crestron is highly “manual” (and pretty professional) integration, I guess manual (rather than auto-discovery) configuration would be most appropriate…
I am all yours, whatever help you need from me, I am ready to help.
Sorry to hear you’re still having issues here even after the most recent IGMP change. I spoke to the team to see what more can be done here but as I initially mentioned in my first post, Roon is unfortunately only designed to work on a single flat subnet at this time.
If you have it configured as such and that’s not working properly, we’re always happy to help, but configuring Roon to communicate across multiple subnets falls more in the experimental category rather than the intended usage.
Some users have found that it’s possible to configure a network so that Roon can communicate across multiple subnets, but this requires a level of networking expertise and it’s not something we can support or advise about specifically.
Speaking generally, you’ll need to make sure these devices can pass multicast and make connections in both directions, just like they would if they were on the same subnet. You’ll also want to make sure your firewalls are configured at the application level (for both Roon/Roonserver and for RAATServer), as opposed to opening specific ports for communication.
We know that other users have been able to configure this properly, so if a single subnet is really not an option here and the information above isn’t enough to make progress, you may want to post some of the issues you’re having in the tweaking section or do a more extended search on this forum to see what other users have done to get this kind of configuration working, as well as asking other Roon members to weigh in on what worked for them.
I’m sorry I don’t have better news for you here, if there’s anything else I can help with that falls under Roon’s intended usage, just let me know and I will be glad to assist. Thanks!