ha no, the opposite 
if key sequences are not a problem, then secure input is not the cause - also good to know 
The only trigger type that always worked before your fix were key sequences. So, shift, shift = hud, and everything was fine again.
1 Like
so showing the HUD or switching to a different application did both do the trick?
yes, showing the HUD with a key sequence, with no other trigger ... or just switching the front app.
hi, this just started happening to me today (or maybe yesterday, can't recall). Please let me know when you find a solution. I didn't change any setting whatsoever. Thanks!
Hi,
The problem still occurs with the 4.168 and the sleep system wide disabled.
thanks
hi, I still have the problem
any debug log created after waking from sleep can help, (Help -> Export Diagnostic Debug Information, andreas@folivora.ai)
I think the current alpha versions have already fixed issues in some such cases, but it definitely seems to be different things causing this. Most likely some system settings or BTT featurw combinations Iām not yet aware of.
4.177 alpha reworks the whole wakeup process - would be great if you could try this version if you are affected by wakeup issues
Is there a corresponding version of BetterSnapTool to try? I get the same behavior there.
Unfortunately BetterSnapTool can't be affected by the exact same issue, the wake/sleep setup there is very different. If you encounter similar behavior there, would be good if you'd create a separate issue and describe in detail!
How do I send a log in BetterSnapTool? There isn't a Help menu to send Diagnostic information.
I've been having problems with wake from sleep for some time now on M1 Mac Mini. Waking with Apple watch seemed to fix the problem, but now it doesn't seem to make a difference. I'd be interested in trying an Alpha version that reworks the wakeup process. How do I get it to try.
Just looping back to this thread with some info that I've told Andreas privately...there is a slightly easier workaround option when it gets wedged.
When it gets stuck, just opening the 'configuration' window from the widget in the toolbar is enough to unstick it. You don't have to actually restart BTT. It's a little bit faster and a little bit less disruptive. You can save about 3cm of valuable pointer travel. It sounds insane that opening the configuration window without pressing save would actually "fix" the problem, but I've been doing this now for months and it seems 100% for me. (NSAppSleepDisabled brought me no joy.)
Hopefully that'll help others that are affected by this until a fix lands in either Sonoma or BTT. Save up enough of those centimeters of mouse travel and move forward your own retirement date!
Opening the BTT window is probably equivalent to changing the front app. And that has always worked. The question is how to change the front app. With which app or with which BTT trigger. This seems to be different and unsystematic among users, unfortunately. What works for me, does not work for others. 
I'll be darned. You're right. Just changing the input focus window is enough to resuscitate it. That's even better. Thank you!
With the new alpha 4.196 I'm trying to trigger an "internal app change" when BTT detects a wake from sleep. Not sure whether that will make any difference, but worth a try.
Ah, interesting. I've been trying something similar for a few days. A "wake up trigger" with KM. After waking up the mac, the Finder is activated and then the previous app again. I'm not quite sure yet, but I'm afraid ... but maybe your internal solution is more successful.
edit: I'm changing the macro to see how the front app changes, just to be sure....
I think I found a specific issue related to app specific shortcuts. If you encountered app specific shortcuts stopping to work after sleep, maybe it is fixed in 4.198 alpha
Good day
I'm running the alpha 4.226, and it's way better now.
BBT is not immediately active when I open the lid, but only few seconds later it's up un running.
Thanks !!
1 Like