It will be great if we have an option to automatically bring a device into DFU mode without having to perform the hardware button-pressing combination.
Opening & closing a serial terminal to the device at 14400 baud will put it into DFU mode. On the mac, I’m using stty to trigger DFU right before flashing:
stty -f /dev/cu.usbmodem141110 14400
Hope a cross-platform implementation of this can be Included as part of the local flashing build task in the next alpha release in 2019… 
That’s a wonderful idea, and thanks a lot for the tip on programatically forcing devices into DFU mode.
For Windows users: mode COMx 14400 will do the trick too.
The intent is to implement USB control requests which don’t require the devices to expose a USB CDC device for this to function - once these are in place a platform independent solution should be a no-brainer 
@chuank, excuse the ignorance, but will it always be usbmodem141110 on any Mac or is this just as “volatile” as the COMx on Windows?
@ScruffR, happily on macOS it's not volatile in the slightest. But it is unique, so other users will have to figure out which usbmodemXXXXXX to use. 99.9% of the time this is just a matter of hitting <TAB> to autocomplete. The only reason there would ever be a conflict here is if you have multiple serial port devices plugged in at once.
I've never understood why Windows makes it difficult/impossible to have a truly unique serial port ID, but it is what it is.
For me it's not really volatile for the same machine but between machines.
Once I've assigned a definet COM port number for that device (or group of devices - when I'm sure to have only one device at a time plugged, all Particle devices can share the same port number).
Yes on the mac it stays the same. In my above example I have a 4-port USB hub plugged in via a KVM, and even in this scenario, they enumerated themselves consistently to the point where I have stuck labels on my USB hub to remind me which is which.
Interestingly, the ports directly on the Mac itself are shorter (usbmodemXXXXX), and are not volatile as well.
However, the recent Mojave (or was it the one before?) update did assign slightly new port numbers (usbmodem1421 is now usbmodem14201). I'm guessing the macOS developers wanted to add a leading zero to the port enumeration. Why I do not know, but like @kubark42 said it's just a matter of hitting the <TAB> key twice in terminal to show a list of devices beginning with /dev/cu.usbmodem ...
Looking forward to the USB control request implementation, the less finger oil we can deposit on the hardware the better 
Is there a way to add the “stty -f /dev/cu.usbmodem141110 14400” line to the workbench “Particle:Flash local” command?
Hi Erich,
you can modified some target (e.g flash-user) from Makefile in .particle/toolchains/buildscripts/x.y.z/Makefile
I use “particle usb dfu && sleep 2” instead “stty -f /dev/cu.usbmodem141110 14400”
*** .particle/toolchains/buildscripts/1.5.1/Makefile_old 2019-06-25 10:39:47.869966515 +0200
--- .particle/toolchains/buildscripts/1.5.1/Makefile 2019-06-25 10:54:38.230963118 +0200
***************
*** 49,69 ****
--- 49,73 ----
# Compile and flash the user part
flash-user: preprocess
+ particle usb dfu && sleep 2
cd "${DEVICE_OS_PATH}/main" && make all program-dfu
$(call print_success,FLASHED SUCCESSFULLY)
# Compile and flash the user and system parts
flash-all: preprocess
+ particle usb dfu && sleep 2
cd "${DEVICE_OS_PATH}/modules" && make all program-dfu
$(call print_success,FLASHED SUCCESSFULLY)
# Compile and flash debug build
flash-debug: preprocess
+ particle usb dfu && sleep 2
cd "${DEVICE_OS_PATH}/main" && make all program-dfu MODULAR=n USE_SWD_JTAG=y DEBUG_BUILD=y
$(call print_notice,ONCE YOU ARE FINISHED DEBUGGING REMEMBER TO RUN `Particle: Flash application & DeviceOS (local)`)
$(call print_success,FLASHED SUCCESSFULLY)