[FEATURE REQUEST] Custom macros for printer states

[me25542]

Printer model

All, though most useful on GPIO compatible

Describe the feature

On the MK4(s) (and similar), XL, and Core1, there is an LED light bar under the screen to indicate printer status. This is useful for being able to quickly tell, at a glance, the state of the printer. However, especially with printers in an enclosure, these lights can be hard to see.
One possible advantage of the GPIO module sold for xBuddy-based printers is the possibility to control lights, etc. from the printer. A way to have a custom macro gcode file run whenever the printers state changes (printing, attention {filament change}, print done, standby, etc.) would improve the functionality of this product. Users could have an "Attention" light turn on when the printer's filament runs out during a print, or have "Printing" and "Print done" indicators.
In my case, I have a custom enclosure connected via I2C to my MK4S's xBuddy board. It would be great to be able to have the printer communicate to the enclosure when attention is needed.
As explained here, the functionality for macros is already somewhat present in the firmware.

Expected functionality

Similar to how GPIO macros function, users would be able to place gcode files of specific names in a "macros" folder in the root directory of the USB drive.
When the printers state changed (e.g. from standby to printing or printing to attention, etc., basically anything the status LEDs would automatically be triggered by), if the macro file was present on the USB drive, the printer would execute its contents.
Perhaps some commands could be disabled in these macro files, such as printing moves (G0 and G1) and temperature control, as they would need to be runnable during a print, or when the filament was being changed.

[CZDanol]

Hello, we could theoretically add macro support for print start/stop, but for example the "attention" macro wouldn't be realizable. Attention statuses typically happen during execution of some gcode and block further gcode processing, so injecting other gcodes during that would simply not work.

Regarding print start/stop, you can basically already achieve the same by using the custom start/end gcode in the slicer.

That being said, I have some ideas about possibly being able to "link" GPIO outputs directly to things like this (without going through the gcode)

[me25542]

Yes, start and stop are already possible with custom gcode from the slicer. The main benefit of macros would be performing certain actions on unpredictable events, such as a filament runout. Directly liking GPIO pins to these events could be a good solution.