I did this recently as I was struggling to get WoL to work with my consumer PC. It seems like this ultra low-level stuff is a total crapshoot so if you can dodge it by just wiring up the power button, that's a good option.
In in the end I just went the whole hog and set up a PiKVM, so now if I mess up the machine's networking (or even completely break the OS) I can still recover it remotely even though it doesn't have a proper BMC or anything like that.
In general this approach seems ugly in principle but I really like it in practice. It lets you retrofit solid remote capabilities onto consumer hardware. That way you have such a broader market to buy from.
I hadn't seen that before, seems neat as the physical inconvenience factor of the KVM approach is definitely real.
It's pretty funny that you have both the input and output physically installed in and powered by the chassis, but then you run cables to connect them!
It would seem reasonable to at least have the option to have it directly enumerate as a USB hub/display device on the PCIe bus it gets power from! But maybe that would add a lot of bulk/cost?
Note: If you're going to use an SBC _only_ for wake up signals, you might want to look into alternatives for the RPi such as the Radxa RockPi S [1]. My home server, for example, runs continuously at 7W, which beats many RPi models. Of course, a Pi to wake things doesn't need that much power and could be an older model, but even then, you'd still be burning "empty Watts".
Of course, the RockPi doesn't give you any KVM like functionality, though.
Yea, technically an esp32 board with ethernet would work for this job. They're typically limited to 10mbit, but if you have 10mbit/s of broadcast traffic you can afford something better.
