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.
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.
Yes WOL in my home network works fine. But I don’t get it to work when I switch off WLAN on my mobile and try to start the core by opening Arc. Anyway I am not going to waste time on it as I cannot turn off my core remotely. I would still have to call my neighbor to turn it off when I am on vacation