Gentlemen - it is sad to see how this thread evolves, especially the arguments for not adding WOL could not be more absurd. @danny
Every software company will check and prioritise CRs/issues/bugs. The severity of the issue, population of affected users and complexity to implement are probably the driving factors.
Let me try to do this exercise here:
Regarding Nucleus users:
I assume only 10% or Roon users use a Roon Nucleus device
the Nucleus is highly energy efficient as we learned
So lets please forget the Nucleus (only for a moment). Yes it can be improved, but we are talking about max savings of 20 EUR per year. Not worth discussing further - our audio gear is much more inefficient!
Regarding all other (non Nucleus) users:
90% of users are using a Windows or Mac located somewhere in the house. Mine is between kitchen and living room. It is a shared family iMac
every Mac or Windows PC made in the last 10 years probably has WOL integrated within the OS
my Mac is well configured: after 30mins of inactivity it will enter sleep consuming only 1W
when Roon is streaming music, it does not enter sleep, so Roon (at least on Mac) has implemented the correct API calls to instruct the OS not to enter sleep (thanks for that!)
if my Mac would be configured not to enter sleep, it would consume around 40W. IIRC that costs over 100 EUR per year - more then my Roon subscription (I live in Germany, energy IS EXPENSIVE and getting more so).
On adding WOL
I use the Roon iPad app. It knows to which Roon Server it was lastly connected. After my Mac enters sleep, well, I get that nice “Waiting for Roon Server” screen on the iPad.
Now please, explain me, why it is “complex” to send a WOL packet at this stage?
forget about households with multiple Roon Servers - this is what, the less than 1% case?
forget about Roon Ready devices - this is not what this CR is about - we can think on that on a later stage
A decent programmer can implement the WOL packet sending to the last known MAC of Roon server in 2 hours. Since Roon loves settings (I don’t, good technology has no settings in my opinion) and for the paranoid ones in here, well, add a setting to Roon to allow enabling/disabling sending WOL. Maybe another 2 hours implementation? Add some QA and planing and this CR takes 1 day to implement.
Implementing WOL brings:
for people living in some parts of Europe, you have at leat allowed them to correctly configure they’re PCs to sleep when not in use and save maybe 100 EUR per year
an enhancement to the user experience, not requiring the user to go to his sleeping PC to wake it in order to hear some more music. Isn’t a great UX Roon’s main proposition?
There might be something else preventing sleep mode, as my Mac Mini Server 2011 goes to sleep after the time I have set in the energy saving settings. And Roon Server is always running on it.
What works really well for me is the Logitech Companion remote with the bridge that supports bluetooth as well. I have programmed an activity for the remote linked up with the Mac Mini as a Bluetooth keyboard, so now my Mac Mini wakes up if I select the ‘Roon’ activity and it goes back to sleep if I press the ‘Off’ button on the remote. Works perfectly as does the regular sleep mode . Also, I have set the Mac Mini to go to sleep each night at 0:30am, which practically means the Mac Mini stops playing at 0:40 in the morning, which is a good time to go to bed anyhow.
precisely and also when i was running las it did not require user login TO start I think this could have been because it was installed as a pref pane addin *i’m am not a dev by any means but it does seem to be a clue it would load on machine start(not user login) and just sit there in the background iirc? the point about user login is pertinent as i would rather not have to use auto login just to get room going
My Mac running Mojave just goes back to sleep after I send it a WOL packet. Has anyone found a solution to actually wake Mojave up completely so the Roon server can play? I use an iPad and want to listen to music remotely from my Mac.
Just upgraded to Catalina and behaviour is the same: my Macmini won’t fully wake up from sleep on WoL packet receipt. It just goes back to sleep after a few seconds. Has anyone figured out a solution to this?
While I leave my Roon core machine (Nucleus+) on all the time also, I think this is a worthwhile feature. If you’re going to tackle this you might also tackle the situation that Roon core’s continuous polling of a NAS (where music is stored) looking for new music causes the NAS to never to be able to sleep. Maybe provide flexibility on when/how often to poll a storage device.
More than 5 years have passed and nothing happened.
Sending a WOL packet is a joke. You are building the Roon Remote apps based on JS arent you? You can easily find libraries on NPMJS that take care of everything so the WOL is just a single line of code (one sample https://www.npmjs.com/package/wol)
As simple as:
When Roon Remote App starts and does not cannot find the Roon Core, send a WOL packet to it while we see that wonderful “Searching for Roon Core” animation.
Either it will work for many users who have setup their PCs and Macs correctly, or it will just not harm anyone.
I do not use the fancy new AI driven Roon Radio. I don’t need new features as long as the basics are not working flawlessly. Just my pov.
Another vote for adding wake on lan - or some other power saving feature for ROCK. I think it’s embarassing for Roon to unnecessarily waste so much power.
. Also, I have set the Mac Mini to go to sleep each night at 0:30am, which practically means the Mac Mini stops playing at 0:40 in the morning, which is a good time to go to bed anyhow. 
