I have several macros which trigger when a given USB device or WiFi network is connected or disconnected. Problem: I'd also like the appropriate macros to trigger if my MacBook boots with the same USB device or WiFi network connected, but the macros don't seem to run in that case.
Is there a trigger that will run if a given USB device or WiFi network is connected on boot?
You could add the login trigger, and an action at the beginning of the macro (such as an assertion, which cancels the macro if the conditions are not met) to determine whether or not the device or network in question is connected. See the example below.
-Chris
Execute on boot if USB device or WiFi network is connected.kmmacros (3.6 KB)
Great solution: implemented.
One question, though; any idea why the various "is connected"/"is disconnected" triggers are not applied on boot?
Glad it works for you! I honestly don’t know why they don’t execute on boot as I don’t use those triggers. My theory is, they are connected during the boot process, or some other time before the Keyboard Maestro Engine launches, which prevents it from detecting them. @peternlewis would know more.
Triggers are "changes in state", so it isn't "is this connected?" but rather "it has just been connected".
So I reckon @cdthomer's right -- on a reboot, the state-change to "connected" happens before the Engine is ready, so no trigger.
I can see the interpretation of "did it happen right now", but I'm sure lots of people have to do the workaround @cdthomer suggested. Perhaps fixing it would break existing code...
As noted, triggers detect state changes, not state.
So the macro triggers when the device is connected. That is, it triggers when it connects. It does not trigger if the device is already connected when Keyboard Maestro Engine launches (which could also be at a time other than Login/Boot, such as after upgrading Keyboard Maestro or if you launch the engine after login, or if you've manually quit the engine, or whatever).
Apologies, I obviously didn't explain things very well. There's nothing to fix and that isn't a workaround -- everything is as intended and, indeed, as it must be.
Think of it this way...
Triggers are point-in-time happenings the KM Engine gets told about. A key being pressed, a change in window title, an app becoming active, a device being connected, and so on[1]. These events are sent just once, when the thing happens.
Conditions are states the KM Engine asks about. Is a key down, is the active window titled "Fizzbuzz", is an app frontmost, is a device connected...? KME asks "How is this now?", getting the current state regardless of how long ago that became the current state.
On a reboot, the device is connected and that event propagated by the OS before the KM Engine is running -- the Engine never gets "told". So you need to use an "Assert" action which, as you can see, uses Conditions to determine current state -- and trigger the macro containing it in some other way, eg at login.
[1] -- I'd argue, from a position of complete ignorance, that even the time-based triggers work this way. KME doesn't sit there, kicking the back of the OS's seat, asking "Is it time yet? Is it time yet? Is it time yet?..." -- rather, KME does nothing until a cron-type scheduler tells it to.
