The Fritzbox setting that is mentioned above is for waking from the internet. When ARC connects to the external IP/port of the Fritzbox, the Fritzbox knows that it’s for the NUC because of the port forwarding rule, so the Fritzbox sends a WOL package to the NUC.
WOL packets must be addressed to a hardware address. It seems that the Fritzbox does what’s necessary automatically (it knows the hardware address). (In networks with complex routing tables, it may be necessary to specify IP broadcast addresses for network traversal as well, but not in regular home LANs). Nothing you need to do besides enabling it.
For waking the NUC manually from the LAN, you need to send the WOL package in another way. There are apps, or you can write a one-line commandline script into an file to doubleclick. You need the NUC’s MAC address, it should be printed on a label on the NUC. (I don’t think you can get it from the ROCK Web UI, but in the worst case one could boot the NUC from a bootable Linux USB and read it out).
This is a good summary for Windows, will be similar for Mac:
I don’t understand how ARC finds its associated core. I assumed Roon was running a cloud-based discovery/redirector of some kind. If that’s the case, then the discovery service is probably maintaining a mapping of account to IP. If a core is asleep long enough, that mapping might age out - there would possibly be a heartbeat protocol to keep the mapping around while a core is active.
I’m not sure that ARC is going to make it to the Fritzbox if the core has been powered down for a long time. Depends on how it’s all built.
Thanks. I know all the rest you mentioned, but what I tried to do is the above. I changed settings in my Fritzbox as described in the link provided by Mike, but when I am outside my Lan and open Arc it doesn’t start the core. I have to try a bit more. But it didn’t work right away. Will try the next days.
You probably already know that there’s a BIOS option for configuring how a NUC responds to having a power source connected. I think it’s called “After Power Failure” and I’m pretty sure the options include “Restore to Last State” and “Power On”.
If you put your NUC on a smart outlet, like the ones from Meross or a bunch of other vendors, and you set your NUC to always power on when a power source is connected, then you could remotely cycle the smart outlet to get your NUC on.
I’m not suggesting you use the smart outlet to power down your NUC. But if you know the NUC is off, you could power the outlet down and then back up and the NUC would start.
This isn’t perfect and you’re adding a thing that is going to use power all the time, but it’s an option.
There are Roon servers involved, but as far as I can tell (and maybe I am being naive), for the Fritzbox it only counts that it receives a packet at its outbound IP address that says “port 50000” in its header. Then the Fritzbox looks up its routing table and finds the rule saying “50000? forward it to this IP” (which is the NUC). When Wake-on-LAN is enabled in the Fritzbox for the the NUC, it looks also up the NUC’s MAC and first sends a WOL packet to it.
You launch ARC on your phone. Assume you’re in an authenticated state. I’m guessing the ARC app makes a call to a Roon server that’s something like
ip = GetCoreIP(user_id)
I assume it has to do something like that because it can’t assume that the user’s IP address is the same as it was the last time it ran. It could even be the first time that ARC is being run on the device.
So the Roon cloud has to be maintaining a mapping of user_id (or whatever) to IP address. If the core is powered down for a sufficient period of time, and the Roon cloud ages out the IP mapping, then the ARC app won’t know what routable IP to connect to.
There’s a thing to be aware of here which is that we might do some testing and figure out that it works (seems to be working for Torben already). But this testing might be happening within a time window that isn’t sufficient for the mapping to age out. So if you go traveling, and you think you’re going to be able to remotely wake your core, you might be surprised and find that you can’t because of this. We just don’t know if it ages out at all or if the time to live is an hour, a day, a week, or something else.
It would be helpful for someone from Roon to help us understand.
The OP doesn’t want to walk over to his NUC/Nucleus and press a button. He wants to do it from a Remote.
The post I’m replying to suggested using a device that would cut the power at the wall.
I’ve been here before. This from Apr '20 where restarting Roon from a Remote was discussed. Notice how it quickly devolved into a bunch of confused argumentative posts -
Sounds good, thanks. Luckily mine is static, I hope they always try the last known one I guess someone with a dynamic one has to check, though how often it actually changes will probably depend on the ISP.
I was thinking more about restarting it after a power outage, for instance. Though that would be a last ditch measure in the first place, I wouldn’t turn it off on purpose. If I can afford a vacation, I surely can afford a NUC being idle for 2 weeks
These things are often built on Redis or something similar and can have expiration policies based on time, memory pressure, or custom logic. All I can say is that if it were me, and I wanted to travel and use ARC, I sure wouldn’t bet on being able to wake it remotely after time had elapsed.
Set it to come back on in the BIOS. That’s easy.
I’m with you about not turning it off. That’s the best advice anyone has given yet
Interesting. I live in an area in which I’ve not heard of power coming back on causing issues. I imagine it can be an issue for some people depending on how their grid works. I’m going to stop saying things now because I don’t want to give bad advice.
And all of the above probably goes to prove why Roon stubbornly refuse to include WOL from their remote app: there are too many variables, and thus it’s not dependable.
I guess someone with a dynamic one has to check, though how often it actually changes will probably depend on the ISP.
