rpdistiso
commented
2 months ago Just an idea for having Ristretto on boot: you could attempt to make Ristretto an Aroma Module since they load when Aroma is launched
Open ItzSwirlz opened 2 months ago
rpdistiso
commented
2 months ago Just an idea for having Ristretto on boot: you could attempt to make Ristretto an Aroma Module since they load when Aroma is launched
ItzSwirlz
commented
2 months ago Just an idea for having Ristretto on boot: you could attempt to make Ristretto an Aroma Module since they load when Aroma is launched
I don't think you understand the issue... Aroma (and therefore Ristretto) is offline when the power is off. Ristretto is currently a plugin. The goal is to make it so we can send a network request *when the console is powered off (or at least in a low power state like ECO mode) to the console to turn it on.
If you're thinking about making an Aroma plugin instead of a stroopwafel plugin, I don't think Aroma is running when in ECO mode. Because isfshax/minute is used to replace the boot loader, we can have full control from there compared to Aroma.
Also I may be wrong but I think the kernel != IOSU. IOSU is what runs on the Starbuck and if we can do that, there will be less heat emitted
ItzSwirlz
commented
2 months ago Here are some options, not requiring hard modding or replacing the ECO process:
This would mean:
This would mean:
I think the bluetooth route is more viable.
While we can turn off the console via Ristretto, we can't really turn it back on. This is obvious because Aroma (and therefore Ristretto) is not active.
For the sake of feature completion, it would be good to have some way of basically creating the equivalent of Wake on LAN for the Wii U.
There are many different ways to go about this, so here is what is on the drawing board.
The Easiest Solution
Don't turn off the Wii U
Yes, this technically is the easiest solution, and most intuitive. When I say the console is "on", I mean, the disc drive is spinning, the light is blue (or purple if you use ISFShax), the Wii U menu or whatever is running in the background, all regular processes are still happening, the fan is still going, it's like the console is on as usual. This distinction will be important later. This accomplishes the goal of getting rid of the need for a "power-on request" while also driving up the power bill and aging the wear and tear on the hardware. Obviously any sort of "always be ready to wake up!" will mean more hardware usage, but the disc drive and all the other services are just so unnecessary.
Requiring Hardware/Modifications
Use a smart plug, automate turning it on.
From what I understand correctly (@Maschell if I am wrong let me know), with some soldering or something you can make the Wii U turn itself on whenever it is plugged in to an outlet. The pros of this is that it would leave no software, but the cons are that this requires modifying the hardware and another smart plug. Also, since Ristretto doesn't start the second the console powers on, there is no way to do a "power on straight to System Settings" for example. There would be have to be a pause which can vary depending on whether ISFShax is installed, for example.
Using a Raspberry Pi or something else to turn the device on internally
This could be like, when the network request is received, push the power button, but in my opinion that is sort of ugly. Another alternative is to wire the Raspberry Pi inside the console, which I don't even know how to even think about getting power to it to be always on. Clearly the console has some power whenever it's plugged in - it keeps the disc light illuminated when something is inside and keeps the power LED red. But again, a pause on boot and it's another hardware mod.
Without hardware modifications but requiring headache on the home automation bridge server
Imitate the Wiimote/GamePad's power on request to the Wii U
This would be hard. The Wii U communicates to the GamePad via a modified version of the 802.11, and also DHCP I think? The issue is, doing this means having an older, patched version of bluez for Wiimote simulation, or a patched wpa_supplicant for GamePad simulation. Both of these ideas are doable, but sort of suck. I don't think servers that are running Homebridge or Home Assistant should be having to used older versions of communication software just for one device. I haven't figured out how the GamePad requests power on, but it's certainly not local - you can test this out by taking your GamePad to a completely different area of the house from your console and hitting power on. You'll see the console still powers on despite being absolutely nowhere near it. @GaryOderNichts has the floor as to how this would work out in reality, he knows all about how input works. There's also the possibility of just reverse engineering the GamePad firmware but.. it's hard.
Requiring more features to Ristretto and even some possible system patching
Don't power off the console, but instead run another title or homebrew application that basically only runs what is necessary - a HTTP server waiting for that "wake up" request
This would basically mean when you're done using the console to open a homebrew application. This would mean shutting down as much of the console as possible. This is the 'on' state, but it's not really 'on', nor is it in the ECO mode (when there's the yellow light, the console checking for updates or whatever). It's in a very separate state from the rest of the console.
ECO Mode
Using configuration, we can make the Wii U never exit eco mode. Since the console has to be home-brewed anyways, we can just replace ECO mode.. but the ECO title/standby mode does very important things. Primarily, it updates the titles on the GamePad for the Quick Start Menu. Also, if there are any SpotPass downloads, I think those can also occur in this state.
ECO mode is the power state we need - the question is how to get an HTTP server running. Unless we want to sacrifice Quick Start mode (which genuinely might be a good option considering the entire console has to wait for you to select something in the Quick Start menu), we will need to find some way to patch the ECO title or recreate it entirely - probably meaning decompile and edit it. Ideally guess it's possible it can be limited down to just the necessary parts and system calls but this would be quite a bit of work. Once the HTTP server is running, as usual, start up whenever the request is sent via the network.
IOSU patching/stroopwafel plugin
@jan-hofmeier suggested that with a system running ISFShax, a stroopwafel plugin can be made for our purpose essentially. I may be wrong, but the entirety of Ristretto could probably be written as a stroopwafel plugin instead of an Aroma plugin. This could possibly work if modifying ECO mode does not work out. Jan also suggested just disabling the PPC side entirely and just running on the ARM processor, which would prevent lots of heat usage. I personally probably will struggle since I am not very knowledgable when it comes to my understanding of IOSU but this is definitely a good idea. However I don't know if the IOSU runs when the console is in ECO mode, I think it is but I'm not sure? Anyways, a stroopwafel plugin would be another alternative to how Ristretto currently functions and could help us out here.
Conclusion
There are so far seven different ways to solve this problem, each with pros and cons. I think the best option that has come up so far is basically modifying the ECO title/standby mode or some sort of stroopwafel plugin. I'm leaving this issue open here instead of using the discussion forms because there are so many different parts to this, and I could use everyone's thoughts here.