Connection of Thunderbolt drives does not trigger the USB Device trigger (unless it also holds a USB component, as some Thunderbolt docks do).
@peternlewis, are there technical possibilities to make a version of the USB Device trigger, that also triggers from attaching (or detaching) a strict Thunderbolt device? If so, could implementation of such a trigger, or changes to the existing USB Device trigger, make sense?
I guess I am not the only one having my external drive needs shifting more and more towards Thunderbolt, to take advantage of the awesome performance of now more affordable NVMe SSDs. So I can imagine I am not the only one seeing the usefulness of such a trigger
Usually the reason for feature omissions like that is that macOS does not have an event for the thing that you want to trigger. But in this case I asked an AI if there was an event in macOS for the attachment or detachment of a thunderbolt device. And it said there was (in the Disk Arbitration Framework.) Perhaps the reason it hasn't been implemented is because it's not unique to Thunderbolt, but also includes USB, therefore it's a bit redundant with the existing trigger.
In the meantime you can make your own macro for detecting Thunderbolt devices being added or removed using this command:
system_profiler SPThunderboltDataType
What you will need to do is read (ie, poll) the names of any attached Thunderbolt devices from the output of this command, intermittently (every 5 seconds perhaps?) and compare the names of the attached Thunderbolt devices to the names of attached Thunderbolt devices that existed during the last poll. I'm sure someone can help with this, but since I don't have any Thunderbolt devices, I'm not sure if I can write the code for you, but maybe if you show me the output from that command for the situation before and after you attach a Thunderbolt device, perhaps I can help then.
Thank you for chiming in on this subject! And you finding this 'Disk Arbitration Framework' brings hope that it might be possible to implement such a trigger.
Thank you also for your suggested workaround. Polling is an acceptable last resort means to solving such a task, but I was actually able to create a workaround here now not relying on it:
Setting up a folder trigger like how I've done below largely mimics the behavior we could expect from a combined USB/Thunderbolt drive trigger. This works well for my current use case, I believe my question to Peter still stands, though; as there are Thunderbolt devices that do not add a Volume, and thus cannot be triggered by this Folder trigger workaround.
I believe your polling for system_profiler SPThunderboltDataType workaround would work in these instances, though. But again, polling should be seen as somewhat of a last resort, and I believe any possible native trigger that comes with an alternative to high-frequency polling (for often useful tasks) could be seen as beneficial for the KM environment.
We agree. But since KM doesn't have a trigger for this, it is an appropriate last resort at this time. We shouldn't avoid polling just because there's a chance that a future version of KM may support what we need.
Not used Thunderbolt much, but I'm wondering what there is that can't be caught by other existing triggers anyway.
A Thunderbolt display connection will trigger "Display Layout Changed", storage "Mounted Volume". You don't generally care that a dock has been connected, it's the services the dock allows access to -- the two previous plus any dock-connected USB devices ("USB Device" trigger), maybe speakers ("Audio Output Changed").
Which leaves a dock or adapter network connection -- you might be able to do something with the %WirelessNetwork% trigger, but "Power Status Changed" would be a good proxy trigger for dock connection.
