The macro is enabled. It's as simple as consisting of 1 action and can be described as follows:
Trigger the macro to quit Mail through the While Logged trigger every day between 11 PM and 1 AM repeating every 5 seconds.
However, nothing happens unless I try the macro. Why?
KM even doesn't log it, be it a success or failure.
If a macro âdoes nothingâ, the first stop should be the Interactive Help in the Help menu, Something expected is not happening.
It will tell you if the macro is active or not, and whether it fires or not. Only after you confirm that it fires should you worry about what the actions are doing or not doing.
I read Help docs as I always do. I found no helpful insights on what to do, which is the reason why I posted here, under Questions & Suggestions. Since you're the developer, I thought you might provide some clues as to what's wrong. The basic conditions for the macro to operate as it's intended are satisfied.
I confirmed it works in KM version 5 on an older device. The Engine log also detects the trigger, like so
2023-03-25 15:50:12 Execute macro âQuit Mailâ from trigger Every 5 seconds between 15:00-16:00 every day
2023-03-25 15:50:17 Execute macro âQuit Mailâ from trigger Every 5 seconds between 15:00-16:00 every day
2023-03-25 15:50:22 Execute macro âQuit Mailâ from trigger Every 5 seconds between 15:00-16:00 every day
2023-03-25 15:50:27 Execute macro âQuit Mailâ from trigger Every 5 seconds between 15:00-16:00 every day
2023-03-25 15:50:32 Execute macro âQuit Mailâ from trigger Every 5 seconds between 15:00-16:00 every day
2023-03-25 15:50:37 Execute macro âQuit Mailâ from trigger Every 5 seconds between 15:00-16:00 every day
2023-03-25 15:50:42 Execute macro âQuit Mailâ from trigger Every 5 seconds between 15:00-16:00 every day
So, I think I found a bug.
Can you post the actual macro? I'm having trouble finding a While Logged trigger -- posting the macro will makes things clearer.
Which implies it isn't being triggered. Again, seeing the actual macro will help more than reading a description of it.
It's a periodic trigger â he misstated the name.
It turns out the culprit is not that the engine is sleeping but that it's in the GUI level. In the version of KM that the issue manifested in, the time range incrementors (and other numerical incrementors, for that matter) respond incorrectly to the input from the keyboard when I'm entering the numbers. The numbers I type are offset by 3 units, so when I key in "20" the incrementor field shows "23". It appears, the latter is the value the engine accepts actually. The mismatch caused the entered span for the action to kick in to fall on deaf ears: the engine was getting different instructions than I told it, so it was always missing the interval.
To set desired values only worked with the keyboard arrow keys or the incrementor arrows.
I still have it in KM 10.2. The macro was working for 3 days then stopped. I attach 2 log files: the Engine.log messages reporting about the "Quit Mail" macro and the one I made of KM entries in the Console messages I collected by entering the keyword "com.stairways".
The very first message from the latter caught my attention
User Defaults 01:28:09.556470 +0300 97825 1 debug com.apple.defaults CoreFoundation Keyboard Maestro Engine found no value for key NSPersistentUIShowQuietSafeQuitStatus in CFPrefsSearchListSource<0x6000020e4580> (Domain: com.stairways.keyboardmaestro.engine, Container: (null))
as did those from the Engine.log
2023-03-31 01:33:47 Running application query took a while (4235 us)
2023-03-31 01:33:47 Running application query took a while (4804 us)
2023-03-31 01:33:55 Running application query took a while (27307 us)
2023-03-31 01:33:55 Running application query took a while (3028 us)
Both lnks expire in 7 days
I may be onto something in identifying the cause of the intended behaviour failure.
This trigger (and, perhaps, other time-induced KM triggers) appears to not be able to discern the lapse happening during the transition from one day to the following day. Particularly, this peculiarity becomes apparent when time ranges are involved. If both extremums fall within the same day the trigger fires up. If they don't the trigger blanks out.
My impression is that it translates the time units to scalar values and applies computations accordingly, completely ignoring the PM and AM qualifiers so that when it encounters a time range simllar to what's in the picture above it discards the day-to-day transition and thinks that 23 > 4. Being incapable of taking into account the aspects of the revolving nature of day change, the trigger sees it as an error and exits.
In the example below, it's the exact cause of why the macro was persistently going down. The solution exists but it's a bit clumsy and not intuitive: it's to create 2 ranges and tell the trigger to respect both (see the picture).
@peternlewis, its it possible to mend the logic to bring it into accord with the human perception of the daytime rather than strictly mathematical perception?
This is inaccurate.
Firstly, there is no PM or AM, Keyboard Maestro works in a 24-hour clock for this trigger.
Also, Keyboard Maestro knows that 04:00 comes after 23:00, it knows which is the start time and which is the end time.
If you trigger every minute from 23:00-04:00 every day, Keyboard Maestro will trigger 61 times, every minute from 23:00 through to 00:00.
It will not trigger from 00:01-04:00 because that is the next day, tomorrow, and it's never tomorrow.
The reason for this is obvious if you think of the behaviour for this trigger:
When should that trigger? Would it be 23:00-00:00 on Monday night, and 00:00-04:00 on Tuesday morning, or would it be 00:00-04:00 on Monday morning, and then 23:00-00:00 on Monday night.
There is no unambiguous answer, and so Keyboard Maestro only triggers on the unambiguous times.
Your solution to use two triggers is the correct one.
I'm afraid I failed to understand you the way you expressed the underlining message. "Tomorrow, it's never tomorrow". It is, for me, and I expect software to serve my purpose not its purpose. Could you re-phrase this sentence?
There's nothing ambiguous about "23:00 - 04:00". Remember, quote-unquote, Keyboard Maestro knows that 04:00 comes after 23:00
There is something ambiguous about 23:00-04:00 every Tuesday.
Without an unambiguous answer to what that means I can't implement it.
Regardless, whether I change the behaviour or (more likely) not, the solution is to use two triggers today. Changing the behaviour (which I probably wont do for the reasons I've already outlined) wont help today (or tomorrow or the next day). Using two triggers will.
Every day from 23:00 to 04:00 implies that the start time falls on this day or the day indicated, and the end time is the adjacent day to the right on the imaginary timeline.
Computers still aren't as good at inference as you are.
I completely understand the urge to use natural language to set the time period you want -- but KM would likely still split that into two schedules behind the scenes (do some searching on cron evaluation for why). So perhaps it's better to have that split shown from the get-go, removing any ambiguity for both the user and the computer.
