2) EMail alert if something fails. Yeah, I know usually it's the pool that will tell you if you are not hashing, but I have always wanted to have the miner let me know if *it* things there is a drop, or if the fan is not spinning, or if it can't connect to pool "X". Probably a lot of programming for it to do that but, I can hope.
There's at least two possible implementation options for having this kind of functionality. The first one would be to use the already existing systemd as source for alerts and enable its notify by email functionality. That shouldn't require too much new implementation but may not have visibility to all the details you listed.
The other alternative is to have the feature somewhere in the monitoring or dashboard implementation. Those have access to all the details you are looking for but indeed would require more new code to be written.
Eventually, at least how I see it, this sort of feature requires most of the implementation work in the configurability of sending that email. These days, for most, it's no longer enough just to configure some email server name + recipient address. Instead, the authentication methods and protocols need also configuring and covering all option combinations is no longer as trivial as it used to be.
3) All LED off except for issue. Walk in, look at rack, red LED on. OK, that one has a problem.
This has the potential issue that you can't see just by looking at the rack if there's power or not. That's why a flashing led is usually the best indicator that everything is ok since it shows directly that there's power and the flashing indicates that the software itself isn't stuck.
