Read back my post #15 above. Your answer in post #16 apparently now seems to be that you can resume pushing the Power button. But that is NOT what we are talking about here. We are talking about waking on an hard-/firmware internal timer of the system (the iron system, not the operating system).
So it seems that you did not even test that or tried to find info on it in the systems docs or the BIOS.
To me the ability to do the wake from internal timer is the crucial thing to have before trying anything else.
I hope you now see how important the if the system supports this. is.
This message is printed when closing/sys/power/sleep after attempting to suspend. Which implies that suspend failed, and I bet that if you looked in kernel log you would have seen the same messages as before.
So, your BIOS does not cooperate well with attempt to schedule wakeup, at least using “standard” interface. There is nothing that can be done from Linux side. Try asking on hardware forums for your system/motherboard whether it is expected to work at all. Try whether it works from within Windows.
Yeah I got it working for some time now. The only thing still bugging me is how to make sure when - after waking up - the network connection is “live” so the stream can start.
I’ve been playing around with “Wants=network-online.target” and “After=network.target network-online.target” in my trigger.service but it’s not always sufficient. Added a “ExecStartPre=sleep…” in the radio.service as a workaround.
No, that won’t help. It is only relevant for startup and shutdown. Besides, if you actually read the post you probably answer (without indicating it by doing Reply), you would have seen that OP already used After=network-online.target without success.
“Software that is written under the assumption that network connectivity is available continuously and never changes is hence not up-to-date with reality. Well-written software should be able to handle dynamic configuration changes. It should react to changing network configuration and make the best of it. If it cannot reach a server it must retry. If network configuration connectivity is lost it must not fail catastrophically. Reacting to local network configuration changes in daemon code is not particularly hard. In fact many well-known network-facing services running on Linux have been doing this for decades. A service written like this is robust, can be started at any time, and will always do the best of the circumstances it is running in.”